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

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

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

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:¶

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 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.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 = <FQDN per RFC 1035 and RFC 1123>

Example: ans://v1.0.0.sentiment-analyzer.example.com¶

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

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

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

4.6. Cryptographic Data Integrity Standards

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.1. Verification Tiers

A client verifies an agent through independent checks, each using a different trust channel:¶

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.¶
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.1. Initial Registration Flow

Registration has two stages:¶

1. AHP submits registration request.¶
2. RA validates domain control (ACME) [RFC8555].¶
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.2. Lifecycle Operations

6.3. DNS Record Set

The RA generates record content for child labels under the agent's FQDN:¶

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

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

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

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

A.1. Registration Request

{
  "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

{
  "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

$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 <sha256_of_server_cert>

_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 <sha256_of_identity_cert>