Allow DID documents to be retrieved using any URI scheme

[msporny]

@gklyne wrote:

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?

[msporny]

What happens if the protocol you're using to resolve the identifier doesn't provide a content-type in return? We have a couple of DID Resolvers that might never return content-types (Bitcoin and Ethereum come to mind). I guess we could require that all Resolvers return content-types... but given the absence of a content-type, the front part of the URI "did" provides all the information you need to process the document.

[gklyne]

I had thought about this in the context of, e.g., a ftp: URI, and have only partial response.

The partial response is that certain DID methods or associated protocols might be associated specifically with the DID Document MIME type. Could that work for Etherium? It doesn't answer the ftp: case, but I guess the answer there could be: don't use those URIs for referencing DID documents?

I guess this this does suggest a specific role for the did: scheme type - any resource dereferenced using such a URI MUST return a representation of the appropriate MIME content-type (**). This would provide a way of ensuring awkward protocols can be handled, without insisting that DID documents can be dereferenced using only did: URIs.

I think that requiring a resource dereferenced using any URI scheme other than did: MUST NOT be a DID Document falls foul of the web architecture principle cited.

(**) I note this might seem contradictory with the next paragraph, but I think it's different to say that a URI scheme is associated with a specific content-type than to say that a client can assume something about the content-type from the URI scheme. The client should generally be able to use a URI as an opaque identifier/locator, but the dereferencing logic necessarily has to know something about the scheme in order to perform dereferencing.

[msporny]

Part of this is about MIME Types for DID Documents, and part of this is about what a DID Resolver returns.

[jandrieu]

Closing as we have adopted this issue in the new DIDWG repo.