Experiments with service, serviceType, relativeRef vs. PathService

[peacekeeper]

During the 14th May 2026 W3C DID WG meeting there were proposals for deprecating the service, serviceType, and relativeRef DID parameters, and there was a claim that the new proposed PathService path handling was a superset of those parameters.

So, here’s a challenge. Please explain how this use case could be fulfilled with PathService instead of the mentioned DID parameters. Please do this without imposing changes or constraints to the resulting final service endpoint URLs.

Given a DID: did:ex:1234

And given this DID document:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:ex:1234",
  "verificationMethod": [
    {
      "id": "did:ex:1234#key-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:ex:1234",
      "publicKeyMultibase": "z6Mkn7s7ofHS6YMFqqUnevNWmKqcytnnyBRRuopt8YVgEUnf"
    }
  ],
  "authentication": [
    "did:ex:1234#key-1"
  ],
  "assertionMethod": [
    "did:ex:1234#key-1"
  ],
  "service": [
    {
      "id": "did:ex:1234#dpp-1",
      "type": "ProductPassport",
      "serviceEndpoint": "https://example.dpp-provider.com/"
    }
  ]
}

I am now constructing two DID URLs:

DID URL 1:

did:ex:1234?service=dpp-1&relativeRef=%2Fproduct%2F9f7866e1-4bc5-4495-9f75-308350a37280%3Fversion%3Dlatest

How this is dereferenced with the current DID URL Dereferencing algorithm:

1. Resolve did:ex:1234 to the current DID document.
2. Select the service with relative id #dpp-1.
3. Apply the relative reference in relativeRef to the service endpoint URL https://service.dpp-provider.com/

The final service endpoint URL is:

https://example.dpp-provider.com/product/9f7866e1-4bc5-4495-9f75-308350a37280?version=latest

DID URL 2:

did:ex:1234?versionTime=2020-12-20T19:17:47Z&service=dpp-1&relativeRef=%2Fproduct%2F9f7866e1-4bc5-4495-9f75-308350a37280%3Fversion%3Dlatest

How this is dereferenced with the current DID URL Dereferencing algorithm:

1. Resolve did:ex:1234 to the DID document at the time 2020-12-20T19:17:47Z.
2. Select the service with relative id #dpp-1.
3. Apply the relative reference in relativeRef to the service endpoint URL https://old-service.dpp-provider.com/

The final service endpoint URL is:

https://old-service.dpp-provider.com/product/9f7866e1-4bc5-4495-9f75-308350a37280?version=latest

Bonus Question:

Try the same exercise with serviceType=ProductPassport instead of service=dpp-1.

Bonus Materials:

Video related to this topic: https://www.youtube.com/watch?v=iRqMjNzo3M8 (from 2023)

[swcurran]

Can the DIDDoc be changed or does it have to be that?

[peacekeeper]

Yes you can change the DID URLs and the DID documents. But the final service endpoints must not change.

And the obvious variable parts of the DID URLs (e.g. "9f7866e1-4bc5-4495-9f75-308350a37280", "latest") must not be hardcoded in the DID document.

[swcurran]

Here’s how I think this would be done with a derived version of my PR (adjusted to fit in the new algorithm vs. the old).

Using just PathService, change the type to "PathService" or specify in the ProductPassport extension definition that it is a “Path Handling” object. Either way, add a path attribute with value ”/product/”, and change the serviceEndpoint value to ”https://example.dpp-provider.com/product/”. Keeping the ProductPassport type allows for having additional specifications related to that type of object, if that is needed.

I agree that getting the parameter added to the resource URL is difficult without using relativeRef and I’ve proposed using that for the situation you raise here. So I’ll assume we keep that for that purpose.

That makes the final DID URL for you DID URL 1 to be:

• did:ex:1234/product/F9f7866e1-4bc5-4495-9f75-308350a37280?relativeRef=%3Fversion%3Dlatest

For the DID URL 2 case, I’ll assume that the earlier version of the DIDDoc (active at 2020-12-20T19:17:47Z) has the same adjustments (or not) for the service type, the path attribute is added as for the current DIDDoc, and the serviceEndpoint value set to ”https://old-service.dpp-provider.com/product/”. That makes the DID URL:

• did:ex:1234/product/F9f7866e1-4bc5-4495-9f75-308350a37280?2020-12-20T19:17:47Z&relativeRef=%3Fversion%3Dlatest

The versionTime is a DID resolution parameter and is handled at DID Resolution time to get the correct DIDDoc. That does leave the sticky question asked (but not answered) at the start of our session today about differentiating resolution time from dereferencing time parameters. I have ideas on that, but will wait for the topic to come up in the steps 1 and 2 of the algorithm.

For the bonus question — if we are using the Path Handling Algorithm, the ID of the service does not matter. What matters is the type of the object (per Joe — could be a service or an object in another array — although I’d like that to be discussed) and in particular, if it is a “Path Handling” object — with a path attribute.

[peacekeeper]

Thanks @swcurran this is kind of what I expected, based on previous discussions.

Maybe a follow-up question. What if I want to have multiple services in my DID document that use overlapping path hierarchies?

E.g. to extend the example above, I add one service:

  "service": [
    {
      "id": "did:ex:1234#dpp-1",
      "type": "ProductPassport",
      "serviceEndpoint": "https://example.dpp-provider.com/"
    },
    {
      "id": "did:ex:1234#dpp-2",
      "type": "ProductInquiries",
      "serviceEndpoint": "https://inquiries.dpp-provider.com/"
    }
  ]

Then I could do this:

did:ex:1234?serviceType=ProductPassport&relativeRef=%2Fproduct%2F9f7866e1-4bc5-4495-9f75-308350a37280%3Fversion%3Dlatest

RESULT -> https://example.dpp-provider.com/product/9f7866e1-4bc5-4495-9f75-308350a37280?version=latest

did:ex:1234?serviceType=ProductInquiries&relativeRef=%2Fproduct%2F9f7866e1-4bc5-4495-9f75-308350a37280%3Fversion%3Dlatest

RESULT -> https://inquiries.dpp-provider.com/product/9f7866e1-4bc5-4495-9f75-308350a37280?version=latest

Is there a way to do this with PathService?

[swcurran]

If I'm starting from the "PathService" mindset (e.g., favoring their use vs. the service parameter), I would say specify that both types "ProductPassport" and "ProductInquiries" are "File Handling Objects" (or both are PathService), and would use a different path for each, say "/product/" and "/product/inquiries/", each with the appropriate serviceEdnpoint values (right server, /product/ path), and the DID URLs become:

did:ex:1234/product/9f7866e1-4bc5-4495-9f75-308350a3728?relativeRef=%2Fversion%3Dlatest
did:ex:1234/product/inquiries/9f7866e1-4bc5-4495-9f75-308350a3728?relativeRef=%2Fversion%3Dlatest

  "service": [
    {
      "id": "did:ex:1234#dpp-1",
      "type": "ProductPassport",
      "path": "/product/",
      "serviceEndpoint": "https://example.dpp-provider.com/product/"
    },
    {
      "id": "did:ex:1234#dpp-2",
      "type": "ProductInquiries",
      "path": "/product/inquiries/",
      "serviceEndpoint": "https://inquiries.dpp-provider.com/product/"
    }
  ]

Other choices could be made to get to the same result.

[swcurran]

I think I may have an idea that could be used for service and serviceType parameters without dropping them.

I think the primary objection to service and serviceType right now is when they are used alone (e.g., without a path) they return “odd” results. In the current spec (and my PR), when used without a path, the result is defined as (based on the accept option) either:

• A modified DIDDoc that includes only the identified services (by id and/or type), with the serviceEndpoint extended with relativeRef (if present), or
• A list of serviceEndpoint URLs (again, applying relativeRef, if present)

I think the general opinion is that those results feel “wrong” — altering the DIDDoc and providing URLs without the service context (type, etc.).

How about instead of supporting either of those results for that specific case (used without a path), the spec says that the DIDDoc is returned, and the client can (non-normative) use the identified services as defined by their types? This is essentially the same as what happens with fragments, but with additional flexibility — selection by type instead of just the id, and leaving it to the client to handle the case when multiple services are identified.

This would still leave room for how those parameters can be used in combination with path — notably as a filter in determining the path handling object for the DID URL.

[peacekeeper]

specify that both types "ProductPassport" and "ProductInquiries" are "File Handling Objects" (or both are PathService)

How would I do that? Every time I have a new service type, would I have to state somewhere that it behaves like PathService?

I feel like we're overloading the concept of "service type" bit. In my mind, "service type" means the type/protocol/behavior of the service that I can find at the service endpoint URI. But with PathService, "service type" seems to mean what type of transformation logic is applied to the path.

use a different path for each, say "/product/" and "/product/inquiries/", each with the appropriate serviceEdnpoint values (right server, /product/ path), and the DID URLs become:
did:ex:1234/product/9f7866e1-4bc5-4495-9f75-308350a3728?relativeRef=%2Fversion%3Dlatest
did:ex:1234/product/inquiries/9f7866e1-4bc5-4495-9f75-308350a3728?relativeRef=%2Fversion%3Dlatest

Yes this makes sense, thank you! It doesn't work quite the same way as I could do it with service, servicesType, and relativeRef, but it kind of solves the same use case.

[swcurran]

I think we will need the concept of "Path Handling Objects" -- I had the name wrong above (shouldn't be "File"). Path Handling Objects are objects that are explicitly defined as handling a path in a DID URL. We have several of those now:

• service types that are intended to use the path -- e.g. PathService, but leaving the door open for others.
  • Note that not all service types are defined to handle the path in a DID URL.
• DID Linked Resources -- where the "Path Handling Objects" are found in the DID Metadata.
• Linked Resources -- where the objects are "linkedResource" objects.

There could be others. A DID URL dereferencer that is able to handle a path will support the path objects that it expects to be able to dereference. The goal of a generalization of saying a DID URL dereferencer supports DID Linked Resources, Linked Resources, and/or Path Service. The concept is used when identifying the possible objects that could be used to handle the DID URL path, and then selecting the precise one.

Hope to discuss this further when we get to the the discussion on dealing with DID URL paths.

[wip-abramson]

Interesting discussion thanks.

I think this makes clear the value of relativeRef - it is the only way today to pass query parameters through the serviceEndpoint. I don't think anyone is arguing with this.

What about the security risks of supporting relativeRef though? e.g. those mentioned here - https://w3c.github.io/did-resolution/#security-query-string-normalization-and-injection-risks.

Are those risks worth the value?

Also, it seems we still need to decide what the result of dereferencing a DID URL is. Is it a URL or the resource retrieved from the URL? I know it is a URL today, but many in the group are arguing it should be the resource. Is this something you feel strongly about @peacekeeper

[peacekeeper]

Is it a URL or the resource retrieved from the URL?

As others have pointed out, you don't necessarily "retrieve" anything from a service. E.g. in did:btcr2, you have "bitcoin:" URis. You could also have "xmpp:" or "mailto:" or "magnet:" services in your DID document. Those don't have a "resource" you can retrieve. Therefore, the result of dereferencing the DID URL should be the service endpoint URI/URL, and interacting with that should be a separate step.

[wip-abramson]

We will discuss this on todays call. Yesterday there was broad agreement that dereferencing a DID URL should involve retrieving the resource.

My perspective is it is up to the type of the service to define what retrieval means in these cases. They may define it to mean returning the URL.