Unclear statement about verifiability of results of DID Resolution

[wip-abramson]

It seems I missed a point raised in the TAG review.

"This inclusion can potentially enable a client to independently verify the results of a DID Resolution process, as long as it trusts the DID resolver." doesn't sound like much of a proof if it requires the resolver to be trusted.

See https://w3c.github.io/did-resolution/#dfn-did-resolver-s:~:text=This%20inclusion%20can%20potentially%20enable%20a%20client%20to%20independently%20verify%20the%20results%20of%20a%20DID%20Resolution%20process%2C%20as%20long%20as%20it%20trusts%20the%20DID%20resolver.

Not sure the best way to resolve this. Just remove this statement?

[pchampin]

This was discussed during the meeting of wg/did on 29 January 2026.

View the transcript

w3c/did-resolution#274

Wip: Jeffrey is saying there is a statement in the spec that mentions proofs but is not clear....

Wip: I wonder if they best way to handle this is just to remove this statement from the spec in section 7

JoeAndrieu: Yes I think this statement is incorrect...

JoeAndrieu: We don't have a standard way to put a proof in DID doc... so yes remove it...

JoeAndrieu: the security model you have is to trust the resolver...

JoeAndrieu: some of this will come out in the Threat Modelling section...

Wip: Yes I think the best way is to just remove this statement....

---

[wip-abramson]

Looking over this again I am wondering about the inclusion of proof as a DID Resolution Metadata property at all. It feels weird and confusing. proof if really just a placeholder property for some as yet undefined proof types that DID resolvers still need to specify. We have no implementation experience of this, shouldn't this be left to extensions?

Additionally, I was wondering if what we meant by proof was actually more inline with a Data Integrity Proof. A signature over the result from the DID Resolver. This statement makes more sense if viewed like that:

This inclusion can potentially enable a client to independently verify the results of a DID Resolution process, as long as it trusts the DID resolver.

Although this bit "to independently verify the results of a DID Resolution process" is still off.

I don't think there are any proofs that the DID Resolver can provide that would enable independent verification of the result of resolution. These kinds of proof, if and where they are possible, belong in DID Document metadata.

[w3cbot]

This was discussed during the #did meeting on 12 February 2026.

View the transcript

w3c/did-resolution#274

wip: Four to discuss. I'll probably jump around a little.
… This is from TAG review. It's pointing to a fuzzy statement we have in the spec around proofs.
… In the DID document metadata and the DID resolution metadata we define this value called "proof" but one of our sentences makes it sound like not much of a proof, e.g., "this is only a proof if you trust the DID resolver".
… I looked at it, and I feel that proof in this context is more like a data integrity proof. The problem is both proof values in our spec are just placeholders for DID method developers to fill in and may not be very good in that respect.
… I don't feel that there's guidance about what we should do with the proof.

manu: The purpose of this is so that proxies can cache DID resolution results and you could do a lot more edge caching with this mechanism.
… There would be some resolver or set of resolvers that you trust out there, and you don't have to talk to them directly to get the results. Rather, you can talk to the caching layer, and the caching layer needs to talk to the upstream resolver e.g., only every five minutes.
… You need to trust the upstream resolver but we haven't defined this at all, so maybe we should delete the sentence until we refine it. I don't feel give where we are that we have time for it right now.

<Zakim> JoeAndrieu, you wanted to ask about implementations

joeandrieu: I don't feel that caching is a legitimate use case. It's an echo of the proxy conversation. +1 to your proposal to remove it, and I don't think that we have any implementations that do this.
… We should start to figure out what the use cases are so we can update the spec.

wip: The simple solution is to delete this sentence, but it points to a bigger problem that the whole proof property is a little questionable. It took me some time to realize that this proof property referred to a data integrity proof. I think the proof in the DID document metadata is more of a proof in that you could provide e.g., all the
… transactions in Bitcoin that led to this document.
… I don't know what we're trying to gain by saving this proof name in the metadata without telling anyone how to use it.

<Zakim> JoeAndrieu, you wanted to say the immediate proof is from TLS

joeandrieu: I agree with everything you just said with the proof being a data integrity style attachment. But we are using TLS, so we can prove that it came from the resolver we think we're talking to.
… I think we should remove the proof from DID documents because we don't have a firm definition. If you have a resolver you can trust, you can trust what it provides.

<ottomorac> dev.uniresolver.io

ottomorac: We just mentioned that very few or no people are using the caching feature and I'm curious about that. I asked Gemini, and it came back with saying that the DIF universal resolver uses caching.

<ottomorac> Affinidi DID Resolver Cache: There is a specific Rust-based SDK

ottomorac: There's also one in Affinity that I believe is built in Rust.
… There's also one in Python that mitigates what's called "Thundering Herd" problems on a resolver.

<ottomorac> Affinidi DID Resolver Cache: There is a specific Rust-based SDK built by Affinidi to add a high-performance caching layer to the Universal Resolver architecture. It is designed to minimize the latency of blockchain-based lookups (like did:ethr or did:indy) which can be slow.

swcurran: We use short caching to prevent multiple resolutions in five-second spans where each one involves pulling the same DID document. So, short caching for what amounts to a single activity prevents going out to the source every time for the duration of the activity.
… We have a TTL attribute as well.

<Zakim> JoeAndrieu, you wanted to say it isn't that people aren't caching, its that we have not defined a standard way to do that with any guarantees of integrity

<ottomorac> dev.uniresolver.io: often use Nginx or similar reverse proxies to cache resolution results based on the DID URL.

joeandrieu: It's not that people aren't caching, it's whether we come up with a standard way to guarantee the integrity of cache results. Right now, if you are using the DIF resolver, you have to trust that they're giving a good result, but we don't have a way to know that any resolver that DIF proxied to gave you a valid result.

manu: I agree with Joe. We should just delete the sentence. We're out of time.

---