w3c
Make https binding mandatory
This PR addresses #93 . It clarifies that conformant implementations must implement at least one did resolver with https binding.
This was discussed during the #did meeting on 04 September 2025.
View the transcript
Make https binding mandatory #182
<ottomorac> w3c/
ottomorac: on this one we have a couple of questions
… we have a requirement to implement some HTTPS binding
… at minimum
… but there are some questions
<ottomorac> Question 1- Is it a requirement on DID Methods or on DID resolvers?
<ottomorac> Question 2 - How do we implement the concept of the 2 conformance classes (libraries versus deployed did resolvers)
ottomorac: I have heard that the DID Resolution spec can only require things of the resolvers
… but as you can see in the conversation, others feel this could be a requirement on the methods
… Question 2 is how do we deal with 2 conformance classes
… I haven't seen that often
… Wip did point me to specs where that has been done in the past
… but I would appreciate some guidance
manu: for the 1st question
… I think it's firmly a DID Resolver requirement
… for DID Method requirements, it would have to be in DID Core
… we could try to do that in DID Resolution, but it would likely get missed
… and it feels strange to force that on DID Methods
<ivan> +1 to manu on method requirements should not be here
manu: I haven't read the conversation, though, but would love to hear more
… it feels like a DID Resolver requirement
… for Question 2: can we do 2 conformance classes, yes, we can
… this happens fairly often
… especially between document conformance and library conformance
… I think it's fine if we have 2 conformance classes in this case
… really, this may be around do we require HTTP binding
… so, the 2 classes may be about that?
… so maybe we say DID resolving libraries vs. DID resolving services
… doesn't have to be that language, but services would be the ones that have to support HTTP
… however, libraries could be all kinds of things
… so we may need to use more general language
… and then we could use service to imply HTTP protocol support
markus_sabadello: I think we're mostly aligned
… just a matter of language, probably
… I think the current sentence isn't very clear
… I interpreted it to read that if you did not have an HTTP binding you were not a conformant DID resolver
… but as Manu points out, libraries may not support HTTP/S
… and in the current language, that library would not be conformant
… what Manu just called libraries and services are currently local and remote resolvers
… so maybe with the current language we assign the HTTP binding to the remote resolvers only
… but there's variation...
… so I was a bit unsure of how to resolve it
… and then I wondered if each method would then need to have at least one remote resolver that supports HTTP
ottomorac: this has been discussed before
markus_sabadello: yes. especially whether or not we require HTTPS binding on methods
ottomorac: so, there is an additional question if this becomes a requirement within DID Core
<Zakim> JoeAndrieu, you wanted to suggest its a DID method requirement conceptually, but we can't fix that under this charter
ottomorac: so the connection to DID Methods becomes clearer
JoeAndrieu: conceptually, I do think this is a DID Method requirement
… I agree with markus_sabadello that requiring that a did:key resolver require HTTP access seems wonky
… so I feel like the 2 conformance classes feels good
… I do hesitate to call it local
… but perhaps we can define it without defining it
… by focusing the HTTP requirement on the "remote resolver" only
JoeAndrieu: if we do this right, we won't be accidently requiring HTTP access to DLLs or similar
<manu> +1 to what Joe said.
<bigbluehat> +1 agreed
ottomorac: I'll resolve this using local and remote resolver language
… not sure if we need to define conformance classes here, but I'll handle that offline
Thanks @msporny ! Does it make sense to also define the 2 conformance class for future reference or not? Here is what the AI bot suggested to me, which I think might be useful, but I defer to you and @peacekeeper for guidance.
A Remote DID Resolver is a resolver implementation that is permitted (and expected, if necessary) to perform network calls, remote registry lookups, or external protocol interactions associated with its resolution and de-referencing functions.
A Local DID Resolver is an implementation of a DID resolver and/or DID URL dereferencer that never performs remote HTTP(s), DNS, blockchain, or other network‐based lookups when executing the resolution or dereferencing functions. All operations are fulfilled by local resources: e.g. embedded keys/methods, cached/packaged DID Documents, or local verifiable registries or storage.
Also we have the concepts of local binding and remote binding from the Terminology section, where the concepts are explained. So not sure if I refer to those instead of creating the conformance classes. Let me know your thoughts.
It might be worth changing Remote DID Resolver and Local DID Resolver to Resolver of Remote DIDs and Resolver of Local DIDs, respectively (or offering the latter as alternatives), so it's clear that Remote and Local qualify the DIDs and not the Resolvers.
so it's clear that
RemoteandLocalqualify the DIDs and not the Resolvers.
Hmm that's not my understanding.. I don't know what a "remote DID" or a "local DID" is. To me, "local" and "remote" qualify the resolver and its binding.
This was discussed during the #did meeting on 18 September 2025.
View the transcript
w3c/did-resolution#182
TallTed: this PR confuses me. I made a comment to replace "remote DID resolver" to "resolver of remote DID".
<Zakim> JoeAndrieu, you wanted to ask about conformance class
<KevinDean> +1
JoeAndrieu: TallTed's comment made me realize that we are defining conformance classes.
… Maybe that's how we should explain it, and "remote" should indeed apply to the resolver.
markus_sabadello: I also find in the title of the issue confusing
… "https binding" is about how the client interacts with the resolver, not how the resolver interacts with other components
JoeAndrieu: we need to figure out where to say that we have 2 conformance classes, and how to define them.
… Probably in this PR, but not in this section.
<Wip> Seems like it should go here https://
JoeAndrieu: But we do need to define "remote resolver"
Wip: [comment about two conformance classes] I'll add a comment in the issue for otto
@ottomorac we discussed this on the call today and agreed that this PR should add another conformance class to https://w3c.github.io/did-resolution/#conformance.
Specifically the remote DID resolver class, that you are mentioning in the current text. This is a conformant DID resolver that implements HTTP get binding.
Added the 2 conformance classes and updated the terms section to also refer to them.
Added the 2 conformance classes and updated the terms section to also refer to them.
@ottomorac this confuses me. The PR hasnt changed. Perhaps you forgot to push?
Hmm reviewing the conformance classes I was a bit confused actually.
I thought we are adding a new conformance class remote DID resolver. This is a conforming DID resolver (existing conformance class) that implements HTTPS binding the resolve API. Makese me think we might need a remote DID URL dereferencer class also though.
I did not think this was about more generically, whether the DID resolver would make network calls as part of executing a resolution request. Which is how I read the current text.
This was discussed during the #did meeting on 02 October 2025.
View the transcript
w3c/did-resolution#182
Make https binding mandatory #182
Wip: Yes the conformance classes needed to be added...
Wip: I thought we are adding a new conformance class remote DID resolver. This is a conforming DID resolver (existing conformance class) that implements HTTPS binding the resolve API. Makes me think we might need a remote DID URL dereferencer class also though.
markus_sabadello: Yes... in the spec we define local binding and remote binding...
maybe the conformance classes can directly reference those 2 terms...
Manu: Maybe we have a base "conformance class" and another "remote resolver" conformance class....
Examples of conformance classes: https://
Manu: The language I was expecting would be a little closer to what the VCALM spec is doing, by directly indicating which sections of the spec the class needs to align too...
Manu: perhaps we layer it using this base conformance class... and then the other
Wip: Yes I think we can just have "conforming did resolver" which includes the local... and then have the additional "remote resolver" class...
Manu: Yes agree with that....
So "remote resolver" would just be a class that also implements https binding...
markus_sabadello: Yes but https binding is not the only remote binding...
Manu: Then a conforming did-resolver is the one that implements section 11.1, or we just define a conforming "https did resolver"....
Wip: Do we also need 2 classes to for the DID URL de-referencer....
Manu: Perhaps not....
Manu: So let's keep base conformance class and add a single conformance class for "https did resolver"
Updates done:
- Indicated that base "conforming DID resolver" also implements local binding
- Defined the "https did resolver" which is a conforming did resolver that also implements https binding
* Indicated that base "conforming DID resolver" also implements local binding
What is the reason for this? To me this doesn't make much sense.. In my mind a "conforming DID resolver" could implement a local binding or remote binding or both.
* Defined the "https did resolver" which is a conforming did resolver that also implements https binding
This is great, I now understand the idea of conforming classes in relation to the HTTP(S) binding.
This was discussed during the #did meeting on 09 October 2025.
View the transcript
w3c/did-resolution#182
ottomorac: On my PR, per guidance from the group, there should be a base conforming DID resolver, that includes a local binding. I don't know how explicit we want to be about including the local binding.
… I also defined an HTTPS resolver that implements an HTTPS binding.
… I don't know how explicit we need to be about a local binding being present in a resolver.
… I'm happy to defer to what the group has here, and I see that there are comments from Will and others in the issue.
manu: I think we're almost there for this one. I found a couple of nits. I don't know if local binding is a subsection of resolving.
ottomorac: It's a separate section.
manu: I don't think we need to say must implement. We should probably point to the section on local binding algorithms as it's pointing to the definition right now.
… Point to the section that contains that definition and the algorithm rather than just the definition.
… The only other feedback there is, I know why we mentioned "Let's Encrypt", but at some point they may be the AOL and CompuServe of today. We should avoid brand names.
markus_sabadello: Maybe I don't remember correctly, I was a bit surprised to see that the confirming DID resolver is defined to implement a local binding.
… I didn't understand that. I thought a conformant resolver could have any binding they want.
… Maybe we discussed it last time and I don't remember.
wip: I think I agree with Markus. There is no conformance statement about implementing local binding.
… A conformant resolver is any implementation of the "resolve" algorithm, then we're subclassing that and constraining it for HTTPS.
manu: I thought we did have normative statements for local binding. If we don't, then I agree with Markus and Will. Conformant statements are about implementation.
… Whatever section we point to, an implementer must say that that's what they implement.
… My understanding is that every resolver must implement local binding, but I may be wrong as I'm not fully familiar with the spec.
wip: A conformant DID resolver says nothing about the binding, only about the functionality.
… We then extend it to say that a conformant HTTPS resolver must have an HTTPS binding.
ottomorac: Where in the spec should we mention HTTPS binding?
manu: Will, I think what you describe is too abstract. What we're saying is that you can do A or B, but I'm writing a test suite that has to call A or B. What piece of software and I writing to do that?
… If the the first thing is that abstract, the only useful conformance class is HTTPS, because I can write for that.
… To me, a library API call is still testable, but I need to read your docs to write the test.
… Implementers want to advertise something concrete like an HTTPS resolver, not something abstract.
markus_sabadello: I agree that we should require HTTPS as a binding. Local binding is very abstract.
… DID resolution has already been defined as an abstract function. We're not saying that every DID resolver must implement every protocol.
<ottomorac> https://
markus_sabadello: We're not really defining a library interface. Local binding is abstract. Remote binding is abstract. HTTPS binding is a concrete remote binding.
ottomorac: Maybe this is the section I can point to.
<Zakim> manu, you wanted to propose some text for "local binding" as "inputs and outputs"
ottomorac: Keep the other class as having normative statements about what needs resolving, then subclassing as necessary.
manu: The other way that you can define conformance classes is as inputs and outputs. Whatever we want to call it, we're saying that for local you're implementing section 4. It has an input DID and an output resolution result.
… We can save the concrete expression.
… This can get us towards something like did:key being something that we resolve.
… We can get to something like, "DID resolver implements section 4, DID resolution, with a concrete input (DID and options) and output (DID resolution result)".
… By using the word concrete, it's not abstract anymore. It's JSON or CBOR or something.
<markus_sabadello> q#
manu: What we should probably have one here is provide a concrete definition.
<ottomorac> A did resolver implements section 4 did resolution with a concrete input and a concrete ouput. Concrete input being did, and output being a concrete did resolution result..... and mention output format
manu: If we say concrete, it's not as abstract, but we should probably pick a format such as JSON.
wip: I think that's what it's already saying. A conformant implementation is any hardware or software that implements section 4.
… I would prefer a description of conformance that is independent of binding.
markus_sabadello: We do have a concrete binding in section 8.
<Zakim> manu, you wanted to speak to interop concerns w/ the way the language is written now.
manu: That's better. It's normative but it has no normative statements in it.
… Will, what are you going to implement? What's your input and output format for a conforming DID resolver?
… "I'm going to implement YAML and we're both conformant and we're not interoperable."
… If we at least lock down the input and output format to JSON we've got a good, testable suite.
markus_sabadello: I understand conformance classes and being interoperable with a concrete format. In practice, what people do, is for local binding the inputs and outputs are objects in application memory.
… I don't think there's ever a JSON object in a programming language implementation in memory.
manu: We would have to figure out how to write conformance language to get to something concrete and testable.
… I don't know how we test in-memory conformance. We can't necessarily test across languages. We have to get it to an interoperable format.
… If the boundary is not well defined, the we don't have interoperability.
markus_sabadello: I understand. I think that makes sense. In sections 8 and 9, we have concrete statements about DID resolution results and DID dereferencing results.
… We should add the same for inputs.
manu: +1 to that. Maybe we could do something simpler and say that a concrete implementation that takes a conformant DID as input produces a concrete serialization.
… I think we can just say it takes a DID as input and provides a DID resolution result as described in section 4, DID resolution.
… It doesn't have to be serialized to JSON but it must be serializable to JSON.
… Then you have a concrete implementation.
… We should probably move this language down into the DID resolution section and say that implementations must provide results that can be serialized to JSON.
<ottomorac> Normative statement: Implementations must provide results that are serializable to JSON.
wip: I know this is taking a while, I just wondered where we want to fix this. Otto's PR is good to go, what we're talking about here is the conformance statement itself. We can address this in another PR.
manu: +1, let's end Otto's suffering. I think these are separable things.
Simplified the change per the WG discussion on 9-Oct.
The conformance class discussion is moved to https://github.com/w3c/did-resolution/issues/213