Re: Introduction: Kaveh Ranjbar, DNS-anchored trust for did:web and did:dns

Hi Kaveh,
I think such a normative profile that the various DNS-using DID methods can
point to would be very helpful!

Dmitri

On Fri, Jul 17, 2026 at 9:44 AM 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
>