DANE-Anchored Identity for Network Clients, Devices, and Autonomous Agents
draft-ranjbar-dane-anchored-identity-00

Network Working Group                                         K. Ranjbar
Internet-Draft                          Whisper Security (viaGraph B.V.)
Intended status: Informational                              21 July 2026
Expires: 22 January 2027

  DANE-Anchored Identity for Network Clients, Devices, and Autonomous
                                 Agents
                draft-ranjbar-dane-anchored-identity-00

Abstract

   A rapidly growing set of protocols for autonomous agents, connected
   devices, and machine workloads bootstraps trust in an endpoint's
   public key over the Web PKI together with an HTTPS .well-known fetch,
   a bespoke certificate authority, or a centralized registry.  These
   approaches inherit domain-takeover exposure, depend on a reachable
   call-home endpoint, are not verifiable across organizational
   boundaries, and frequently provide no timely revocation.  This
   document describes a complementary identity model in which an
   endpoint's key is anchored directly in DNSSEC-signed DNS using DANE
   (a TLSA record), bound to a routable address whose reverse and
   forward names are served from a signed zone, and described by RDAP.
   The model, consistent with the architecture developed in the DANE
   Authentication for Network Clients Everywhere (DANCE) working group,
   lets any relying party verify an endpoint's identity from stock DNS
   tooling with no account or private trust root, and lets the
   identity's holder revoke it worldwide at DNS TTL.  It is intended as
   an anchor that existing agent-, device-, and content-identity schemes
   can adopt without abandoning their own transports or object formats.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 January 2027.

Ranjbar                  Expires 22 January 2027                [Page 1]
Internet-Draft           DANE-Anchored Identity                July 2026

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   4.  DANE-Anchored Identity  . . . . . . . . . . . . . . . . . . .   5
     4.1.  Anchoring a Key to a Name . . . . . . . . . . . . . . . .   5
     4.2.  Binding the Name to a Routable Address  . . . . . . . . .   6
     4.3.  Registration Metadata via RDAP  . . . . . . . . . . . . .   6
     4.4.  Revocation at DNS TTL . . . . . . . . . . . . . . . . . .   7
   5.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Relationship to Existing Work . . . . . . . . . . . . . . . .   8
   7.  Deployment Experience . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Identity for autonomous agents, connected devices, and machine
   workloads is being specified in many venues at once.  A recurring
   pattern is visible across them: the identity of an endpoint, its
   signing or authentication key, is bootstrapped over the Web PKI and
   discovered through an HTTPS fetch of a .well-known resource, through
   a scheme-specific certificate authority, or through a centralized
   registry that the relying party must call at verification time.
   Examples include agent cards fetched over HTTPS, HTTP Message
   Signature key directories, content-provenance trust anchors published
   as a JSON Web Key Set, and per-scheme device PKIs.

Ranjbar                  Expires 22 January 2027                [Page 2]
Internet-Draft           DANE-Anchored Identity                July 2026

   Each of these mechanisms works, and this document does not seek to
   replace any of them.  For a relying party that is itself a web
   client, already operating inside a WebPKI-secured transaction with
   the origin it is verifying, discovering the key over that same web
   endpoint is the pragmatic choice, and anchoring it elsewhere buys
   little: the transaction rides on the WebPKI regardless.  The
   limitations below bite in a different setting, one these schemes
   increasingly have to serve: verification that happens outside any
   such transaction.  Examples include an agent verifying another agent,
   a workload authenticating across an organizational boundary, a non-
   HTTP protocol, or a key directory that lives in a different trust
   domain than the resource being accessed.  There, the authority's web
   endpoint is a distinct trust and availability dependency, not a free
   side effect of a connection the verifier was making anyway.

   In that setting, the following limitations follow from where the key
   is anchored rather than from how it is used:

   *  *Domain-takeover exposure.* When trust in a key rests on the
      ability to serve an HTTPS resource under a domain, an adversary
      who transiently controls that domain (through a lapsed
      registration, a hijacked name server, or a mis-issued certificate)
      controls the identity.

   *  *Call-home dependency and privacy.* Verifying an identity by
      fetching a document from the subject's server reveals to the
      subject which relying parties are checking it, and fails when that
      server is unreachable.

   *  *No cross-organization verifiability.* Keys anchored in a private
      or scheme-specific root cannot be validated outside the ecosystem
      that operates the root; cross-organization trust requires out-of-
      band cross-certification.

   *  *Weak or absent revocation.* Several device-identity profiles
      issue long-lived credentials with no CRL or OCSP, leaving no
      timely off-switch.

   DNSSEC-signed DNS [RFC4033] [RFC9364] together with DANE [RFC6698]
   [RFC7671] addresses these at the anchor for the party positioned to
   use it: an operator that already controls, and can sign, the zone
   under which its identities live.  For such an operator, DNSSEC is not
   an additional deployment step bolted onto identity provisioning; it
   is the same act, the identity and its signed anchoring record
   provisioned together.  This document does not propose that the long
   tail of unsigned web origins adopt DNSSEC to participate.  Where an
   origin is unsigned and the verifier is a web client, an HTTPS .well-
   known fetch remains the reasonable path.  This document describes the

Ranjbar                  Expires 22 January 2027                [Page 3]
Internet-Draft           DANE-Anchored Identity                July 2026

   anchor for the complementary case, operator-controlled, cross-
   organization, and non-transaction verification, where a key published
   as a TLSA record under a DNSSEC-signed name is verifiable by any
   party from the DNS root of trust, without contacting the subject and
   without a private CA; can be removed, revoking the identity, within a
   DNS TTL; and is verifiable across every organizational boundary
   because the name is part of the global DNS.  This is the model the
   DANCE working group has developed for DNS-bound client and device
   identity [I-D.ietf-dance-architecture] [I-D.ietf-dance-client-auth].
   This document generalizes that model into an identity anchor that
   agent-, device-, and content-identity schemes can adopt, and
   describes the additional bindings (a routable address and RDAP
   registration metadata) that make the anchor a complete, operable
   identity.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document uses DNS terminology from [RFC8499].

   DANE-anchored identity:  The public key of an endpoint, published as
      a TLSA record under a DNSSEC-signed name and thereby verifiable
      from the DNS root of trust.

   Anchoring name:  The DNSSEC-signed domain name under which an
      endpoint's TLSA record is published.  In this document the
      anchoring name is derived from a routable address assigned to the
      endpoint (see Section 4.2).

   Relying party:  Any party that verifies an endpoint's identity.  A
      relying party needs only a validating DNS resolver; it needs no
      account, API key, or membership in a private trust ecosystem.

3.  Problem Statement

   The mechanisms surveyed in Section 5 anchor an endpoint's key in one
   of three places: the Web PKI plus an HTTPS .well-known document, a
   scheme-specific certificate authority, or a centralized registry.
   None of these anchors is the DNS, and so none inherits DNSSEC's
   properties.  That is not by itself a deficiency: DNSSEC deployment is
   uneven, and for a verifier already inside a WebPKI transaction with a
   web origin, an .well-known fetch over that transaction is lower-
   friction than requiring the origin to sign its zone.  The gap this

Ranjbar                  Expires 22 January 2027                [Page 4]
Internet-Draft           DANE-Anchored Identity                July 2026

   document addresses is narrower and does not depend on universal
   DNSSEC.  It is the case where (a) the identity operator controls the
   anchoring zone, so signing it is part of provisioning the identity
   rather than an external prerequisite, and (b) the relying party
   verifies outside any WebPKI-secured transaction with the subject, so
   the web origin's continued control and availability are a real,
   separate dependency.

   The goal of this document is to describe a single anchor that, for
   operators who sign their own anchoring zones, (a) is verifiable by
   any relying party from the DNS root of trust, (b) requires no call-
   home to the subject, (c) is valid across organizational boundaries,
   and (d) can be revoked worldwide within a DNS TTL, adoptable
   underneath the existing agent-, device-, and content-identity schemes
   without disturbing their transports or object formats.  It is
   explicitly not a proposal to require DNSSEC of parties that do not
   already operate signed zones, nor a replacement for .well-known
   discovery in the web-client case.

4.  DANE-Anchored Identity

4.1.  Anchoring a Key to a Name

   An endpoint holds a key pair whose private half never leaves the
   endpoint.  The endpoint's public key is published as a TLSA record
   [RFC6698] under a DNSSEC-signed anchoring name.  The RECOMMENDED TLSA
   usage is DANE-EE with a SubjectPublicKeyInfo selector and a SHA-256
   matching type (3 1 1), which binds the identity to the key itself
   rather than to any issuing authority, consistent with
   [I-D.ietf-dance-architecture].  A relying party retrieves the TLSA
   record, validates the DNSSEC chain from the root, and thereby learns
   the endpoint's authentic public key with no dependency on the Web PKI
   and no fetch from the endpoint.

   Because the binding is to the SubjectPublicKeyInfo, an endpoint MAY
   present the same key it already uses at another layer (for example
   the key in a TLS client certificate, an application-instance
   certificate, or a signed object), so that adopting a DANE anchor
   requires no re-keying of already-deployed endpoints.

   This document specifies the TLSA record [RFC6698] as the anchoring
   record because it is deployable today with existing DNS and DANE-
   aware tooling, and because the DANCE architecture
   [I-D.ietf-dance-architecture] already defines its use for endpoint
   keys.  The TLSA record carries an implication of TLS use.  Where the
   anchored key serves a non-TLS purpose, for example an HTTP message
   signature, a purpose-specific resource record type, or a signed
   identity envelope carried in a TXT record so that the record type

Ranjbar                  Expires 22 January 2027                [Page 5]
Internet-Draft           DANE-Anchored Identity                July 2026

   itself asserts nothing, may be a cleaner long-term binding; this is
   noted as an open design question, not resolved here.  The anchoring
   model, a DNSSEC-signed name binding a key by its
   SubjectPublicKeyInfo, is independent of the record type chosen to
   carry it.

4.2.  Binding the Name to a Routable Address

   To make the identity reachable as well as verifiable, the anchoring
   name is associated with a routable address assigned to the endpoint.
   The address's reverse name (for IPv6, under ip6.arpa) is served from
   a DNSSEC-signed zone and resolves to the anchoring name, and the
   anchoring name resolves back to the address.  The endpoint's TLSA
   record is published relative to this name.  An address bound in this
   way is not a disposable label that an intermediary can rotate: it is
   a cryptographic fact that only the holder of the corresponding
   private key can stand behind, because a relying party that reaches
   the address can require the peer to prove possession of the DANE-
   anchored key.  The address is chosen as the anchor because it is the
   one identifier actually present, unforgeably, on every packet the
   endpoint sends.  When an endpoint egresses or opens a connection, the
   wire carries a source address, not a name, so a relying party can
   attribute and verify the peer at the moment it acts, with no out-of-
   band lookup and nothing to trust first.  A name has to be asserted
   and then resolved; the address asserts itself.  Binding the DNSSEC-
   signed anchoring name to that address carries this property into a
   form any relying party can verify from the DNS root of trust.

   This document does not mandate a particular address assignment or
   key-to-name derivation.  It requires only that the anchoring name be
   DNSSEC-signed, that the TLSA record bind the endpoint's public key,
   and that the reverse/forward names be mutually consistent.

4.3.  Registration Metadata via RDAP

   Contact, holder, and status metadata for the identity are published
   through RDAP [RFC7480] [RFC9082] [RFC9083] anchored on the address.
   RDAP gives a relying party a standard, machine-readable way to answer
   "who is accountable for this identity" without a proprietary lookup
   service, and complements the DNS anchor with the registration-data
   layer that DANE alone does not carry.

Ranjbar                  Expires 22 January 2027                [Page 6]
Internet-Draft           DANE-Anchored Identity                July 2026

4.4.  Revocation at DNS TTL

   An identity is revoked by removing or replacing its TLSA record.
   Because relying parties validate against live DNS, a revocation
   propagates within the record's TTL, giving a global off-switch on the
   order of seconds to minutes rather than the lifetime of a
   certificate.  Operators SHOULD choose TTLs that balance revocation
   latency against resolver load, and SHOULD treat the anchoring zone's
   DNSSEC key management as security-critical (see Section 8).

5.  Applicability

   The anchor described in Section 4 is deliberately independent of any
   single application.  The following schemes each define a place where
   an endpoint's key is asserted; each can carry, or be complemented by,
   a DANE-anchored identity without changing its wire format:

   *  *Autonomous agents.* Agent-interoperability protocols publish an
      "agent card" whose signature key is discovered over HTTPS; a DANE
      anchor lets a counterparty verify that the key belongs to the
      claimed domain from DNS, independent of transport TLS.  The Agent
      Identity & Discovery convention [AID] already places an agent
      record in DNS TXT but does not require DANE; DANE closes that gap.

   *  *Automated HTTP clients.* HTTP Message Signature key directories
      [I-D.meunier-web-bot-auth-architecture] are fetched over HTTPS
      only; a DANE anchor provides a DNS-rooted alternative to the
      .well-known directory.

   *  *Connected devices and industrial assets.* Device identity
      profiles bind a globally unique name to a certificate held by the
      device (for example an OPC UA ApplicationUri, an IEEE 802.1AR
      IDevID, or an IEEE 2030.5 LFDI); a DANE anchor makes that key-
      bound name publicly verifiable and revocable across the
      vendor/integrator/operator boundary.

   *  *Network functions.* In service-based architectures a function's
      instance identifier already appears in its certificate; anchoring
      it via DANE makes peer identity verifiable at trust boundaries
      independent of a private operator PKI.

   *  *Content provenance.* Content-provenance trust anchors published
      as an HTTPS-fetched JSON Web Key Set [C2PA-WDTA] can instead, or
      additionally, be anchored in DNSSEC via DANE, removing the domain-
      takeover and call-home exposure the authors themselves note.

   In every case the DANE anchor is complementary: it changes where the
   key is rooted, not how the application uses it.

Ranjbar                  Expires 22 January 2027                [Page 7]
Internet-Draft           DANE-Anchored Identity                July 2026

6.  Relationship to Existing Work

   This document is consistent with, and depends on, the DANCE
   architecture [I-D.ietf-dance-architecture] and client-authentication
   work [I-D.ietf-dance-client-auth]; it can be read as a deployment-
   oriented generalization of that architecture to agent and content
   identity.  It is complementary to workload-identity efforts
   [I-D.ietf-wimse-arch], which define identity documents and their
   exchange but not a DNS anchor, and to the did:dns method [DID-DNS],
   which stores decentralized-identifier data in DNS but does not
   mandate DNSSEC or use DANE.  Where those efforts define the identity
   object or its exchange, this document defines the anchor beneath
   them.

7.  Deployment Experience

   The model has been implemented and operated in production on real,
   registered address space.  The operator announces an IPv6 space under
   a public Autonomous System, serves DNSSEC-signed forward and reverse
   zones for per-endpoint addresses, publishes DANE-EE TLSA records
   binding each endpoint's key, and exposes RDAP for each address.
   Relying parties verify identities using only dig, kdig, and curl
   against public resolvers, with no account.  This demonstrates that
   the anchor is operable with existing DNS, DNSSEC, and RDAP
   infrastructure, and that verification is possible from unmodified
   client tooling.  Detailed operational parameters are out of scope for
   this document.

8.  Security Considerations

   The security of a DANE-anchored identity rests on the DNSSEC
   validation chain of the anchoring zone.  Relying parties MUST
   validate DNSSEC and MUST NOT accept a TLSA record whose chain does
   not validate to a trusted anchor.  The operator of the anchoring zone
   MUST protect the zone-signing and key-signing keys accordingly;
   compromise of those keys is equivalent to compromise of every
   identity anchored in the zone.

   Because the anchor binds an endpoint's public key rather than an
   issued certificate, there is no issuing-CA layer to compromise, but
   there is also no external party attesting to the subject's real-world
   identity beyond the RDAP registration data; applications that require
   such attestation MUST obtain it by other means and treat the DANE
   anchor as proof of key control, not of provenance.

Ranjbar                  Expires 22 January 2027                [Page 8]
Internet-Draft           DANE-Anchored Identity                July 2026

   Revocation depends on DNS propagation; an operator cannot revoke
   faster than the TTL previously served.  Operators SHOULD keep
   anchoring-record TTLs short enough that revocation is timely for
   their threat model.

   This anchor complements, and does not replace, transport-layer and
   application-layer authentication (for example mutual TLS or object
   signatures); it changes where a key is rooted, and provides a
   verification and revocation path, but it does not by itself
   authenticate individual protocol messages.

9.  Privacy Considerations

   A DANE-anchored identity is, by construction, public: the anchoring
   name, the TLSA record, and the RDAP registration are visible to
   anyone.  This is a deliberate trade that removes the call-home
   privacy problem of fetch-based discovery.  Relying parties learn
   nothing that the subject reveals to them, and the subject learns
   nothing about which relying parties verify it.  However, publishing a
   stable, enumerable identity for an endpoint enables correlation of
   that endpoint's activity [RFC7626].  Deployments that assign one
   anchoring name per endpoint SHOULD consider whether such correlation
   is acceptable for their use case, and MAY rotate or scope anchoring
   names where it is not.  RDAP registration data SHOULD be minimized to
   what accountability requires.

10.  IANA Considerations

   This document has no IANA actions.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <https://www.rfc-editor.org/rfc/rfc6698>.

   [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 7480, DOI 10.17487/RFC7480, March 2015,
              <https://www.rfc-editor.org/rfc/rfc7480>.

Ranjbar                  Expires 22 January 2027                [Page 9]
Internet-Draft           DANE-Anchored Identity                July 2026

   [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
              Authentication of Named Entities (DANE) Protocol: Updates
              and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
              October 2015, <https://www.rfc-editor.org/rfc/rfc7671>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access
              Protocol (RDAP) Query Format", STD 95, RFC 9082,
              DOI 10.17487/RFC9082, June 2021,
              <https://www.rfc-editor.org/rfc/rfc9082>.

   [RFC9083]  Hollenbeck, S. and A. Newton, "JSON Responses for the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 9083, DOI 10.17487/RFC9083, June 2021,
              <https://www.rfc-editor.org/rfc/rfc9083>.

11.2.  Informative References

   [AID]      agentcommunity.org, "Agent Identity & Discovery (AID)",
              n.d., <https://aid.agentcommunity.org/docs/specification>.

   [C2PA-WDTA]
              Paquin, C., "C2PA Explorations: Web Domain Trust Anchor",
              n.d., <https://github.com/christianpaquin/c2pa-
              explorations/blob/main/web-domain-trust-anchor/web-domain-
              trust-anchor.md>.

   [DID-DNS]  Tech, D., "The did:dns Method", n.d.,
              <https://danubetech.github.io/did-method-dns/>.

   [I-D.ietf-dance-architecture]
              Wilson, A., Huque, S., Johansson, O. E., and M.
              Richardson, "An Architecture for DNS-Bound Client and
              Sender Identities", Work in Progress, Internet-Draft,
              draft-ietf-dance-architecture-10, 2 December 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dance-
              architecture-10>.

   [I-D.ietf-dance-client-auth]
              Huque, S. and V. Dukhovni, "TLS Client Authentication via
              DANE TLSA records", Work in Progress, Internet-Draft,
              draft-ietf-dance-client-auth-12, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dance-
              client-auth-12>.

Ranjbar                  Expires 22 January 2027               [Page 10]
Internet-Draft           DANE-Anchored Identity                July 2026

   [I-D.ietf-wimse-arch]
              Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
              "Workload Identity in a Multi System Environment (WIMSE)
              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-wimse-arch-08, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              arch-08>.

   [I-D.meunier-web-bot-auth-architecture]
              Meunier, T. and S. Major, "HTTP Message Signatures for
              automated traffic Architecture", Work in Progress,
              Internet-Draft, draft-meunier-web-bot-auth-architecture-
              05, 2 March 2026, <https://datatracker.ietf.org/doc/html/
              draft-meunier-web-bot-auth-architecture-05>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4033>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015,
              <https://www.rfc-editor.org/rfc/rfc7626>.

   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 8499, DOI 10.17487/RFC8499, January
              2019, <https://www.rfc-editor.org/rfc/rfc8499>.

   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/rfc/rfc9364>.

Acknowledgments

   This work builds on the DANE Authentication for Network Clients
   Everywhere (DANCE) working group's architecture and on decades of
   DNSSEC, DANE, and RDAP deployment experience in the operator
   community.  The author thanks Ben Schwartz and Eric Rescorla, whose
   comments sharpened the scoping of this document as a complement to,
   rather than a replacement for, WebPKI-based mechanisms; Wes Hardaker
   for guidance on where this work belongs; and Geoff Huston for a
   candid reading that shaped the plain-language framing.
   Acknowledgment here reflects review and discussion, not endorsement.

Author's Address

Ranjbar                  Expires 22 January 2027               [Page 11]
Internet-Draft           DANE-Anchored Identity                July 2026

   Kaveh Ranjbar
   Whisper Security (viaGraph B.V.)
   Netherlands
   Email: kaveh@whisper.security

Ranjbar                  Expires 22 January 2027               [Page 12]