Remove "client" from identifying an error in the path handling

[swcurran]

In the path handling section of the current "DID Dereferencing Algorithm" -- steps 9 and 10, I don't understand the reference in step 10 that if the "client can't dereference the path" (as per step 9.4) an error should be returned. I think that would imply that a DID Resolver would have to be able to "call back" to the client to say -- "Hey, I can't resolve this -- can you?", get back the response from the client, and package it up to respond to the client.

It minimum, I think the the reference in step 10 to the client needs to be removed. An error is returned if the resolver can't resolve the path. I would also suggest removing step 9.4. A client might be able to process the path after it gets the error back from the DID Resolver (Step 10) but can't do anything until it gets the DID resolution result back.

[msporny]

Change step 10 to say something along the lines of:

10: Otherwise, the result is an error:

[peacekeeper]

I'm fine with the proposed change.

[peacekeeper]

Regarding 9.4, I think there may be some theoretical situations where dereferencing is done by a client in an application-specific way. But I can't think of a practical example, so I'd be fine with removing that.

[w3cbot]

This was discussed during the #did meeting on 11 November 2025.

View the transcript

w3c/did-resolution#244

<Wip> https://w3c.github.io/did-resolution/#dereferencing-algorithm

JoeAndrieu: I think what he's talking about is that there is an option in the APi to have the resolver dereference for you -- that's the "client" -- it's not the resolution client... it's the local client.

JoeAndrieu: The caller to the resolver isn't returning an error to anyone.

wip: in step 9 we have a bunch of ways to dereference, 10 is what happens when those fail

manu: this should be rewritten to say if you make it this far, return an error

wip: I think we all agree something needs to change

manu: yeah, we should just rewrite that step 10. Maybe we can think of something now. [thinking... thinking...]
… Otherwise, the algorithm has resulted in an error
… And we can ask Markus to make the language better

[manu updates the issue]

---

[w3cbot]

This was discussed during the #did meeting on 11 November 2025.

View the transcript

w3c/did-resolution#244

Wip: We discussed this earlier today Markus -- dereferncing algorithm step 10 is problematic -- client returns error, but noted new language -- we think language around step 10 needs to change.

Wip: Steven is also recommending that we remove step 9.4

markus_sabadello: Im fine with changing that to Manu's proposal to simplify the step. I agree step 9.4 sounds strange -- has to do with RDF and semantic web applications where this doesn't necessarily mean retrieval -- sometimes in semantic web there are use cases where URI there is no URL meaning/processing of URI is determined by client.

markus_sabadello: I'd be fine with removing it if it sounds too strange, something related to URI philosophy and theoretical constructs, but also fine w/ removing it.

Wip: I think I'm hearing remove 9.4 and refactor 10 to use Manu's language.

Wip: Those are all the discuss issues.

Wip: We're going to move on to test suite now

---

[wip-abramson]

@swcurran assigning this issue to you. Assume you will handle it as part of the DID Path PR?

[swcurran]

Yes -- it is removed as part of #260