Specify that semantics are the same if @context is not used.

[msporny]

This PR is an attempt to partially address issue #94 by specifying that document semantics are the same even when @context is not used.

/cc @jyasskin and @hadleybeeman

---

Preview | Diff

[David-Chadwick]

Suggested change

	value or JSON-LD processors are used or not, the semantics for all properties
	value and/or JSON-LD processors are used or not, the semantics for all properties

[TallTed]

Included in my suggestion below.

[TallTed]

Included in my suggestion below.

[iherman]

The issue was discussed in a meeting on 2024-10-16

• no resolutions were taken

View the transcript

4.2. Specify that semantics are the same if @context is not used. (pr controller-document#106)

See github pull request controller-document#106.

Manu Sporny: the TAG said a JSON-LD processor might resolve to a different solution to pure JSON processing, so need to make clear that this is not the case.
… so even if @context is not there, the result should still be the same.
… if you get two different results then you have a bug in one of your processors.

Ivan Herman: +1 to put this into VCDM.

Phillip Long: +1 to putting this in the VCDM for consistency.

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

Substantive, multiple reviews, changes requested and made, no objections, merging.