DID service parameter does not account for cases where id of service is a full IRI external to the DID document

[trwnh]

Extracted from w3c/did-core#864 (comment)

By my reading of https://w3c.github.io/did-resolution/#dereferencing-algorithm-primary -- it seems like algorithm step 4.1.1 doesn't account for a "full IRI external to the DID document" use case:

If the input DID URL contains the DID parameter service and optionally the relativeRef DID parameter:

Example 1
did:example:1234?service=files&relativeRef=%2Fmyresume%2Fdoc%3Fversion%3Dlatest

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. This is called the input service endpoint.

So for something like

did:example:abc123?service=https%3A%2F%2Fexternal-node.example

The resolution algorithm above reads in a way that it would fail to match anything -- certainly there is no fragment matching service=https%3A%2F%2Fexternal-jsonld-node.example, and indeed there is no fragment at all!

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:abc123",
  "service": {
    "id": "https://external-jsonld-node.example",
    "serviceEndpoint": "https://will-this-ever-match.example"
  }
}

In fact, because of the "fragment" matching algo, something like this might be expected to match:

did:example:abc123?service=example

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:abc123",
  "service": {
    "id": "https://this-part-doesnt-actually-matter.example/#example",
    "serviceEndpoint": "https://i-guess-this-matches.example"
  }
}

[peacekeeper]

@trwnh Thanks for reporting this, I agree this is a bug that should be fixed.

[w3cbot]

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