w3c-ccg / did-key-test-suite Goto Github PK

I really like the idea of the enableExperimentalPublicKeyTypes resolution option and invalidPublicKeyType error. We have also defined and implemented something very similar:

• The option overrideVerificationMethodTypePolicy
• The error notAllowedVerificationMethodType

See https://github.com/decentralized-identity/did-spec-extensions/blob/main/error-codes/not-allowed-verification-method-type.md.

This is one of several security-related policies that a resolver can enforce, see here for more: https://github.com/decentralized-identity/did-spec-extensions

I think the only difference is that in our case, individual verification method types (such as Ed25519VerificationKey2018) can be allowed/denied by a resolver, whereas in your case your option is about a group of types (such as "experimental"). It should be possible to harmonize both into a single option.

The did key spec has no normative statements: https://w3c-ccg.github.io/did-method-key/

We need more tests for did key based off of underlying specifications.

Replace the previous mention of implementations and instead link to implementations.

I see several tests of features that apply to DID Resolution in general, not just the did:key method. I think those should be moved into the DID Resolution test suite, and/or be re-used consistently across future DID method test suites as well.

Here's a list where this might be the case:

1. The scheme MUST be the value did
2. MUST raise invalidDid error if scheme is not did
3. If "didDocument.id" is not a valid DID, an invalidDid error MUST be raised
4. If verificationMethod.id is not a valid DID URL, an invalidDidUrl error MUST be raised.
5. For Signature Verification Methods, if options.enableExperimentalPublicKeyTypes is set to false and publicKeyFormat is not Multikey, JsonWebKey2020, or Ed25519VerificationKey2020, an invalidPublicKeyType error MUST be raised.
6. For Encryption Verification Methods, if options.enableExperimentalPublicKeyTypes is set to false and publicKeyFormat is not Multikey, JsonWebKey2020, or X25519KeyAgreementKey2020, an invalidPublicKeyType error MUST be raised.
7. If verificationMethod.controller is not a valid DID, an invalidDid error MUST be raised.

For 5. and 6., don't test this yet until #23 is resolved.

Add the didResolvers to this package: https://github.com/w3c-ccg/vc-api-test-suite-implementations
then remove the /implementations dir and use implementations in tests.

One of the tests is currently:

MUST raise invalidDid error if method is not key

Per the discussion we recently had in DID Resolution (w3c-ccg/did-resolution#74 and w3c-ccg/did-resolution#72), I believe that error should be methodNotSupported instead of invalidDid.

requite-dir is a commonjs module that has issues with es6 modules. We should figure out a way or replacing it in the future.

I see that one of the tests is:

MUST raise invalidDid if the multibaseValue does not begin with the letter z.

I have been assuming so far that the invalidDid error would be returned only if the DID doesn't conform to the generic DID Core syntax. So if you try to resolve did:key:12345, the error would actually be notFound, since the DID does conform to the generic DID Core syntax, but the method-specific ID "12345" doesn't exist within the did:key method.

But maybe my assumption was wrong. I also understand the rationale that invalidDid would cover not only the generic DID Core syntax, but also method-specific syntax requirements (starting with z, in this case). So, just opening this issue to talk about it. We could define this in more detail in the DID Resolution spec: https://w3c-ccg.github.io/did-resolution/#errors