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

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