Independent Submission S. Courtney Internet-Draft GoDaddy Intended status: Informational V. S. Narajala Expires: 15 October 2026 OWASP K. Huang DistributedApps.ai I. Habler OWASP A. Sheriff Cisco Systems 13 April 2026 Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity draft-narajala-courtney-ansv2-00 Abstract Autonomous AI agents execute transactions across organizational boundaries. No single agent platform provides the trust infrastructure they need. This document defines the Agent Name Service (ANS) v2 protocol, which anchors every agent identity to a DNS domain name. A Registration Authority (RA) verifies domain ownership via ACME, issues dual certificates (a Server Certificate from a public CA and an Identity Certificate from a private CA binding a version-specific ANSName), and seals every lifecycle event into an append-only Transparency Log aligned with IETF SCITT. Three verification tiers -- Bronze (PKI), Silver (PKI + DANE), and Gold (PKI + DANE + Transparency Log) -- let clients choose assurance levels appropriate to transaction risk. 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 15 October 2026. Courtney, et al. Expires 15 October 2026 [Page 1] Internet-Draft ANS v2 April 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Origin and Evolution . . . . . . . . . . . . . . . . . . 4 1.2. Relationship to Other Standards . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Registration Authority System . . . . . . . . . . . . . . 5 3.2. Agent Hosting Platform System . . . . . . . . . . . . . . 6 3.3. Transparency Log . . . . . . . . . . . . . . . . . . . . 6 3.4. Certificate Authorities . . . . . . . . . . . . . . . . . 7 3.5. Trust Framework: Three Layers . . . . . . . . . . . . . . 7 4. Data Model and Integrity . . . . . . . . . . . . . . . . . . 8 4.1. The ANSName . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Identifier Taxonomy . . . . . . . . . . . . . . . . . . . 9 4.3. Three Agent Card Terms . . . . . . . . . . . . . . . . . 10 4.4. Certificate Integrity . . . . . . . . . . . . . . . . . . 10 4.5. Agent State Lifecycle . . . . . . . . . . . . . . . . . . 10 4.6. Cryptographic Data Integrity Standards . . . . . . . . . 11 5. Trust, Security, and Attestation . . . . . . . . . . . . . . 11 5.1. Verification Tiers . . . . . . . . . . . . . . . . . . . 12 5.2. Mutual TLS Between ANS-Registered Agents . . . . . . . . 12 5.3. Key Management . . . . . . . . . . . . . . . . . . . . . 13 5.4. Privacy Considerations . . . . . . . . . . . . . . . . . 13 6. Operational Flow . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Initial Registration Flow . . . . . . . . . . . . . . . . 13 6.1.1. Stage 1: Pending Registration . . . . . . . . . . . . 14 6.1.2. Stage 2: Activation . . . . . . . . . . . . . . . . . 14 6.2. Lifecycle Operations . . . . . . . . . . . . . . . . . . 15 6.3. DNS Record Set . . . . . . . . . . . . . . . . . . . . . 15 6.4. Ongoing Integrity Verification . . . . . . . . . . . . . 16 7. Interoperability and Standards Alignment . . . . . . . . . . 17 7.1. HCS-14 ANS Profile . . . . . . . . . . . . . . . . . . . 17 7.2. HCS-27 Merkle Tree Checkpoint . . . . . . . . . . . . . . 17 7.3. IETF SCITT Alignment . . . . . . . . . . . . . . . . . . 17 7.4. Deployment Topologies . . . . . . . . . . . . . . . . . . 17 7.5. Coexistence with DNS-AID . . . . . . . . . . . . . . . . 18 Courtney, et al. Expires 15 October 2026 [Page 2] Internet-Draft ANS v2 April 2026 8. Formal Properties . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Two-Layer Proof Composition . . . . . . . . . . . . . . . 18 8.2. Cryptographic Boundary Enforcement . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9.1. Agent Impersonation . . . . . . . . . . . . . . . . . . . 19 9.2. Registry Poisoning . . . . . . . . . . . . . . . . . . . 19 9.3. Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . 19 9.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 20 9.5. Transparency Log Compromise . . . . . . . . . . . . . . . 20 9.6. Compromised RA Instance . . . . . . . . . . . . . . . . . 20 9.7. Single Operator Risk . . . . . . . . . . . . . . . . . . 20 9.8. Ecosystem Integrity and Remediation . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Data Structure Examples . . . . . . . . . . . . . . 23 A.1. Registration Request . . . . . . . . . . . . . . . . . . 23 A.2. TL Event Payload . . . . . . . . . . . . . . . . . . . . 24 A.3. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction AI agents now buy supplies, book travel, and sign contracts without a human in the loop. The ones handling real money need proof of who stands behind them. DNS [RFC1035] maps names to addresses but does not verify identity or track software versions. DNS-SD [RFC6763] adds service discovery but cannot tell a client whether the agent at an address is the one it claims to be. Two prominent protocols define how agents communicate. MCP [MCP] connects models to local tools and external APIs. A2A [A2A] governs how autonomous agents negotiate and delegate tasks across organizational boundaries. These protocols define how agents communicate but explicitly defer the question of who the agent is and whether it should be trusted. ANS addresses these gaps by combining three mechanisms. First, the agent's identity is anchored to a domain name whose ownership the Registration Authority (RA) has verified. Second, every change to the agent's software produces a new version number and a new Identity Certificate, recording which version is registered. Third, every lifecycle event is sealed into a Transparency Log, an append-only ledger where entries cannot be altered or removed after the fact. The three mechanisms together prove which version was declared and when. Courtney, et al. Expires 15 October 2026 [Page 3] Internet-Draft ANS v2 April 2026 1.1. Origin and Evolution This document builds on "Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability" [ANSv1], published at IEEE ICAIC 2026 and contributed to the IETF as an Internet-Draft. The original paper proposed a conceptual architecture with a six-component ANSName format. The architecture presented here simplifies the ANSName to three components (ans://v{version}.{agentHost}), introduces a dual-certificate model, replaces conceptual registry integrity with a cryptographic Transparency Log, moves protocol adapters to a client SDK, and decouples discovery from the RA. 1.2. Relationship to Other Standards HCS-14 [HCS14] uses DNS TXT records for agent discovery; an ANS Profile for HCS-14 allows any HCS-14 resolver to discover ANS agents. HCS-27 [HCS27] defines a checkpoint format for publishing the Transparency Log's root hash to a distributed consensus topic. The IETF SCITT working group [I-D.ietf-scitt-architecture] defines an append-only transparency service; the ANS TL follows this model. DNS-AID [DNSAID] uses SVCB service binding records [RFC9460] for agent endpoint discovery; DNS-AID tells a client where to connect, ANS tells it whether to trust the agent. 2. Terminology 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. Agent Hosting Platform (AHP): The entity that hosts the agent's code and serves the live endpoints at the agent's FQDN. Agent Integrity Monitor (AIM): A monitoring service that compares the live state of an agent's DNS records and Trust Card against the sealed TL records. It publishes findings but cannot command state changes. ANSName: The canonical identifier for a registered agent, following the format ans://v{version}.{agentHost}. ANS Trust Card: An optional COSE_Sign1 document hosted by the AHP containing protocol-native metadata augmented with ANS trust fields and a stapled SCITT receipt. Courtney, et al. Expires 15 October 2026 [Page 4] Internet-Draft ANS v2 April 2026 Discovery Service: An independent service that consumes RA output and indexes agents for searchability. Identity Certificate: An X.509 certificate issued by the Private CA with a URI SAN containing the agent's ANSName. Protocol Card: The protocol-native metadata file (A2A Agent Card, MCP manifest, OpenAPI document) created by the developer. Registration Authority (RA): The trusted third party that validates domain control via ACME, issues certificates, generates DNS record content, and seals lifecycle events into the Transparency Log. Registration Metadata: The agentCardContent field in the registration payload, translated from the Protocol Card by the SDK. The RA hashes it and seals the hash into the TL. Server Certificate: An X.509 certificate issued by a public CA with a dNSName SAN for the agent's stable FQDN. Transparency Log (TL): An append-only cryptographic data structure that seals signed events and provides inclusion and consistency proofs. Trust Index: A scoring service that crawls TL events and external signals to produce a numeric trust evaluation for each agent. 3. Architecture The architecture connects a central Registration Authority with Agent Hosting Platforms and shared internet infrastructure. Two chokepoints define trust flow: the RA, where identity enters the system, and the Transparency Log, where sealed evidence leaves it. 3.1. Registration Authority System The RA system comprises: Registration Authority (RA): Receives registration requests from AHPs, validates domain control via ACME [RFC8555], requests an Identity Certificate from the Private CA, obtains a Server Certificate from the Public CA (or accepts one the AHP brings), generates DNS records, and seals the registration into the TL. Key Management System (KMS): Signs every TL checkpoint. If this key is compromised, every sealed record in the log becomes untrustworthy. Courtney, et al. Expires 15 October 2026 [Page 5] Internet-Draft ANS v2 April 2026 Provider Registry: Decouples an entity's legal name from its identifier. Agent Integrity Monitor (AIM): Compares the live internet against what the RA sealed. It cannot revoke certificates or command state changes. 3.2. Agent Hosting Platform System The AHP hosts the agent's code and serves the live endpoints at the agent's FQDN. During registration, the AHP responds to ACME challenges so the RA can verify domain control, then receives both certificates and installs them in its keystore. The AHP provisions DNS records using content the RA generates. When the agent's code changes, the AHP initiates a new version registration. 3.3. Transparency Log The TL receives signed events from the RA, validates each signature, and seals the events into a cryptographic append-only structure. That structure produces two kinds of proof: inclusion proofs (proving a specific event exists in the log) and consistency proofs (proving the log has only grown, never shrunk or rewritten). The KMS signs each checkpoint. A conforming TL MUST operate as a SCITT Transparency Service [I-D.ietf-scitt-architecture], issuing binary COSE receipts as proof of inclusion. A conforming TL MUST expose a REST API for external verifiers: Courtney, et al. Expires 15 October 2026 [Page 6] Internet-Draft ANS v2 April 2026 +==========================+================================+ | Endpoint | Purpose | +==========================+================================+ | GET /v1/agents/{agentId} | Sealed event, TL signature, | | | and inclusion proof | +--------------------------+--------------------------------+ | GET /v1/ | Paginated history of all | | agents/{agentId}/audit | lifecycle events | +--------------------------+--------------------------------+ | GET /v1/log/checkpoint | Latest signed checkpoint: log | | | size, root hash, KMS signature | +--------------------------+--------------------------------+ | GET /v1/log/checkpoint/ | Checkpoint history for | | history | consistency proof verification | +--------------------------+--------------------------------+ | GET /v1/log/ | JSON Schema definition for a | | schema/{version} | given event schema version | +--------------------------+--------------------------------+ | GET /root-keys | KMS verification keys, | | | including historical keys | +--------------------------+--------------------------------+ Table 1 The TL MUST distribute verification keys via /root-keys so that any verifier can check root signatures without contacting the RA. Verification MUST NOT require access to producer public keys, authentication for read-only operations, or knowledge of RA implementation details. 3.4. Certificate Authorities Two CAs, two trust roots, two revocation paths: * Public CA: Issues Server Certificates. Revocation propagates through public OCSP/CRL [RFC6960]. * Private CA: Issues Identity Certificates on the RA's behalf. The Identity Certificate requires a URI SAN that no Public CA can issue. Only a Private CA, operating under its own issuance policy, can include the ans:// scheme. 3.5. Trust Framework: Three Layers The RA answers one question: "Who are you?" Three layers of trust data together provide a complete answer. Layer 1: Foundational identity (this protocol). The RA verifies Courtney, et al. Expires 15 October 2026 [Page 7] Internet-Draft ANS v2 April 2026 domain control, issues certificates, and seals the Registration Metadata hash into the Transparency Log. Layer 2: Operational maturity (third-party attestors). SOC 2 reports, HIPAA compliance certificates, and SBOMs arrive as references in the Trust Card's verifiableClaims array. Layer 3: Behavioral reputation (real-time scoring). Transaction records, settlement rates, and dispute flags. No single source controls the evaluation. A companion Trust Index specification defines how a provider consumes sealed data from Layer 1 and external signals from Layers 2 and 3, computes a multi- dimensional trust evaluation, and returns it as a signed credential. 4. Data Model and Integrity 4.1. The ANSName The canonical identifier for a registered agent has three components ([RFC1035], [RFC1123]): ANSName = "ans://v" version "." agentHost version = 1*DIGIT "." 1*DIGIT "." 1*DIGIT agentHost = Example: ans://v1.0.0.sentiment-analyzer.example.com Courtney, et al. Expires 15 October 2026 [Page 8] Internet-Draft ANS v2 April 2026 +===========+================================+=====================+ | Component | Example | Constraints | +===========+================================+=====================+ | protocol | ans | Fixed. Always | | | | "ans". | +-----------+--------------------------------+---------------------+ | version | 1.0.0 | Semantic version, | | | | numeric only: | | | | major.minor.patch. | | | | The "v" prefix is a | | | | literal part of the | | | | ANSName syntax, not | | | | part of the version | | | | string. | +-----------+--------------------------------+---------------------+ | agentHost | sentiment-analyzer.example.com | FQDN per RFC 1035 | | | | and RFC 1123. MUST | | | | NOT exceed 237 | | | | octets. | +-----------+--------------------------------+---------------------+ Table 2 The 237-octet host limit: The RA derives DNS record names by prepending labels to the agentHost. The longest derived name is _acme-challenge.{agentHost}, consuming 17 octets (16 characters plus the label separator) of the 253-octet presentation-format domain name limit (RFC 1035 Section 2.3.4, RFC 1123 Section 2.1). 253 - 16 = 237. The complete ANSName MUST NOT exceed 400 octets, providing headroom for safe transport across HTTP headers, TLS fields, and database columns. 4.2. Identifier Taxonomy +============+=============+=========+============================+ | Identifier | Assigned by | Mutable | Purpose | +============+=============+=========+============================+ | ANSName | Derived | No | Which version is | | | | | registered on which domain | +------------+-------------+---------+----------------------------+ | FQDN | AHP | No | Stable domain across all | | | | | versions | +------------+-------------+---------+----------------------------+ | Agent ID | RA | No | Registration record's | | | | | unique key | +------------+-------------+---------+----------------------------+ | ProviderID | RA | No | Who controls the domain | Courtney, et al. Expires 15 October 2026 [Page 9] Internet-Draft ANS v2 April 2026 +------------+-------------+---------+----------------------------+ | Supersedes | RA | No | Previous version's record | | ID | | | | +------------+-------------+---------+----------------------------+ Table 3 4.3. Three Agent Card Terms 1. Protocol Card: The protocol-native metadata file (A2A Agent Card, MCP manifest, OpenAPI document). 2. Registration Metadata: The agentCardContent field in the registration payload. The SDK translates the Protocol Card into this format. The RA hashes it and seals the hash into the TL. 3. ANS Trust Card: An optional COSE_Sign1 document hosted at /.well- known/ans/trust-card.json. Contains protocol-native metadata augmented with ANS trust fields and a stapled SCITT receipt. 4.4. Certificate Integrity +=============+===========+==========+======================+ | Certificate | Issued by | SAN type | Purpose | +=============+===========+==========+======================+ | Server | Public CA | dNSName | Standard TLS for the | | | | | stable FQDN | +-------------+-----------+----------+----------------------+ | Identity | Private | URI SAN | Binds certificate to | | | CA | | a versioned ANSName | +-------------+-----------+----------+----------------------+ Table 4 The Identity Certificate requires a URI SAN. The ans:// scheme is syntactically valid per RFC 3986 [RFC3986] Section 3.1 and permitted in URI SANs per RFC 5280 [RFC5280] Section 4.2.1.6. 4.5. Agent State Lifecycle The RA tracks registration state in its database. Only certain transitions produce TL events: entering ACTIVE, DEPRECATED, REVOKED, or EXPIRED, and renewal while ACTIVE (the AGENT_RENEWED event type). RENEWED is a TL event type, not a distinct registration state; the agent remains ACTIVE throughout the renewal process. Courtney, et al. Expires 15 October 2026 [Page 10] Internet-Draft ANS v2 April 2026 +=============+====================================================+ | State | Description | +=============+====================================================+ | PENDING | Awaiting validation | +-------------+----------------------------------------------------+ | PENDING_DNS | Domain validated; awaiting DNS record verification | +-------------+----------------------------------------------------+ | ACTIVE | Operational | +-------------+----------------------------------------------------+ | DEPRECATED | Signals consumers to migrate | +-------------+----------------------------------------------------+ | REVOKED | Certificates invalidated (terminal) | +-------------+----------------------------------------------------+ | EXPIRED | Requires renewal (terminal) | +-------------+----------------------------------------------------+ Table 5 4.6. Cryptographic Data Integrity Standards +==================+==============+================================+ | Requirement | Standard | Rule | +==================+==============+================================+ | Canonicalization | JCS (RFC | All JSON MUST be canonicalized | | | 8785) | before signing or hashing | +------------------+--------------+--------------------------------+ | Signature format | JWS Detached | Payload is not embedded; | | | | signatures stored separately | +------------------+--------------+--------------------------------+ | Algorithm | ES256 (ECDSA | Default. MUST support | | | P-256/SHA- | algorithm agility. | | | 256) | | +------------------+--------------+--------------------------------+ | Wire format | JWS Compact |
..signature (two dots; | | | | detached payload) | +------------------+--------------+--------------------------------+ Table 6 Every signature MUST include protected headers: alg (signing algorithm), kid (key identifier), typ (type indicator), timestamp (Unix timestamp), and raId (RA instance identifier). All JSON payloads MUST be canonicalized per JCS [RFC8785] before signing. Signatures use JWS Compact Serialization [RFC7515] with the JSON data interchange format [RFC8259]. 5. Trust, Security, and Attestation Courtney, et al. Expires 15 October 2026 [Page 11] Internet-Draft ANS v2 April 2026 5.1. Verification Tiers A client verifies an agent through independent checks, each using a different trust channel: +======+============================+=================+ | Step | Check | Trust channel | +======+============================+=================+ | 1 | PKI certificate validation | CA system | +------+----------------------------+-----------------+ | 2 | DANE record validation | DNS (DNSSEC) | +------+----------------------------+-----------------+ | 3 | TL verification | TL (KMS-signed) | +------+----------------------------+-----------------+ Table 7 +========+=======+=================+ | Tier | Steps | Shorthand | +========+=======+=================+ | Bronze | 1 | PKI only | +--------+-------+-----------------+ | Silver | 1-2 | PKI + DANE | +--------+-------+-----------------+ | Gold | 1-3 | PKI + DANE + TL | +--------+-------+-----------------+ Table 8 A tier describes what the client verified, not a property the RA assigned. The RA specifies TLSA 3 0 1 [sha256_hash]: DANE-EE (usage 3), full Server Certificate (selector 0), SHA-256 (matching type 1) [RFC6698]. DANE requires DNSSEC [RFC4033]. Per RFC 6698 Section 4, a TLSA RRset whose DNSSEC validation state is not "secure" MUST be treated as unusable, and the client falls back to standard PKIX certificate validation. 5.2. Mutual TLS Between ANS-Registered Agents The mTLS handshake proceeds as follows: 1. Caller sends ClientHello. 2. Server returns Server Certificate + CertificateRequest. 3. Caller presents its Identity Certificate. Courtney, et al. Expires 15 October 2026 [Page 12] Internet-Draft ANS v2 April 2026 4. Server verifies the caller's Identity Certificate against the ANS Private CA. 5. mTLS tunnel established. The caller knows the server's FQDN; the server knows the caller's ANSName. 6. Caller verifies the server's versioned identity via _ans-badge TXT record or TL query. When the agent's ANS Trust Card carries a stapled SCITT receipt, the caller verifies locally with no TL call. When an agent acts on behalf of a human, the agent proves its own identity via mTLS. The human's authorization travels separately as a delegation token [RFC8693]. 5.3. Key Management The RA never generates, handles, or accesses an agent's private keys. The AHP owns its key lifecycle. Each RA instance MUST register at least one active public key with the TL before submitting events. Rotation uses an overlap window: new keys are registered with future validFrom dates; both old and new remain active during the transition. Historical signatures remain valid after key expiration but not after revocation. 5.4. Privacy Considerations Query privacy is out of scope for the RA. Discovery Services SHOULD implement privacy-preserving techniques (Private Information Retrieval, Anonymized Query Relays). The TLS handshake reveals the agent's hostname to network observers. Encrypted Client Hello (ECH, RFC 9849) [RFC9849] encrypts the inner ClientHello, hiding the hostname. When an AHP provides an ECH configuration during registration, the RA publishes it in the HTTPS record. 6. Operational Flow 6.1. Initial Registration Flow Registration has two stages: 1. AHP submits registration request. 2. RA validates domain control (ACME) [RFC8555]. Courtney, et al. Expires 15 October 2026 [Page 13] Internet-Draft ANS v2 April 2026 3. RA obtains Server + Identity Certificates. 4. RA seals event into TL. (Point of no return.) 5. RA returns certificates + DNS record content to AHP. 6. AHP provisions DNS. 6.1.1. Stage 1: Pending Registration The AHP submits a registration request containing: * Identity: agentHost (FQDN), version (semver), agentDisplayName, optional agentDescription. * Endpoints: Array of protocol-specific endpoints (minimum 1). * Certificates: Identity CSR (required), optional Server CSR or existing Server Certificate (BYOC). * Registration Metadata: Optional agentCardContent. * Organization: Optional lei (Legal Entity Identifier). * Privacy: Optional echConfigList (ECH configuration). 6.1.2. Stage 2: Activation All validations must pass before activation: domain control (ACME DNS-01 or HTTP-01), organization identity (when applicable), schema integrity (fetch and hash), and DNSSEC presence (advisory). The activation sequence, irreversible once step 4 completes: 1. Certificate issuance: RA obtains the Identity Certificate and the Server Certificate. 2. DNS record generation: RA generates record set content. 3. Event payload: RA hashes Registration Metadata and assembles the event payload. 4. Log sealing: RA submits signed event to TL. 5. Artifact delivery: RA delivers certificates and DNS record content to AHP. Courtney, et al. Expires 15 October 2026 [Page 14] Internet-Draft ANS v2 April 2026 6. AHP provisions DNS: The AHP creates the DNS records using the content the RA specified. 6.2. Lifecycle Operations +==============+=============+==================+=================+ | Operation | Trigger | TL Event | DNS Effect | +==============+=============+==================+=================+ | Version bump | Code/config | AGENT_REGISTERED | New per-version | | | change | | records | +--------------+-------------+------------------+-----------------+ | Renewal | Certificate | AGENT_RENEWED | None | | | expiring | | | +--------------+-------------+------------------+-----------------+ | Revocation | Agent | AGENT_REVOKED | Per-version | | | shutdown | | removed | +--------------+-------------+------------------+-----------------+ Table 9 6.3. DNS Record Set The RA generates record content for child labels under the agent's FQDN: Courtney, et al. Expires 15 October 2026 [Page 15] Internet-Draft ANS v2 April 2026 +===========+===========================+=======+===================+ | Record | Label | Type | Purpose | +===========+===========================+=======+===================+ | Discovery | _ans.{host} | TXT | Protocol and | | | | | metadata | | | | | location | +-----------+---------------------------+-------+-------------------+ | Badge | _ans-badge.{host} | TXT | TL badge URL | | | | | for | | | | | verification | +-----------+---------------------------+-------+-------------------+ | DANE | _443._tcp.{host} | TLSA | Server Cert | | | | | fingerprint | +-----------+---------------------------+-------+-------------------+ | HTTPS | {host} | HTTPS | ALPN hints, | | | | | ECH | | | | | parameters | +-----------+---------------------------+-------+-------------------+ | Identity | _ans-identity._tls.{host} | TLSA | Identity | | DANE | | | Cert | | | | | fingerprint | +-----------+---------------------------+-------+-------------------+ Table 10 The _ans TXT record is a connection hint published in DNS: _ans.{agentHost} IN TXT "v=ans1; version=v1.0.0; p=a2a; url=https://agent.example.com/.well-known/agent-card.json" The _ans-badge TXT record points to the version's badge in the TL: _ans-badge.{agentHost} IN TXT "v=ans-badge1; version=v1.0.0; url=https://{tl_host}/v1/agents/{agentId}" 6.4. Ongoing Integrity Verification An AIM MUST distinguish between "Unreachable" (transient network failure, retry later) and "Mismatch" (the content has changed, remediation needed). Courtney, et al. Expires 15 October 2026 [Page 16] Internet-Draft ANS v2 April 2026 +============+==============================+=====================+ | Check | What the AIM does | Pass condition | +============+==============================+=====================+ | DNS | Authoritative query for _ans | Records exist and | | pointer | and _ans-badge with DNSSEC | validate | +------------+------------------------------+---------------------+ | Trust Card | Fetch Trust Card, hash | Hash matches sealed | | integrity | content | agentCardHash | +------------+------------------------------+---------------------+ | Schema | Fetch each schema.url, hash | Hash matches | | integrity | content | schema.hash in | | | | Trust Card | +------------+------------------------------+---------------------+ Table 11 7. Interoperability and Standards Alignment 7.1. HCS-14 ANS Profile An ANS Profile within HCS-14 allows resolvers to verify ANS DNS records, certificates, and log proofs through a standard interface without ANS-specific branching. 7.2. HCS-27 Merkle Tree Checkpoint A companion specification [HCS27] defines a checkpoint format for publishing the TL's root hash to a distributed consensus topic. The timestamp is independently verifiable, strengthening the guarantee that historical log entries have not been backdated or rewritten. 7.3. IETF SCITT Alignment The SCITT architecture [I-D.ietf-scitt-architecture] defines an append-only transparency service that accepts signed statements, registers them, and returns receipts. The ANS TL follows this model. A future goal is formal SCITT compliance, adopting COSE (RFC 9052) [RFC9052] signed statements and standardized receipt formats. 7.4. Deployment Topologies The same RA, TL, and certificate infrastructure can run at different scopes: * Public ANS: internet-facing RA, TL, and event feeds. * Internal ANS: behind a corporate network. Courtney, et al. Expires 15 October 2026 [Page 17] Internet-Draft ANS v2 April 2026 * Enterprise ANS as a service: hosted on behalf of an enterprise. * Extranet ANS: semi-private, shared among partner organizations. 7.5. Coexistence with DNS-AID A domain owner can publish DNS-AID SVCB records [DNSAID] [RFC9460] alongside _ans TXT records. The two record families occupy different DNS names and do not collide. 8. Formal Properties 8.1. Two-Layer Proof Composition A sealed event carries two independent proofs of existence, each anchored to a different trust root. Layer 1 (Transparency Log): Let E be a lifecycle event sealed at leaf index i in a log of size n with Merkle root R. An inclusion proof consists of a hash path of length ceil(log2(n)). The proof is valid iff recomputing the root from LeafHash(E), the path, and i yields R, and the signature over R verifies against the TL's published KMS key. Layer 2 (Consensus Checkpoint): An HCS-27 checkpoint publishes R to a distributed consensus topic at timestamp T. Together, the two layers guarantee: inclusion, non-repudiation (removing E after checkpoint publication contradicts the collision resistance of SHA-256), and temporal binding (the consensus topic provides independently verifiable timestamps). 8.2. Cryptographic Boundary Enforcement The protocol distributes trust across four services. No service accepts another's assertions without verifying a cryptographic signature. Courtney, et al. Expires 15 October 2026 [Page 18] Internet-Draft ANS v2 April 2026 +==========+================================+=======================+ | Boundary | Verification | What compromise | | | | means | +==========+================================+=======================+ | RA to TL | TL verifies producer signature | Forged event | | | (ES256, registered key) | rejected at | | | | ingestion | +----------+--------------------------------+-----------------------+ | TL to | Verifier checks KMS signature | Tampered | | Verifier | on checkpoint | checkpoint fails | | | | validation | +----------+--------------------------------+-----------------------+ | TL to | Each event carries the | Fabricated event | | Event | producer's signature | fails signature | | Stream | | check | +----------+--------------------------------+-----------------------+ | AIM to | RA re-verifies each finding | False finding | | RA | against TL records | detected on re- | | | | verification | +----------+--------------------------------+-----------------------+ Table 12 9. Security Considerations This section addresses threats identified through a MAESTRO framework analysis applied to the ANS architecture. 9.1. Agent Impersonation Risk: An adversary impersonates a legitimate agent. Mitigation: Mandatory PKI with dual certificates. The Identity Certificate binds a specific code version to a verified domain. The agent must prove possession of the private key. 9.2. Registry Poisoning Risk: An adversary injects malicious data into the registry. Mitigation: The Transparency Log makes all sealed entries immutable and tamper-evident. The RA validates all payloads before sealing. The AIM continuously compares live state against sealed records. 9.3. Man-in-the-Middle Risk: An adversary modifies communications between components. Mitigation: Message integrity via digital signatures (JWS Detached). mTLS between agents using Identity Certificates. DANE provides a second trust channel independent of the CA system. Courtney, et al. Expires 15 October 2026 [Page 19] Internet-Draft ANS v2 April 2026 9.4. Denial of Service Risk: Adversary incapacitates RA, TL, or resolution services. Mitigation: The data plane (mTLS handshakes between agents) continues during RA or AIM outages. Previously established trust proofs remain valid until certificates expire. 9.5. Transparency Log Compromise Risk: An adversary modifies or deletes historical TL entries. Mitigation: Merkle tree structure makes tampering mathematically detectable via consistency proofs. KMS key separation ensures the signing key does not reside on the TL host. HCS-27 checkpoint anchoring to a public distributed ledger provides independently verifiable timestamps. 9.6. Compromised RA Instance Risk: A single RA instance is breached. Mitigation: Every TL entry records the raId of the processing instance. Auditors isolate every event that instance touched. Separation of duties requires the RA's DNS permissions exclude TLSA write access. 9.7. Single Operator Risk For a given registration, the same entity may operate both the RA and the TL. HCS-27 consensus checkpoints are the primary mitigation: the TL's root hash is anchored to an independently verifiable ledger. Federation adds a second layer: an agent can register with an RA operated by one entity and have events sealed by a TL operated by another. 9.8. Ecosystem Integrity and Remediation Four principles guard against malicious monitoring services: 1. Monitors report, the RA acts. 2. Reports are public and signed. 3. Quorum before action: the RA MUST NOT act on a single report. 4. Evidence must be verifiable with cryptographic proof. 10. IANA Considerations This document has no IANA actions at this time. Courtney, et al. Expires 15 October 2026 [Page 20] Internet-Draft ANS v2 April 2026 Future revisions may request registration of the "ans" URI scheme with IANA per RFC 7595, and registration of underscore labels "_ans", "_ans-badge", and "_ans-identity" per RFC 8552. 11. References 11.1. Normative References [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987, . [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012, . [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013, . Courtney, et al. Expires 15 October 2026 [Page 21] Internet-Draft ANS v2 April 2026 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, March 2019, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", RFC 9052, August 2022, . [I-D.ietf-scitt-architecture] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture-22, October 2025, . 11.2. Informative References [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, January 2020, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, November 2023, . Courtney, et al. Expires 15 October 2026 [Page 22] Internet-Draft ANS v2 April 2026 [RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", RFC 9849, 2025, . [ANSv1] Narajala, V. S., Huang, K., Habler, I., and A. Sheriff, "Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability", IEEE ICAIC 2026, 2025. [MCP] Anthropic, "Model Context Protocol Specification", 2025, . [A2A] Google, "Agent-to-Agent (A2A) Protocol", 2025, . [HCS14] Hiero, "HCS-14: Universal Agent ID", 2025, . [HCS27] Hiero HCS-27 Working Group, "HCS-27: Merkle Tree Checkpoint Specification", 2025, . [DNSAID] Mozley, J., Williams, N., Sarikaya, B., and R. Schott, "DNS for AI Discovery", Work in Progress, Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-01, March 2026, . Appendix A. Data Structure Examples All examples follow one agent, "Acme Support Agent" (support.example.com, version 1.5.0), through the registration lifecycle. CSRs and signatures are truncated for brevity. A.1. Registration Request Courtney, et al. Expires 15 October 2026 [Page 23] Internet-Draft ANS v2 April 2026 { "agentDisplayName": "Acme Support Agent", "agentDescription": "Customer support agent.", "version": "1.5.0", "agentHost": "support.example.com", "endpoints": [ { "protocol": "A2A", "agentUrl": "wss://support.example.com/a2a", "metadataUrl": "https://support.example.com/.well-known/agent-card.json", "transports": ["STREAMABLE-HTTP", "SSE"], "functions": [ { "id": "lookupOrder", "name": "Lookup Order", "tags": ["order", "support"] } ] } ], "identityCsrPEM": "-----BEGIN CERTIFICATE REQUEST----- ...(truncated)... -----END CERTIFICATE REQUEST-----", "serverCsrPEM": "-----BEGIN CERTIFICATE REQUEST----- ...(truncated)... -----END CERTIFICATE REQUEST-----", "lei": "549300EXAMPLE00LEI17" } A.2. TL Event Payload Courtney, et al. Expires 15 October 2026 [Page 24] Internet-Draft ANS v2 April 2026 { "ansId": "550e8400-e29b-41d4-a716-446655440000", "ansName": "ans://v1.5.0.support.example.com", "eventType": "AGENT_REGISTERED", "agent": { "host": "support.example.com", "name": "Acme Support Agent", "version": "v1.5.0", "providerId": "PID-8294", "lei": "549300EXAMPLE00LEI17" }, "attestations": { "identityCert": { "fingerprint": "SHA256:22b8a804...", "type": "X509-OV-CLIENT" }, "serverCert": { "fingerprint": "SHA256:d2b71bc0...", "type": "X509-DV-SERVER" }, "domainValidation": "ACME-DNS-01", "dnssecStatus": "fully_validated" }, "issuedAt": "2026-03-05T18:00:00.000000Z", "raId": "id-A", "timestamp": "2026-03-05T18:00:00.000000Z" } A.3. DNS Records Courtney, et al. Expires 15 October 2026 [Page 25] Internet-Draft ANS v2 April 2026 $ORIGIN support.example.com. $TTL 3600 ; Core Location Records (Managed by AHP) @ IN A 192.0.2.50 @ IN AAAA 2001:db8::50 ; RA generates; AHP provisions @ IN HTTPS 1 . alpn="h2" _443._tcp IN TLSA 3 0 1 _ans IN TXT "v=ans1; version=v1.5.0; p=a2a; url=https://support.example.com/.well-known/agent-card.json" _ans-badge IN TXT "v=ans-badge1; version=v1.5.0; url=https://{tl_host}/v1/agents/{agentId}" ; High-assurance (AHP-managed, per ADR 010) _ans-identity._tls IN TLSA 3 0 1 Authors' Addresses Scott Courtney GoDaddy Email: scourtney@godaddy.com Vineeth Sai Narajala OWASP Email: vineeth.sai@owasp.org Ken Huang DistributedApps.ai Email: ken.huang@distributedapps.ai Idan Habler OWASP Email: idan.habler@gmail.com Akram Sheriff Cisco Systems Email: isheriff@cisco.com Courtney, et al. Expires 15 October 2026 [Page 26]