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

From: Manu Sporny <[email-masked]>
Date: Mon, 14 May 2018 09:57:45 -0400

Graham Klyne suggested that I send the following URI provisional
registration request to this mailing list for review. He also had
several informal comments that I'll respond to below.

BCC'ing the W3C Credentials Community Group that is developing the
specification associated with this URI Scheme.

On 05/14/2018 05:42 AM, Graham Klyne wrote:
> I've responded directly to you rather than track down a public
> forum, but please feel free to copy my comments to a suitable public
>  discussion forum.

Doing so on [email-masked]

> With my reviewer hat on I'd say this meets requirements for 
> provisional registration, but I do have some personal comments:
> 
> 1. (nit) You say "Conceptually, the relationship of this 
> specification and a DID method specification is similar to the 
> relationship of the IETF generic URI specification ([[RFC3986]]) and
>  a specific URI scheme" - to me, it feels more like the relationship
>  between the URN specification and a specific URN namespace ID.

Yes, you're correct, that's closer to the intent. Raised an issue to
make sure we update the language:

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

> The way you describe it, it sounds like a reinvention of URIs within 
> URIs, and begs the question: why not just use a separate URI scheme 
> for each distributed identifier method, with the DID specification 
> aiming to be something that can be included by reference into any new
> DID scheme?

This concern has been raised by Dan Connolly and is being tracked here
(although it's current state is CLOSED):

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

At present, the current reasons for this approach are:

* It may be helpful to developers to understand that all these
  sub-schemes are a part of the bigger DID scheme.
* We don't pollute the global URI scheme namespace (although, some would
  argue that is not a problem).
* Writing more general code that keys off of "did:" and sends those
  requests to a DID resolver is easier than keeping track of all of the
  schemes that should go to a DID resolver (simpler client code).

That is not to say that some of these arguments lack counter-arguments.
At present, the consensus in the group seems to be to keep the "did:"
prefix until a compelling technical concern compels the group to re-open
the issue.

That is to say, the group seems to think that more harm will be done by
removing the "did:" prefix than keeping it.

> 2. Hierarchical URI scheme?  Is the scheme intended to operate in  a 
> hierarchical fashion?

Well, it depends on what you mean by "hierarchical fashion"...

did: is at the top of the hierarchy.

did:METHOD: is next... then

did:METHOD:METHOD_ID

... where METHOD_ID may be hierarchical or not, depending on the
characteristics of the DID Method.

> RFC 3986 defines a (hierarchical) reference resolution procedure that
> operates on any URI containing "/" characters (which are part of your
> "did-path" syntax. Conventionally, this works in conjunction with an
> "authority" component that is introduced by "//", but your scheme
> proposal does not use "authority" syntax.  I'm not sure if there are
> any potential surprises in store if resolution is attempted with DID
> URIs.

Good point, now tracking your concern here:

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

We don't expect surprises, and I think we had this in mind when we
created the URI... and we specifically wanted to avoid the "//"
separator, but it's been a long time since we checked and the did URI
syntax has changed a bit since then.

> 3. DID fragments - the URI specification reserves the interpretation
>  of fragment ids to the MIME type of a representation of the 
> identified resource, and: "Fragment identifier semantics are 
> independent of the URI scheme and thus cannot be redefined by scheme
>  specifications." -- https://tools.ietf.org/html/rfc3986#section-3.5 
> I would suggest the fragment id interpretation maybe could be 
> associated with a MIME type defined for the DID document?

Ah, good point. I'll update the spec to address this point:

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

> 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 wonder if this aspect could be sidestepped by focusing more on the 
> DID document and DID service (abstract) functionality.  Then maybe an
> arbitrary URI scheme could be used to access the DID document? (As a
> "thought experiment", would it make sense to convey a DID document as
> a :"data:" URI?)

This I don't have a good answer for nor do I know how to write the issue.

I don't think a "data:" URI makes much sense as DID Documents can be
large... but I could see an HTTP-based URL subscheme that could map to a
DID Document.

Can you help me formulate how to explore this? What would we call the
issue? Doesn't "arbitrary URI scheme" take us a step backwards? How
would developers know that this is a DID Scheme? Perhaps by the MIME type?

> Notwithstanding my comments, this looks like an interesting piece of 
> work, and I wish it well :)

Thanks Graham, and also many thanks for your input. You'll be notified
as we process these issues in the CG.

-- 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

Subject: Registration request: did URI scheme
From: Manu Sporny <[email-masked]>
To: [email-masked]
Date: Sat, 12 May 2018 12:25:40 -0400

Per RFC 7595, Section 7.2. Registration Procedures - this is a request
to register a new provisional "did" URI Scheme in anticipation of
standardization track work that may occur later this year at W3C.

----------------

Scheme name: did
Status: Provisional

Applications/protocols that use this scheme name:

A "did" URI is used to express an identifier that is conformant to the
Decentralized Identifier[1] specification. The specification details how
identifiers conformant to the "did" URI Scheme can be implemented using
decentralized ledgers, decentralized hashtables, and other types of
decentralized networks.

This specification is currently under development in the W3C Credentials
Community Group and is expected to transition to the W3C standards track
at the end of 2018 or early 2019 calendar year.

Contact:

 Manu Sporny <[email-masked]>

Change controller:

 Manu Sporny <[email-masked]>
 W3C Credentials Community Group <[email-masked]>

References:

[1] https://w3c-ccg.github.io/did-spec/

----------------

-- 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

---

From: Graham Klyne <[email-masked]>
Date: Mon, 14 May 2018 15:41:46 +0100

> 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
--

---

From: Graham Klyne <[email-masked]>
Date: Mon, 14 May 2018 16:05:39 +0100

> would developers know that this is a DID Scheme? Perhaps by the MIME type?

The nub of my comment is to focus the DID functionality specification through a 
MIME content-type rather than the URI scheme specification.  (Not attempting to 
claim the the did scheme serves no purpose.)

Your specification indicates a number of operations that need to be provided by 
a DID service (sections "DID Operations" and "DID Resolvers").  This is what I 
meant by the "DID service (abstract) functionality", which I am assuming is 
mediated by the DID document.  I.e. I assume the intended purpose of a DID URI 
is to access a DID document, then the rest of the DID handling is driven by that 
document.

Conventional Web wisdom says that one shouldn't make assumptions about the 
nature of a resource from its URI (cf. 
http://www.w3.org/TR/webarch/#uri-opacity).  Rather, a generally preferred 
approach is to dereference the URI and examine the content-type of what is 
returned.  So the answer to your question "How would developers know that this 
is a DID Scheme?" would be as you suggest: by the MIME type of the dereferenced 
value (and maybe also guided by the context in which the URI occurs).  Then it 
wouldn't matter what URI scheme was used - it's the response that would trigger 
DID document processing.

My suggestion of "data:" was offered as a thought experiment, not (necessarily) 
a practical solution.  If you ignore the problems of document size, are there 
any fundamental reasons that a data: URI couldn't work for representing a DID 
document?

I think the issue might be titled something like: "Allow DID documents to be 
retrieved using any URI scheme".  (I'm not sure why you think this might be a 
step backwards, but I could be missing something here.  Again, thinking about 
the notion of using a "data:" URI might flush out the issues here: what breaks?)

#g
--

---

From: Manu Sporny <[email-masked]>
Date: Mon, 14 May 2018 11:22:45 -0400

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

---

From: Manu Sporny <[email-masked]>
Date: Mon, 14 May 2018 11:33:29 -0400

On 05/14/2018 11:05 AM, Graham Klyne wrote:
> I think the issue might be titled something like: "Allow DID 
> documents to be retrieved using any URI scheme".

Ok, I understand the point you're making now. I've created a new issue
to track this here:

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

... and will track the discussion there.

> Rather, a generally preferred approach is to dereference the URI and
>  examine the content-type of what is returned.

What happens if the protocol you're using to resolve the identifier
doesn't provide a content-type in return? We have a couple of DID
Resolvers that might never return content-types (Bitcoin and Ethereum
come to mind). I guess we could require that all Resolvers return
content-types... but given the absence of a content-type, the front part
of the URI "did" provides all the information you need to process the
document.

-- manu

---

From: Melvin Carvalho <[email-masked]>
Date: Tue, 15 May 2018 10:41:39 +0200

On 14 May 2018 at 15:57, Manu Sporny <[email-masked]> wrote:

> .... where METHOD_ID may be hierarchical or not, depending on the
> .... so to say that it's centralized is problematic. For "truly

(nit)

Just a note on this.  Blockchains, as popularized by Satoshi's original
paper on bitcoin, are not 100% decentralized.  In fact, the term does not
appear once in that paper.  The term "distributed" occurs quite
frequently.

In truth nothing is truly decentralized.  For example, any registry is a
source of centralization.  Drilling down further so is any specification,
and assumptions on which they are built.

Distributed may be a more useful term in technical specifications, but
decentralized tends to be more popular in the space this spec operates.

This is really just an observation.  No action is expected.

> ---------- Forwarded message ----------
> Cc:
> Bcc:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>
>

---

From: Manu Sporny <[email-masked]>
Date: Tue, 15 May 2018 09:35:35 -0400

On 05/15/2018 04:41 AM, Melvin Carvalho wrote:
> Distributed may be a more useful term in technical specifications,
> but decentralized tends to be more popular in the space this spec
> operates.

+1, good point, Melvin.

I don't know how to square that particular circle either. Please let us
know if you have a suggestion that would 1) resonate with folks not
deeply in tune with the nuances here, and 2) be more accurate than what
we have right now.

-- manu