Agent Name Service v2 (ANS): A Domain-Anchored Identity Layer for Autonomous AI Agents

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 29 April 2027.¶

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

An AI agent that calls another agent over MCP [MCP] or A2A [A2A] learns a hostname and an endpoint URL. Before it sends a payment instruction or a customer record, the calling agent needs to know who answers for this endpoint, which release of the software is running there, and whether anyone can check what happened to that release over time. A TLS server certificate names the hostname, which answers part of the first question. No interoperable record names the release running at the endpoint or its history.¶

An ANS v2 verifier answers all three by checking systems the Internet already runs. The DNS, signed with DNSSEC [RFC4033], anchors each agent's name in a domain its owner controls. X.509 certificates [RFC5280] let a caller authenticate the agent's TLS endpoint, and an operator can pin them in DNS with DANE [RFC6698]. An append-only transparency log records every agent the RA registers or revokes, where any party can read and audit the record. The log uses the Merkle-tree construction of Certificate Transparency [RFC9162] and the model of SCITT [I-D.ietf-scitt-architecture], in which a transparency service signs a receipt for each statement it records.¶

This document describes how the DNS records, certificates, and transparency log fit together and what each one defends against. The ANS specifications [ANS-SPEC], numbered ANS-0 through ANS-6, state what each implementation must do.¶

2. Terminology

Agent:

Software that accepts requests at a network endpoint and acts on them without a human approving each step.¶

agentHost:

The fully qualified domain name (FQDN) at which an agent serves requests, for example "travel.example.com".¶

ANSName:

The versioned name of one registration, of the form "ans://v{version}.{agentHost}", for example "ans://v1.4.2.travel.example.com".¶

Registrant:

The party that submits a registration and proves control of the agentHost: either the agent's owner or an Agent Hosting Platform acting for the owner.¶

Agent Hosting Platform (AHP):

The operator that runs the agent's code and manages its DNS records and certificates.¶

Registration Authority (RA):

The service that accepts a registration, checks the registrant's proof of domain control, issues or accepts the agent's certificates, and submits signed lifecycle events to the transparency log.¶

Transparency Log (TL):

The append-only Merkle-tree log that seals each lifecycle event the RA submits and serves receipts, status tokens, checkpoints, and tiles that let any party verify what it sealed.¶

Server Certificate:

The X.509 certificate that the agent presents as a TLS server. It names the agentHost as a DNS subject alternative name.¶

Identity Certificate:

An optional X.509 client certificate, issued from the RA's private certification authority (CA), that carries the full ANSName as a URI subject alternative name and so binds one version of the agent to one key.¶

Badge:

The TL's public record for one registration, which a verifier reaches through the "_ans-badge" DNS record.¶

Receipt:

A COSE_Sign1 [RFC9052] object, signed by the TL, that proves a given event was sealed into the log.¶

Status token:

A short-lived object, signed by the TL, that states a registration's current status.¶

Checkpoint:

A signed note recording the TL's tree size and root hash at a point in time.¶

Verifier:

Any party that checks an agent's ANS records, usually the calling agent or the agent being called.¶

3. Architecture

Five parties take part. The registrant holds the domain, runs the agent, and publishes DNS records. The RA checks domain control and issues or accepts certificates. The TL seals what the RA submits. A DNS operator serves the registrant's zone. A verifier reads the DNS records, certificates, and TL records and decides for itself.¶

  Registrant (owner or AHP)                 Verifier
    | 1 register agentHost,                  ^   ^   ^
    |   prove domain control                 |   |   |
    v                                        |   |   |
  +-----------------+  2 signed event  +-----+---+---+---+
  | Registration    |----------------->| Transparency Log |
  | Authority (RA)  |                  | (receipts, tiles,|
  +-----------------+                  |  checkpoints)    |
    | 3 certificates;                  +------------------+
    |   expected DNS record content            ^
    v                                          | 5 badge, receipt,
  Registrant publishes in its zone:           |   status token
    SVCB (DNS-AID), _ans-badge TXT, (TLSA)    |
                     |                         |
                     +---- 4 DNS (DNSSEC) -----+--> Verifier

An RA can also offer an optional identity service [ANS-SPEC]. The service verifies an identifier the registrant controls, such as a did:web identifier, which resolves to keys published under a web domain, or a Legal Entity Identifier (LEI) proven with a vLEI credential chain plus a possession signature, and links that identifier to the registrant's agents. The RA submits a TL event each time it verifies, updates, links, unlinks, or revokes the identifier.¶

Many RAs can operate, each integrated with its own systems, such as the CA it obtains Server Certificates from and the DNS zones it hosts. The ANS specifications fix what every registration carries, whichever RA handles it: proof of domain control, the certificate fingerprints the TL seals, and the badge record. A verifier therefore checks a registration from any RA the same way.¶

A verifier can check the DNS, the certificates, and the TL separately; an attacker has to defeat all three to pass a verifier that checks all three.¶

4. Versioned Naming

Every registration has an ANSName of the form "ans://v{version}.{agentHost}". The version is a numeric semantic version (major.minor.patch) with no pre-release or build-metadata suffix. The RA keeps each full ANSName unique, so "ans://v1.0.0.travel.example.com" and "ans://v2.0.0.travel.example.com" are two independent registrations with independent statuses.¶

A registrant releases a new version by registering the new ANSName. Both versions can stay ACTIVE until the registrant or the RA retires the old one. The registrant revokes the old version, or an RA may apply a retirement policy that it publishes to registrants, for example deprecating the old version when the new one activates and revoking it after a grace period with the revocation reason SUPERSEDED. The RA records each step in the TL: it submits an AGENT_DEPRECATED event when it deprecates the old version and an AGENT_REVOKED event when it revokes it, and from each event on, the badge and the status token report the new status. Because verifiers on both tiers decide from that status whether the old version is retired (Section 11.6), the registrant keeps the old version's "_ans-badge" record published until the RA revokes the version. When the RA revokes the old version, the RA leaves valid every certificate the new version still holds. If registering the new version fails, the RA leaves the old version untouched.¶

An Identity Certificate, when the registrant requests one, carries the full ANSName as a uniformResourceIdentifier subject alternative name, with the clientAuth extended key usage. The CA/Browser Forum Baseline Requirements [CABF-BR] prohibit URI subject alternative names in publicly trusted server certificates, so a public CA cannot issue an Identity Certificate; the RA's private CA issues the Identity Certificate against a certificate signing request (CSR) the registrant submits. ANS-2 prohibits registrants from bringing their own Identity Certificates, because a rogue CA could otherwise issue one for an ANSName the RA never validated. A registrant can skip the Identity Certificate; the registration then activates and operates on its Server Certificate alone. An agent registered without an Identity Certificate can answer calls but cannot authenticate when it calls another agent, because both ANS-6 caller methods (Section 8) bind the caller to its Identity Certificate. The registrant cannot add an Identity Certificate later without registering a new version. A registrant whose agent calls other agents should therefore request an Identity Certificate.¶

5. Registration Lifecycle

A registrant registers an agent in three steps [ANS-SPEC]:¶

1. The registrant submits the ANSName, its endpoints, and either a CSR for the Server Certificate or a Server Certificate it already holds, plus an optional CSR for an Identity Certificate. When the registrant sends a CSR, the RA obtains the Server Certificate from a CA it integrates with. For each endpoint the registrant can also declare the SHA-256 digest of the agent card it serves at the endpoint's metadata URL; the RA checks the digest's format but does not fetch the card. The RA returns domain-control challenges in the style of ACME [RFC8555], and the registration enters PENDING_VALIDATION.¶
2. The registrant satisfies either a DNS-01 TXT challenge or an HTTP-01 challenge. The RA checks the challenge response, issues the requested certificates, returns the content of the DNS records the registrant must publish, and moves the registration to PENDING_DNS.¶
3. The registrant publishes the records. The RA queries public DNS, checks that the required records are present and that DNSSEC validates where the zone is signed, and moves the registration to ACTIVE. The RA then submits an AGENT_REGISTERED event to the TL. The event carries any card digests the registrant declared and, for each SVCB, HTTPS, and TLSA answer, whether the RA's resolver validated that answer under DNSSEC; TXT answers carry no such flag. The integrity monitor repeats the DNSSEC check after activation (Section 9).¶

After activation, the RA can move a registration to DEPRECATED or REVOKED. The RA never marks an active registration EXPIRED; each time a verifier reads the registration's badge or status token, the TL reports WARNING as the expiry sealed in the AGENT_REGISTERED event approaches and EXPIRED once that expiry passes. The RA itself marks a registration EXPIRED only when the registration is still pending and its domain-control challenge lapses. When the registrant or the RA revokes a registration, the RA submits an AGENT_REVOKED event. The RA also submits a TL event when it deprecates a version (Section 4) and each time it renews a certificate. The TL lists a renewed certificate's fingerprint only after the RA logs the renewal, so without that event verifiers reject the agent once the agent presents the new certificate. A content delivery network (CDN) or hosting platform that manages the Server Certificate can rotate that certificate without telling the registrant, and the same rejection follows until the registrant submits the new certificate through the RA's renewal.¶

The registrant re-proves domain control at every Server Certificate renewal and every new version, subject to the reuse window ANS-1 allows for a recent ACME authorization. A party that loses control of the domain therefore cannot renew or extend a registration, and the domain's new holder does not silently inherit the reputation its former holder built. Section 11.9 covers what the former holder can still do with its existing registrations.¶

6. DNS Publication

ANS-3 organizes discovery records into named profiles. The registrant chooses the profiles for each registration; ANS_DNSAID is the default.¶

ANS_DNSAID (default):

One SVCB record in ServiceMode at the agentHost for each protocol endpoint, carrying connection hints and capability locators in the SvcParams of [I-D.mozleywilliams-dnsop-dnsaid], including the card digest, when the registrant declared one, as the DNS-AID cap-sha256 parameter.¶

ANS_TXT (opt-in):

One "_ans" TXT record for each endpoint plus an HTTPS record at the agentHost, which ANS-3 keeps for operators whose zone-editing tools target "_ans.{agentHost}".¶

Whatever profiles the registrant chooses, the registrant publishes the badge record and can add DANE records:¶

Badge record:

A TXT record at "_ans-badge.{agentHost}" with the value "v=ans-badge1; version=v{version}; url={badgeURL}", where badgeURL is the TL's public record for the registration. A badge-verifying client does not trust an agent whose discovery records appear without a matching badge record.¶

DANE record (optional):

A TLSA record at "_{port}._tcp.{agentHost}" for each TLS endpoint port, using DANE-EE with selector 0 (the full certificate) or selector 1 (the public key) and SHA-256. Verifiers accept either selector. The binding a verifier relies on is the Server Certificate fingerprint the TL seals; a DNSSEC-validated TLSA record adds a second, DNS-anchored check of the same certificate. When several agents share one Server Certificate, such as a wildcard, that fingerprint identifies the operator's certificate, not one agent or version; the Identity Certificate's ANSName and the status token carry the version.¶

ANS-3 requires the discovery and trust records to sit in public DNS zones that any third party can query; a private zone or proprietary lookup channel does not conform. DNS-AID, which ANS composes, makes TLSA records optional, recommends that zones be DNSSEC-signed, and requires a zone that publishes TLSA records to be signed; ANS follows the same rules. Following [RFC6698], a verifier treats a TLSA record set as unusable unless DNSSEC validates it as "secure".¶

7. Transparency Log

The TL keeps one Merkle tree. ANS-4 specifies the TL's leaf hashing, which follows [RFC9162], and the TL's signature algorithms.¶

Any reader can fetch the TL's contents without authenticating:¶

• the current checkpoint and the history of past checkpoints, in the C2SP tlog-checkpoint signed-note format [C2SP];¶
• the Merkle tree's hash tiles and entry bundles, in the C2SP tlog-tiles format, for bulk verification;¶
• per-registration records: the badge, an audit history, a receipt, and a status token.¶

A receipt proves that an event was sealed and stays valid forever, including for a registration revoked later. A status token states the registration's current status and expires after a short lifetime (one hour by default). A verifier that needs to know an agent is still live uses the status token or the badge, not the receipt alone.¶

Each RA instance signs the events it submits with a producer key the TL has registered. The TL can also publish periodic checkpoints to an external consensus ledger, following HCS-27 [HCS27], the Hashgraph Online profile for publishing Merkle checkpoints to a Hedera Consensus Service topic.¶

8. Verification

ANS-6 lets each deployment make two independent choices about how one agent authenticates another. In the first choice, the verification tier, the deployment picks where the verifier gets its evidence: on the badge tier, the verifier queries the TL when it connects; on the SCITT tier, the verifier checks a receipt and a status token locally with no network call per request. In the second choice, the possession method, the deployment picks how the caller proves it holds its key: Method A presents the Identity Certificate in the mutual-TLS handshake; Method B sends a DPoP proof [RFC9449] in an HTTP header, which survives proxies and gateways that terminate TLS.¶

Whatever the tier and method, the verifier establishes three facts, all bound to one certificate: identity (a badge or receipt shows the registration exists), liveness (the badge or status token shows the registration is not revoked), and possession (the handshake or DPoP proof shows the peer holds the key). The presented certificate matches when its fingerprint equals one of the fingerprints the TL sealed for that registration.¶

ANS-5 lays out the checks a verifier can run against an agent, each through a different trust channel:¶

1. Validate the Server Certificate chain through the Web PKI.¶
2. Where the operator publishes TLSA records and the zone is signed, check that the Server Certificate matches a TLSA record at "_{port}._tcp.{agentHost}" under that record's selector.¶
3. Verify the TL inclusion proof for the registration. A tampered or deleted entry breaks the proof.¶
4. Check that the live DNS records and certificates match what the TL sealed.¶
5. Where the registrant declared a card digest, hash the fetched agent card with SHA-256 and compare the hash with the digest in the status token and, under ANS_DNSAID, with the cap-sha256 parameter in the SVCB record. The status token carries the digest as hex and the SVCB record carries the digest as base64url, so the verifier decodes each to bytes before comparing. ANS-6 asks a verifier to compare both where the verifier can and, when the two digests differ, to report the difference even if the fetched card matches one of them.¶

9. Integrity Monitoring

ANS-5 defines an integrity monitor that re-checks registered agents on a schedule its operator sets: that the TL entry exists, that the DNS records match the sealed values and validate under DNSSEC, and that the certificate fingerprints match. A monitor reports a mismatch; the monitor cannot change a registration's state. The RA records a warning only for a confirmed finding that carries cryptographic evidence of the discrepancy, and only after the RA re-verifies that evidence. A warning is advisory: the agent stays ACTIVE, and each consumer decides what to do with the warning.¶

10. Evolving Areas

The ANS specifications change in the open; these changes are under discussion or under way:¶

Version-free names:

A proposal would drop the mandatory version from the ANSName, giving names such as "ans://agent.example.com", and would let a registrant update endpoint metadata in place instead of registering a new version. A verifier could then pin a release only where the registrant publishes release information. Version-free names would leave the "_ans-badge" lookup (Section 11.6) with no version to match; retiring that record altogether is a step ANS maintainers have discussed and set aside for now.¶

DANE records:

The current specifications have the RA compute the expected TLSA content and check it before activation. A pending edit to ANS-1, ANS-3, ANS-5, and ANS-6 removes those duties and leaves DANE to operators, as Section 6 describes. The TLSA selector rule (selector 0 or 1, verifiers accepting either) is already settled.¶

Identity Certificates from other CAs:

A proposal would let a registrant enroll an Identity Certificate issued elsewhere, without the ANSName URI subject alternative name, for use with Method B. The RA would bind that certificate's fingerprint to the registration in the status token, so the version binding would move from the certificate to the TL, which matters most for operators whose agents share one Server Certificate (Section 6).¶

Version retirement:

The current ANS-1 text says the RA imposes no retirement timeline, and ANS-6 lets only the registrant mark an old version DEPRECATED. This document permits an RA retirement policy that the RA records in the TL, and has verifiers on both tiers learn from the TL whether a version is retired (Section 4); a proposal to ANS maintainers would add the same rules to ANS-1, ANS-2, ANS-4, and ANS-6. Still undecided is whether a verifier must accept a DEPRECATED version with a warning, as ANS-6 says today, or may reject it as local policy.¶

Lifecycle events and expiry:

ANS maintainers are revising the event names for certificate renewal and the rule that computes a registration's expiry, and are discussing a recovery period after a certificate lapses. The current ANS-1 text reserves the renewal event without requiring the RA to submit it; this document requires the renewal event (Section 5).¶

Domain transfers:

ANS maintainers are deciding how an RA retires a former holder's registrations once a new holder proves control of the domain, and whether the new holder may reuse a name and version the former holder published.¶

Discovery parameters:

The DNS-AID authors and authors of related discovery drafts are aligning on a common set of SvcParams, including a new name for the protocol parameter and an algorithm-agile digest, cap-digest, in place of cap-sha256. The ANS_DNSAID profile will follow the parameter names they settle.¶

Log witnessing:

ANS maintainers are designing witnessing for TL checkpoints, so that verifiers can detect a split view without relying on external anchoring alone.¶

Agents without a domain:

Proposals describe client-only agents that call other agents but serve no endpoint, and hosting providers that register agents under a provider-assigned hostname for operators who hold no domain or key. Both would extend ANS beyond its domain-anchored base.¶

11. Security Considerations

12. Privacy Considerations

The RA and the TL publish every registration: anyone can read an agent's ANSName, endpoints, certificate fingerprints, and lifecycle history from DNS and the TL. Registrants place nothing in a registration that they would not publish.¶

A verifier's lookups reveal which agents it intends to call. Discovery services can reduce that exposure with privacy-preserving query techniques; the RA does not see these queries. The TLS handshake reveals the agent's hostname to network observers unless both sides use Encrypted Client Hello [RFC9849].¶

13. IANA Considerations

This document has no IANA actions at this time.¶

A future revision may ask IANA to register the "ans" URI scheme per [RFC7595] and the underscore labels "_ans" and "_ans-badge" per [RFC8552].¶

Changes from draft-narajala-courtney-ansv2-01

• Rewrote the document as a short description of the architecture. Normative detail moved to the open-source ANS-0 through ANS-6 specifications [ANS-SPEC].¶
• Retitled from "Trust Layer" to "Identity Layer": ANS identifies an agent; whether to trust it is the relying party's decision, which a separate scoring service can inform.¶
• Adopted DNS-AID SVCB records as the default discovery format; the "_ans" TXT format is now an opt-in profile.¶
• Added the Status and Transition Note, the verification tiers and possession methods of ANS-6, and Security Considerations for split views, version rollback, agent card tampering, and revocation latency.¶
• Described the TL-sealed Server Certificate fingerprint as the ANS binding, with DANE as optional, operator-published TLSA records that accept selector 0 or 1.¶
• Required the RA to log each certificate renewal in the TL, and described the optional identity service.¶
• Added a Security Considerations subsection on domain transfer.¶
• Permitted an RA retirement policy that the RA records in the TL, had verifiers on both tiers learn from the TL whether a version is retired, and added the Evolving Areas section.¶
• Removed the sections on the SDK, the event stream, HCS-14 profiles, deployment topologies, non-functional requirements, and future work.¶

Authors' Addresses