w3c
Should the HTTPS binding be mandatory?
This is a concrete question that has been identified in https://github.com/w3c/did-resolution/issues/83#issuecomment-2305041064 and https://github.com/w3c/did-resolution/issues/83#issuecomment-2349135848 on the question whether the HTTP(S) binding should be mandatory to implement.
What does mandatory mean in this case? Does this affect resolver, or DID methods, or something else?
This was discussed during the #did meeting on 16 January 2025.
View the transcript
w3c/did-resolution#93
wip: I'm going to go through these in order starting with Issue 93
… Issue 93 - should we be making https binding necessary
markus_sabadello: interesting question, came up in comment earlier in working group related to different issue
… to explain, https binding how client can invoke function over http endpoint
… don't always need it, when you resolve did, no need to ?? can be done locally
… therefore this question came up who would have to implement it, something every DID method would have to provide or something a resolver would have to support as a client to talk to ? resolver, what this topic is about. any thoughts?
Wip: I think to me, I know Joe cares about this, if everyobody is exposing http url way to have interoperability
<Zakim> JoeAndrieu, you wanted to say I think its methods, not the resolver that has the requirement
Wip: challenge when I'm devoting resolvers locally that don't have to be ??
JoeAndrieu: I do think the best route for an ecosystem is for every method to have at least one http resolver so that if you run into such a DID there is a way your software already has the interfaces if there is already a resolver. don't think we need every one to have a binding, but there must be one that has that binding.
markus_sabadello: agree with Joe that this is a conversation that happens around interoperability, if you have the https biding you do increase interop
. . . where this feels strange is did: key and did:? Very weird to call a remote https endpoint to resolve did:key, who would host and be in charge of deploying a resolver
Wip: I think it sounds like a good requirement to ask DID methods to maintain https, not sure where it should go. DID: Core Spec? DID: Resolver?
pchampin: point to Markus about did:key, think it would make sense to include a https endpoint, if you don't know the DID method you can rely on ? but you can generate the did document from the DID itself. Not absolutely stupid in my opinion to have this service but suboptimal
<Zakim> JoeAndrieu, you wanted to say software not service
. . . not sure if we made it a requirement to have an http endpoint, but kind of thing that should be available in DID Method Registry / List, maybe criteria in Rubric, is it usable in one or several?
JoeAndrieu: interesting disconnect in the way we're talking about this. I would be very opposed to this, could have a local, didn't realize that if you had to do https locally, that would be annoying. If you had to do did:key, not so much that someone would run a resolver for did:key, but a piece of software, note app or apache app
Wip: next steps to move this from discuss to action
<Zakim> JoeAndrieu, you wanted to say I don't think a URL for a resolver is the right solution. this, IMO, is a DID method requirement, hence part of did core
markus_sabadello: not something that would be part of Method Spec. Think what Joe said was also interesting. Add to Extension Registry where ? Link in Registry to public resolver
JoeAndrieu: very opposed to putting live URLs in registry to use for a resolver. Methods themselves, if we want this form of inter, goes into DID:Core - any DID method that wants to be conformant should have one resolver that you can access of HTTP
<Wip> https://
Wip: would also feel uncomfortable putting it in Registry, would think it should go into did-core. But, can we make that change as a group?
markus_sabadello: so requirement would be there has to be one piece of software or one implementation
<Zakim> bigbluehat, you wanted to ask if we are talking about referencing HTTP software then? or some sort of protocol mapping?
Wip: i was thinking more did methods SHOULD
bigbluehat: I just want to clarify what we're talking about. When Joe talks about it t sounds like a piece of software, open source did protocol wrapper, which ? easy route would be for me to get that software and communicate over http, never implement more of the value of the DID method. If implementation is one for each method, raises questions
… about who is maintaining, proprietary did methods, how does this work?
… or are we saying with your did method, provide some protocol mapping, here is how it should map into your did method, work you would have to do if you want to stay at http layer. maybe I've missed the driver behind this, apologize if this seems out of synch
Wip: first I will say is I want to move on from the discussion, didn't get to Actions, but appreciate if people can add their next steps to Issue. Could this be a pathway to interoperability to resolve it without having to implement ? kind of a fallback. Unless any final comments, would like to move on
<pchampin> +1 to consider those as fallbacks
This was discussed during the #did meeting on 19 June 2025.
View the transcript
Should the HTTPS binding be mandatory? #93
<ottomorac> w3c/
ottomorac: Discussion was held in January as to whether this is something that Resolvers or DID methods need to define and whether an https endpoint is mandatory.
… Also wondering if this belongs in did core
markus_sabadello: This should not be in DID core. It is DID resolution where we have the binding defined for resolution
… We just need to decide if it should be mandatory
<Zakim> JoeAndrieu, you wanted to say because DID methods need compatible resolvers.
JoeAndrieu: markus has a good point. What is important in DID core is that DID methods to be conformant must have at least one implementation of a resolver with a https binding
… THis is not a requirement on all resolvers
… This is a requirement on DID methods for compatibility
… It is the DID method that needs to provide this as a software component
Wip: If we agree that this is a requirement for the did method, which sounds reasonable to ask for an https binding, ideally this requirement might need to go into did-core... perhaps challenging because did-core is just in maintenance mode...
Remember that HTTPS relies on the TLS certificate stack, and doesn't work on machines with non-routable IP addresses, such as those commonly found within VPNs and/or LANs (e.g., 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12).
Technically, you can still use non-routable IP addresses, e.g., using self-signed certs whose authority the caller has added to its root authorities table.
THAT said, it's still a valid point, as self-signed SSL certs are a well-known PITA, both for security and configuration reasons.
This came up in our discussion that lead to #160, in which we want to see the signed provenance of resolution metadata from all resolvers who may be in the resolution chain.
We discussed possibly shifting to requiring EITHER
- an https binding (with TLS as verification of provenance)
- an http binding with required attached proof (using data integrity for provenance)
The latter gets around the TLS challenge with IP-address URLs, meaning you don't need a TLS stack to secure DID resolution.
In fact, the more I think of this, the more I like the tradeoffs of being able to use HTTP but still have confidence in the integrity of the response.
This was discussed during the #did meeting on 21 August 2025.
View the transcript
Should the HTTPS binding be mandatory? #93
<ottomorac> w3c/
<ottomorac> Raises the question of whether an HTTPS binding—the ability for resolvers to expose a DID resolution endpoint over HTTPS—should be mandatory
<ottomorac> There was broad agreement that the decision on whether such a binding should be mandatory should reside with the DID controller or be exposed as metadata—rather than baked into every DID method—though opinions differed on whether this requirement belongs in DID Core given its more maintenance‑mode status
manu: Thinks that it should be mandatory because otherwise how do you test anything. It is the only interface in the spec. Not sure how this impacts the DID Controller. Not bad to use DNS or DNS infra, DNS allows for getting a TLS Cert for an IP. Seems like not a big ask to require endpoint over HTTPS and we need something that is testable.
Wip: What is the concrete action we need to take. Need something in the spec and who will do that?
manu: Is in the HTTPS binding section that HTTPS is mandatory, others may be provided. Mandatory to use TLS, but not DNS. Can use Let's Encrypt-style IP certs. PR is needed.
Wip: It is mandatory for resolvers -- all resolvers -- to be considered compliant. Or is it that DID Methods provide an implementation with HTTPS binding?
manu: No connection between DID Resolution and DID Methods. Don't think there is a connection. If we don't mandate some interface, the TAG and reviewers will say nothing is testable. How are you testing this? Response is to say HTTPS by most implementations, but... Better to mandate and see if anyone complains about why they won't do it.
Wip: Makes sense. Anyone else care about this? Implementors that just implement a library, but not an implementation don't care about it. But if this the route, let's do it.
manu: We could deal with this with a classes of implementation. Could provide the nuance that separates out libraries from resolvers deployments that includes HTTPS and all of the criteria. Two conformance classes -- library and more than a library that conforms.
<Zakim> JoeAndrieu, you wanted to speak to small device use cases in addition to libraries
Wip: That makes good sense. I also don't want to take this on. If no one takes this, then we will wind up repeating this conversation.
JoeAndrieu: I like Manu's suggestion of classes. Constrained devices class where they don't want to deal with the TLS stack. Could secure the context with Data Integrity. Not sure that is needed.
manu: As long as we need it open, and not saying they can't do that. May want to in version 1.1 to clarify further. Spec won't stop them from doing it.
ottomorac: I'll take this one. With help from the community.