Define network based conformance classes for resolver and dereferencer

[wip-abramson]

This attempts to address #213

I have addressed this issue a little differently than discussed. Specifically around naming of the conformance class.

I have a conforming resolver (the software bit) then a conforming network-based resolver is a conforming resolver that implements HTTP Binding.

I also added a similar class for DID URL dereferencers.

Then I attempted to clarify the requirement for JSON serialization of inputs and outputs for both resolving and dereferencing.

Reviews appreciated.

---

Preview | Diff

[peacekeeper]

Could we maybe call it a "conforming HTTPS-based DID resolver" instead of a "conforming network-based DID resolver"?

My understanding has always been that there can also be other network-based / remote bindings than HTTPS, e.g. a DIDComm binding (i.e. sending resolution requests and responses over DIDComm).

[jandrieu]

My understanding has always been that there can also be other network-based / remote bindings than HTTPS, e.g. a DIDComm binding (i.e. sending resolution requests and responses over DIDComm).

I think if there is a resolver that doesn't support the https binding, e.g., it ONLY supports DIDComm bindings, then it would not be conformant.

The distinction I believe we are trying to make in these conformance classes is whether or not you cross a device boundary and go over the network.

Local = library patterns, whether DLLs or statically linked at compile time.
Remote = network = https

In this specification we are only standardizing a binding to https, so "network-based DID resolver" is semantically identical to "https-base DID resolver".

And, perhaps more nuanced, DIDComm can go over https, in fact, its most common usage seems to be over websockets through https. So, I'm not seeing how "https-binding" helps clarify the potential confusion.

Seems to me, the DID Resolution network protocol is https with specific bindings. DIDComm is an alternate communications strategy that some resolvers might support, but which is not defined in this specification. It's a fine spec, just not what we are using for interoperable DID resolution.

I think we should keep it "conforming network-based DID resolver".

[w3cbot]

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

View the transcript

Review PR for #213: Make conformance statements concretely testable

<ottomorac> w3c/did-resolution#243

<ottomorac> Will has proposed some wording around the conformance classes and there is initially some feedback from Markus.

wip: We have talked about this a number of times. I want to know what people think but I want to get this in as it's blocking a number of open PRs that depend on its language.
… You can be a conforming resolver just by being a library, don't need HTTP.
… There are conformance classes that we need to reference in the document that other PRs depend on.

JoeAndrieu: I think Markus is wrong on this. We don't have confirming DIDCOMM-based resolvers that don't have HTTPS binding. My understanding of the distinction is "Are we crossing a device boundary?"
… I thought that's what we're trying to highlight in the security of the two systems.

wip: I think that's what we're trying to highlight. Right now, only HTTPS crosses the device boundary. Do we want to limit it to that?

JoeAndrieu: I think we are not specifying that future thing. If a future working group with a different charter wants to add different features, that's up to them. If we want the network architecture to be interoperable, then we need extensions, and we lose interoperability.

ottomarc: A DIDCOMM resolver may do Bluetooth, HTTPS, etc.

JoeAndrieu: If it does HTTPS, then it's conformant, and that's the minimum.

wip: I don't care what we call it, I want to get that in. I'll change it back to "network" and ask that JoeAndrieu add a comment.

---