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

[Manu Sporny <[e-mail]>]

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 [e-mail]

> 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

--- Begin Message ---

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 <[e-mail]>

Change controller:

 Manu Sporny <[e-mail]>
 W3C Credentials Community Group <[e-mail]>

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

--- End Message ---