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

Graham Klyne <> Mon, 14 May 2018 15:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD765124BAC for <>; Mon, 14 May 2018 08:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UMAEGU9-IqKi for <>; Mon, 14 May 2018 08:05:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BAC112421A for <>; Mon, 14 May 2018 08:05:42 -0700 (PDT)
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1fIF2j-0005hQ-r4; Mon, 14 May 2018 16:05:41 +0100
Received: from ([] helo=sasharissa.local) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1fIF2j-0000SH-Jk; Mon, 14 May 2018 16:05:41 +0100
Message-ID: <>
Date: Mon, 14 May 2018 16:05:39 +0100
From: Graham Klyne <>
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 <>,
CC: Graham Klyne <>
References: <> <>
In-Reply-To: <>
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: <>
Subject: Re: [Uri-review] Fwd: Registration request: did URI scheme
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

Conventional Web wisdom says that one shouldn't make assumptions about the 
nature of a resource from its URI (cf.  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 

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