Service Endpoint Construction inconsistency

[clehner]

The example (https://w3c-ccg.github.io/did-resolution/#example-11) is inconsistent with the algorithm (https://w3c-ccg.github.io/did-resolution/#algorithm).

The example says:

Given the following input service endpoint URL:

https://example.com/messages/8377464

And given the following input DID URL:

did:example:123456789abcdefghi?service=messages&relative-ref=%2Fsome%2Fpath%3Fquery#frag

Then the output service endpoint URL is:

https://example.com/messages/8377464/some/path?query#frag

But by following the algorithm, I get this as the output URL:

https://example.com/messages/8377464?service=messages&relative-ref=%2Fsome%2Fpath%3Fquery#frag

It looks like in the example the relative-ref DID parameter is used instead of (or in addition to) the input DID URL path and query.

There is also an example in did-core (https://w3c.github.io/did-core/#example-9) for "A resource external to a DID Document", using service and relativeRef:

did:example:123?service=agent&relativeRef=/credentials#degree

Is using relativeRef/relative-ref the way to go? If so, how should it interact with the path component and other query parameters in service endpoint construction?

[koptan]

I am also facing the same issue somehow, for me, when I followed the algorithm I got the following as an output: https://example.com/messages/8377464/some/path?query#frag because in algorithm is not mentioning anything about relative-ref so simply I ignored :)

but I don't think this correct, because relative-ref should be part of the final result.

@clehner how did you solve this issue?

[clehner]

@koptan In the Service Endpoint Construction algorithm I use the path and query component from the decoded relativeRef parameter if present rather than from the input DID URL.

https://github.com/spruceid/ssi/blob/80a3f24bc721eba38d150c2912443b9a97cfe71e/src/did_resolve.rs#L549 (2021-02-02)

This should comply with the examples and the definition of relativeRef https://www.w3.org/TR/2022/REC-did-core-20220719/#did-parameters

[peacekeeper]

Sorry it took so long to pay attention to this.

I use the path and query component from the decoded relativeRef parameter if present rather than from the input DID URL.

Yes, this is correct. The current Service Endpoint Construction algorithm is wrong and needs to be fixed to use relativeRef. That current algorithm in the document is based on a much earlier version of the spec when we still had matrix parameters.

[w3cbot]

This was discussed during the #did meeting on 21 November 2024.

[peacekeeper]

Assigning to myself for now.

[w3cbot]

This was discussed during the #did meeting on 30 January 2025.

View the transcript

w3c/did-resolution#61

Wip: the next one that's ready is 61
… service endpoint construction inconsistency

markus_sabadello: this one is more complicated
… it has to do with the service parameter
… and a relative ref parameter
… they can be used together to point at a service endpoint plus the relative reference
… someone will have to go through the algorithm and fix the references
… and if no one wants to, I can assign it to myself
… but it'd be great to have more contributors

Wip: I agree with markus_sabadello, these issues would be great opportunities to get involved
… we appreciate help

---

[peacekeeper]

Marking as pending-close, since I think this has been addressed by https://github.com/w3c/did-resolution/pull/125