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

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 maps names to addresses but does not verify identity or track software versions. DNS-SD 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 connects models to local tools and external APIs. 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.

Origin and Evolution This document builds on "Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability" , 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.

Relationship to Other Standards HCS-14 uses DNS TXT records for agent discovery; an ANS Profile for HCS-14 allows any HCS-14 resolver to discover ANS agents. HCS-27 defines a checkpoint format for publishing the Transparency Log's root hash to a distributed consensus topic. The IETF SCITT working group defines an append-only transparency service; the ANS TL follows this model. DNS-AID uses SVCB service binding records for agent endpoint discovery; DNS-AID tells a client where to connect, ANS tells it whether to trust the agent.

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

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.

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.

Registration Authority System The RA system comprises:

Registration Authority (RA):

Receives registration requests from AHPs, validates domain control via ACME , 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.

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.

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.

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 , issuing binary COSE receipts as proof of inclusion. A conforming TL MUST expose a REST API for external verifiers:

Endpoint	Purpose
GET /v1/agents/{agentId}	Sealed event, TL signature, and inclusion proof
GET /v1/agents/{agentId}/audit	Paginated history of all lifecycle events
GET /v1/log/checkpoint	Latest signed checkpoint: log size, root hash, KMS signature
GET /v1/log/checkpoint/history	Checkpoint history for consistency proof verification
GET /v1/log/schema/{version}	JSON Schema definition for a given event schema version
GET /root-keys	KMS verification keys, including historical keys

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.

Certificate Authorities Two CAs, two trust roots, two revocation paths:

• Public CA: Issues Server Certificates. Revocation propagates through public OCSP/CRL .
• 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.

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

Data Model and Integrity

The ANSName The canonical identifier for a registered agent has three components (, ): ]]> Example: ans://v1.0.0.sentiment-analyzer.example.com

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.

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.

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
Supersedes ID	RA	No	Previous version's record

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.

Certificate Integrity

Certificate	Issued by	SAN type	Purpose
Server	Public CA	dNSName	Standard TLS for the stable FQDN
Identity	Private CA	URI SAN	Binds certificate to a versioned ANSName

The Identity Certificate requires a URI SAN. The ans:// scheme is syntactically valid per RFC 3986 Section 3.1 and permitted in URI SANs per RFC 5280 Section 4.2.1.6.

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.

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)

Cryptographic Data Integrity Standards

Requirement	Standard	Rule
Canonicalization	JCS (RFC 8785)	All JSON MUST be canonicalized before signing or hashing
Signature format	JWS Detached	Payload is not embedded; signatures stored separately
Algorithm	ES256 (ECDSA P-256/SHA-256)	Default. MUST support algorithm agility.
Wire format	JWS Compact	<header>..signature (two dots; detached payload)

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 before signing. Signatures use JWS Compact Serialization with the JSON data interchange format .

Trust, Security, and Attestation

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)

Tier	Steps	Shorthand
Bronze	1	PKI only
Silver	1-2	PKI + DANE
Gold	1-3	PKI + DANE + TL

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) . DANE requires DNSSEC . 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.

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

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.

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) encrypts the inner ClientHello, hiding the hostname. When an AHP provides an ECH configuration during registration, the RA publishes it in the HTTPS record.

Operational Flow

Initial Registration Flow Registration has two stages:

1. AHP submits registration request.
2. RA validates domain control (ACME) .
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.

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

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.
6. AHP provisions DNS: The AHP creates the DNS records using the content the RA specified.

Lifecycle Operations

Operation	Trigger	TL Event	DNS Effect
Version bump	Code/config change	AGENT_REGISTERED	New per-version records
Renewal	Certificate expiring	AGENT_RENEWED	None
Revocation	Agent shutdown	AGENT_REVOKED	Per-version removed

DNS Record Set The RA generates record content for child labels under the agent's FQDN:

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 DANE	_ans-identity._tls.{host}	TLSA	Identity Cert fingerprint

The _ans TXT record is a connection hint published in DNS: The _ans-badge TXT record points to the version's badge in the TL:

Ongoing Integrity Verification An AIM MUST distinguish between "Unreachable" (transient network failure, retry later) and "Mismatch" (the content has changed, remediation needed).

Check	What the AIM does	Pass condition
DNS pointer	Authoritative query for _ans and _ans-badge with DNSSEC	Records exist and validate
Trust Card integrity	Fetch Trust Card, hash content	Hash matches sealed agentCardHash
Schema integrity	Fetch each schema.url, hash content	Hash matches schema.hash in Trust Card

Interoperability and Standards Alignment

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.

HCS-27 Merkle Tree Checkpoint A companion specification 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.

IETF SCITT Alignment The 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) signed statements and standardized receipt formats.

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.
• Enterprise ANS as a service: hosted on behalf of an enterprise.
• Extranet ANS: semi-private, shared among partner organizations.

Coexistence with DNS-AID A domain owner can publish DNS-AID SVCB records alongside _ans TXT records. The two record families occupy different DNS names and do not collide.

Formal Properties

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

Cryptographic Boundary Enforcement The protocol distributes trust across four services. No service accepts another's assertions without verifying a cryptographic signature.

Boundary	Verification	What compromise means
RA to TL	TL verifies producer signature (ES256, registered key)	Forged event rejected at ingestion
TL to Verifier	Verifier checks KMS signature on checkpoint	Tampered checkpoint fails validation
TL to Event Stream	Each event carries the producer's signature	Fabricated event fails signature check
AIM to RA	RA re-verifies each finding against TL records	False finding detected on re-verification

Security Considerations This section addresses threats identified through a MAESTRO framework analysis applied to the ANS architecture.

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.

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.

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.

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.

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.

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.

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.

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.

IANA Considerations This document has no IANA actions at this time. 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.

References Normative References Informative References IEEE ICAIC 2026 Anthropic Google Hiero Hiero HCS-27 Working Group

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.

Registration Request

TL Event Payload

DNS Records _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 ]]>