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

Manu Sporny <msporny@digitalbazaar.com> Mon, 14 May 2018 15:22 UTC

Return-Path: <msporny@digitalbazaar.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 EE1FF126BF7 for <uri-review@ietfa.amsl.com>; Mon, 14 May 2018 08:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 pZkeSghO8lGJ for <uri-review@ietfa.amsl.com>; Mon, 14 May 2018 08:22:49 -0700 (PDT)
Received: from mail.digitalbazaar.com (mail.digitalbazaar.com [96.89.14.193]) (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 10B1912421A for <uri-review@ietf.org>; Mon, 14 May 2018 08:22:48 -0700 (PDT)
Received: from [192.168.0.149] by mail.digitalbazaar.com with esmtp (Exim 4.86) (envelope-from <msporny@digitalbazaar.com>) id 1fIFJF-0004Va-SQ; Mon, 14 May 2018 11:22:45 -0400
To: Graham Klyne <gk@ninebynine.org>, 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> <5AF9A02A.20507@ninebynine.org>
From: Manu Sporny <msporny@digitalbazaar.com>
X-Opacus-Archived: none
Message-ID: <18153daf-97ed-37e3-7313-209e3d849f99@digitalbazaar.com>
Date: Mon, 14 May 2018 11:22:45 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <5AF9A02A.20507@ninebynine.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-CA
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 192.168.0.149
X-SA-Exim-Mail-From: msporny@digitalbazaar.com
X-SA-Exim-Scanned: No (on mail.digitalbazaar.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/xd_0Z-b-UkHcONsAdKrdXFea42U>
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 15:22:51 -0000

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

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