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

Melvin Carvalho <melvincarvalho@gmail.com> Tue, 15 May 2018 08:41 UTC

Return-Path: <melvincarvalho@gmail.com>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B17F12D77A for <uri-review@ietfa.amsl.com>; Tue, 15 May 2018 01:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-SZHwl4cUpN for <uri-review@ietfa.amsl.com>; Tue, 15 May 2018 01:41:41 -0700 (PDT)
Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F7B120721 for <uri-review@ietf.org>; Tue, 15 May 2018 01:41:40 -0700 (PDT)
Received: by mail-it0-x244.google.com with SMTP id n202-v6so17178338ita.1 for <uri-review@ietf.org>; Tue, 15 May 2018 01:41:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vto3GC6wJ6VbvnJCc3lm0Cvhn2DSXg2Frcz6pvDRP08=; b=P8qHbYRAOgOypQ850jrxVjVmpgUG1Xywl9bSLSPabtCoPqcIoLqqh+m25mqLY2lnwS GuzuSg8ZIBz89+MqEnSuwc2SioWlKXLybIf+GPRZDNw4s2VCk7Nc6DuniHX4hTN/lD6N 4Dv0WaEB4IBTZXFtbxQhI1AHadT6RodQzBdiatFPUG+Qno0+eTMR7Ylx43KFT5QbHqxQ 4p/2ag0CLS9Gmd6Hj+c3m/5/sbTj820yVJuJDjFb4xL40vBBkqcBocSCihbHmfAw1B1k jKHw6oflOagwzMFk9VxXUfymIoUFmF12PN/YdUrVzUYj7yTIkZsDP7fXSWQRbE6tjcoT Zu/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vto3GC6wJ6VbvnJCc3lm0Cvhn2DSXg2Frcz6pvDRP08=; b=HLIfWB9cNtOMo9uEgMoTydteDDaZWtPKPAi9sy/fZnAFisju3Ntow75lu+b6+RLEXo Mo4Yy9Dl9bW/LchFUuaPQIjB7ISgP5Pz5JecSgatUiwo97mJuOr1qTbkObYmHmtaJzBR zG1qewxfdOf8TCbXsPHGKjoZl0IbRWulOS59Swjf6paXLaSWEawWXoTu+Ugf+6dAf2uI 00SjkXtUCbO/VBJh9SUHR/vPXuKfSypVi46w7SmlmRK3t7JLsZNOGqNZfVKVnCiQssVK LF1p1OqNJWrqPMUpng5aKEz86dc/gVeosvkMvmif8h6l6lSTLvrBPYLbxwL7gXhNh3wI kicg==
X-Gm-Message-State: ALKqPweQ5mAkfErWTtLJpk+2BbDvDu0RRaltwCmUDJt4utrSH94BfrKs fVSIYjy0PNV7pFa06mYwdgCg1kubYRc4DV2iilE=
X-Google-Smtp-Source: AB8JxZo9DtuoG2s+dzDAZILhxm2TLJOaqKvbZebUVGsXaHY0UOspJhcqPwJ55OmUFQNlowUiHGn7nlvjUMPEETEfgHs=
X-Received: by 2002:a6b:da04:: with SMTP id x4-v6mr14523817iob.19.1526373700119; Tue, 15 May 2018 01:41:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.192.173.195 with HTTP; Tue, 15 May 2018 01:41:39 -0700 (PDT)
In-Reply-To: <cd5cb373-7bd8-e0c7-ba6d-a293562589f3@digitalbazaar.com>
References: <c7b3123a-f5db-d365-3bc7-31fd6d11eaa3@digitalbazaar.com> <cd5cb373-7bd8-e0c7-ba6d-a293562589f3@digitalbazaar.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tue, 15 May 2018 10:41:39 +0200
Message-ID: <CAKaEYhKtBx6TD-TuX3kxH4mWV_K1t_KM6FhKMxt5mngP5qTadg@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: uri-review@ietf.org, Graham Klyne <gklyne@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000030b30d056c3a929e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/cNdP5__RvSk9nCe5PaWbfimd90g>
Subject: Re: [Uri-review] Fwd: Registration request: did URI scheme
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 May 2018 08:41:44 -0000

On 14 May 2018 at 15:57, Manu Sporny <msporny@digitalbazaar.com>; 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 uri-review@ietf.org
>
> > 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 <msporny@digitalbazaar.com>;
> To: iana@iana.org
> 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 <msporny@digitalbazaar.com>;
>
> Change controller:
>
>  Manu Sporny <msporny@digitalbazaar.com>;
>  W3C Credentials Community Group <public-credentials@w3.org>;
>
> 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
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>
>