]> Ericsson

jaime@iki.fi

Applications This document defines the Agent Directory (AD), a service where agents register their identity, capabilities, and reachable endpoints and where clients discover them by capability. The AD adapts the Constrained RESTful Environments (CoRE) Resource Directory (RFC 9176) from constrained IoT devices to software agents, reusing its registration, lookup, and soft-state lifecycle model. The AD uses HTTP and JSON. MCP and A2A define how agents interact; this document defines how they are found. Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The CoRE Resource Directory defines a service for discovering resources hosted by other web servers, particularly in networks where direct discovery is impractical. Endpoints register links describing their resources, and clients look them up later. Registrations are soft state with a configurable lifetime. The RD provides both resource-level and endpoint-level lookup. A similar discovery problem arises for software agents. LLM-based assistants, tool-calling agents, and multi-agent systems are deployed without fixed addresses and speak different interaction protocols (MCP , A2A , gRPC). Direct enumeration of candidate endpoints does not scale beyond a single administrative domain. Individual agents may publish their own metadata at well-known endpoints (such as the A2A Agent Card at /.well-known/agent-card.json). However, per-agent metadata requires knowing the agent's URL before you can discover what it offers. The AD aggregates per-agent metadata into a queryable service. Clients discover agents by capability without prior knowledge of their addresses. Like the CoRE RD, the AD has a small footprint: it can run as a cloud service, as a sidecar alongside an agent orchestrator, on an edge gateway, or on a constrained device. Deployment profiles range from cloud services to constrained devices colocated with sensors and actuators. The lookup interface is a small set of HTTP GET requests with a fixed set of query parameters. Clients include both conventional applications, which use structured filters, and LLM-based clients, which can additionally match on the natural-language descriptions and tags carried in registrations. The interface is small enough to be described as a tool in an MCP server or function-calling schema. This document specifies the Agent Directory (AD). The core mapping to CoRE RD concepts is: CoRE RD Concept AD Equivalent Endpoint (EP) Agent Resource link Capability / tool description Registration resource Agent registration resource Endpoint lookup Lookup, agent view (view=agent) Resource lookup Lookup, capability view (view=cap) Lifetime (lt) Registration lifetime Agents register with the AD by sending a POST request with a JSON document describing their capabilities. Registrations are soft state and expire unless refreshed.

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 () () when, and only when, they appear in all capitals, as shown here. This specification makes use of the following terminology:

Agent:

An autonomous or semi-autonomous software entity that can initiate and receive interactions, expose capabilities (tools, skills, APIs), and optionally collaborate with other agents.

Agent Directory (AD):

An HTTP service that stores agent registrations and provides discovery and lookup interfaces.

Capability:

A discrete function, tool, or skill that an agent exposes. Capabilities are described as entries within an agent's registration.

Registration:

The act of an agent (or a commissioning tool acting on its behalf) submitting its identity, capabilities, and endpoint information to the AD.

Registration Resource:

The resource stored at the AD as a result of a successful registration. Identified by the URI returned in the Location header of the creation response.

Interaction Protocol:

The application-level protocol through which an agent can be reached for task execution, such as MCP , A2A , or gRPC. HTTP is the underlying transport for most interaction protocols but is not itself an interaction protocol in this context.

Architecture shows the AD architecture.

Agents register their capabilities and endpoints with the AD. Clients (which may themselves be agents) query the AD's lookup interface to discover agents matching desired criteria. A Commissioning Tool (CT) may register agents on their behalf, for example when a platform operator manages a fleet of agents. How a CT proves authority to act on behalf of an agent is deployment-specific and out of scope for this document.

Principles The AD operates on the following principles: The AD stores information that could otherwise only be obtained by directly querying each agent's metadata endpoint. Registrations are soft state. The registering agent (or its CT) MUST periodically refresh each registration before its lifetime expires. The AD MUST NOT permit modification of a registration by any entity other than the original registrant or an authorized CT. The AD does not proxy agent interactions; it only provides discovery.

Content Model An AD contains zero or more agent registrations. Each registration has: An agent name ("agent", a Unicode string) unique within the AD instance. A registration base URI ("base") , typically the agent's reachable address. A lifetime ("lt") in seconds. A registration resource location within the AD ("href"). Optionally, a version string ("version"). Optionally, a vendor string ("vendor"). Zero or more capabilities, each described as a JSON object with at minimum a name and a type.

Federation In deployments that span multiple administrative domains or geographic regions, multiple AD instances may operate independently. Federation allows these instances to share registration information so that a client querying one AD can discover agents registered at another. This document does not specify a federation protocol. Possible approaches include periodic synchronization between peered AD instances, a publish/subscribe notification mechanism, and a hierarchical model where a root AD aggregates entries from subordinate instances. The soft-state model bounds staleness: federated entries carry the original lifetime and expire without explicit deletion if synchronization lapses.

AD Discovery

Well-Known URI An AD MUST be discoverable at the well-known URI:

A GET request to this URI returns a JSON document describing the AD's interfaces. The response object contains the following fields:

registration:

(string, REQUIRED) Path to the registration endpoint.

lookup:

(string, REQUIRED) Path to the lookup endpoint.

max_count:

(integer, REQUIRED) Maximum value the AD accepts for the count pagination parameter.

Example:

DNS-SD An AD MAY advertise itself on a local network via DNS-SD using the service name _ad._tcp. This provides zero-configuration discovery of a local AD, which is useful on networks where agents are colocated with sensors and actuators. Several DNS-based mechanisms have been proposed in the DAWN working group for wide-area agent discovery. DNS-AID publishes agent metadata under _agents subdomains using SVCB records. DN-ANR defines a resolution layer using FQDNs and SVCB/HTTPS records. These mechanisms handle naming and resolution: mapping an agent name to a network location. The AD handles the layer above: finding agents by capability without prior knowledge of their names. DNS resolves the AD's hostname; the AD carries the capability metadata that DNS cannot efficiently carry.

Registration

Registration Request An agent registers by sending a POST request to the AD's registration endpoint. All HTTP interactions with the AD follow the semantics defined in . The request body is a JSON object containing the agent's metadata and capabilities.

The query parameters are:

agent:

REQUIRED. Agent name. MUST be unique within the AD instance. SHOULD be short and meaningful; the AD MAY enforce a maximum length.

lt:

Lifetime in seconds (OPTIONAL). Default: 86400 (24 hours). Range: 60 to 4294967295 (2^32-1, matching ). The AD SHOULD enforce a maximum lifetime; a recommended default maximum is 604800 seconds (7 days).

The body JSON object contains:

base:

(string, REQUIRED) The agent's reachable base URI .

description:

(string, OPTIONAL) A short human-readable description of what the agent does. SHOULD be one or two sentences. Returned in lookup responses to help clients evaluate agents without additional round-trips.

protocols:

(array of strings, OPTIONAL) Interaction protocols supported. The following values are defined by this document: "mcp" (Model Context Protocol), "a2a" (Agent-to-Agent Protocol), "grpc" (gRPC). Implementations SHOULD use lowercase short names and MAY append a version (e.g., "mcp/1.0"). A future version of this document may define an IANA registry for protocol identifiers.

capabilities:

(array of objects, OPTIONAL) The agent's capabilities. Each object MUST have "name" (string) and "type" (string) fields. The "type" field indicates the kind of capability (see ). Additional fields such as "description" (string), "tags" (array of strings), "input_schema" (object), and "output_schema" (object) are OPTIONAL. When present, input_schema and output_schema SHOULD be JSON Schema objects. Capability names MUST be unique within a registration.

version:

(string, OPTIONAL) The agent's version identifier.

vendor:

(string, OPTIONAL) The organization or individual that provides the agent.

identity:

(string, OPTIONAL) A URI pointing to the agent's identity metadata document. This document describes the agent's verified identity, trust posture, owner binding, or credentials in a structured format. The AD stores and returns this URI without interpreting its contents.

identity_type:

(string, OPTIONAL) The schema or format of the identity document referenced by identity. Values include "aip" (Agent Identity Profile), "oidc" (OpenID Connect Discovery), "wimse" (WIMSE workload identity), and "did" (Decentralized Identifier Document). Clients that recognize the type can dereference and validate the identity document; clients that do not recognize the type SHOULD ignore both fields.

When present, the identity field lets a client verify an agent beyond trusting the AD. For example, a client discovering a financial-analysis agent can fetch its AIP document to check owner binding, attestation state, and credential lifetime before invoking the agent. The AD stores the URI and does not interpret it; trust decisions remain the client's. Clients MUST NOT treat the presence of an identity field as proof of identity without verifying the referenced document.

Capability Types The "type" field in a capability object indicates the kind of function the agent exposes. The following initial values are defined:

tool:

A discrete, stateless function that accepts structured input and returns structured output.

skill:

A higher-level, potentially multi-step behavior that may involve internal reasoning, planning, or coordination. Unlike a tool, a skill may maintain conversational state.

resource:

A data source or content provider that the agent can expose for reading.

prompt:

A reusable prompt template that the agent can execute with supplied parameters.

This list is extensible. Implementations MAY use additional type values. The remaining types mirror those defined by MCP .

Registration Semantics Registration is idempotent on the agent name; a POST with the same agent name acts as an upsert. This follows the RFC 9176 pattern of POST-to-collection for registration rather than PUT to a canonical agent URL. The AD stores the agent value from the query parameter as part of the registration resource and includes it in all response representations. If no registration exists for the agent name, a new registration resource is created. The AD returns 201 (Created) with a Location header pointing to the registration resource. If a registration already exists for the agent name and the request comes from the same authenticated entity, the registration is replaced with the new content. The AD returns 200 (OK) with the Location header of the existing registration resource. If a registration already exists for the agent name but is owned by a different authenticated entity, the AD returns 409 (Conflict). The response body for both 201 and 200 is empty. Clients that need the full representation SHOULD send a GET request to the URI in the Location header. The AD MAY grant a lifetime shorter than requested; the granted lifetime MUST be indicated in the response via a lt field in a JSON body or via the Location header's associated resource.

Reading a Registration An agent or client retrieves a single registration by sending a GET request to the registration resource.

The response includes the full registration content, including capability details (description, schemas) that are omitted from lookup results with view=agent. If the registration resource does not exist, the AD MUST return 404 (Not Found).

Registration Update An agent refreshes or updates its registration by sending a POST request to its registration resource (the URI returned in the Location header at creation time).

An empty POST resets the lifetime. The agent MAY include query parameters (lt) to update those values, or a JSON body to replace the capabilities. If the registration has already expired, the AD MUST return 404 (Not Found); the agent must re-register via the registration endpoint. An agent may update the lifetime via the lt query parameter:

If the registration has already expired, the update fails:

Registration Removal An agent removes its registration by sending a DELETE request to its registration resource.

The AD MUST automatically remove a registration when its lifetime elapses without a refresh.

Lookup The AD provides a single unified lookup endpoint. The view query parameter controls how results are grouped: view=agent (default): returns a list of registered agents matching the query, with capability summaries. view=cap: returns a list of individual capabilities across all matching agents.

Agent View

Agent view returns capability summary objects (name and type only). Full capability details (description, schemas) are omitted to keep lookup responses compact. Clients that need the full registration SHOULD retrieve the individual registration resource (GET /ad/r/{id}). This two-step pattern mirrors the RD's separation between endpoint lookup and resource lookup.

Capability View Capability view returns individual capabilities with their owning agent's information. Clients use this view to find specific tools or skills across all registered agents.

Each capability object in the response includes: "name", "type", "description" (if registered), the owning agent's "agent", "base", "protocols", and "href" (the registration resource URI). Clients can use "href" to retrieve the full registration.

Query Parameters All query parameters are OPTIONAL and act as filters. When multiple filter parameters are present, the AD MUST AND them: only entries matching all specified filters are returned. A request with no filter parameters returns all registrations visible to the requesting client.

agent:

Filter by agent name. A trailing asterisk (*) matches any suffix (e.g., agent=sum* matches "summarizer" and "summary-bot"). Without an asterisk, the value MUST match exactly. Wildcard matching is only supported for the agent and cap_name parameters.

protocol:

Filter by supported interaction protocol. Exact match.

cap_name:

Filter by capability name. Trailing asterisk (*) for prefix match; exact match otherwise.

cap_type:

Filter by capability type (e.g., "tool", "skill"). Exact match.

tag:

Filter by capability tag. Returns agents (or capabilities) that have at least one capability carrying the specified tag. Exact match. In agent view, the full agent with all its capabilities is returned if any capability matches.

view:

Result grouping. "agent" (default) groups results by agent; "cap" groups results by individual capability. If omitted, the AD MUST use "agent".

page:

Page number (zero-based) for pagination. Default: 0.

count:

Maximum number of results per page. Default: 100. The AD MAY enforce a lower maximum and MUST document its limit in the well-known response.

Error Responses When the AD cannot fulfill a request, it MUST return an appropriate HTTP status code and SHOULD include a problem details object as defined in . The type URIs shown below are illustrative; this document does not register them.

The following error conditions are defined:

400 Bad Request:

The request body is malformed or missing required fields.

401 Unauthorized:

The request lacks valid authentication credentials.

403 Forbidden:

The authenticated entity is not authorized for the requested operation.

404 Not Found:

The referenced registration resource does not exist.

409 Conflict:

The agent name is already registered by a different entity.

429 Too Many Requests:

The client has exceeded the rate limit.

Security Policies The security model is derived from and adapted for agents. Policies for capability attestation and cross-domain trust are out of scope for this document.

Agent Name and Registration Ownership The AD MUST ensure that a registering agent is authorized to use the given agent name. The default policy is "First Come First Remembered" as described in : accept registrations for any agent name not currently active, and only accept updates from the same authenticated entity. Whether the AD should return 409 (Conflict) or 403 (Forbidden) when a different entity tries to claim an existing name is an open design question; this document uses 409 to signal a naming conflict rather than an authorization failure.

Capability Confidentiality The AD MUST enforce access control on lookup results when the operator policy designates some registrations as restricted. Not every client is entitled to see every registration.

Capability Vetting The AD SHOULD restrict which capability types and names an agent may claim, based on operator policy. For example, registration of an agent as a "financial-analysis" tool can be limited to agents presenting the corresponding credentials. The policy mechanism is deployment-specific and out of scope for this document.

Security Considerations

Transport Security All communication with the AD MUST be protected using TLS.

Authentication Agents MUST authenticate when registering. The AD MUST support OAuth 2.0 bearer tokens or mutual TLS (mTLS). API keys are acceptable for development but do not satisfy the authentication requirement for production use. Registration requires a verified agent identity: the AD must know who is registering before it can enforce ownership of the registration resource. Bearer tokens prove authorization but not workload identity. For production deployments, the AD SHOULD accept workload identity credentials as defined by the WIMSE working group . The WIMSE architecture treats agents as workloads and defines a wimse: URI scheme that can serve as the agent's authenticated identity at registration time. This provides a cryptographically verifiable binding between the registrant and the registration. If an agent's credentials are compromised, the attacker can modify the registration (including the base URI) until the credentials are revoked. Deployments SHOULD keep credential lifetimes comparable to registration lifetimes, and SHOULD log registration changes for audit.

Authorization The AD MUST enforce that only the original registrant (or an authorized CT) can modify or delete a registration. The AD SHOULD implement rate limiting on both registration and lookup endpoints, and MUST enforce limits on registration size and number of capabilities per agent.

Privacy Agent metadata can reveal organizational structure: a lookup response listing all agents discloses which capabilities an organization has deployed. The AD SHOULD return only those registrations that the requester is authorized to see. The interaction between scoped responses and federation is out of scope for this document.

Adversarial Metadata Capability descriptions and tags are free-form text that LLM-based clients may use as input to their decisions. A malicious registrant can craft descriptions that bias those decisions toward invoking the wrong agent. A malicious registrant can also set base to a victim's endpoint, redirecting traffic intended for the registered agent. Clients SHOULD treat registration metadata as untrusted input. Clients MAY verify a registration by fetching the agent's own metadata at base and comparing it with the AD response before invocation.

IANA Considerations

Well-Known URI Registration This document requests registration of the following well-known URI :

URI suffix:

ad

Change controller:

IETF

Specification document:

[RFC-XXXX]

Media Type This document uses application/json for all request and response bodies and application/problem+json for error responses.

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. Independent This document specifies the Agent Registration and Discovery Protocol (ARDP), a lightweight protocol for registering, discovering, and reaching autonomous software agents in distributed and federated environments. ARDP provides stable agent identities, dynamic endpoint resolution, capability advertisement (including protocol selection among MCP, A2A, HTTP, and gRPC), minimal presence signaling, and a security-first discovery control plane. ARDP is transport-agnostic and complementary to existing agent interaction protocols. Cisco Cisco The Agent Directory Service (ADS) is a distributed directory service designed to store metadata for AI agent applications. This metadata, stored as directory records, enables the discovery of agent applications with specific skills for solving various problems. The implementation features distributed directories that interconnect through a content-routing protocol. DistributedApps.ai Amazon Web Services Intuit Cisco Systems The proliferation of AI agents requires robust mechanisms for secure discovery. This document introduces the Agent Name Service (ANS), a novel architecture based on DNS addressing the lack of a public agent discovery framework. ANS provides a protocol-agnostic registry mechanism that leverages Public Key Infrastructure (PKI) certificates for verifiable agent identity and trust. The architecture features several key innovations: a formalized agent registration and renewal mechanism for lifecycle management; DNS-inspired naming conventions with capability-aware resolution; a modular Protocol Adapter Layer supporting diverse communication standards (A2A, MCP, ACP, etc.); and precisely defined algorithms for secure resolution. This specification describes structured communication using JSON Schema and includes a comprehensive threat analysis. The result is a foundational agent directory service protocol addressing the core challenges of secure discovery and interaction in multi-agent systems, paving the way for future interoperable, trustworthy, and scalable agent ecosystems. Nomotic, Inc. AI agents and agentic systems generate a growing volume of intent- driven, unstructured, and undifferentiated traffic that flows through HTTP indistinguishably from human-initiated requests. HTTP lacks the semantic vocabulary, observability primitives, and identity mechanisms required by agent systems operating at scale. Existing protocols described as Agent Group Messaging Protocols (AGMP), including MCP, ACP, A2A, and ANP, are messaging-layer constructs that presuppose HTTP as their transport. They do not address the underlying transport problem. This document defines the Agent Transfer Protocol (AGTP): a dedicated application-layer protocol for AI agent traffic. Version 05 restores the canonical Agent-ID as the primary identity primitive and decouples Trust Tier 1 verification from DNS as a sole requirement. A canonical Agent-ID is derived from the agent's Birth Certificate hash and is authoritative in every AGTP protocol operation. Three equivalent verification paths are recognized for Trust Tier 1: DNS- anchored verification via RFC 8555 ACME challenge, log-anchored verification via Birth Certificate inclusion in an append-only transparency log aligned with RFC 9162 and RFC 9943 (SCITT), and hybrid verification combining DNS control with blockchain address ownership. The .agent and .nomo hierarchical namespaces are reinstated as agent-native resolution aliases with deterministic disambiguation rules governing coexistence with Web3 naming systems. Version 04 introduced normative integration hooks for the AGTP Merchant Identity and Agentic Commerce Binding specification [AGTP-MERCHANT], which defines the merchant-side identity model that complements AGTP's agent-side identity model. Version 04 added four merchant-related request headers (Merchant-ID, Merchant-Manifest- Fingerprint, Intent-Assertion, Cart- Digest), the 455 Counterparty Unverified status code, and the merchant and intent Authority-Scope domains. Together these elements close the verification loop between the initiating agent and the receiving merchant on AGTP PURCHASE invocations. Version 03 introduced normative integration with the Agentic Grammar and Interface Specification (AGIS) [AGIS], which defines the grammar-based validation pathway for AGTP method identifiers. AGIS-conformant methods are accepted at the transport layer via the Method-Grammar header without requiring prior IANA registration, enabling organizations to define domain-specific Agentive API vocabularies while preserving interoperability through shared grammatical constraints. AGTP provides agent-native intent methods (QUERY, SUMMARIZE, BOOK, SCHEDULE, LEARN, DELEGATE, COLLABORATE, CONFIRM, ESCALATE, NOTIFY, DESCRIBE, SUSPEND), protocol- level agent identity and authority headers, and a status code vocabulary designed for the conditions AI agent systems encounter. AGTP SHOULD prefer QUIC for new implementations and MUST support TCP/ TLS for compatibility and fallback. It is designed to be composable with existing agent frameworks, not to replace them. Version 02 introduces capability discovery (DESCRIBE), resource budget signaling and enforcement, optional RATS-aligned execution attestation, observability hooks, network zone isolation, session suspension as a method, and normative composition profiles with AGMP (Agent Group Messaging Protocols). Version 02 enables dynamic capability negotiation and resource-aware governance. ANP Open Source Community China Mobile China Telecom China Unicom Huawei This document defines the framework of AI agent networks based on Agent Network Protocol (ANP) protocol. [ANP] It provides the basic functions that needs to support AI agent communication in the AI agent networks within the trust domain. Tsinghua University This document specifies DNS-Native Agent Naming and Resolution (DN- ANR) for AI agents. DN-ANR has three goals: (1) use domain names (FQDNs) as stable Agent Identifiers, (2) resolve Agent Identifiers to verifiable endpoints and supported protocol/version information with a cryptographic integrity chain (DNSSEC preferred), and (3) provide only minimal and stable pointer/index capabilities that can be referenced by upper-layer discovery systems. DN-ANR intentionally does not carry heavy semantic metadata in DNS, and does not define semantic discovery, ranking, or routing decisions. Infoblox, Inc. Infoblox, Inc. Unaffiliated Deutsche Telekom This document specifies a method for utilizing the Domain Name System (DNS) to facilitate scalable and interoperable discovery between AI agents. The proposed mechanism, referred to as "DNS AI agent Discovery (DNS-AID)", defines a structured DNS namespace and record usage model to support metadata exchange and capability advertisement. This will allow organisations to publish information about their AI agents on the Internet or internal networks using a well-known label within the organisation's own DNS namespace. This document does not define how the published agent information is accessed or the exact structure of that information. Instead, it specifies a mechanism for indicating which access protocol should be used and what format the agent information will be provided in. This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. CyberArk Zscaler University of Applied Sciences Bonn-Rhein-Sieg The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Zscaler CyberArk This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in digital credentials, including X.509 certificates and security tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Relationship to Other Work

CoRE Resource Directory (RFC 9176) The AD is a direct adaptation of the CoRE RD. The registration, update, removal, and lookup interfaces follow the same patterns. The differences reflect the shift from CoAP and CoRE Link Format to HTTP and JSON: structured capability objects replace flat link attributes, and interaction protocol is advertised as a first-class field.

Per-Agent Metadata Endpoints A2A serves an Agent Card at /.well-known/agent-card.json; MCP exchanges server metadata during initialization. Both describe a single agent and both require the client to already know the agent's URL. The AD complements these by aggregating metadata from many agents into a queryable registry. Clients perform capability-based search without prior knowledge of agent addresses. Once the AD returns a matching agent's base URI, the client MAY fetch the agent's own metadata endpoint for protocol-specific details before initiating interaction.

MCP Registry The Model Context Protocol project maintains a public registry where MCP servers are catalogued for discovery by MCP-compatible clients. The registry and the AD address overlapping concerns from different ends: the MCP Registry is scoped to MCP servers and curated by a single project; the AD is protocol-agnostic (MCP, A2A, gRPC, and others are all describable) and is specified here as an open interface that any operator can implement. An agent registered in the MCP Registry can also appear in an AD instance without conflict; the two are complementary rather than substitutable.

Agent Transfer Protocol (AGTP) proposes an agent-native transport protocol over TCP/TLS or QUIC, with agent identity, session semantics, and authorization expressed at the wire level rather than layered on HTTP. The AD takes the opposite approach, reusing HTTP and JSON as a substrate. The two are not mutually exclusive: an AD instance could register agents reachable over AGTP in the same way it registers agents reachable over MCP, A2A, or gRPC, by carrying the relevant protocol identifier in the protocols field.

Agent Directory Service (ADS) specifies a system with goals similar to the AD. ADS takes a fully decentralized approach: content-addressed identifiers (CIDs) for records, a libp2p Kad-DHT for routing, OCI-compliant storage (ORAS/zot) for retrieval, and gRPC for the client interface. It defines OASF, a hierarchical skill taxonomy with 15 top-level categories and 100+ specific skills, used for capability-based routing through the DHT. This provides federation and cryptographic integrity at the cost of requiring DHT peers, OCI registries, and gRPC infrastructure. The AD makes the opposite trade-off: a single HTTP/JSON service with no additional infrastructure. Federation is not built in (see ) and there is no content-addressed integrity model. ADS targets decentralized deployments where no single operator is trusted; the AD targets deployments where a managed directory is acceptable. Interoperability between the two (an AD instance indexing ADS records, or vice versa) is not specified in this document.

Agent Registration and Discovery Protocol (ARDP) defines a similar registration and discovery service with a custom agent: identifier scheme. The AD differs by reusing standard HTTP URIs for agent identity and by grounding the design in the RD model.

DNS-Based Agent Discovery (ANS) proposes DNS-based agent discovery with PKI certificates. The AD operates at the application layer and does not require DNS infrastructure changes. DN-ANR defines a thin DNS resolution layer using FQDNs and SVCB records, explicitly leaving capability-based discovery to an upper layer. The AD can serve as that upper layer. DNS-AID places agent metadata in DNS zones for intra-organization discovery; the AD provides cross-organization lookup. The two approaches are complementary.

Platform-Specific and On-Chain Registries General-purpose service registries (Consul, etcd, Kubernetes service discovery) solve service location but do not model agent capabilities, interaction protocols, or soft-state registration semantics. The AD addresses the agent-specific aspects that these systems lack. Azure API Center provides a centralized agent registry within the Azure ecosystem. The agentregistry project offers a SaaS registry with a CLI. ERC-8004 defines on-chain agent registries on Ethereum. These systems are each tied to a single provider: a cloud vendor, a SaaS operator, or a blockchain. The AD is specified by this document and can be operated by anyone; clients authenticate to the instance they use.

Agent Network Protocol (ANP) ANP's Agent Discovery Protocol defines active discovery via /.well-known/agent-descriptions and passive discovery where agents register with a search service. The AD's registration model corresponds to ANP's passive mode but specifies the registration API concretely. ANP uses JSON-LD and DIDs; the AD uses plain JSON and HTTP URIs. The broader ANP framework is described in .

Agent Identity Profiles The AD's identity and identity_type fields provide an extension point for linking registrations to external identity metadata. The Agent Identity Profile (AIP) is one such format, defining a JSON document that describes an agent's owner binding, capabilities, attestation state, trust posture, and credential lifecycle. Other formats include OpenID Connect Discovery documents and WIMSE workload identity endpoints. The AD does not mandate any particular identity schema; it provides the pointer so that clients can verify agents through whatever trust framework their deployment requires.

Examples

Discovery Flow Discovering an agent through the AD involves four steps: locating the directory, discovering its interfaces, querying for a matching capability, and contacting the agent directly.

| | | <--- lookup interface URL | | | | | | 3. GET /ad/l? | | | cap_name=summarize | | | &view=cap -------------->| | | <--- matching agents + base | | | | | | 4. Interact with agent using protocol from lookup -----> | | <--- Response ------------------------------------------ | ]]>

The steps in detail: Step 1: Obtain the AD URL. The client already knows the URL of an Agent Directory. This may have been learned through a DNS-SD browse for _ad._tcp, a .well-known/ad query to a known host, or simply through static configuration.

Step 2: Discover the AD's lookup interface. The client queries the well-known endpoint to learn the available interfaces.

In some deployments the lookup interface path is already known or follows a convention, in which case this step can be skipped. Step 3: Search for an agent with the desired capability. The client queries the lookup interface with view=cap.

The response includes the agent's base URI and supported protocols, giving the client enough information to contact the agent directly. Step 4: Interact with the agent. The lookup response indicated that summarizer-v2 is reachable over A2A. The client fetches the agent's A2A Agent Card to obtain the full task interface before invocation.

The subsequent task invocation is defined by the interaction protocol (A2A in this case, MCP or gRPC in others) and is out of scope for this document.

Enterprise Agent Portfolio A Publisher at example.com operates three agents behind a single AD. Step 1: Agents register with the AD.

Step 2: A client queries for MCP agents.

Filtered Lookup with Pagination A client enumerates MCP tool capabilities in pages of two.

Registration Conflict A second entity attempts to register an agent under an already-claimed name.

Content-Type: application/json { "base": "https://attacker.example.org/ticket-classifier", "protocols": ["mcp"], "capabilities": [{"name": "classify_ticket", "type": "tool"}] } HTTP/1.1 409 Conflict Content-Type: application/problem+json { "type": "https://ad.example.com/errors/agent-name-taken", "title": "Agent name already registered", "detail": "Agent name 'ticket-classifier' already registered.", "status": 409 } ]]>

Tooling and Integration The AD uses application/json for all request and response bodies (and application/problem+json for errors). No custom media types or content negotiation is required. The HTTP/JSON interface is usable from command-line tools (curl and a JSON parser), shell scripts, and CI/CD pipelines without specialized client libraries. The lookup interface can also be exposed as an MCP tool, so that an MCP-compatible client performs agent discovery through its existing tool-calling mechanism.

Implementation Status (Boilerplate as per :) This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

ad.jaime.win

Organization:

Ericsson

Implementation:

https://ad.jaime.win

Description:

A public AD instance deployed as a Cloudflare Worker with a Durable Object for persistent storage. Implements the registration, lookup, and soft-state lifecycle interfaces defined in this document. Source code is available at the GitHub repository linked from the deployment.

Level of Maturity:

Prototype

Coverage:

All features specified in this document: well-known URI discovery, agent registration (create, update, replace, delete), agent lookup with filtering and pagination, capability lookup with filtering and pagination, soft-state expiry, and RFC 9457 error responses.

Version Compatibility:

draft-jimenez-agent-directory-00

Licensing:

MIT

Contact:

Jaime Jimenez (jaime@iki.fi)

Acknowledgments The AD design is directly based on the CoRE Resource Directory by Christian Amsüss, Zach Shelby, Michael Koster, Carsten Bormann, and Peter van der Stok.

Mapping from CoRE RD to AD The following table summarizes the conceptual mapping between CoRE RD concepts and their AD equivalents. CoRE RD (RFC 9176) AD Notes Endpoint (EP) Agent Software entity that registers Resource link Capability Structured JSON instead of link-format /.well-known/core /.well-known/ad Discovery entry point Registration (POST /rd) Registration (POST /ad/r) Same soft-state model Registration resource Registration resource Same lifecycle Lifetime (lt) Lifetime (lt) Same semantics, different default Endpoint name (ep) Agent name (agent) Same uniqueness constraint Resource lookup Lookup view=cap (GET /ad/l?view=cap) Structured query instead of link-format filter Endpoint lookup Lookup view=agent (GET /ad/l) Same pattern, unified endpoint Commissioning Tool (CT) Commissioning Tool (CT) Third-party registration application/link-format application/json Representation format