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

Graham Klyne <gk@ninebynine.org> Mon, 14 May 2018 15:05 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 DD765124BAC for <uri-review@ietfa.amsl.com>; Mon, 14 May 2018 08:05:45 -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 UMAEGU9-IqKi for <uri-review@ietfa.amsl.com>; Mon, 14 May 2018 08:05:43 -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 0BAC112421A for <uri-review@ietf.org>; Mon, 14 May 2018 08:05:42 -0700 (PDT)
Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) 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 1fIF2j-0005hQ-r4; Mon, 14 May 2018 16:05:41 +0100
Received: from client0366.vpn.ox.ac.uk ([129.67.117.110] helo=sasharissa.local) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <gk@ninebynine.org>) id 1fIF2j-0000SH-Jk; Mon, 14 May 2018 16:05:41 +0100
Message-ID: <5AF9A5C3.7010307@ninebynine.org>
Date: Mon, 14 May 2018 16:05:39 +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/BPjnDv3w4iWfaDfYS1cr_QMELR0>
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:05:46 -0000

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

The nub of my comment is to focus the DID functionality specification through a 
MIME content-type rather than the URI scheme specification.  (Not attempting to 
claim the the did scheme serves no purpose.)

Your specification indicates a number of operations that need to be provided by 
a DID service (sections "DID Operations" and "DID Resolvers").  This is what I 
meant by the "DID service (abstract) functionality", which I am assuming is 
mediated by the DID document.  I.e. I assume the intended purpose of a DID URI 
is to access a DID document, then the rest of the DID handling is driven by that 
document.

Conventional Web wisdom says that one shouldn't make assumptions about the 
nature of a resource from its URI (cf. 
http://www.w3.org/TR/webarch/#uri-opacity).  Rather, a generally preferred 
approach is to dereference the URI and examine the content-type of what is 
returned.  So the answer to your question "How would developers know that this 
is a DID Scheme?" would be as you suggest: by the MIME type of the dereferenced 
value (and maybe also guided by the context in which the URI occurs).  Then it 
wouldn't matter what URI scheme was used - it's the response that would trigger 
DID document processing.

My suggestion of "data:" was offered as a thought experiment, not (necessarily) 
a practical solution.  If you ignore the problems of document size, are there 
any fundamental reasons that a data: URI couldn't work for representing a DID 
document?

I think the issue might be titled something like: "Allow DID documents to be 
retrieved using any URI scheme".  (I'm not sure why you think this might be a 
step backwards, but I could be missing something here.  Again, thinking about 
the notion of using a "data:" URI might flush out the issues here: what breaks?)

#g
--