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

The implicit DID document design is what we use in did-tezos and did-doge too!

http://did-tezos.spruceid.com/
http://did-doge.spruceid.com/

There is a privacy disadvantage for this in did-doge though...you are effectively outing your doge address as DID-capable if you do decide to create on-chain updates, but the privacy is better than did-btcr if you decide to not to update the DID document. did-btcr, while requiring an initiation transaction, is better for privacy in the sense that its update transactions can be created so they're though to distinguish from normal btc transactions, which could be hidden enough in the herd privacy of the bitcoin blockchain, but possibly still vulnerable to statistical discovery attacks.

On Thu, Mar 18, 2021, at 10:35 PM, Christopher Allen wrote:
> 
> 
> 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
>>