`application/did+ld+json` should be revisited

[TallTed]

_Originally posted by @TallTed in https://github.com/w3c/did-resolution/pull/88#discussion_r1747431386_

Multiple + have been disallowed in IETF/IANA media types.

application/ld+json might be sufficient.

This needs to be applied throughout did-resolution as well as did-core.

[pchampin]

This was discussed during the #did meeting on 19 September 2024.

View the transcript

w3c/did-core#863 application/did+ld+json should be revisited

manu: Strategy to discuss the big rocks first. Class 3, then 2 then 1
… 863 is about the media type. In did-core we said application/did+ld+json
… open question what the media type should be. Cannot have did+ld+json
… some implementors want to use json serialization others jsonld
… Looking at potentially 2 media types
… we could try application/did as the media type
… with the new controller document which supports context injection. We can parse as json if it doesnt have a json if it does have a @context you can parse as jsonld
… if you want to parse as jsonld but it doesn't have a context you can inject one

<ivan> Controller document context injection section

manu: Strongly suggesting we just do application/did to keep it simple
… Need to be clear we are not allowing two different processing models
… thoughts concerns about application/did

<bigbluehat> +1 to `application/did`

<dmitriz> my vote would be for application/did+json. To enable the eventual (and inevitable?) application/did+cbor

markus_sabadello: What does this mean for the abstract data model, if the controller document allows context injection

<Zakim> manu, you wanted to go into polyglot response if it becomes an issue.

manu: Still have the abstract data model. You would still be able to use JSON. Or you can use jsonld. Fundamentally these are interpretted the same. The meaning is the same

markus_sabadello: I want to do this. Seems like we don't need the different representations anymore.

dmitriz: In JSON vs JSONLD we loose track of other things like CBOR and YAML. My vote is for application/did+json
… implementations need to know how to parse the document

ivan: Understand dmitriz opinion. But, the VCWG has decided to use application/vc for verifiable credentials

<Zakim> manu, you wanted to note that we could have CBOR in the future. and to ask if it's "application/json", then what do we do for JSON-LD?

manu: Not closed the door on CBOR or YAML. Could have did+cbor or did+yaml. But what do we do about jsonld. We could say application/did is jsonld
… Or we would have to get a new suffix through the jsonld working group
… Markus, the reason we would have different representations is to support CBOR and YAML
… One more option, for JSONLD DID documents jsonld/we could use application/ld+json/jsonld

decentralgabe: encourage people to consider discussion on an issue

decentralgabe: time for one or two more

---

[pchampin]

This was discussed during the did meeting on 10 October 2024.

View the transcript

w3c/did-core#863

manu: something to think about. Issue 863 about our media type
… We should reconsider application/vc and application/vp
… We had a conversation with TAG, when you are using JSON-LD and it could also be JSON, we'd feel better if the spec says ANY interpretation cannot be different between the two. Any difference is either a specification bug or an implementation bug.
… This feels like it addresses some outstanding confusion.
… In which case we can just be application/did
… but fundamentally, no software system should interpret one over the other.
… I'll bring this up again the next time we discuss the issue

burn: Any other items?

burn: Thanks everyone

---

[pchampin]

This was discussed during the did meeting on 17 October 2024.

View the transcript

w3c/did-core#863

manu: during TPAC, the TAG suggested to add some text in the VC documents about JSON-LD,
… but that also applies to the DID WG.
… The text is to explain (even more) clearly that downloading JSON-LD contexts from the web is not necessary for complying with the standard.
… And that processing a VC or DID document as JSON is equivalent to processing it as JSON-LD.
… The proposal was to add some text saying "any difference in the behaviour between JSON and JSON-LD would be a bug of this spec"
… We have some text to this effect in VC.
… In the Controller Document spec, we got to a point where there is no difference between JSON and JSON-LD processing.
… As a side effect, we can have a single media-type.

<ivan> VC's version on the JSON(-LD) that Manu was talking about:

manu: We never picked a media-type because of 5-year long debate at IETF about multiple suffixes in media-types.
… The proposal to this group is to do the same for did: would people be happy with a media-type like application/did ?
… We haven't heard any pushback so far. Should be take a resolution?

markus_sabadello: A CBOR representation would have a different media type, but there would be no difference between JSON and JSON-LD?

manu: correct

markus_sabadello: I think that would be fine, sounds like a good idea, one thing I'm wondering, separate media type for DID Resolution result.

markus_sabadello: Separate media type for that, I think that's fine, sounds like a separate question we can discuss separately, but don't think there would be any implications/problems, sounds good.

manu: I agree, we should have a separate media-type for DID Resolution results.
… Another thing we did in VC is tell people "use the most accurate media-type when you serve these documents".
… Many people get media-types wrong, so often that people are encouraged to not rely on media-types.
… For a JSON(-LD) prepresentation, this would be application/did ; for a CBOR representation, this would be something like application/did+cbor .
… Serving a DID document as application/ld+json or application/json is not wrong, but not optimal.
… A text to this effect has reached consensus in the VC WG, I will do something similar for DID.
… Developers should be ready to deal with lower fidelity media-types.

Wip: Quick comment, this text is in the controller document, will we rely on that? Controller document has its own media type?

manu: good question. I think the Controller Document will have its own media-type.
… We don't want to duplicate content. I try to get a sense of what the group wants.
… We fist need a decision on the DID document media-type, then we can discuss the rest.

Wip: Any comments on the draft proposals?

pchampin: Without being too pedantic, the spec makes a clear disctinction between a DID and a DID Document, application/did might be a bit confusing since a DID is an identifier?

manu: I take your point. I'm wondering if it matters all that much?

<ivan> +1 manu

manu: I don't think we would ever serve a pure DID with a media-type.
… It feels nicer to have a short compact media-type.

PROPOSAL: The media type for the JSON and JSON-LD expression of a DID Document will be application/did.

<dmitriz> +1

<TallTed> +1

<Wip> +1

<manu> +1

<ivan> +1

<markus_sabadello> +1

<pchampin> +0.5

<JennieM> +1

<bigbluehat> +1

RESOLUTION: The media type for the JSON and JSON-LD expression of a DID Document will be application/did.

PROPOSAL: The specification should warn that it is possible to use lower fidelity media types like application/json or application/ld+json to serve DID Documents and that implementations should be aware of this fact and use the highest precision media type in their applications.

<manu> +1

<Wip> +1

<dmitriz> +1

<TallTed> +1

<JennieM> +1

<ivan> +1

<JoeAndrieu> +1

<markus_sabadello> +1

<pchampin> +1

RESOLUTION: The specification should warn that it is possible to use lower fidelity media types like application/json or application/ld+json to serve DID Documents and that implementations should be aware of this fact and use the highest precision media type in their applications.

---

[msporny]

PR #868 has been raised to address this issue. This issue will be closed once PR #868 has been merged.