Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability

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 2 November 2025.¶

Copyright Notice

Copyright (c) 2025 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Agent-to-agent communication is expected to become a significant component of internet traffic, driving the need for reliable mechanisms enabling agents to discover, verify, and securely interact with one another. Traditional service discovery, notably the Domain Name System (DNS) [RFC1035], primarily maps human-readable names to network addresses and is insufficient for the dynamic, semantically rich, and security-sensitive environment of agentic AI. Enhancements like DNS-Based Service Discovery (DNS-SD) [RFC6763] offer improvements but still fall short of the necessary agent capability granularity, identity verification, and lifecycle management required by autonomous agents. Furthermore, maintaining a trustworthy registry necessitates robust processes for agent registration and periodic renewal.¶

Several agent communication protocols are emerging to standardize interactions:¶

• Agent2Agent (A2A) Protocol: Developed by Google, providing a standardized protocol for inter-agent communication, aiming to bridge different agent frameworks.¶
• Model Context Protocol (MCP): Focused on simplifying the integration of AI models with external tools and data sources.¶
• Agent Communication Protocol (ACP): Designed to standardize how agents communicate, enabling automation, collaboration, UI integration, and developer tooling, evolving from initial MCP concepts.¶

This document outlines the Agent Name Service (ANS), a framework for a protocol-agnostic Agentic AI Registry. ANS complements these emerging protocols by integrating Public Key Infrastructure (PKI) for identity and trust, defining structured communication via JSON Schema, incorporating DNS-like naming for discovery, establishing mechanisms for agent registration and renewal, and providing a formal specification of the protocol to enhance precision and implementability. ANS aims to provide a universal, secure directory service foundation for interoperable agent ecosystems.¶

2. Related Work

Traditional service discovery, such as DNS [RFC1035], provides essential name-to-address resolution but lacks the semantic understanding and security features needed for agentic AI. DNS-SD [RFC6763] adds local service discovery capabilities but doesn't address verifiable identity or complex agentCapability matching on a global scale.¶

Research in multi-agent systems (MAS) has explored various agent communication languages (ACLs), such as those defined by the Foundation for Intelligent Physical Agents (FIPA) [FIPA-ACL]. While influential, these often lack standardized, built-in security mechanisms and universally adopted transport protocols suitable for the modern internet.¶

The emerging protocols represent significant advancements:¶

• A2A [A2A-Blog] [A2A-Spec] focuses on bridging agent ecosystems.¶
• MCP [MCP-News] [MCP-Spec] emphasizes dynamic discovery and integration of tools/data for AI models.¶
• ACP [IBM-ACP-Placeholder] targets broader agent-to-agent communication needs, including delegation and orchestration.¶

Our work builds upon these efforts not by replacing them, but by providing a complementary, protocol-agnostic infrastructure layer. ANS differentiates itself by integrating PKI-based identity verification [RFC5280] directly into the discovery and lifecycle management process, offering a universal registry mechanism that enhances trust and facilitates secure interaction across different protocol standards via a common discovery plan. Furthermore, the formalized specification of the ANS protocol ensures clarity and ease of implementation.¶

3. Agent Registry Architecture

The proposed Agent Registry architecture provides a secure, interoperable platform for agent discovery and interaction, supporting multiple communication protocols through a modular design. Key components include:¶

Requesting Agent:

The entity initiating the agent registration process, which could be an individual, organization, or automated system seeking to register a new agent or update existing agent information in the registry.¶

Agent Registry:

A potentially distributed database for storing ACEM (Agent Credential and Entitlement Management) and DID (Decentralized Identifier) related information. This registry encompasses agent capabilities, security policies, PKI certificates, protocol-specific metadata (via protocolExtensions), and registration/renewal timestamps, supporting a comprehensive framework for agent identity, authentication, and authorization.¶

Certificate Authority (CA):

A trusted entity issuing and managing X.509 digital certificates [RFC5280] for agents, forming the root of trust.¶

Registration Authority (RA):

Verifies agent registration/renewal requests, interacts with the CA to issue certificates based on Certificate Signing Requests (CSRs), manages the agent lifecycle (registration, renewal, revocation), and validates the legal entity of the Requesting Agent. It enforces registry policies.¶

Protocol Adapter Layer:

Translates between the registry's internal representation and protocol-specific formats (details in Section 5).¶

Request/Response Schema:

A protocol-agnostic JSON-based schema [RFC8259] for registry interactions (discovery, registration, etc.), incorporating PKI data and allowing protocol-specific extensions (details in Section 3.4).¶

Agent Name Service (ANS):

Enables agent discovery using human-readable, structured names, coupled with agentCapability-based resolution (details in Section 3.5).¶

Figure 1 illustrates the core components of the Agent Name Service (ANS) and their interactions.¶

+-----------+    Requests agent discovery    +-------------+
|   Agent   | ----------------------------> | ANS Service |
+-----------+                               +-------------+
                                                      |
                                                      | Looks up agent info
                                                      v
+-----------------------+    Translates messages    +----------------+
| Protocol Adapter Layer| <---------------------- | Agent Registry |
+-----------------------+                         +----------------+
                                                      ^      ^
                                                      |      | Verifies
                                Validates reg.        |      | identity
                                                      |      |
                                +-----------------------+  +---------------------+
                                | Registration Authority|  | Certificate Authority |
                                +-----------------------+  +---------------------+

The Protocol Adapter Layer translates between the registry's internal representation and protocol-specific formats. For example, consider an agent registering with the MCP. An MCP tool description might be represented as a JSON blob. The agent would need to be registered with ANS first and foremost. Therefore, imagine this tool is associated with the following ANSName: "mcp://sentimentAnalyzer.textAnalysis.ExampleCorp.v1.0".¶

This would mean the MCP tool is now discoverable via the ANS. The MCP specific extension data itself might look like this:¶

{
  "description": "Analyzes sentiment of text input.",
  "input_schema": {
    "type": "string",
    "description": "Text to analyze."
  },
  "output_schema": {
    "type": "object",
    "properties": {
      "sentiment": {
        "type": "string",
        "enum": ["positive", "negative", "neutral"]
      },
      "score": {
        "type": "number",
        "description": "Sentiment score (-1 to 1)."
      }
    }
  },
  "mcpEndpoint": "https://sentiment.example.com/analyze"
}

The MCP Adapter within the Protocol Adapter Layer would parse this JSON and map it to the registry's internal columns. This could involve:¶

• Extracting information implicitly: since the ANSName is "mcp://sentimentAnalyzer.textAnalysis.ExampleCorp.v1.0", this implicitly defines the:¶

  • Protocol: mcp¶
  • AgentID: sentimentAnalyzer¶
  • agentCapability: textAnalysis¶
  • Provider: ExampleCorp¶
  • Version: v1.0¶
• Storing the description ("Analyzes sentiment of text input.") in a dedicated description field within protocolExtensions.¶
• Serializing the input_schema and output_schema and storing them in a protocolExtensions column specific to MCP, allowing other MCP-aware agents to understand the tool's interface.¶
• The actual MCP endpoint "https://sentiment.example.com/analyze" would be stored within the protocolExtensions, under the key mcpEndpoint.¶

This normalization process allows the Agent Registry to store and query MCP-specific information in a protocol-agnostic way, while adhering to the ANSName structure for consistent identification and resolution.¶

Agent                           RA                               CA                       Agent Registry
  |---Registration Request--->|                                  |                                |
  | (metadata & CSR)        |                                  |                                |
  |                           |---Validate Identity----->|                                  |
  |                           |<--[Validation Fails]-----|                                  |
  |<----Registration Rejected-|                                  |                                |
  |                           |---[Validation Successful]->                                  |
  |                           |---Request Certificate--->|                                  |
  |                           |                          |<----Issue Certificate----|
  |                           |<----Certificate----------|                                  |
  |                           |---Store Agent Info & Cert-------------------------->|
  |<----Confirmation---------|                                                          |

VerifyCertChain (Cert, TrustedCA) -> Boolean:
  1. Get the certificate authority (CA_signer) that signed the Cert.
  2. Check for Certificate Revocation status of Cert via CRL or OCSP.
  3. If Cert is Revoked, Return False.
  4. If CA_signer is the TrustedCA, Return True (assuming Cert is validly signed by it and not expired).
  5. Else, get the certificate of CA_signer (IssuerCert) and recursively call
     VerifyCertChain(IssuerCert, TrustedCA).
  6. If no trusted CA is found in the chain, Return False.

VerifySignature (Data, Signature, PublicKey) -> Boolean:
  1. Use PublicKey to decrypt/verify the Signature against the Data.
  2. Hash Data using the agreed-upon cryptographic hash function (e.g., SHA-256)
     that was used by the signer.
  3. Compare the hash obtained from the signature with the hash
     calculated from the Data.
  4. If the hashes match and the signature is cryptographically valid,
     Return True.
  5. Else, Return False.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "AgentRegistrationRequest",
  "description": "Schema for Agent Registration Request",
  "type": "object",
  "properties": {
    "protocol": {
      "type": "string",
      "enum": ["a2a", "mcp", "acp"],
      "description": "Communication Protocol"
    },
    "agentID": {
      "type": "string",
      "description": "Unique Agent Identifier"
    },
    "agentCapability": {
      "type": "string",
      "description": "Primary Agent Capability"
    },
    "provider": {
      "type": "string",
      "description": "Name of the Provider"
    },
    "version": {
      "type": "string",
      "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-((?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\\.(?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\\+([0-9a-zA-Z-]+(?:\\.[0-9a-zA-Z-]+)*))?$",
      "description": "Semantic Versioning format"
    },
    "extension": {
      "type": "string",
      "description": "Extension Metadata"
    },
    "certificate": {
      "type": "object",
      "properties": {
        "subject": {"type": "string", "description": "Certificate Subject"},
        "issuer": {"type": "string", "description": "Certificate Issuer"},
        "pem": {
          "type": "string",
          "description": "PEM-encoded Certificate (strongly recommended to use a secure vault reference instead)",
          "readOnly": false
        }
      },
      "required": ["subject", "issuer", "pem"]
    },
    "protocolExtensions": {
      "type": "object",
      "description": "Protocol-specific data"
    }
  },
  "required": ["protocol", "agentID", "agentCapability", "provider", "version", "certificate"]
}

ANSName = Protocol "://" AgentID "." agentCapability "." Provider ".v" Version ["." Extension]

Requesting Agent        ANS Service                 Agent Registry          Trusted CA
  |---Resolution Query---->|                           |                       |
  | (ANSName + filters)   |                           |                       |
  |                       |---Query Agent Record--->|                           |
  |                       |                           |<--[Record Not Found]-|
  |                       |<----No Record Found-----|                           |
  |<--Agent Not Found Err--|                           |                       |
  |                       |                           |---[Record Found]---->|
  |                       |<--Return Agent Endpoint-|                           |
  |                       |   (data, sig, cert)     |                           |
  |                       |---Verify Signature (using Agent Registry Key)-->|
  |                       |<--[Signature Invalid]--|                           |
  |<--Invalid Sig Error---|                           |                       |
  |                       |---[Signature Valid]--->|                           |
  |                       |---Verify Cert Chain (Target Agent Cert)------>| (Trusted CA for agent certs)
  |                       |                           |<--[Cert Invalid]-----|
  |                       |<----Invalid Cert Error--|                           |
  |                       |                           |---[Cert Valid]------>|
  |<--Return Verified Endpoint----------------------|                           |
  | (binding & sec info)  |                           |                       |

Resolve(ANSName, RequestedVersionRange) -> EndpointRecord / ERROR:
1. Parse ANSName into Protocol, AgentID, agentCapability,
   Provider, Version, Extension.
2. Query Agent Registry for Agents with matching Protocol, AgentID,
   agentCapability, Provider.
3. If no match found:
   Return ERROR("Agent not found").
4. If multiple matches found (different versions):
   Match = VersionNegotiation(Matches, RequestedVersionRange).
   If Match is ERROR("Incompatible Version"):
     Return ERROR("Incompatible Version").
5. EndpointRecord_struct = GetAgentEndpointRecord(Match.AgentID).
   // Renamed to avoid conflict, EndpointRecord_struct: {data, signature, Cert}
   If EndpointRecord_struct is ERROR:
     Return ERROR("Could not retrieve endpoint record").
6. Valid = VerifyAgentEndpointRecord(EndpointRecord_struct,
                                     TrustedCA_for_Registry_Signature,
                                     TrustedCA_for_Agent_Certs).
7. If Valid is False:
   Return ERROR("Invalid Endpoint").
8. Return EndpointRecord_struct.data. // Contains the actual endpoint URI/info

--- Helper Functions ---
GetAgentEndpointRecord(AgentID_from_Match) -> EndpointRecord_struct / ERROR:
  // Agent Registry implements this to fetch records.
  // This function must enforce authentication and authorization
  // against Agent Registry ACLs if applicable.
  // Returns {data, signature, Cert} or ERROR.

VerifyAgentEndpointRecord(EndpointRecord_struct, RegistryTrustedCA, AgentCertTrustedCA) -> Boolean:
  // 1. Verify signature on EndpointRecord_struct.data using
  //    AgentRegistry.PublicKey (obtained from a cert issued by RegistryTrustedCA).
  signatureValid = VerifySignature(EndpointRecord_struct.data,
                                   EndpointRecord_struct.signature,
                                   AgentRegistry.PublicKey);
  If not signatureValid:
    Return False; // Or ERROR("Invalid Registry Signature")

  // 2. Verify certificate chain of the target Agent's Cert (EndpointRecord_struct.Cert)
  //    against AgentCertTrustedCA.
  certChainValid = VerifyCertChain(EndpointRecord_struct.Cert, AgentCertTrustedCA);
  If not certChainValid:
    Return False; // Or ERROR("Invalid Agent Certificate Chain")

  Return True;

// VerifySignature and VerifyCertChain are defined in Section 3.3

VersionNegotiation(Matches, RequestedVersionRange) -> Match_object / ERROR:
  1. Sort Matches by Version (highest to lowest Semantic Version).
  2. For each Match_item in Matches:
  3.   If RequestedVersionRange is empty OR RequestedVersionRange == "*" OR
         IsVersionCompatible(Match_item.Version, RequestedVersionRange):
  4.       Return Match_item;
  5. End For
  6. Return ERROR("Incompatible Version");

IsVersionCompatible(AgentVersion, ReqRange) -> Boolean:
  // Implement Semantic Version range compatibility check.
  // (e.g., using a library like node-semver's satisfies function)
  // 1. Attempt to parse ReqRange as a SemVer range.
  // 2. If parsing fails, treat ReqRange as a specific SemVer version.
  // 3. Check if AgentVersion is satisfied by the ReqRange.
  // Example: return SemVer.satisfies(AgentVersion, ReqRange);
  Return true; // Placeholder for actual SemVer library call

{
  "a2aCapabilityVerification": {
    "capabilityVerification": {
      "proofMechanism": "ZKP",
      "verificationCircuit": {
        "constraints": [
          "agent.hasCapability(c) AND agent.isAuthorized(c)",
          "agent.certificate.isValid() AND agent.certificate.notRevoked()"
        ],
        "proofGeneration": "Groth16",
        "verificationKey": "0x4a8f..."
      }
    },
    "rateLimit": {
      "algorithm": "TokenBucket",
      "refillRate": "100/s",
      "burstCapacity": 500,
      "perCapability": true
    }
  }
}

{
  "mcpAgentIdentity": {
    "resourceAccessControl": {
      "model": "RBAC+ABAC",
      "policyDecisionPoint": {
        "engine": "OPA",
        "evaluationMode": "distributed"
      },
      "contextAttributes": [
        "agent.role",
        "resource.classification",
        "time.window",
        "operation.sensitivity"
      ]
    },
    "toolRegistration": {
      "sandboxValidation": {
        "environment": "gVisor",
        "runtime": "V8Isolate",
        "memoryLimit": "256MB",
        "cpuQuota": "0.5",
        "networkPolicy": "DENY_ALL"
      }
    }
  }
}

4. Request/Response Schema for ANS Name Resolution

The following core JSON Schemas define the structure for AgentCapability requests (used for resolving ANSNames) and responses. These ensure validated and structured communication for discovery operations. (Full schemas are linked in Appendix A).¶

AgentCapabilityRequest Schema:¶

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "AgentCapabilityRequest",
  "description": "Schema for Agent agentCapability Request (Resolution)",
  "type": "object",
  "properties": {
    "requestType": { "type": "string", "enum": ["resolve"] },
    "protocol": { "type": "string",
                  "description": "Target protocol (from ANSName)"},
    "agentID": { "type": "string",
                 "description": "Target agentID (from ANSName)"},
    "agentCapability": { "type": "string",
                         "description": "Target capability (from ANSName)"},
    "provider": { "type": "string",
                  "description": "Target provider (from ANSName)"},
    "version": { "type": "string",
                 "description": "Target version or version range (from ANSName or query)" },
    "extension": { "type": "string",
                   "description": "Target extension (from ANSName, optional)"}
  },
  "required": ["requestType", "protocol", "agentID",
               "agentCapability", "provider", "version"]
}

AgentCapabilityResponse Schema:¶

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "AgentCapabilityResponse",
  "description": "Schema for Agent agentCapability Response (Resolution)",
  "type": "object",
  "properties": {
    "Endpoint": {
      "type": "string",
      "description": "Resolved agent address/endpoint URI (e.g., a2a://translatorBot.DocumentTranslation.exampleCorp.v1.2.3.secure)"
    },
    "signature": {
      "type": "string",
      "description": "Digital signature of the Endpoint data by Agent Registry"
    },
    "cert": {
      "type": "string",
      "description": "PEM-encoded Certificate of the target Agent (strongly recommended to use a secure vault reference instead)",
      "readOnly": false
    }
  },
  "required": ["Endpoint", "signature", "cert"]
}

Key points regarding schemas:¶

• Use a JSON Schema validator library for enforcement.¶
• Pay close attention to required fields and data type constraints.¶
• Validate all incoming and outgoing messages related to ANS resolution against these schemas.¶
• Implement graceful error handling for validation failures.¶
• Monitor evolving standards in agent communication (A2A, MCP, ACP) and update schemas as necessary to maintain compatibility and incorporate new features.¶

5. Protocol Adapter Layer

The Protocol Adapter Layer is a critical component that enables the ANS registry to support diverse agent communication protocols (like A2A, MCP, ACP) without being tightly coupled to any single one. It acts as an intermediary, translating between the registry's core logic and internal data storage format and the specific requirements and metadata formats of each supported protocol.¶

Modularity:

Adapters are implemented as distinct, pluggable modules (e.g., plugins or separate services). This allows for easy addition of support for new protocols or updates to existing ones without altering the core registry logic.¶

Functionality:

Each protocol adapter understands how to:¶

• Parse protocol-specific metadata (e.g., from an A2A Agent Card, MCP Tool Description) and map relevant parts into the registry's internal representation, especially within the 'protocolExtensions' field of an agent's record.¶
• Extract information from an agent's registry record to construct responses to protocol-specific discovery queries.¶
• Potentially handle protocol-specific aspects of the registration or validation process if they differ significantly from the generic ANS procedures.¶

Each adapter is responsible to securely implement features defined by each protocol.

Some protocols have built-in security, such as signed messages.¶

Translation Focus:

Adapters primarily focus on metadata translation for the purposes of discovery and registration. They do not typically handle real-time message translation between different protocols during agent-to-agent interaction. Their role is to help agents find each other and verify identity; subsequent communication generally uses the agents' shared native protocol.¶

Security aspect:

• All adapter implementations must use secure, up-to-date libraries commonly employed for the supported protocols.¶
• Implementations MUST adhere to the security guidance provided by each specific protocol.¶
• Since each adapter parses potentially untrusted blobs of data (protocol-specific metadata), it is MANDATED that they be implemented in memory-safe languages (e.g., Rust, Go) and be accompanied by formal test suites to ensure robustness against parsing vulnerabilities.¶

                                +-----------------+
                                | Agent Name      |
                                | Service (ANS)   |
                                | (Core Registry) |
                                +-----------------+
                                  /      |      \
                                 /       |       \
                                v        v        v
        +-----------------+   +-----------------+   +-----------------+
        | A2A Protocol    |<->| MCP Protocol    |<->| ACP Protocol    |
        | Adapter         |   | Adapter         |   | Adapter         |
        +-----------------+   +-----------------+   +-----------------+
                ^                       ^                       ^
                |                       |                       |
                v                       v                       v
        +-----------------+   +-----------------+   +-----------------+
        | A2A Agent       |   | MCP Agent       |   | ACP Agent       |
        +-----------------+   +-----------------+   +-----------------+

interface ProtocolAdapter {
  // Identifies the protocol supported by this adapter
  // (e.g., "a2a", "mcp", "acp")
  String getProtocol();

  // Parses protocol-specific metadata from the raw
  // 'protocolExtensions' data (e.g., a JSON object or string)
  // and maps it to a structured internal representation used by
  // the registry (e.g., a map or a dedicated object).
  // Returns a representation of the extracted data.
  Map<String, Object> parseMetadata(Object protocolExtensionsData);

  // Constructs a protocol-specific discovery response payload
  // based on information retrieved from an agent's registry record.
  // 'registryRecord' contains the agent's core ANS data and the
  // parsed protocolExtensions.
  Object createDiscoveryResponse(Map<String, Object> registryRecord);

  // Handles any protocol-specific validation logic required during
  // the agent registration process, beyond the standard ANS checks.
  // 'registrationRequest' is the full request object.
  // Returns true if validation passes, false otherwise.
  Boolean validateRegistration(AgentRegistrationRequest request);
}

6. Security Considerations

The security of the Agent Name Service is paramount for its adoption and the trustworthiness of the agent ecosystems it supports. This section outlines key threats, mitigation strategies, and security controls, referencing the MAESTRO 7 Layers framework [Huang-MAESTRO] where applicable. See RFC 3552 [RFC3552] for a general guide on writing security considerations.¶

7. Implementation Considerations

The Agent Registry, the core of ANS, can be implemented using various architectural patterns. The choice depends on factors such as the expected scale of deployment, trust model, performance requirements (latency, throughput), administrative overhead, and cost. The Protocol Adapter Layer is well-suited to a plugin-based architecture.¶

Common implementation patterns for the registry include:¶

Centralized:

A single logical registry instance. Simple to manage and ensures strong consistency. However, it can be a single point of failure and a performance bottleneck. Suitable for smaller, private, or experimental deployments.¶

Distributed (e.g., using Cassandra, CockroachDB):

Offers high availability, fault tolerance, and scalability. Technologies like Cassandra provide tunable consistency (often eventual consistency). Requires robust coordination mechanisms and careful data partitioning strategies.¶

Distributed (DHT - Distributed Hash Table):

Highly scalable peer-to-peer lookup. Can be complex for state management and ensuring data integrity. Suitable for very large-scale, decentralized deployments where eventual consistency is acceptable.¶

Blockchain/Distributed Ledger Technology (DLT):

Smart contracts can act as Registry Agents, with registrations and updates recorded as transactions on a blockchain. Offers high security, transparency, and auditability but typically suffers from high latency, limited scalability (transactions per second), and significant write amplification (one logical write results in many physical writes across the network and storage), increasing storage costs and reducing performance.¶

Federated:

Multiple independent registries interoperate, often aligning with organizational or geographic boundaries. Requires standardized inter-registry communication protocols, shared trust anchors (e.g., cross-certified CAs or a common root CA), and mechanisms for cross-domain name resolution and identity verification. Without these, a federated system risks becoming a collection of isolated silos.¶

Hybrid:

Combines elements of different patterns. For example, a centralized RA/CA infrastructure might serve multiple distributed/replicated read-only registry nodes. Caching layers (e.g., Redis, Memcached) can be used to improve read performance in many of these models. Requires careful management of consistency between components.¶

Key considerations when choosing an implementation pattern:¶

• Consistency vs. Latency: Strong consistency ensures all reads see the most recent write but can increase latency. Eventual consistency allows lower latency and higher scalability but reads might temporarily see stale data.¶
• Write Amplification (especially for Blockchain): Be mindful of the storage and performance implications.¶
• Operational Cost: Includes hardware, software, and personnel. Blockchain solutions can be particularly expensive to operate.¶
• Complexity: Distributed systems (DHTs, blockchains, some federated models) are generally more complex to design, implement, deploy, and maintain than centralized systems.¶

DECISION MATRIX FOR AGENT REGISTRY IMPLEMENTATION PATTERNS¶

8. Future Considerations

This document lays the foundational groundwork for ANS. Significant future work is envisioned to mature the proposal into a widely adopted standard:¶

• Prototype Implementation and Evaluation: Build and rigorously evaluate a working ANS prototype. The existing work at https://github.com/kenhuangus/dns-for-agents/ serves as an initial base.¶
• Bootstrap Model for Distributed Trust: Explore an innovative bootstrap model for the distributed trust infrastructure, potentially focusing on a foundation-led root governance approach with delegated sub-spaces (analogous to CNCF's certificate transparency roots). This includes developing a sustainable funding and fee schedule.¶
• Performance & Scalability Benchmarking: Conduct thorough benchmarking of resolution latency, registration throughput, and overall scalability under various load conditions and deployment models.¶
• Advanced Cryptography: Investigate the integration of privacy-preserving cryptographic techniques, such as zero-knowledge proofs (ZKPs) for selective capability advertisement/disclosure, or more advanced PIR schemes.¶
• Formal Verification: Mathematically model and formally verify the security properties of the registration, resolution, and identity management protocols within ANS.¶
• Detailed Governance Model: Develop a comprehensive governance model, including detailed policies for naming conventions, CA/RA operational requirements, dispute resolution mechanisms, and the evolution of the trust framework.¶
• Platform and Framework Integration: Demonstrate and facilitate integration with popular agent development frameworks (e.g., LangChain, AutoGen, CrewAI) and major cloud platforms.¶
• Semantic Interoperability Enhancements: Research mechanisms that leverage ANS metadata for deeper cross-protocol communication, such as standardized capability ontologies or translation gateways facilitated by ANS discovery.¶
• Reputation Systems: Investigate the integration of reputation scores, endorsements, or attestations into agent profiles within ANS to further enhance trust in agent interactions.¶
• ANS Capability Negotiation and Binding Protocol: Develop standardized protocols that allow agents, post-ANS resolution, to negotiate specific capabilities, agree on service level objectives (SLOs), and formally bind to service contracts.¶
• Governance White Paper: Draft a detailed white paper outlining name allocation strategies, a sustainable fee model, dispute arbitration processes, and stewardship of the root CA infrastructure.¶

9. Conclusion

The Agent Name Service (ANS) offers a foundational infrastructure designed to foster a more secure, trustworthy, and interconnected ecosystem for agentic AI. By addressing the critical needs of verifiable identity, secure discovery, and protocol-agnostic interoperability, ANS aims to provide significant benefits:¶

• Enhancing Interoperability: A protocol-agnostic directory facilitates seamless discovery and initial contact between diverse agents built on different communication standards.¶
• Boosting Trust and Security: The integration of PKI for identity verification enhances trust, which is crucial for agents operating in sensitive domains such as finance, healthcare, and cybersecurity.¶
• Accelerating Innovation: By providing common infrastructure for discovery and identity, ANS can lower barriers to entry for developers, allowing them to focus on core agent functionalities and solutions.¶
• Facilitating Autonomous Systems: ANS is a critical enabler for complex autonomous systems that require dynamic, secure discovery and interaction between their constituent agents (e.g., in autonomous vehicles, smart cities, and industrial automation).¶
• Powering Secure AI Marketplaces: The framework can serve as a foundation for AI marketplaces where agents with verifiable identities and capabilities can be securely listed, discovered, and engaged.¶

The modular Protocol Adapter Layer ensures that ANS can evolve and extend its support to new and emerging agent communication standards. While challenges related to governance, global scalability, and achieving deep semantic interoperability remain, ANS represents a necessary and significant step towards building a robust, secure, and scalable future for agentic AI.¶

10. IANA Considerations

This document has no IANA actions requested at this time. Future versions may request registration of a URI scheme for ANSNames, new port numbers if a dedicated ANS protocol is defined, or new registries for ANS components if deemed necessary by the community.¶

Appendix A. Appendix A: Complete Request/Response Schemas

The detailed JSON Schema documents for various registry interactions are maintained externally due to their length. Implementers should refer to these sources for complete and up-to-date schema definitions. It is crucial that these schemas are well-commented and validated in any ANS implementation.¶

• AgentRegistrationRequest Schema: https://github.com/kenhuangus/dns-for-agents/blob/main/agent_registration_request_schema.json¶
• AgentRenewalRequest Schema: https://github.com/kenhuangus/dns-for-agents/blob/main/agent_renewal_request_schema.json¶
• AgentRegistrationResponse Schema: https://github.com/kenhuangus/dns-for-agents/blob/main/agent_registration_response_schema.json¶
• AgentRenewalResponse Schema: https://github.com/kenhuangus/dns-for-agents/blob/main/agent_renewal_response_schema.json¶
• AgentCapabilityRequest Schema (for resolution): https://github.com/kenhuangus/dns-for-agents/blob/main/agent_capability_request.schema.json¶
• AgentCapabilityResponse Schema (for resolution): https://github.com/kenhuangus/dns-for-agents/blob/main/agent_capability_response.schema.json¶

Appendix B. Appendix B: Glossary of Terms - Agent Name Service (ANS)

A2A (Agent2Agent Protocol):

A communication protocol developed by Google for standardizing inter-agent communication, designed to bridge different agent frameworks.¶

ACP (Agent Communication Protocol):

A protocol designed by IBM Research to standardize how agents communicate, enabling automation, collaboration, UI integration, and developer tooling.¶

Agent:

An autonomous software entity capable of performing tasks, making decisions, and interacting with other agents or systems.¶

Agent Identity:

The verifiable identity of an agent within the ANS ecosystem, comprising cryptographic identity (PKI certificate), logical identity (ANSName), and protocol-specific identities.¶

Agent Registry:

A database storing registered agent information including capabilities, security policies, PKI certificates, protocol-specific metadata, and registration/renewal timestamps.¶

agentCapability:

A specific function, service, or skill that an agent can perform or provide to other agents or users.¶

ANS (Agent Name Service):

A universal directory service framework that enables secure discovery and interoperability between AI agents across different protocols and platforms.¶

ANSName:

A structured, human-readable, and machine-resolvable identifier for agents in the ANS ecosystem.¶

CA (Certificate Authority):

A trusted entity that issues and manages digital certificates that bind public keys to entities (like agents) to establish a chain of trust in the ANS ecosystem.¶

Certificate Chain Verification:

The process of validating a certificate by checking the chain of trust from the certificate up to a trusted root certificate authority.¶

Certificate Revocation:

The process of invalidating a certificate before its scheduled expiration date, typically due to a key compromise or when an agent is deregistered.¶

CRL (Certificate Revocation List):

A list of digital certificates that have been revoked by the issuing CA before their scheduled expiration date and should no longer be trusted.¶

CSR (Certificate Signing Request):

A message, typically in a standardized format, sent by an applicant (an agent in this context) to a Certificate Authority to apply for a digital identity certificate.¶

Digital Signature:

A mathematical scheme for verifying the authenticity (proof of sender) and integrity (proof data has not been altered) of digital messages or documents.¶

DHT (Distributed Hash Table):

A decentralized distributed system that provides a lookup service similar to a hash table; keys are mapped to values, and the table is distributed among participating nodes.¶

DNS (Domain Name System):

The hierarchical and decentralized naming system used to identify computers, services, and other resources reachable through the Internet or other Internet Protocol networks.¶

DNS-SD (DNS-Based Service Discovery):

An extension to DNS that enables automatic discovery of services available on a local network using standard DNS queries.¶

Endpoint:

A resolvable network address, service binding, or metadata document that allows agents to connect and communicate with each other.¶

Extension (in ANSName):

An optional field in the ANSName structure that holds deployment-specific or provider-defined metadata, not part of the core identity.¶

Interoperability:

The ability of different agent systems, devices, or applications from different vendors to access, exchange, integrate, and cooperatively use data in a coordinated manner.¶

MAESTRO (7 Layers):

A threat modeling framework specifically designed for agentic AI systems, consisting of 7 layers, used to structure the security analysis of ANS.¶

MAS (Multi-Agent Systems):

Systems composed of multiple interacting intelligent agents that can cooperate, coordinate, or compete to solve problems that are beyond the individual capabilities or knowledge of each agent.¶

MCP (Model Context Protocol):

A protocol developed by Anthropic focused on simplifying the integration of AI models with external tools and data sources.¶

OCSP (Online Certificate Status Protocol):

An Internet protocol used for obtaining the revocation status of an X.509 digital certificate as an alternative to CRLs, providing more timely status information.¶

PKI (Public Key Infrastructure):

A set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.¶

Protocol Adapter Layer:

A component in the ANS architecture that translates between the registry's internal, protocol-agnostic representation and protocol-specific formats for metadata and discovery.¶

protocolExtensions (in Schema):

A flexible field within the ANS JSON schemas that acts as a container for protocol-specific data, allowing ANS to support diverse agent types.¶

Provider (in ANSName):

An organization or entity that offers, maintains, or is responsible for agents registered in the ANS ecosystem.¶

RA (Registration Authority):

An entity, authorized by a CA, that verifies agent registration and renewal requests, interacts with the CA to issue certificates, and manages aspects of the agent lifecycle.¶

Registry Poisoning:

A security threat where an adversary successfully injects malicious, false, or misleading data into the Agent Registry to disrupt services or deceive users/agents.¶

Semantic Versioning:

A formal versioning scheme with a format of MAJOR.MINOR.PATCH (e.g., 1.2.3), used to indicate compatibility and changes in agent versions.¶

Service Discovery:

The process of automatically detecting devices and services offered by these devices on a computer network.¶

Signature Verification:

The process of using the signer's public key to check that a digital signature is authentic and that the associated data has not been tampered with since it was signed.¶

Sybil Attack:

A type of attack on a peer-to-peer network in which a malicious actor creates a large number of pseudonymous identities and uses them to gain a disproportionately large influence.¶

Trust Anchor:

A CA certificate that is implicitly trusted and serves as the starting point for validating a certificate chain in a PKI system.¶

Version Negotiation:

The process by which communicating entities (agents in this case) determine which version of a protocol or capability to use, based on compatibility and preferences.¶

VerifyCertChain (Function):

A function or process that checks the validity of a digital certificate by tracing its chain of signatures and revocation statuses back to a trusted root CA (Trust Anchor).¶

VerifySignature (Function):

A function or process that validates a digital signature against a given message and a public key to confirm the message's authenticity and integrity.¶

Acknowledgements

The authors acknowledge the contributions of the communities and organizations developing foundational agent communication standards, including Google (A2A), Anthropic (MCP), IBM (ACP), and the broader AI research community.¶

This document was created as part of the OWASP Gen AI Security Project - Agentic Security Initiative (ASI).¶

Authors' Addresses