Open clehner opened 3 years ago
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?
@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
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.
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:
But by following the algorithm, I get this as the output URL:
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: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?