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

[Manu Sporny <[e-mail]>]

On 05/14/2018 10:41 AM, Graham Klyne wrote:
> 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.

Ah, I understand the question you were asking now. As a result, I've
documented some tribal knowledge that will hopefully enable you to see
that subversion would be difficult:

https://github.com/w3c-ccg/did-method-registry/pull/5/commits/6d3d215160089e7bb07218d94f7f762b3c5f9108#diff-eacf331f0ffc35d4b482f1d15a887d3bR126

Registering a new DID Method is designed to be a lightweight, public and
transparent, community-driven process. It's also advisory as software
implementers can choose to ignore the registry in the event that the
process is corrupted.

> 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!).

We had considered doing this a while ago. If I remember the conversation
correctly, DID Resolver implementers pushed back and would rather have
it in code than dereference a document to discover the DID methods. The
latter increases implementation burden, may create potential attack
vectors and it doesn't help the DID Resolver if there is no known way to
talk w/ the DID Method network.

We could always make the registry referenced above machine-readable, but
it's not clear it would be beneficial as a whole because:

* It increases implementation burden,
* It possibly creates a new attack vector (from a security standpoint -
  e.g. providing a document that contains spam/injection attacks),
* It enables DID Methods to censure other DID Methods by not listing
  them
* There are no "service access points" since these are decentralized
  networks. You connect to the node closest to you, or the one you trust
  the most, or some other metric that's important to you... and then
  bootstrap into the network from there.

This issue is being tracked here:

https://github.com/w3c-ccg/did-spec/issues/83

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches