W3C home > Mailing lists > Public > public-credentials@w3.org > March 2021

Re: How to verify the did:key document is authorized by the private key holder ... JWS?

From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Thu, 18 Mar 2021 19:35:59 -0700
Message-ID: <CACrqygAjM10HtMKzT2kAX2d0p+6Q7w1Dc11t-JtaecOhddLA7A@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: public-credentials@w3.org
On Thu, Mar 18, 2021 at 5:58 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> Correct. did:key DID Documents are purely generative things... if you know
> the
> did:key value, you have everything you need to:
>
> 1) Generate the DID Document, and
> 2) Verify that any signature created by that did:key was
>    generated by the controller of that key.
>
> In other words, this is a cryptographic public key:
>
> did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH
>
> and that's all you need to verify a signature. It's the simplest and
> easiest
> to use type a DID.
>
> As a related aside... all off-ledger Veres One DIDs share this same
> property
> (and are effectively did:keys).


I think many people do not understand this about many did methods - that
there is no did: document, it is purely derived by the method. did:key is a
good example — you CAN’T have anything but a derived did document. Nothing
can be added.

In btcr 0.1 we called this the “implicit” did document, which doesn’t need
to be signed as it comes from the blockchain data itself. It is sufficient
to prove simple VCs like did:key is.

But btcr 0.1 also allows for an optionally “extended” did document that
adds (but not override) the implicit. But this extended did document has to
be separately provable (signed in case of BTCR 0.1) before being merged
with the implicit.

I’m thinking more about this in regards to did:onion, where the bare onion
address itself gives you an implicit did document because it has a public
key in it that is sufficient to prove a vc. However, you can also go to the
onion website (which BTW, accessing successfully proves they have control
of the private key) to get an extended did document with more keys in it.
And because it comes from the active onion address, this extended did:
document does not need to be signed!

It could be we need to make this distinction about implicit and extended
did: documents more clear in general, not just defined these two did
methods.

— Christopher Allen

>
Received on Friday, 19 March 2021 02:36:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 19 March 2021 02:36:24 UTC