Re: Proposed work item: did:key DID Method

I've been working on an experimental matrix parameter that can do this:

|curl -X GET
"https://uniresolver.io/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw;transform-keys=jwk"
||curl -X GET
"https://uniresolver.io/1.0/identifiers/did:btcr:xz35-jznz-q6mr-7q6;transform-keys=jwk"
||curl -X GET
"https://uniresolver.io/1.0/identifiers/did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6;transform-keys=jwk"|

See here for more info:
https://hackmd.io/XmL-Bjh5TdqV4fj6nwdPEQ

Note: I'm not actually proposing to introduce this matrix parameter at
this point. It may actually be better to do something like this with a
resolver input option, rather than a DID URL matrix parameter. Just
wanted to add this as input to the discussion.

Markus

(Also posted this here
<https://github.com/w3c/did-core/issues/67#issuecomment-557970745>)

On 11/24/19 2:00 AM, Manu Sporny wrote:
> On 11/23/19 11:57 AM, Orie Steele wrote:
>>> I had a question before the spec was available, regarding
>>> multibase as the only encoding format for the DID.
>>>
>>> Is it true that there will always only be a single DID per public 
>>> key?
> If I understand your question, yes. The way I'm interpreting your
> question is "Will there always be a single public key per did:key
> identifier?"... yes, but it could have more than one representation...
> more below.
>
>>> I was hoping that this work could be extended to support a DID 
>>> Document representation for cryptographic key types, as well as 
>>> formats, such as PEM / JWK, secp256k1, RSA, etc... but it would be 
>>> the case that the same key encoded in different ways would result 
>>> in different documents.
> Well, remember that because of the way we encode keys in the DID
> Document, that you can have multiple key representations per key. This
> is completely valid (by design):
>
> {
>   "@context": ["https://www.w3.org/ns/did/v1",
>   "id": "did:example:123456789abcdefghi",
>   "authorization": [{
>     "id": "did:example:123456789abcdefghi#keys-2",
>     "type": "Ed25519VerificationKey2018",
>     "controller": "did:example:pqrstuvwxyz0987654321",
>     "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV",
>     "publicKeyJwk": {... JWK GOES HERE ...}
>   }],
>   ...
> }
>
> ... whether the DID WG decides to allow that is still up in the air. An
> alternative is that you could pass in a flag to a library to give you
> the version of the DID Document that you'd like to see (all keys in JWK
> format, or all keys in native non-JWK format).
>
> All options are currently open to us, and yes, I do think what you're
> suggesting would be an important consideration for the spec. We should
> figure out a way to enable what I think you are suggesting.
>
> -- manu
>