- From: Kaveh Ranjbar <kaveh@whisper.security>
- Date: Sat, 1 Aug 2026 11:59:53 +0100
- To: public-credentials@w3.org
- Cc: alex.tweeddale@gmail.com
- Message-ID: <CA+kObRKGOB60SKfYZt87bLomod5adNhTkjBz19D5R4WGpsd0mA@mail.gmail.com>
Alex, Thank you, this is exactly the thread I was hoping to pick up. The CIRA "High Assurance DIDs with DNS" work is what I pointed at in my introduction, so hearing it carried on at Trust over IP as HAVID, with you, Jesse, Drummond, Scott and Tim, tells me most of the hard thinking is already done and I have been reinventing corners of it. I will read the spec properly this week and come back here and to the repo with real comments rather than a wave, and if it helps get HAVID off pause I am glad to take the DNS and DANE side, that is the part I can move quickly. Where I think the two efforts meet is the DNS binding. The profile I put in front of this group, now posted as an Internet-Draft that Anivar Aravind and I co-authored, is a single normative DANE-EE profile, TLSA 3 1 1 over a DNSSEC-signed name, that did:web high assurance, did:dns and did:webvh can all point at rather than each writing their own. If HAVID's DNS anchor is the same mechanism, it could reference the profile for its DNS binding so the normative text lives in one place instead of two, and I would rather serve your spec that way than run a parallel one. I will know how well it fits once I have read HAVID closely, and I am happy to be told it does not. To close the loop I owe this group, it is up as -01, and the continuity-of-holding section in it is Anivar's, both the question, which he raised on this thread, and the text that answers it: https://datatracker.ietf.org/doc/draft-ranjbar-dane-did <https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ranjbar-dane-did/&source=gmail&ust=1785667194535000&sa=E> More once I have been through the ToIP work. All the best, K. On Mon, Jul 27, 2026 11:30 AM, Alex Tweeddale <alex.tweeddale@gmail.com> wrote: > Hi Kaveh, > > Great discussion topic. The "High Assurance DIDs with DNS" work you > referenced continued until recently at Trust over IP under the High > Assurance Verifiable Identifiers (HAVID) task force. This was continued by > myself, Jesse, Drummond Reed, Scott Perry, Tim Bouma and others. > > There is now an extensive spec on the topic of bridging DIDs with X.509 > and DNS > <https://trustoverip.github.io/high-assurance-verifiable-identifiers/>. > The task force is currently on pause due to myself and Jesse having other > commitments and losing the time to get this to v1. > > We'd massively appreciate your review of the work (and the wider CCGs > review), and hopefully we can push this towards a formal published spec! > > The GitHub repo with the spec is here: > https://github.com/trustoverip/high-assurance-verifiable-identifiers > > All the best, > > Alex > > On Fri, Jul 17, 2026 at 4:44 PM Kaveh Ranjbar <kaveh@whisper.security> > wrote: > >> Hi all, >> >> I have just joined the group and wanted to introduce myself. My >> background is the internet's naming and numbering layer, six years on the >> ICANN Board and fifteen at the RIPE NCC, so I come at credentials from the >> DNS and registry side rather than the wallet side. >> >> What brought me here is the DNS-anchored trust question. I recently >> started contributing to the did:dns method, on making DNSSEC normative and >> adding an optional DANE-EE / TLSA key binding, so a verification method's >> key can be checked against a DNSSEC-signed name and chained to the IANA >> root.. Reading around, I keep seeing the same primitive surface on this >> side of the fence: did:web already stands on a DNS name, today via the >> WebPKI certificate at that name, and the "High Assurance DIDs with DNS" >> draft from Jesse Carter and Jacques Latour at CIRA reaches past that to >> DNSSEC and DANE/TLSA to harden it. >> >> That overlap is the part I find interesting. I would like to help make >> the DNS side of it rigorous and, ideally, shared: one normative DANE-EE >> profile (3 1 1, per RFC 7671 and 7218, chaining back to RFC 6698) that both >> did:web high-assurance and did:dns could point at, rather than each >> reinventing it. I have running code for this at the per-name level, so I >> can bring implementation experience rather than just opinions. >> >> To put a concrete question on the table: is there appetite to converge >> did:web high-assurance and did:dns on a common DANE-EE key-binding profile, >> or are these better kept as method-specific choices? I am happy to bring it >> to a Tuesday call if that is the better venue. >> >> For context only, I co-founded Whisper Security, but I am here as a DNS >> person and not to pitch anything. >> >> Kaveh Ranjbar >> >
Received on Saturday, 1 August 2026 11:01:16 UTC