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

[Graham Klyne <[e-mail]>]

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