More advanced DID URL dereferencing for verificationMethods?

[wip-abramson]

As I reread the DID URL dereferencing section I found myself wondering about the focus on service endpoints for the primary resource section. (Section 4.3.1)

I guess the simple way to dereference a verificationMethod is through a fragment to the ID of the vm you want.

e.g. did:example:1234#keys-1

But what about a more complex query that returns all verificationMethods with a given verificationRelationship?

I am not exactly sure what that query should look like, but it feels like a useful and common interaction pattern across different DID methods.

Maybe something like did:example:1234/verificationMethods?rel=assertionMethod

I think you can also imagine a common dereference like this which includes a fragment to a verificationMethod. Basically, you are checking that the verificationMethod that produced this kind proof was authorized to do so in the DID document.

e.g. for this proof

  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2021-11-13T18:19:39Z",
    "verificationMethod": "did:example:1234#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQp...jQCrfFPP2oumHKtz"
  }

You might want to dereference the following DID URL: did:example:1234/verificationMethods?rel=assertionMethod#key-1

I guess per 4.3) anyone could implement this in a custom manner for their DID method. Is it worth trying to bring something like this into the DID resolution spec?

[peacekeeper]

I think this makes a lot of sense, since there are many use cases (e.g. when verifying a VC) where a client is only interested in keys that have a certain verification relationship such as assertionMethod.

I don't think the DID Path should be used for this, and I don't think rel is a suitable name for a DID Parameter in this case, but maybe a DID Parameter such as verificationRelationship, e.g.:

did:example:1234?verificationRelationship=assertionMethod
did:example:1234?verificationRelationship=assertionMethod#key-1

[wip-abramson]

I think this is a good idea to add into the DID resolution specification. I expect it to be useful across DID methods as verificationRelationships is a DID core property.

[pchampin]

This was discussed during the did meeting on 10 October 2024.

View the transcript

DID Resolution Issue/PR Processing

burn: Contact the chairs if anyone would suggest an improvement

markus_sabadello: let's start with new issues

<markus_sabadello> https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3Apending-close

markus_sabadello: first with pending close issues

burn: note that, in the agenda email, we listed these issues.
… We'll be using this process until the end of the thursday meeting to object to the close.

<TallTed> I strongly recommend such searches be ordered by "least recently updated" to keep the churn active, e.g., https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3Apending-close+sort%3Aupdated-asc

burn: the point is, we'll review these quickly today, but the expectation is that you are too look for these in the agenda and speak up or comment in the issue if you have an objection
… so we will not be spending time unless there is a concern (as a general rule)

<markus_sabadello> w3c/did-resolution#57

markus_sabadello: Proposal to rename one of the resolution functions
… Resolve and ResolveStream
… This issue is a proposal to rename ResolveStream. That's already happened. I posted a comment 2 weeks ago. No further discussion

burn: any objections to closing?

markus_sabadello: I'll close them after the call

<markus_sabadello> w3c/did-resolution#30

markus_sabadello: Issue 30, several years old. Has to do with dereferencing discussion at TPAC
… "The result of dereference can be a DID document, but it can also be something else"
… Looking at this issue after a long time, I think the current specification addresses this. I see 3 thumbs up to that comment.
… So, if no objections, we'll be closing this.

<markus_sabadello> w3c/did-resolution#29

markus_sabadello: also several years old, about the definition of the term did resolver.
… In the current specification, both terms are defined formally in terminology section. Also two thumbs up.
… Any objections?

<markus_sabadello> w3c/did-resolution#21

markus_sabadello: Issue 21 about removing the term DID Reference from DID core to DID Resolution.
… I think this is now obsolete. We don't use that term in any spec.
… Same discussion was also in did-core, which was closed. So I think this one can be as well.
… Any objections?

<markus_sabadello> w3c/did-resolution#11

markus_sabadello: All methods must have a name of at least three characters.
… This seems like a DID Core issue, not in DID Resolution
… Similar issue in DID-core, which has also been closed.
… For all of these issues, it seems straightforward to close them.
… Since they are older issues, we may not be getting engagement from the initial poster, but unless there are objections, seems like we should close

decentralgabe: If we mark it pending close and give it a week, that would address the older participants

burn: requirements vary from group to group. In past groups, we've made the point to actively reach out by email and ask for engagement. Then you can comment that in the issue.
… so ping in the issue, then email, then document that email in the issue.
… That let's us show we've done what we can to address the concerns of the original poster
… For these, I think we're good, but going forward that's a nice improvement to our process

burn: you have 10 more minutes if you like

<markus_sabadello> https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22

markus_sabadello: one other thing. A few issues are tagged as "Good First Issue"
… Two of them have been assigned. One has not.
… These are a good way to contribute, especially if you might not be familiar with deeper technical issues.
… We'll try to find more like that and encourage PRs
… A few that might be ready to close

<markus_sabadello> w3c/did-resolution#23

markus_sabadello: Issue 23 is about result of dereferencing

<manu> JoeAndrieu: Looking at the backlog. There is an opportunity here to make a distinction -- how we talk about a DID with and without a trailing slash... but I don't know if that helps us. I need to look at this in more detail, it's five years old, we can close it, if problem still exists, we can raise a new issue again.

<manu> markus_sabadello: I think this might be obsolete by now?

<manu> JoeAndrieu: Yeah, sounds like it might be.

<manu> markus_sabadello: We will have until next call to look at it or raise a new issue if this comes back.

<manu> JoeAndrieu: Sounds good to me.

manu: I'm wondering what is the ... I'm fine with closing it. I'm wondering where did we land?
… the response from a resolver is a resolution result, which might contain a did document?
… Is that where we landed?

markus_sabadello: that's right the resolution response might contain a did document, but dereferencing might return something else

manu: i think it's already addressed (as opposed to an older issue that isn't valid)

markus_sabadello: this was from when we didn't have a did resolution result, we were just returning DID documents
… That has been addressed

<JoeAndrieu> +1

manu: +1

markus_sabadello: also to be aware of, from discussions at TPAC, when we talked about path, query, and fragment parts.
… we talked about different patterns in the past and how much of that should be in the resolution spec itself or in did core, or in both.
… If people come up with certain features that use the path or query string, how does that fit in and where does it get specified?

<markus_sabadello> w3c/did-resolution#85

markus_sabadello: There are two open issues for new DID parameters with certain functionality

<markus_sabadello> w3c/did-resolution#90

markus_sabadello: The first introduces version-type the second XYZ as parameters
… Please comment about where these should go and whether or not it should be did-method-specific or standardized across methods

burn: ok, you have about another 5 minutes if you'd like

markus_sabadello: ok. I'm wondering if we can merge that pull request

<markus_sabadello> w3c/did-resolution#89

markus_sabadello: or if anyone has new thoughts about the discussion we had about primary resource and secondary resource
… there is an open PR where I tried to improve the headings
… to help with that. I'm wondering if people have opinions.
… I would actually prefer not to merge because it makes the headings longer
… But the algorithm talks about dereferencing the primary resource and secondary resource
… This PR adds explanation to the headings

manu: I think it is unfortunate that the initial wording was primary and secondary resource, as that is so abstract it is confusing.
… +1 to comment about section titles get hard

<TallTed> +1 to manu's suggestion

manu: maybe we can call it derereferencing a DID? or a #fragment
… +1 to not merge this, but maybe we can have did document and fragment as the terms

markus_sabadello: there is something that right now is called a primary resource.
… there needs to be a name for what you get when you dereference the did document
… For example, dereferencing the DID URL resource may be a better phrase

manu: yes. that was my thinking. Name the types of things you can dereference.
… A use case where you get a DID Document. A case where you dereference a fragment in a resource. And a third case where it's neither of those.
… Related Resource? (Not suggesting that, but if we name it, it will help)

markus_sabadello: this needs to be extensible. we can't imaging all the things they dereference to.
… but i think we can use better terms than Primary & Secondary. I'll try to do that.

<manu> JoeAndrieu: I would like to try my hand at writing this PR, don't know when I'm going to get to it, but want to help.

---

[wip-abramson]

We discussed this on the call.

We agreed to add a new parameter - verificationRelationship. The dereferencing algorithm for this parameter should point to the algorithm documented in the controller document - https://w3c.github.io/controller-document/#retrieve-verification-method

We will wait until the DID Core has been aligned with the Controller Document to make this change.

[w3cbot]

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

[w3cbot]

This was discussed during the #did meeting on 30 January 2025.

View the transcript

w3c/did-resolution#90

Wip: can one dereference a DID document to a specific verification method
… do we want this to be standard across all the specifications?
… we talked about this before
… and manu mentioned it was already in the CID specification

markus_sabadello: I think it's useful and be in the specification
… we can reference the algorithm in the controlled identifier document specification
… another thing manu pointed out is whether it should be a parameter
… which would put it into the URL

<ivan> Manu may have referred to this: https://www.w3.org/TR/cid-1.0/#retrieve-verification-method

markus_sabadello: or should it be an option
… in that way it is separate from the URL itself
… and this case it may be better as an option

Wip: what do others think?
… my question is why not make it a parameter?
… not hearing much interest in this one
… I did open it, but let's leave it for now

---

[wip-abramson]

I looked into writing a PR for this issue, but I have some questions around aligning with the CID spec.

The Retrieve Verification Method algorithm takes as input a vmIdentifier and a verificationRelationship.

Which makes sense, as you can get those values directly from a proof your are attempting to verify e.g.:

  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2021-11-13T18:19:39Z",
    "verificationMethod": "did:example:1234#key-1", // The vmIdentifier
    "proofPurpose": "assertionMethod", // The verificationRelationship
    "proofValue": "z58DAdFfa9SkqZMVPxAQp...jQCrfFPP2oumHKtz"
  }

So given that, I am questioning whether a verificationRelationship parameter actually makes sense. Are there usecases where an entity would want to dereference ALL verificationMethods for a specific verificationRelationship?

Instead, a verificationRelationship as a DID URL Dereferencing Option would align more closely with the Retrieve Verification Method algorithm.

What I would like to do is just say, if the verificationRelationship option is present then call the Retrieve Verification Method algorithm. I.e. sidestep the default dereferencing algorithm. This is because the Retrieve Verification Method algorithm calls the dereferencing within it.

As I am writing this up, this makes sense to me. So I will submit a PR for this and see what people think.

[peacekeeper]

Marking as pending-close after merging https://github.com/w3c/did-resolution/pull/122.