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

Hi Kaveh,

A normative DANE-EE profile that did:web high assurance and did:dns can both
point at seems clearly worth doing, and doing once. I came at DNS from the
other
end, as a member of the Neo-Brahmi Generation Panel on the Neo-Brahmi root
zone LGRs,
 so mostly what a label is permitted to be rather than what a key is bound
to.

One question from that side, and it may already be in scope for you.

DNSSEC and DANE bind a key to a name and let a verifier check it offline.
What
they do not carry is anything about the holding of the name. Registrant
lapse
and a drop catch, a UDRP transfer, or a registry level failure all move the
name
to a different party, and the new holder publishes their own TLSA record.
Every
signature verifies. The chain to the IANA root is intact. The anchor has
changed
hands and no relying party that trusted it last week is told.

For a TLS certificate this matters less, because sessions are short and the
certificate has its own lifetime and revocation story. For an identifier
that
other parties have already recorded and may re-verify much later, agent to
agent
or across an organisational boundary, the same silence is a different kind
of
gap: the verifier gets a correct answer to the question it asked, and no
signal
that it is now asking about a different party.

Is continuity of holding something you see the profile addressing, even as a
statement of what it deliberately does not cover? I am not suggesting DANE
should carry registry state. But a verifier that caches a binding might
reasonably want to know that the question has an answer somewhere, and
today I
do not think it does.

Happy to help on the DNS side text if useful.

Anivar A. Aravind

--
https://anivar.net
Newsletter: http://layer8.anivar.net/
LinkedIn: https://www.linkedin.com/in/anivar/


On Fri, Jul 17, 2026 07:14 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
>