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

Graham Klyne <gk@ninebynine.org> Mon, 14 May 2018 14:41 UTC

Return-Path: <gk@ninebynine.org>
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 4718712D94C for <uri-review@ietfa.amsl.com>; Mon, 14 May 2018 07:41:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 qRBfGLlT1SzW for <uri-review@ietfa.amsl.com>; Mon, 14 May 2018 07:41:50 -0700 (PDT)
Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0042D12D87F for <uri-review@ietf.org>; Mon, 14 May 2018 07:41:49 -0700 (PDT)
Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay16.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <gk@ninebynine.org>) id 1fIEfb-0007VB-sR; Mon, 14 May 2018 15:41:48 +0100
Received: from client0366.vpn.ox.ac.uk ([129.67.117.110] helo=sasharissa.local) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <gk@ninebynine.org>) id 1fIEfb-0005vR-GD; Mon, 14 May 2018 15:41:47 +0100
Message-ID: <5AF9A02A.20507@ninebynine.org>
Date: Mon, 14 May 2018 15:41:46 +0100
From: Graham Klyne <gk@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Manu Sporny <msporny@digitalbazaar.com>, uri-review@ietf.org
CC: Graham Klyne <gklyne@gmail.com>
References: <c7b3123a-f5db-d365-3bc7-31fd6d11eaa3@digitalbazaar.com> <cd5cb373-7bd8-e0c7-ba6d-a293562589f3@digitalbazaar.com>
In-Reply-To: <cd5cb373-7bd8-e0c7-ba6d-a293562589f3@digitalbazaar.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
X-Oxmail-Spam-Status: score=0.0 tests=none
X-Oxmail-Spam-Level: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/o2AJvt3vuS6CaMFYiSekGPXgOV4>
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: Mon, 14 May 2018 14:41:52 -0000

On 14/05/2018 14:57, Manu Sporny wrote:
>> >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 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
--