3.2 DID URL Syntax "Fragment" Example 6 Question

[SaulMoonves]

Example 6: A resource external to a DID Document

did:example:123?service=agent&relativeRef=/credentials#degree

So, this dereferences a service in the DID document with an ID fragment of agent. What then does #degree fragment refer to in this context?

Is it meant to be part of relativeRef? If so shouldn't it be percent-encoded?

And, just to be clear, I am reading the spec and agent is meant to be like a relative reference, if I had a service ID that wasn't relative to the DID, I could use the full URI in the parameter value (percent encoded I guess?)

[msporny]

@SaulMoonves wrote:

So, this dereferences a service in the DID document with an ID fragment of agent. What then does #degree fragment refer to in this context? Is it meant to be part of relativeRef?

Yes.

If so shouldn't it be percent-encoded?

Yes. :)

You might see that we fixed that issue in the latest v1.1 specification:

https://w3c.github.io/did-core/#example-a-resource-external-to-a-did-document

I could use the full URI in the parameter value (percent encoded I guess?)

Yes, you could do that.

I believe that answers your question, and so I'm marking this "pending close" (it'll be closed after 7 days if we don't hear from you). If we didn't answer your question, let us know and we can re-open the issue and discuss. Thanks for your interest in DIDs! :)

[trwnh]

I could use the full URI in the parameter value (percent encoded I guess?)

Yes, you could do that.

Can you actually do that? By my reading of https://w3c.github.io/did-resolution/#dereferencing-algorithm-primary (is there something more official I should be looking at instead?), it seems like algorithm step 4.1.1 doesn't account for this "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"
  }
}

Should this be filed as a separate issue, and if so, where should I file it?

[msporny]

Should this be filed as a separate issue, and if so, where should I file it?

Yes, please. @peacekeeper might have more to say on this (in the new issue).

Please file it here https://github.com/w3c/did-resolution/issues/new (in DID Resolution)

Based on that, I'm closing the issue as I don't think there's more for us to do in DID Core. Please re-open the issue if you disagree, @SaulMoonves

[trwnh]

w3c/did-resolution#97 filed!