Add serviceType parameter, and update service construction algorithm. #125
Conversation
peacekeeper
requested review from
dmitrizagidulin,
mccown,
ChristopherA and
danpape
as code owners
|
I am not sure I agree with you you have implemented this algorithm @peacekeeper. If I am understanding correctly, the algorithm is expecting to always return a single service. Or rather the serviceEndpoint of that single service. But, if I use the The DID URL: I would expect to return 0 or more services of the Only if I also included the Would I expect to get a serviceEndpoint for a single service. And only if that service is of the type specified. |
|
I think you're right @wip-abramson , there is no reason why this couldn't return a list of matching services. I'll work on updating this PR accordingly. |
|
So reviewing this further, I realise I did not fully understand what the The definition of
With the definition of service referenced here - https://www.w3.org/TR/did-1.0/#services However, actually what the
|
index.html
Outdated
| The selected <a data-cite="did-core#services">services</a> are a list called the <var>resolved <a>services</a></var>. | ||
| </li> | ||
| <li>Read the values of the <code>serviceEndpoint</code> properties of the | ||
| <var>resolved <a>services</a></var>. This list is called the <var>resolved <a>service endpoint</a> URLs</var>.</li> |
There was a problem hiding this comment.
There is an extra complication here that the serviceEndpoint property is defined as
The value of the serviceEndpoint property MUST be a string, a map, or a set composed of one or more strings and/or maps. All string values MUST be valid URIs conforming to [RFC3986] and normalized according to the Normalization and Comparison rules in RFC3986 and to any normalization rules in its applicable URI scheme specification.
https://www.w3.org/TR/did-1.0/#dfn-serviceendpoint
In the case where a serviceEndpoint is not a string, what should happen?
|
This was discussed during the #did meeting on 27 February 2025. View the transcriptw3c/did-resolution#125wip: this is adding a service type parameter.... Markus? markus_sabadello: this is also an enhancement that we discussed.... this would introduce a parameter to select a service by type.... markus_sabadello: I see that you Wip also had some comments on it.... markus_sabadello: you correctly pointed out some details about it... wip: yes in regards to the service parameter... markus_sabadello: Yes i think we discussed about resolution.... and also it would depend on media type as to the list of URIs or service objects... markus_sabadello: I think it would make sense to update the PR in that regard... |
index.html
Outdated
| Select the <a data-cite="did-core#services">service</a> if its <code>id</code> | ||
| property contains a fragment which matches the value of the <code>service</code> DID parameter.</p> |
There was a problem hiding this comment.
Wondering if it might also be worth addressing this bug in this PR - #97
I was working on it, then remembered this PR. So I will at least wait until this is in. But maybe we could just address here?
There was a problem hiding this comment.
I tried to address this in cda94f2, i.e. the value of the service parameter can be an absolute or relative URL. The absolute forms are used for the matching.
|
@wip-abramson I tried to address some of your comments now, e.g. in #125 (comment) and #125 (comment), and also tried to add some more details of other aspects of how "service", "serviceType", and "relativeRef" are handled. Maybe you can re-review? |
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
| </ol> | ||
| </li> | ||
| <li>If the <b>accept</b> <var>input <a href="#did-url-dereferencing-options">DID dereferencing option</a></var> | ||
| is missing, or if its value is the Media Type of a <a>representation</a> of a <a>DID document</a>: |
There was a problem hiding this comment.
Wondering about the Media Type here. I thought we said there was only one media type for a DID document - application/did
There was a problem hiding this comment.
One that we define in our specs. But my understanding is that anyone can also define different DID document representations with different media types, e.g. CBOR based.
|
Added a few minor suggestions, but this looks good to me. |
Co-authored-by: Will Abramson <wip.abramson@gmail.com>
Co-authored-by: Will Abramson <wip.abramson@gmail.com>
|
This was discussed during the #did meeting on 20 March 2025. View the transcriptw3c/did-resolution#125Wip: skipping PR#123 is ready to be reviewed. Markus: This PR adds service type that lets you select services from the DID doc. Algorithm answers questions when service identifier is any URI. Fixes a bug in processing the relative reference parameter. Relatively big PR. Possibly more reviews would be useful, but it looks like it's in good shape now. wip: would be good to get more reviews on this PR |
|
Merging, after approval, suggestions applied. |
This PR addresses two issues:
serviceTypeDID parameter in addition to the existingserviceDID parameter. See Request service by type #85relativeRefDID parameter. See Service Endpoint Construction inconsistency #61One aspect I wasn't sure about is what to do if there are multiple services with the same type. At the moment, this PR says that the first matching service will be returned, but we could also return a random matching service, or we could return a list of all matching services and leave it up to the client to pick one. I found an old message by @dlongley on this topic: https://lists.w3.org/Archives/Public/public-credentials/2019Jun/0028.html
Preview | Diff