Re: DID URI Scheme registration updating

Moving this discussion to public-did-wg as it isn't something that
should be member-only.

> On Fri, Jan 13, 2023 at 7:06 AM Orie Steele <orie@transmute.industries> wrote:
>> Possibly an unpopular opinion, but given how long it took to get the formal objections overruled and the fact that there was nearly a 3rd formal objection related to the confusion between the 2 representation, I might suggest not registering the media types...

I agree with Orie's suggestion to not register the DID media types
yet, though for slightly different reasons:

It's becoming increasingly apparent, as predicted by some in the WG,
that having two different JSON encodings for DID Documents where the
only difference between the two is the existence of a single field was
a mistake (as a number of us in the WG had warned when the decision
was made to create a new abstract data model for DID Documents).

At this point, implementers are knowingly implementing against the
guidance of the specification and placing @context in DID Documents
served as JSON. There is only one example of a DID Method (that I know
about), out of 161 registered methods, that knowingly uses the pure
JSON representation. At this point, we should catalog how many DID
Methods knowingly use the JSON-only (the one w/o @context)
representation, and make a decision based on that data.

All that to say, let's hold off on registering the media types because
it's quite possible that we're going to change some details there.

>> The media type that applies to both representation and is the default one that web servers respond with for .json... is application/json.

This is true for did:web, we don't know what it is for other DID
Methods w/o collecting more data. I suggest that we could do a quick
sample by seeing what the universal resolver returns for media types
from different DID Documents today.

>> It would be nice to not be required to use application/did+json and application/did+ld+json... Especially while we don't have any standardized did methods.

There's a sane way out of this, and that's to define what you should
do when what you're retrieving doesn't result in an
application/did+json and application/did+ld+json media type:

If the document is valid JSON, and you can find an @context that
contains a DID Core context as the first item in the array, then you
know you're dealing with a DID Document and can proceed even w/ a
media type such as "application/json" or "application/octet-stream".
If you can't find that, then its up to the application to do content
sniffing to see if it can proceed (but we leave that content sniffing
up to the application).

What we don't know yet are what valid file extensions for DID
Documents are. The spec currently says .didjson and .didjsonld (to
handle the cases where the files exist on filesystems AND to support
automatic media type results by putting these media types in the
default media types shipped with operating systems).

I believe the approach above would cover all of our bases, but would
require normative updates to DID Core, and until we have the
opportunity to do that, we shouldn't register the media types.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Friday, 13 January 2023 14:12:00 UTC