DID Parameters: Service - only fragment or complete id?

[mschmidm]

I think I have found an unclear, possibly incorrect, specification. It is not clear how the DID service parameter should be used.

• In 5.4 Services, the service id is specified as an URI: "The value of the id property MUST be a URI"
• In the corresponding example 20, the id seems to be set to the DID of the corresponding DID Document with a fragment specifying the service: "did:example:123#linked-domain"
• In 3.2.1 DID Parameters, the "service" parameter is specified as "Identifies a service from the DID document by service ID. [...]".
• So the service parameter must be the service id which must be an URI. However, nowhere is it mentioned that this URI must be encoded in the parameter value.
• In addition, Example 8 does not use a URI as a service parameter value, but only a simple keyword ("files"): "did:example:123?service=files&relativeRef=/resume.pdf"
• In 4.1.1 of the DID Resolution specs it is suggested, that the service parameter value is only referencing an URI fragment: "From the resolved DID document, select the service endpoint whose id property contains a fragment which matches the value of the service DID parameter of the input DID URL".

How exactly should the "service" parameter be used? Should it be the whole service id URI (and then presumably use percent-encoding)? Or should it just be a URL fragment (but then the service id specification would have to be more precisely defined)?

Thank you for working on this great specification! :)

Best regards mschmidm

[peacekeeper]

Hello @mschmidm , good question, and nice summary of sources related to this topic! My understanding has always been that the value of the service DID parameter is not the full DID URL, but rather the value of the fragment of the id property of a service endpoint, i.e. like in Example 8 that you mention.

So for example service=files would refer to a service with id did:example:1234#files.

Regarding the language in 3.2.1: "Identifies a service from the DID document by service ID"

I would agree that this language isn't very clear, but I don't think it necessarily implies that the value of the service must be the full DID URL that is the value of the id property of a service.

A future DID WG will have the opportunity to clarify this topic more in the DID Resolution specification, and standardize the exact steps for dereferencing a DID URL with a service parameter.

[mschmidm]

Hi @peacekeeper , thank you for your answer!

I agree, this is most likely the intended meaning. The phrasing im 3.2.1. is unclear, but it does not contradict this interpretation.

This interpretation could have two different implications.

1. Service ids must always be the corresponding DID plus some fragment identifier like #files. -> In this case, the service id is way too loosely specified as only "MUST be a URI".
2. Service ids can be any URI as specified. However, the DID service parameter can only be used with services having an id as defined in 1.

In both cases, the DID service parameter should always work if you refer to a service with the according format. Fortunately, this assumption should be sufficient for most use cases, including mine. This makes the parametee definitely a handy feature.

Thanks again!