add interop with jwk and key #56
Conversation
|
cc: @msporny @quartzjer |
| 1. Verify the `did:key` value begins with the prefix `z6Mk`. | ||
| 2. Decode the [[ref:Ed25519]] key in the `did:key` identifier, and re-encode it using [[ref:z-base-32]]. | ||
| 3. Expand the `did:key` using the [process outlined in the did:key spec](https://w3c-ccg.github.io/did-method-key/#read), | ||
| with `options.publicKeyFormat` set to `JsonWebKey2020`. | ||
| 4. Optionally, amend the [[ref:DID Document]] with additional properties (Verification Methods, Services, etc.). | ||
| 5. Follow steps 3 onward in as outlined in the [create section of the spec](../index.html#create), using the identifier from step 2. |
There was a problem hiding this comment.
We'll want to modify this slightly to:
- Use the different prefix for a
did:dhtEd25519 key (that just makes sure we bind the Ed25519 key to a resolution network --did:dht). We can register the Multikey prefix pretty quickly to do that. - did:key can take an argument and you can get your keys back as either Multikey or JsonWebKey, so no need to be specific here.
JsonWebKey2020is definitely out of date and is not going to survive standardization. We should be usingJsonWebKeyanywhere that we were usingJsonWebKey2020before. - If you wanted the
did:keyto be encoded in z-base-32, we could do that... though I don't think there's a Multibase encoding for that yet? If there is interest there, we could look into that (this is one of the reasons Multibase exists -- because the base-encoding you use is largely driven by what the protocols are optimized for -- humans, ASCII, glyph compression, or some combination of the previous).
None of the feedback above is blocking for now, but wanted to just make sure it was registered as feedback so we can adjust going forward.
There was a problem hiding this comment.
agree with 1 + 2 will update when the did:key spec is updated ... (#57)
for 3 I think this is a good idea as it reduces the need to re-encode/decode here for resolvers...but that raises a question. Is it preferable to reduce the impact on existing implementations (i.e. not need to support z-base-32) and just keep the translation a function of resolvers/registrars?
There was a problem hiding this comment.
re: 3 -- yes, it's a good question. I haven't had enough time to think about it in detail... my gut tells me to not add the z-base-32 requirement for did:key implementations... but then again, it's a fairly trivial piece of code to write (it's just general base-encoding w/ a specific base-32 alphabet). Most implementations should just treat the did:key value as text until it's handed to a resolver/registrar/verifier... someone will have to do a deeper analysis on the benefits/drawbacks.
fix #36