Duplicate normative requirements around implementing DID resolution algorithm

[wip-abramson]

All conformant DID resolvers MUST implement the DID resolution function for at least one DID method and MUST be able to return a DID document in at least one conformant representation.

https://w3c.github.io/did-resolution/#resolving:~:text=All%20conformant%20DID%20resolvers%20MUST%20implement%20the%20DID%20resolution%20function%20for%20at%20least%20one%20DID%20method%20and%20MUST%20be%20able%20to%20return%20a%20DID%20document%20in%20at%20least%20one%20conformant%20representation.

A DID resolver MUST support the DID resolution algorithm for at least one DID method and MAY support it for multiple DID methods:

https://w3c.github.io/did-resolution/#resolver-architectures-multiple:~:text=A%20DID%20resolver%20MUST%20support%20the%20DID%20resolution%20algorithm%20for%20at%20least%20one%20DID%20method%20and%20MAY%20support%20it%20for%20multiple%20DID%20methods%3A

Suggest we remove the normative language from DID Resolution Architecture section

[peacekeeper]

To address this: Change the first paragraph to:

All conformant DID resolvers MUST implement the DID resolution function for at least one DID method and MUST be able to return a DID document in at least one conformant representation.

Change the second paragraph to:

A DID resolver might support multiple DID methods:

[wip-abramson]

This PR should remove the second normative statement (in DID Resolution architectures) and remove the in at least one conformant [representation](https://w3c.github.io/did-resolution/#dfn-representations). fragement from the first statement

[w3cbot]

This was discussed during the #did meeting on 11 November 2025.

View the transcript

w3c/did-resolution#239

Wip: There are duplicated satements, we might want to remove items.

Wip: Same requirement -- second normative statement we probably don't need it

manu: +1, don't need it.

JoeAndrieu: We only have one conformant representation.

Wip: That's a separate issue.

JoeAndrieu: We had a long discussion about this w/ VCs -- we say that things that can be transformed into VCs are VCs... you can't give me a media type and not be serialized in that format.

Section about representations: https://w3c.github.io/did/#production-and-consumption

JoeAndrieu: This is all legacy

JoeAndrieu: This could confuse the market -- we don't want to revisit that -- it would be better if we could update via wisdom learned from that conversation

manu_: I tried to modify the spec according to the charter
… I tried to do the minimal changes possible

JoeAndrieu: If you send me someething that is not a DID Document, it shouldn't work.

pchampin: This isn't aying media type should be the same.

JoeAndrieu: The media type defines the serialization, and we have one media type and one serialization.

JoeAndrieu: All this laguage creates confusion that we don't need to have.

Wip: This has been my sense, but relates to use of accept -- if we have one media type, and you do did resolution if there is an accept header, why do we have this?

Wip: markus_sabadello has said you might ask for CBOR, application/did-cbor -- not a DID Document, repreentation that can be tranforme dinto a DID Document.

markus_sabadello: I'm not sure, Joe -- we did remove abstract data model, there could be other representations... don't know what this means for accept option, still makes sense to have that.

JoeAndrieu: To speak to accept header, in DID Resolution, enabling feature extensibility, but we don't ave any use for it right now.

manu_: I don't think the language says you can shove anything that is not application/did in the resolution result
… I agree this is confusing to have production and consumption rules in DID 1.1 when we only have one media type
… there are many normative requirements in this section. I wanted to avoid making class 4 changes

Wip: We got off topic on this -- feels like this group doesn't have time to take that on -- do we want to raise an issue on didv1.1 and label it future. I'd be wary about getting this in.

Wip: Back to 239 -- are we ok w/ the suggested change -- no duplicate requirements. I'm going to make this change

JoeAndrieu: +1

markus_sabadello: The change would be to remove the second statement -- yes, that's fine. We can remove/change it to say resolvers might support multiple DID Methods.

JoeAndrieu: I think I understood your pushback -- that's not what this issue is about -- can we change conformant representation -- I think it's understood that a non-conformant representation is not what we're talking about.

---