Closed OR13 closed 3 years ago
I am with Orie on this: devs don't care about the irrelevant nerd-differences between these curly brace objects, and we should make it as easy for them not to care as humanly possible.
I agree with every word @OR13 wrote above, but disagree with his conclusion and recommendation that application/did+json
and application/did+ld+json
representations of DID documents should both be JSON-LD.
In order to get the PR approved, I had to remove this paragraph:
<p>
If a DID Method supports both <code>application/did+json</code> and
<code>application/did+ld+json</code>, it is recommended that they both
include an <code>@context</code> and that both be capable of
supporting linked data proofs, document loaders and related JSON-LD tooling.
</p>
As discussed on: https://github.com/w3c/did-imp-guide/pull/3
There are proposals on both sides of the statement:
"DID Method Implementers SHOULD strive to make representations interoperable."
In order to make concrete recommendations to implementers, we must consider did resolution and did dereferencing "by representation" in addition to "by did method".
Software implementations that conflate dereferencing with resolution or that assume all representations handle dereferencing the same way lead to developer burden and tooling requirements, which we can encourage developers to forward to consumers or internalize in their did method construction.... hence recommendations should be made in the implementation guide for folks who intend to support
did+json
anddid+ld+json
vs ONLYdid+json
or ONLYdid+ld+json
.This is to track ongoing lack of consensus regarding
did+json
anddid+ld+json
interoperability guidance for did method implementers.