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

[Melvin Carvalho <[e-mail]>]

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

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

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


>
> > 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
>
>
> ---------- Forwarded message ----------
> From: Manu Sporny <[e-mail]>
> To: [e-mail]
> Cc:
> Bcc:
> Date: Sat, 12 May 2018 12:25:40 -0400
> Subject: Registration request: did URI scheme
> 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
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>
>