Re: [Uri-review] Fwd: Registration request: did URI scheme

[Graham Klyne <[e-mail]>]

On 14/05/2018 14:57, Manu Sporny wrote:
>> >4. Is this scheme truly decentralized?  It occurs to me that the DID
>> >method registry serves a comparable purpose to DNS in the delegation
>> >of authority when resolving DIDs.  (e.g. consider the claims "DIDs
>> >are fully under the control of the DID subject, independent from any
>> >centralized registry", "In a decentralized identity system, entities
>> >are free to use any shared root of trust.", etc.  It seems to me
>> >there's no escaping the DID registry?)
> Note that in the common case that the "DID Registry" is implemented
> using decentralized ledger technologies. That is, they are Blockchains
> that are not "owned" in the traditional sense. These blockchains do have
> governance structures, where certain people are responsible for certain
> aspects of the global public utility, for example:
>
> https://veres.one/network/
>
> ... so to say that it's centralized is problematic. For "truly
> decentralized", you'd have to define what you mean by that. Many of
> these DID Ledger systems are "as decentralized as we know how to make
> them today"... and they're certainly more decentralized than DNS (but
> are NOT a replacement for DNS and are complementary to that system).
>

I think I wasn't very clear.  I wasn't referring to the decentralized registry 
referred to by the DID method, but to the did method registry itself (i.e. the 
information that currently appears at 
https://w3c-ccg.github.io/did-method-registry, which in turn is referenced from 
the "Registry" section of https://w3c-ccg.github.io/did-spec/.

In any case, I don't think it's a big deal (as you say: "as decentralized as we 
know how to make them today"), as long as there is no way to subvert the path 
from method name to distributed id service.

A thought: maybe every DID service should have an associated DID document, which 
among other things connects the method name to its service access point(s), 
complete with cryptographic verification content.  This document could in turn 
be served by any and/or all DID services.  In this respect, the various DID 
services might function like multiple DNS root servers, and starting from any 
one of them, the others are discoverable.  This is not a thought-out proposal, 
and is probably shot through with holes, but I offer it for consideration (or not!).

#g
--