Update `did:jwk` resolve test vectors

[mistermoe]

• Added README to describe inputs and outputs of did:jwk test vectors
• Removed didResolutionResult from output. Inclusion of this property left room to believe that the resolve implementations should contain a literal didResolutionResult property
• added didDocumentMetadata to output where missing. Note: on success, this will always be an empty object for did:jwk
• added didResolutionMetadata to output where missing. Note: on success, this will always be an empty object for did:jwk

[mistermoe]

great point @decentralgabe we should definitely do that. will update the PR to reflect

[frankhinek]

just a comment (non blocking) - I would recommend adding vectors for all the key type/algs we support. I've run into issues by assuming these work and realizing much later they in fact don't. Forcing compatibility with each support key type here will prevent that risk.

Great point. One thing to note is that we're not yet at a point of consistent support for crypto algs across the web5-* libs:

• web5-js and web5-kt support secp256k1
• web5-js and web5-kt haven't added support for secp256r1 (aka P-256) yet
• web5-js supports X25519 but web5-kt doesn't yet
• web5-rs is quickly evolving but I think it supports secp256k1, secp256r1, and Ed25519 but not yet X25519

We could always expand the did:jwk test vector to include what should be supported and not run the vector for all SDKs until their crypto packages are fully compliant.

[frankhinek]

Do we want to consider canonicalizing the public key before Base64URL encoding?

per the spec it is optional:

Canonicalization such as JCS is not required but may be helpful if the resulting DID isn't going to be stored in its serialized form.

[andresuribe87]

Do we want to consider canonicalizing the public key before Base64URL encoding?

per the spec it is optional:

Canonicalization such as JCS is not required but may be helpful if the resulting DID isn't going to be stored in its serialized form.

I thought that would be part of creation, but I believe this PR is only for resolution

[frankhinek]

Do we want to consider canonicalizing the public key before Base64URL encoding? per the spec it is optional:

Canonicalization such as JCS is not required but may be helpful if the resulting DID isn't going to be stored in its serialized form.

I thought that would be part of creation, but I believe this PR is only for resolution

It is but this PR's resolution results are based on not-canonicalizing the public key. As a result, if a web5-* implementation does canonicalization it will fail this vector.

[andresuribe87]

Do we want to consider canonicalizing the public key before Base64URL encoding? per the spec it is optional:

Canonicalization such as JCS is not required but may be helpful if the resulting DID isn't going to be stored in its serialized form.

I thought that would be part of creation, but I believe this PR is only for resolution

It is but this PR's resolution results are based on not-canonicalizing the public key. As a result, if a web5-* implementation does canonicalization it will fail this vector.

I'm a bit confused still, hoping you can help me understand.

Are you suggesting that resolution should canonicalize the encoded JWK before putting it in the did document? I.e. something like the following

resolve("did:jwk:<foo>").didDocument.verificationMethod[0].publicKeyJwk == canonicalize(decode64url("<foo>"))

[decentralgabe]

Canonicalization was removed from the latest draft, so I would advise against it https://github.com/quartzjer/did-jwk/pull/21/files

[frankhinek]

Canonicalization was removed from the latest draft, so I would advise against it https://github.com/quartzjer/did-jwk/pull/21/files

Excellent insight! Thanks @decentralgabe. Makes the decision easy.

[mistermoe]

updated vectors to include supported cryptographic algorithms - secp256k1 & Ed25519