Simplify dereferencing of the DID fragment based on the media type.

[peacekeeper]

This removes language about how to dereference a fragment in the case of a application/did+ld+json DID document, and instead states that this is defined by the media type.

[danpape]

Looks good, except for that one misspelling.

[TallTed]

Note that multiple + have been disallowed in IETF/IANA media types.

application/ld+json might be sufficient, here?

Suggested change

	For example, if the primary resource is a representation of a DID document with media type <code>application/did+ld+json</code>, then
	For example, if the primary resource is a representation of a DID document with media type <code>application/ld+json</code>, then

[peacekeeper]

@TallTed I agree with your comment, but I think it would be better if this gets discussed and fixed first in did-core, and then later in did-resolution, and that we address this in a separate PR.

[TallTed]

See w3c/did-core#863

[pchampin]

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

[mccown]

These changes make the process much more clear and straightforward for readers.

[dmitrizagidulin]

👍 to the PR (though I agree that we're essentially depending on what the DID Core spec chooses for the DID media type)

[pchampin]

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

View the transcript

DID Resolution PR 88 / 89

"w3c/did-resolution#88

w3c/did-resolution#89"

Simplify dereferencing of the DID fragment based on the media type

Wip: I put this on the agenda. We talked about it last week. Should the primary resource be the DID Document? it says 'first you get the DID Document in resolution, then primary resource...'

<swcurran> +1 to WIP about primary document

markus_sabadello: agree, lets not have a big discussion about the naming of primary and secondary resource. I have been using the terms as introduced in original rfc3936
… PR 88 is an attempt to remove language related to processing the fragment. This depends on the media type
… Currently the text is specific to a JSONLD document. The intent of the PR is to simplify and remove this part
… regarding the discussion of primary and secondary resource lets have a special topic about it. It effects a lot of things

manu: Fine with 88 being merged. Agree there was confusion with primary and secondary resource. I also found the current spec text clear on that
… not blocking 88

decentralgabe: We will plan on a special topic call for 88 and 80 around this resource discussion

---

[pchampin]

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

View the transcript

w3c/did-resolution#88

markus_sabadello: I can merge this, right?

Wip: Yes.

---

[peacekeeper]

Merging after consensus on last DID WG call.