GoDaddy

scourtney@godaddy.com

OWASP

vineeth.sai@owasp.org

DistributedApps.ai

ken.huang@distributedapps.ai

OWASP

idan.habler@gmail.com

Cisco Systems

isheriff@cisco.com

Security Independent Submission agent identity DNS transparency log DANE SCITT PKI Autonomous AI agents now invoke one another across organizational boundaries over protocols such as the Model Context Protocol (MCP) and Agent2Agent (A2A). A relying party has no interoperable way to bind a discoverable agent endpoint to the holder of its domain (optionally verified as a legal entity), a specific software release, and an auditable issuance history. This document specifies the architecture of Agent Name Service version 2 (ANS v2), an identity layer, anchored in DNS domains, that binds an agent endpoint to its domain holder, its release, and its history. ANS v2 composes systems the Internet already runs (the DNS with DNSSEC; the Web PKI, with DANE where operators publish it; and an append-only transparency log) and introduces no new root of trust. Every ANS v2 agent carries a versioned name rooted in a DNS domain that the registrant controls. When a registrant registers an agent, the Registration Authority (RA) checks the registrant's control of that domain, can issue an Identity Certificate that binds the versioned name to the agent's key, and submits a signed registration record to a Merkle-tree transparency log. Under the current specifications, a new version is a new registration and a new log entry, so a verifier can pin an agent to a specific release. Any third party can detect a rewritten log by computing, from the log's public tiles, a consistency proof between two of its signed checkpoints. For discovery, ANS v2 adopts the SVCB records and SvcParams of DNS for AI Discovery (DNS-AID) as its default format, and keeps an older TXT-based format only as an opt-in profile. Beyond those discovery records, ANS v2 specifies one DNS record, an "_ans-badge" TXT record that points to the agent's transparency-log entry; the log seals the fingerprint of the agent server's certificate, and operators can add DANE records. With these records, a verifier resolves an agent, authenticates its TLS endpoint, and confirms that the presented name, version, and key match a logged registration. This document also states a threat model covering agent impersonation, DNS spoofing, CA and Registration Authority compromise, version rollback, agent card tampering, and log rewriting, and names what each ANS check does and does not prevent. The reference registry, transparency log, verifier, JSON Schemas, SDKs, and CLI are open source.

Introduction An AI agent that calls another agent over MCP or 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 , anchors each agent's name in a domain its owner controls. X.509 certificates let a caller authenticate the agent's TLS endpoint, and an operator can pin them in DNS with DANE . 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 and the model of SCITT , 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 , numbered ANS-0 through ANS-6, state what each implementation must do.

Status and Transition Note ANS began as the Agent Name Service specification by Huang, Narajala, Habler, and Sheriff , which Vineeth Narajala brought to the IETF as . then specified ANS v2. ANS has since separated into these parts:

1. DNS discovery. An ANS registrant publishes agent discovery records as the SVCB resource records and SvcParams that defines; the DNS-AID authors develop that draft separately in the IETF DNSOP working group. Beyond its opt-in TXT discovery format, ANS defines one DNS record of its own, the "_ans-badge" TXT record.
2. Specifications and reference implementation. The ANS project develops the ANS-0 through ANS-6 specifications, the reference registry, transparency log, verifier, JSON Schemas, SDKs, and CLI as open source at https://github.com/agentnameservice.
3. Architecture: this document.

Scope This document does not define the wire format of discovery records (DNS-AID does), or the application protocols agents speak (MCP, A2A, and others). ANS tells a verifier who an agent is; whether to trust or transact with that agent is the verifier's own decision, which a separate scoring service that reads ANS records can inform. ANS records registrations and their lifecycle, not the actions an agent takes, and binds the keys in the certificates the TL seals and, through the optional identity service (), the keys an organization identifier lists. Keys an agent publishes for application protocols, such as keys that sign payment authorizations, stay outside ANS.

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 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.

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.

ANS v2 roles and the records each one produces 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 . 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.

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 (), 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 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 () 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.

Registration Lifecycle A registrant registers an agent in three steps :

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 , 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 ().

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 () 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. covers what the former holder can still do with its existing registrations.

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 , 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 , a verifier treats a TLSA record set as unusable unless DNSSEC validates it as "secure".

Transparency Log The TL keeps one Merkle tree. ANS-4 specifies the TL's leaf hashing, which follows , 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 ;
• 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 , the Hashgraph Online profile for publishing Merkle checkpoints to a Hedera Consensus Service topic.

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 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.

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.

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 () 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 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 ().

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 (); 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 ().

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.

Security Considerations

Agent Impersonation An attacker who wants to pose as "travel.example.com" must answer the RA's domain-control challenge for that name, present a certificate whose fingerprint the TL sealed, and prove it holds that certificate's key. Without control of the domain, the attacker cannot register the name; without the key, the attacker cannot pass Method A or Method B. An operator's agents that share a wildcard certificate present the same fingerprint, so a verifier tells them apart by the name it dialed and, for a caller, by the ANSName in the caller's Identity Certificate. An attacker who does gain control of the domain can register new versions, but each one appears in the public TL, where the owner and any monitor can see it.

DNS Spoofing Without DNSSEC, an attacker on the path can forge the "_ans-badge" answer. ANS-6 limits the damage with an allowlist of trusted TLs: the attacker can point the verifier at a trusted TL's badge for a different agent, but every field the verifier compares is anchored either to the validated client certificate or to the name the caller dialed, so the verifier's checks fail. Without DNSSEC, a verifier gets nothing from DANE (). Operators who want verifiers to check their DNS records sign their zones.

Certification Authority Compromise A compromised public CA can issue a Server Certificate for any agentHost, and a compromised RA private CA can issue Identity Certificates for any ANSName. Neither certificate has a fingerprint in the TL, so a verifier that matches the presented fingerprint against the TL rejects both. A legitimately renewed certificate does have a fingerprint in the TL, because this document requires the RA to log each renewal (). Where the operator publishes DANE records in a signed zone, the TLSA check catches the forged Server Certificate a second time.

Registration Authority Compromise A TLSA record adds an independent check only when the party that publishes the TLSA record differs from the party that obtained the Server Certificate. An RA that both obtains the certificate and operates the zone can defeat DANE alone; a verifier then relies on the TL's public history, where every certificate fingerprint the RA seals stays visible to the owner and to monitors. If an attacker steals a producer key, the operator revokes that key: the TL stops accepting events signed with it, events sealed before the compromise stay verifiable, and the sealed history bounds what the attacker could have injected to the compromise window.

Log Rewriting and Equivocation When one operator runs both the RA and the TL, that operator holds the keys that sign events and checkpoints and could in principle forge history. The public checkpoints and tiles let any third party compute a consistency proof that the log only appended entries between two checkpoints, and a rewritten log cannot produce consistent proofs against checkpoints it already published. A TL that anchors its checkpoints to an external ledger puts the record of those checkpoints outside the operator's control, and a deployment that runs the RA and the TL under different operators removes the risk that one operator forges both. Verifiers catch a log that shows different checkpoints to different verifiers (a split view) only when they compare the checkpoints they received through an independent channel. The external ledger gives verifiers that channel, provided each verifier checks its checkpoints against the ledger. The ANS specifications do not yet define a witnessing protocol ().

Version Rollback Each version is a separate registration with its own ANSName, certificates, and TL records, so a verifier that requires "ans://v1.4.2.travel.example.com" can reject any other version. Otherwise the verifier learns from the version's TL status whether the version is retired, on either tier: the badge-tier verifier reads the status in the badge, the SCITT-tier verifier reads the status in the status token, and the TL derives both from the same events (). On the badge tier the verifier first selects the "_ans-badge" record whose version matches the version in the caller's Identity Certificate; selecting the record finds the TL entry to read and does not decide whether the version is retired. A registrant that deleted an old version's badge record before the RA revoked the version would block that version for badge-tier verifiers only, which is why has the registrant keep the record until then. ANS-6 currently treats a DEPRECATED version as valid for connections and has the verifier warn, so a deprecated release stays reachable until the RA revokes it (). A caller that must reach only the latest release checks the version itself, and a registrant that retires a vulnerable release revokes that release's registration.

Agent Card Tampering A verifier running the card check in catches a host that changes an agent's card after registration, if the registrant declared a digest. The digest is optional, so a registration without one gives a verifier nothing to compare. The registrant computes the digest and the RA never fetches the card (), so a matching digest shows only that the card has not changed since registration, not that any third party checked the card's content. The ANS specifications define no way to update a sealed digest; a registrant who changes the card registers a new version.

Revocation Latency After the RA revokes a registration, verifiers stop accepting the agent within a bounded time, not instantly. On the SCITT tier the worst case at default settings is the status token's one-hour lifetime, plus up to ten minutes of allowed clock skew, plus a grace window of up to one more token lifetime: two hours and ten minutes. High-assurance deployments shorten the token lifetime, decline the grace window, or check the live badge for critical transactions.

Domain Transfer When a domain changes hands, the former holder's registrations stay ACTIVE until the RA revokes them () or their certificates expire. Until then, the former holder can still call other agents under an old ANSName, and a verifier on the SCITT tier accepts the call, because that tier never reads the new holder's zone. On the badge tier, the verifier reads the new holder's "_ans-badge" records, finds no badge that matches the former holder's certificate, and rejects the call. A relying party that must notice a change of holder checks the live badge, the same check suggests for revocation.

Monitor Abuse A malicious monitor might try to get consumers to drop a valid agent. Under the rules in , a single false report produces no warning.

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 .

IANA Considerations This document has no IANA actions at this time. A future revision may ask IANA to register the "ans" URI scheme per and the underscore labels "_ans" and "_ans-badge" per .

References Normative References The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Agent Name Service project Informative References This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. IEEE ICAIC 2026 Anthropic A2A Project Community Cryptography Specification Project Hashgraph Online CA/Browser Forum

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 .
• 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.