feat(vc): signature suite registration - #2887
Conversation
Signed-off-by: rmlearney-digicatapult <robert.learney@digicatapult.org.uk>
Signed-off-by: rmlearney-digicatapult <robert.learney@digicatapult.org.uk>
Signed-off-by: rmlearney-digicatapult <robert.learney@digicatapult.org.uk>
|
📄 Knowledge reviewDosu skipped reviewing this PR because your organization has used its
|
|
|
||
| const LinkedDataSignature = suites.LinkedDataSignature | ||
|
|
||
| export const SignatureSuiteToken = Symbol('SignatureSuiteToken') |
There was a problem hiding this comment.
If we want to make this a non-breaking addition, we should keep the token for now and still inject them (external registration outside of core repo). We can mark it as deprecated, and remove it in 0.8
There was a problem hiding this comment.
Done :)
| verificationMethodTypes: [VERIFICATION_METHOD_TYPE_ED25519_VERIFICATION_KEY_2020], | ||
| supportedPublicJwkTypes: [Ed25519PublicJwk], | ||
| } satisfies SuiteInfo) | ||
| const signatureSuiteRegistry = dependencyManager.resolve(SignatureSuiteRegistry) |
There was a problem hiding this comment.
I think we need to register this first as a singleton before we can register it. Since we always use agent scoped registraiotn ,we don't use @singleton from tsyringe, but then we first need to registerSingleton on the dependency manager.
So it would need to happen in the base agent then as we need to make sure it runs before any code calls resolve on the SignatureSuiteRegistry. This is the reason it has this kinda hacky approach.
There was a problem hiding this comment.
I think we're safe to register inside W3cCredentialsModule and not on the base agent.
Registration order on the base agent is:
- EventEmitter
- JwsService
- StorageVersionRepository
- StorageUpdateService
- AgentConfig
- AgentDependencies
- Stop$
- Filesystem
Then default modules:
- dcql <- resolves
SignatureSuiteRegistrylazily from request-handling method, not duringDcqlModule.register() - genericRecords
- dids
- w3cCredentials <- SignatureSuiteRegistry singleton registered here and Ed25519 suites populated
Unless a user passes an alternative w3cCredentials overriding the default and forgets to call registerSingleton(SignatureSuiteRegistry) we should be safe.
Signed-off-by: rmlearney-digicatapult <robert.learney@digicatapult.org.uk>
|
Conformance test issue #2888 |
|
@TimoGlastra the goal with this is to allow signature suites to pass their compatible @context at registration, so that JSON-LD credential composition can easily match @context to pass the strict parsing requirement. I'm current facing issues with strict mode because context for Eddsa25519-2020 is not compatible with the DID Core context (which was finalised in 2018 and only contains the context for the Eddsa25519-2018 suite) |
Signed-off-by: rmlearney-digicatapult <robert.learney@digicatapult.org.uk>
Signed-off-by: rmlearney-digicatapult <robert.learney@digicatapult.org.uk>
270f8d1 to
97364c1
Compare
Signed-off-by: rmlearney-digicatapult <robert.learney@digicatapult.org.uk>
447ac85 to
78094a9
Compare
2 participants
Address
TODOinSignatureSuiteRegistry.tsby registeringSignatureSuitesRegistryonW3cCredentialsModule.tsand constructor-style registration of both signature suites within the registry.Backwards-compatible token registration with deprecation marker for removal in
v0.8.Necessary change for simplifying final fix for
json-ldstrict parsing requirements when usinged25519-2020suite (next PR after merge).Required updates throughout multiple test suites, mostly basic changes.