]> Ericsson

jaime@iki.fi

Ericsson

jim.feng@ericsson.com

Ericsson

jari.arkko@ericsson.com

Ericsson

mirja.kuehlewind@ericsson.com

Ericsson

rajat.kandoi@ericsson.com

Applications Discovery of Agents, Workloads, and Named entities (DAWN) agent discovery AI agents MCP A2A dawn This document surveys mechanisms for AI agent discovery being developed at the IETF, at AAIF, at 3GPP, and in open-source projects. It compares them by discovery model, scope, dynamism, cross-domain reach, and semantic capability. It identifies gaps, overlaps, and conflicts between the approaches to inform future standardization work. Status information for this document may be found at . Discussion of this document takes place on the Discovery of Agents, Workloads, and Named entities Working Group mailing list (), which is archived at . Subscribe at .

Introduction An AI agent is an LLM-driven system that operates as a loop (see ): it consults a Large Language Model to plan, acts on external tools and services, observes the results, and repeats. Discovery is one of the action types available within this loop. When the agent determines that its current tool set is insufficient for the task, it queries a discovery source and adds the returned references to its working set for subsequent iterations.

| |-----act----->| Target tool, | | or | | AI Agent |<-------------| service, or | | Sys. |<---res---| (loop) | | resource | +------+ | | +----------------+ | action selected: | | - reason (LLM) | +----------------+ | - act |---discover-->| Discovery | | - discover |<-------------| source | | | +----------------+ +--------------------+ ]]>

An agent's ability to find the right tool or another agent, and to learn enough about it to interact, is what this document calls agent discovery. The term covers finding entities (agents, tools, services) and discovering their capabilities. Discovery can occur before a task begins, through static configuration such as reading a local file, resolving a fixed DNS name, or fetching a well-known URI at startup. It can also occur dynamically during a task, when the agent queries a discovery source in response to a need identified at runtime. The same discovery sources can serve both paths; what differs is when and why they are consulted. This document surveys what those discovery sources are, how they compare, and where gaps remain. It does not prescribe which mechanism an agent should select for a given task. Agent discovery mechanisms are already being built. Protocols, well-known URIs, directory services, and DNS extensions have emerged in parallel from different organizations, often addressing overlapping problems with incompatible approaches. No single IETF document yet inventories this work. A Discovery of Agents, Workloads, and Named entities (DAWN) working group is proposed in the IETF to address this space. DAWN's proposed charter targets interoperable discovery across organizational boundaries, with planned deliverables including terminology , a problem statement , requirements , and a gap analysis. This document contributes to that gap analysis by surveying the existing mechanisms, comparing them, and identifying gaps. It does not propose a new discovery mechanism. This document is organized as follows. defines five use cases that motivate the survey. establishes the analytical framework: five functional components that any discovery system must address, and how they compose. surveys existing mechanisms grouped by approach. compares them across multiple dimensions. identifies where standardization gaps remain.

Use Cases The surveyed discovery mechanisms address different scenarios that differ mainly in the assumed trust based on who controls the set of discoverable agents.

Curated set:

A general-purpose AI agent application ships with a bundled set of subagents and tools. The provider selects the initial set. The implementations, or references to them, are part of the application.

Local context:

Agents and tools are deployed in a single administrative context such as a corporate network. A local administrator controls the set. Applications receive static configuration or discover through local mechanisms, for example multicast within a subnet or resolution within a configured domain such as agents.example.com.

Known partner:

An agent contacts a specific collaboration partner whose capabilities and addresses it does not yet know. Discovery targets that partner, typically starting from their domain name. For instance, a travel service agent discovers a hotel chain's booking agent.

Federated consortium:

Multiple organizations establish mutual trust agreements and share agent registrations across their domains. Discovery spans the consortium but not the open Internet. Each organization publishes its own agents; federated peers propagate or proxy discovery queries across domain boundaries. For instance, a supply-chain consortium lets each member's logistics agents discover partner agents in peer domains without exposing them to the public.

Free-form search:

An agent searches across the Internet for agents or tools suitable for a task, without restricting who can provide them. Search engines or curated directories of agent services support this mode. Discovery can also proceed transitively: an agent or tool reached through an initial search may itself reference further agents or tools, and the agent follows those references as it explores. This hypermedia-driven pattern lets the discoverable surface grow during a task rather than being fixed up front.

These scenarios differ along three axes: the trust assumptions between parties, whether a prior contract exists, and the discovery techniques available. Local-network discovery applies in the first two cases; discovery anchored in a partner's domain name applies in the third; federated registries with pre-negotiated trust apply in the fourth; Internet-wide search through a third-party directory, followed by hypermedia-driven traversal, applies in the fifth.

Discovery Framework This section defines the functional components that discovery systems address. The components serve as the analytical framework for the mechanism survey and comparison that follow.

Discovery Components Agent systems address five functional components: lookup, name, description, trust, and interaction. Lookup is the act of finding candidates; the other components handle what happens once candidates are known. The mechanisms surveyed later combine these components in different ways, and the combinations determine which mechanisms can be compared to which.

| Trust | +-------------+ +-------+ | | | declares | v | +-------------+ validates | | Interaction |<-------------+ +-------------+ ]]>

Lookup:

The act of finding a candidate agent or tool. It produces a pointer, typically a name, that the rest of the stack can resolve. A DHT query returning a CID and a DNS-SD browse returning an FQDN are both instances of lookup.

Name:

The stable name or address under which an agent is referenced. FQDNs, DIDs, and content identifiers are all naming schemes. A name anchors trust: a lookup produces one, and a trust mechanism validates it.

Description:

The metadata that tells a caller what an agent is and how to use it. Capabilities, supported protocols, authentication schemes, and endpoints live here. A2A Agent Cards and MCP Server Cards are description formats; JSON-LD agent descriptions and OASF records are richer alternatives.

Trust:

The mechanisms that establish whether a discovered name and description can be relied on. DNSSEC and DANE anchor trust in the DNS hierarchy; DID documents anchor trust in public keys; OAuth, SPIFFE, and mTLS authenticate the session once interaction begins.

Interaction:

The protocols used once trust is established: JSON-RPC, HTTPS, gRPC, SSE. Discovery is only useful if the caller can then talk to the agent, so description formats must declare which interaction protocols are on offer.

Mechanisms differ in how many of these components they bundle. DNS-AID bundles lookup and name. A2A's /.well-known fetch bundles lookup and description. ANP spans all five. These differences explain why the mechanisms surveyed later are not drop-in replacements for each other. Note also that a target resource may itself serve as a discovery source - for example, when an agent fetches another agent's capability description via a well-known URI. The "act" and "discover" roles shown in are conceptually distinct but not necessarily distinct endpoints.

Illustrative Flow: Known Partner To illustrate how the components compose in practice, consider the Known Partner use case. An agent that knows a partner's domain name but nothing else might proceed as follows: resolve the domain (Name), fetch a well-known URI to retrieve an Agent Card or description (Lookup + Description), discover authentication requirements from the card (Trust), and then connect using the declared protocol (Interaction). This sequence is not normative; mechanisms differ in which steps they require, which they skip, and which they collapse. MCP, for instance, goes directly from local configuration to interaction with no resolution or trust step. ANP may perform all five components in a single protocol exchange.

Discovery Mechanisms This section surveys mechanisms drawn from IETF (httpapi drafts, CATALIST contributions, DNS-based proposals), AAIF (A2A Agent Cards, MCP Server Cards), 3GPP (6G architecture studies on agent discovery), and open-source projects (ANP Agent Discovery Service Protocol, AGNTCY Agent Directory Service, the IoA framework, and related efforts). They are grouped by approach: DNS-based resolution, host-level self-description, and registries and directories.

DNS-Based Resolution Maps agent identifiers to network locations. Answers "where does this agent live" using DNS primitives (A/AAAA, SVCB, DNS-SD), with optional agent-specific record types.

DNS-AID uses a structured namespace under _agents subdomains (e.g., _chat._agents.example.com) with SVCB records to publish agent metadata. It requires no new DNS protocol elements and integrates with DNSSEC and DANE for trust. An accompanying problem statement argues that decentralized publication through known entry points is preferable to centralized registries.

DN-ANR proposes a 3-layer model (discovery, resolution, connection) using FQDNs as stable identifiers and SVCB/HTTPS records for endpoint resolution. Its scope is deliberately limited to the resolution layer; discovery and connection are delegated to other mechanisms.

AID takes a minimal approach: a DNS TXT record at _agent.<domain> with semicolon-delimited key-value pairs (version, URI, protocol token, authentication hint, optional Ed25519 public key). It is protocol-agnostic, delegating interaction to A2A, MCP, or other protocols. AID requests IANA registration of the _agent DNS node name.

AgentDNS proposes a root domain naming system for LLM agents with unified namespace, semantic service discovery, protocol-aware interoperability, and unified authentication. This draft has expired. All four proposals agree that DNS handles naming and location; they differ on record type (SVCB vs. TXT), namespace convention (_agents vs. _agent), and how much metadata belongs in DNS versus a fetched document.

Host-Level Self-Description These approaches are based on self-publication at a known location. A host serves its own machine-readable description at a well-known URI; the client dereferences the URL rather than querying a registry.

IETF httpapi: api-catalog (RFC 9727) defines /.well-known/api-catalog as a well-known URI for advertising available APIs on a given host. It was not designed with agents in mind, but the pattern serves the same function as A2A Agent Cards and MCP Server Cards: "here is what this host offers, in machine-readable form." Companion drafts cover link hints and authentication links . The A2A community has adopted this pattern for multi-agent hosts. A2A now allows an api-catalog at /.well-known/api-catalog to advertise several agents under a single origin, each entry linking to that agent's card. This addresses the one-agent-per-host assumption of the base Agent Card discovery model.

A2A Agent Cards The Agent-to-Agent protocol uses Agent Cards as the primary discovery artifact: a JSON document served at /.well-known/agent-card.json describing identity, capabilities, skills, and authentication requirements. Discovery is pull-based and static; you need to know the agent's host to fetch its card.

MCP Server Discovery The Model Context Protocol focuses on agent-to-tool communication via JSON-RPC 2.0 over Streamable HTTP or stdio. Discovery is local configuration: clients are pre-configured with server URLs or launch commands. Once connected, capability negotiation occurs via a JSON-RPC initialize exchange where client and server declare supported features (tools, resources, prompts). MCP defines OAuth discovery endpoints (/.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server) for authentication. The base protocol has no mechanism for discovering available servers; clients learn about servers out of band. A separate MCP Registry addresses this: it is a centralized catalog of publicly available MCP servers, with namespace ownership validated at publication through GitHub, DNS, or HTTP verification. The registry is a hosted service rather than a peer-to-peer or federated protocol, and it indexes only MCP servers.

ANP Agent Descriptions The Agent Network Protocol defines a /.well-known/agent-descriptions endpoint for JSON-LD metadata documents, with agent identity anchored in Decentralized Identifiers (DIDs). ANP also specifies an Agent Discovery Service Protocol (ADSP) for cross-domain indexing; ADSP is covered under Registries and Directories below.

AIDIP: Agent Discovery and Invocation (referred to as AIDIP in the comparison tables below) proposes patterns for agent discovery and invocation with an optional Agent Semantic Resolution (ASR) layer, contributing to the CATALIST discussion space .

Other Community Efforts The .well-known pattern is being independently reinvented outside standards bodies. For example, the Agent Discovery Protocol (ADP) publishes a /.well-known/agent-discovery.json document that bundles service endpoints for identity, memory, governance, reputation, and other agent services into a single JSON file served identically across all subdomains of an operator. ADP is a single-author effort (Walko Systems, April 2025) with one implementation. It illustrates the pull toward self-describing discovery documents but lacks IANA registration, formal specification, or multi-implementer review.

Registries and Directories A discovery and registration layer provides aggregation across hosts. A registry accepts agent metadata and answers capability-centric queries, trading per-host autonomy for cross-domain search.

3GPP Network-Assisted Agent Discovery 3GPP is studying agent registration and discovery as part of the 6G system architecture across multiple working groups. defines service requirements for AI agent communication in 6G, establishing that 6G systems shall support mechanisms for AI agents (on-device, 3rd-party, and network-internal) to register their attributes and enable discovery. A companion IETF draft reframes these requirements for protocol design and notes that existing 3GPP discovery mechanisms (e.g., NRF) may not be sufficient for cross-platform and cross-domain agent discovery. Two parallel paths are emerging within 3GPP: The SA6 application enablement study examines how to extend the exposure framework, including the Common API Framework (CAPIF) , so that 3rd-party AI agents can act as API Invokers. Key Issue 1.3 ("Enabling Exposure to 3rd Party AI Agents") identifies that current CAPIF has no semantic API discovery mechanism aligned to AI agent interaction patterns, and that CAPIF's existing structured API descriptions are not suitable for AI agents that interact through intent-based or less structured requests. The study considers enabling AI agents to discover and consume CAPIF-published services, as well as supporting the publication and discovery of services provided by service producers' AI agents. Because CAPIF operates at the application layer, this path is potentially applicable to any 3rd-party AI agent regardless of where it resides. The SA2 6G system architecture study addresses agent discovery in Key Issue #19 ("6G Network for AI"). It studies whether and how the 6G core network can support an AI agent on a UE discovering another AI agent on a different UE, enable inter-agent communication including identification and authorization, and enhance network capability exposure to AI agents on Application Functions (AFs). The study proposes new 3GPP-specific network functionalities - an AI agent Management Functionality (registration, authentication, authorization) and an AI agent Discovery Functionality. Discovery options under study include signalling via NAS (control plane), via user plane, or via AF-triggered queries, with support for both identity-based lookup and skill-based discovery. The study also considers exposing network capabilities as tools to external AI agents using agentic protocols such as MCP. This path is more UE-agent oriented, with the operator-managed network acting as an active mediator of agent identity, authorization, and discovery. Both paths are in study phase (Rel-20, target completion 2027) and have not yet produced normative specifications.

IoA Framework (Semantic Discovery) The Internet of Agents framework coordinates heterogeneous AI agents using structured protocols. Its discovery mechanism is semantic: agents register capability metadata and others find them via semantic queries rather than URL-based lookups. IoA is an academic framework (OpenBMB), open source.

ANP Agent Discovery Service Protocol (ADSP) ANP's ADSP is the aggregation layer above the per-host /.well-known/agent-descriptions endpoint described in . It operates in two modes. In active discovery, an indexing service queries domains' well-known endpoints to retrieve paginated collections of agent descriptions in JSON-LD format. In passive discovery, agents submit their description URLs to an indexing service, analogous to submitting a sitemap to a search engine. Agent identity in ADSP is anchored in did:wba identifiers resolved via HTTPS-hosted DID documents. ADSP does not define soft-state lifetimes or federation between indexers; each indexer maintains its own crawl scope.

AGNTCY Agent Directory Service (ADS) The Agent Directory Service is a distributed directory that stores and discovers AI agent metadata using a federated network of interconnected servers. ADS combines three building blocks: a libp2p Kad-DHT for content routing and server discovery, the Open Agentic Schema Framework (OASF) for capability-based matching, and OCI Distribution-compliant storage (ORAS/zot) for record retrieval. OASF is a schema system for describing agent capabilities and metadata, created by Cisco/Outshift. It defines a record format whose key fields include skills drawn from a hierarchical taxonomy (15 top-level categories such as NLP, computer vision, security, agent orchestration, and advanced reasoning, with 100+ specific skills underneath), domain classifications, locators (endpoint URLs), author information, and extensible modules for additional metadata. Skills and domains are the routable attributes: when an OASF record is published into ADS, its skill annotations are extracted and announced into the DHT so that capability-based queries can locate relevant servers. Discovery is two-phase: a client queries the DHT with skill taxonomy terms, receiving both matching record identifiers (CIDs) and the addresses of servers hosting them, then fetches the full OASF records from the relevant server's OCI-compliant store. ADS also includes a runtime discovery component that automatically detects labeled containers and pods in Docker and Kubernetes environments. The specification is published as an Internet-Draft. A reference implementation in Go with gRPC/protobuf interfaces is open source, and a production instance is operated by Cisco/Outshift. ADS is the most complete federated directory implementation surveyed: it addresses cross-domain search (via DHT-routed skill queries), federation (via Kad-DHT), and structured capability matching (via OASF taxonomy). Its main limitations are that OASF is not yet adopted by other discovery systems (A2A, MCP, and ANP each define their own metadata formats), and ADS does not natively index A2A Agent Cards or MCP Server Cards.

Agent Registration and Discovery Protocol (ARDP) specifies a lightweight federated protocol for registering and discovering agents. Agents obtain stable identifiers in the form agent:<local-id>@<authority>, register with endpoints, capabilities, and time-to-live values, and are discovered via direct AID resolution or capability-based queries. Registration requires cryptographic proof-of-control via JWS signatures (ES256 mandatory). ARDP supports cross-domain federation through explicit trust relationships. Its scope is deliberately narrow: it excludes interaction protocols, identity governance, and runtime authorization.

Agent Directory (AD) defines the Agent Directory (AD), an HTTP/JSON service that adapts the CoRE Resource Directory from constrained IoT devices to software agents. Agents register their identity, capabilities, and reachable endpoints via POST to /ad/r; clients discover them via GET to /ad/l with filters on agent name, capability name, capability type, protocol, and tags. Registrations are soft state with configurable lifetimes, following the same lifecycle model as . The AD is discoverable at /.well-known/ad, which returns the paths to the registration and lookup interfaces. On local networks, DNS-SD with service name _ad._tcp provides zero-configuration discovery. The lookup interface supports two views: agent view (default) groups results by agent with capability summaries; capability view returns individual capabilities across all matching agents with the owning agent's base URI and protocols inlined. Capability types defined by the AD are tool, skill, resource, and prompt. Registrations carry optional identity and identity_type fields that point to external identity metadata (Agent Identity Profiles, OpenID Connect, WIMSE, or DID documents), letting clients verify agents beyond trusting the directory. The AD requires TLS and mandates OAuth 2.0 bearer tokens or mTLS for registration; errors use RFC 9457 Problem Details. Federation across multiple AD instances is acknowledged but not specified in the initial version. The soft-state model bounds staleness: federated entries carry the original lifetime and expire without explicit deletion if synchronization lapses. A public prototype is deployed at ad.jaime.win (Cloudflare Worker, MIT license).

A2A Registry The A2A Registry (a2aregistry.org) is a curated web directory of A2A-compatible agents. Entries are persistent and include periodic health checks to verify agent availability. The registry is human-browsable but provides no programmatic query API; discovery requires manual search through the web interface. It is A2A-only and does not index agents using other protocols.

Comparison This section compares the surveyed mechanisms along three dimensions: discovery model and scope (), coverage of the five components defined in (), and applicability to the use cases defined in (). It concludes with a summary of the key structural differences that cut across all three tables.

Discovery Model and Scope characterizes each mechanism by its architectural model, the scope of agents it can reach, whether it supports dynamic updates, cross-domain queries, and semantic (capability-based) lookup. Approach Model Scope Dynamic Cross-domain Semantic api-catalog Pull Per-host No No No A2A Agent Cards Pull Per-agent No Yes (known host) No MCP Config Per-tool No No No ANP ADSP Hybrid Internet Yes Yes Partial AGNTCY ADS DHT Cross-domain Yes Yes (DHT) Yes (OASF) 3GPP 6G Registry Network Yes Operator Partial IoA Registry Cross-agent Yes Yes Yes ARDP Registry Federated Yes (TTL) Yes (federation) No Directory (AD) Registry Cross-domain Yes (TTL) Yes (federation) No A2A Registry Curated A2A agents Health check No No DNS-AID DNS Per-domain DNS TTL Per-domain No DN-ANR DNS Per-domain DNS TTL Per-domain No AID DNS Per-domain DNS TTL Per-domain No AgentDNS DNS Cross-domain Unknown Yes Yes AIDIP Hybrid Cross-domain Unknown Unknown Yes (ASR) Key observations from : Pull-based self-description (api-catalog, A2A, MCP) is the most widely deployed pattern but offers neither cross-domain reach nor dynamic updates. DNS-based approaches are decentralized but limited to per-domain scope with no semantic capability. Registry and directory approaches (3GPP 6G, ADS, AD, ARDP) achieve cross-domain reach and dynamic updates but require centralization or federation. Semantic lookup - finding an agent by what it can do - remains rare, with partial support only in ADS (OASF taxonomy), IoA, 3GPP 6G (skill-based discovery), AgentDNS, and AIDIP.

Component Coverage maps each mechanism to the five discovery components. A cell indicates what the mechanism provides for that component; a dash indicates the component is out of scope or delegated elsewhere. Approach Lookup Name Description Trust Interaction api-catalog Well-known URI - API list TLS - A2A Agent Cards Well-known URI - Agent Card Per-card auth - MCP Local config - JSON-RPC caps - JSON-RPC ANP ADSP Crawl/index DID JSON-LD DID HTTP AGNTCY ADS DHT query CID OASF record - - 3GPP 6G Registry query Operator Capabilities Operator PKI Per-API IoA Registry query Platform Capabilities - Structured ARDP Query agent: URI Capabilities JWS proof - Directory (AD) Registry query Scoped Cap. views TLS + ident. - A2A Registry Web browse URL Card link - - DNS-AID DNS query FQDN - DNSSEC/DANE - DN-ANR DNS query FQDN - DNSSEC - AID DNS TXT query FQDN - Ed25519 (opt) - AgentDNS DNS query Domain Semantic - - AIDIP Semantic query - Capabilities - Invocation

Use Case Applicability maps mechanisms to the five use cases. "Yes" means the mechanism is designed for that scenario; "Partial" means it can be applied but with limitations; a dash means it does not address the scenario. Approach Curated set Local context Known partner Federated consortium Free-form search api-catalog Yes Yes Yes Partial Partial A2A Agent Cards - - Yes - - MCP Yes Partial - - - ANP ADSP - - Yes Partial (DID) Yes AGNTCY ADS - - - Yes (DHT) Yes 3GPP 6G - Yes - Partial (operator) - IoA - - - - Yes ARDP - Partial Yes Yes - Directory (AD) Yes Yes Yes Partial Partial A2A Registry - - - - Partial (human) DNS-AID - Yes Yes - - DN-ANR - Yes Yes - - AID - Yes Yes - - AgentDNS - - - - Partial AIDIP - - Partial - Yes (ASR) No single mechanism spans all five use cases; a complete system requires composing mechanisms from different approaches. expands on the gaps visible from this mapping.

Gap Analysis This section identifies gaps that emerge from the comparison in . Each gap represents a problem that no surveyed mechanism fully solves.

No Standard for Semantic Discovery Most mechanisms require prior knowledge of an agent's URL or host (see the Semantic column in ). No standardized way exists to discover agents by capability alone. The Free-form search use case depends on this capability, yet existing solutions (ADS via OASF taxonomy, ANP ADSP via crawling, IoA via semantic queries) are each single-implementer with incompatible metadata formats. No IETF standard addresses capability-based agent search.

No Interoperable Federation The Federated consortium use case has emerging support from ARDP (explicit trust relationships), ADS (DHT peering), and AD (acknowledged but unspecified), as shown in the Cross-domain column of and the Federated consortium column of . Each uses a different trust model, propagation mechanism, and identity scheme. No interoperable standard lets federated directories from different implementations exchange agent registrations.

Network and Application Layer Integration 3GPP is studying two approaches to agent discovery: extending the application-layer exposure framework (CAPIF) for AI agent interactions, and defining new 3GPP-specific network functionalities for UE agent discovery. Neither path has yet defined how agents discovered through these mechanisms relate to agents discoverable via application-layer protocols such as A2A or MCP. No bridging mechanism exists between network-registered agents and A2A Agent Cards or MCP tool schemas. The Local context use case within operator networks may require both network-assisted and application-layer discovery to interoperate.

Metadata Schema Fragmentation Each approach defines its own metadata format: A2A Agent Cards, MCP tool schemas, ANP agent descriptions (JSON-LD), OASF records, 3GPP capability metadata, DNS-AID agent indexes (see the Description column in ). No common schema or mapping exists between them. An agent discovered via one mechanism cannot be described to a client expecting another format without bespoke translation. A unified "AI Card" format merging A2A Agent Cards and MCP Server Cards has been announced under the AAIF umbrella, but no specification has been published.

Trust Bootstrapping DNS lookup is not enough to establish trust. TLS gives a domain certificate, but a domain certificate alone does not establish trust in the agent behind it. Discovery mechanisms generally assume trust is established out of band. maps existing IETF standards to agent auth, but the mapping between WIMSE workload identifiers and MCP server identity, or between SPIFFE trust domains and A2A Agent Card authentication, has not been written down. The Known partner use case requires verifying a partner's identity and capabilities before interaction, but no standard connects the identity returned by DNS-based lookup to the trust required for interaction. Establishing a root of trust - whether via a registry, WIMSE workload identity, or another mechanism - remains an open problem.

No Lifecycle Management Most pull-based mechanisms (api-catalog, A2A Agent Cards, ANP descriptions) serve static metadata with no way to propagate capability changes to previously discovered clients. Soft-state registration with TTLs (as in ) addresses this for directory-based approaches; and both adopt this model. Well-known URI approaches have no equivalent, leaving the Curated set and Known partner use cases without change notification.

Well-Known Namespace Pressure The .well-known URI namespace is under pressure from AI-related registrations. At IETF 125 DISPATCH, the designated expert reported agents.json, ai.txt, and /.well-known/ai were all filed without real specs. Multiple discovery approaches depend on .well-known URIs, making namespace coordination a practical concern.

No Mechanism Spans All Use Cases shows that no single mechanism addresses all five scenarios. A complete discovery system requires composing multiple mechanisms, but no standard defines how they compose or interoperate.

Security Considerations Agent discovery introduces security considerations around metadata integrity, impersonation, and information disclosure. provides a framework for agent authentication and authorization using existing standards. addresses human-anchored agent identity and delegation chains.

IANA Considerations This document has no IANA actions.

This document defines the "api-catalog" well-known URI and link relation. It is intended to facilitate automated discovery and usage of published Application Programming Interfaces (APIs). A request to the api-catalog resource will return a document providing information about, and links to, the Publisher's APIs. 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 specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. This memo specifies "HTTP Link Hints", a mechanism for annotating Web links to HTTP(S) resources with information that otherwise might be discovered by interacting with them. This specification defines a set of relationships that may be used to indicate where a user may authenticate, log out, register a new account or find out who is currently authenticated. Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory This document proposes a standardized protocol for discovery and invocation of AI agents. It defines a common metadata format for describing AI agents (including capabilities, I/O specifications, supported languages, tags, authentication methods, etc.), a capability-based discovery mechanism, and a unified RESTful invocation interface. This revision additionally specifies an optional extension that enables intent-based agent selection prior to discovery and invocation, without changing existing discovery or invocation semantics. The goal is to enable cross-platform interoperability among AI agents by providing a discover-and-match mechanism and a unified invocation entry point. Security considerations, including authentication and trust measures, are also discussed. This specification aims to facilitate the formation of multi-agent systems by making it easy to find the right agent for a task and invoke it in a consistent manner across different vendors and platforms. China Mobile Nokia This document aims to identify IETF-relevant problem space and potential areas and working groups, exploring internal and external coordination for AI Agent protocols by analyzing open source efforts. It may serve as a target for CATALIST BoF discussions. Independent Software agents increasingly act on behalf of people across communication, automation, and decision-making contexts. These agents initiate actions, delegate tasks, and interact with other agents without a consistent model for representing the human who authorized them, the scope of authority they possess, or the provenance of their actions across ecosystems. This document defines an architectural model for human-anchored agent identity. The model introduces a human identity root, explicit delegation semantics, and a provenance structure that enables ecosystems to determine whether an agent is legitimate, whether it is acting within its intended authority, and how its actions relate to a responsible human. This document does not define a protocol or wire format. It provides an architectural foundation that existing systems may bind to in order to support accountable, interoperable, and human-aligned agent ecosystems. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Infoblox, Inc. Infoblox, Inc. Unaffiliated Deutsche Telekom Amazon The document standardizes an approach for publishing AI agents in the Domain Name System (DNS) so that other agents can discover them. Discovery is then initiated based on one of three generic use cases, in increasing computational and latency cost: (1) the requestor knows both the organization and agent (2) the requestor knows the organization that provides a capability, but not the specific agent (3) the requestor knows the required capability, but not the organization or agent. Of these use cases only (1) and (2) are in scope for this document, although (3) can be derived from this specification. DNS for AI Discovery (DNS-AID) is designed so that, once a client has learned an organization's agents, subsequent transactions can utilize the first use case with the benefit of cacheable connectivity information that is learnable as an agentic skill. The mechanism uses Service Binding (SVCB) records for connectivity information and key meta data, a well known entry point using DNS-Based Service Discovery (DNS-SD) labels into an organization's agent index, and optionally DNS Security Extensions (DNSSEC) and DNS-Based Authentication of Named Entities (DANE) TLSA records for trust and security. DNS-AID provides consumers of agent services with a direct connection method for agentic workloads not mediated by a third party. Organizations can use the same approach across public and private networks networks, providing consistency and common operational models, including publishing agents that are hosted in service provider domains. This document introduces no new resource record types, opcodes, or response codes. 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. Open Agent Registry, Inc. Agent Identity and Discovery (AID) is a minimal, DNS-first discovery protocol for locating agent service endpoints. Given a domain name, an AID client queries a DNS TXT record at the well-known subdomain _agent.<domain> and learns the service endpoint URI, protocol token, authentication hint, and optional metadata for that agent. This document defines the AID v1.2 record format, client discovery algorithm, exact-host lookup rules, security requirements, and IANA registrations for the `_agent` DNS node name and the `agent` service name. AID is intentionally small. After discovery, protocol- specific mechanisms such as MCP or A2A handle communication and capability negotiation. China Telecom Research Institute China Telecom Research Institute University of Science and Technology Beijing This document describes AgentDNS, a root domain naming and service discovery system designed for Large Language Model (LLM) agents. Inspired by the traditional Domain Name System (DNS), AgentDNS enables agents to autonomously discover, resolve, and securely invoke third-party agent and tool services across different vendors. AgentDNS introduces a unified namespace, semantic service discovery, protocol-aware interoperability, and unified authentication and billing. The system aims to address interoperability, service discovery, and trust management challenges in large-scale agent collaboration ecosystems. 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. Ericsson 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. Old Dog Consulting China Mobile Deutsche Telekom Infoblox The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines terminology for Discovery of Agents, Workloads, and Named Entities (DAWN). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space. Huawei Technologies Canada Huawei Technologies Canada Old Dog Consulting Interacting entities such as agents, tasks, users, workloads, data, compute, etc., in AI ecosystem/network are proliferating, yet there is no standardised way to discover what entities exist, what attributes such as skills, capabilities, physical characteristics, etc., they posses, what services they offer, or how to reach them across organisational boundaries. Discovery today relies on proprietary directories or manual configuration, creating fragmented ecosystems that prevent cross- domain collaboration. This document describes the problem space that motivates Discovery of Agents, Workloads, and Named Entities (DAWN). It clarifies the scope of work within entity ecosystems, identifies why current approaches are insufficient, and outlines the challenges a standardised discovery mechanism must address. It does not propose a specific solution or protocol. Old Dog Consulting Old Dog Consulting The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents, Workloads, and Named Entities (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution. Infoblox, Inc. Infoblox, Inc. Unaffiliated Deutsche Telekom With the proliferation of AI agents comes a need for mechanisms to support agent-to-agent discovery. This document discusses the scope, requirements and considerations to support discovery processes so that these are not reliant on manually defined configurations and relationships. China Telecom China Telecom China Telecom China Telecom This draft introduces use cases related to AI Agents in 6G networks, primarily referencing the technical report of 3GPP SA1 R20 Study on 6G Use Cases and Service Requirements (TR 22.870). It also elaborates on some of the requirements for introducing AI Agents into 6G networks from the perspective of operators. 3GPP 3GPP 3GPP 3GPP

Acknowledgments The authors thank Heidi-Maria Back, Emil Zhang, Paul Ardeleanu, and Carlos Bravo for input and review.

Detailed Discovery Flow Example This appendix expands the Known Partner illustration from into a step-by-step sequence showing where existing standards apply. Not all mechanisms require all steps; this represents one possible composition.

Step 1 (resolve entry point):

Standard DNS resolution applies if the agent knows a domain name. SVCB records can provide service parameters. DNS-AID , DN-ANR , and AID propose agent-specific DNS extensions. If the agent has only a capability description, it must query a directory or registry such as ARDP .

Step 2 (fetch host metadata):

Multiple competing well-known URIs exist: api-catalog , agent-card.json (A2A), agent-descriptions (ANP). There is no single standard entry point.

Step 3 (fetch agent metadata):

Each protocol defines its own metadata format. A2A uses Agent Cards, MCP uses JSON-RPC capability negotiation, ANP uses JSON-LD agent descriptions.

Step 4 (discover auth requirements):

maps 3 OAuth discovery mechanisms to agent auth: AS metadata , Protected Resource Metadata , and Client ID Metadata Documents.

Step 5 (authenticate):

The AIMS stack from applies: identifier, credentials, attestation, provisioning, authentication, authorization.

Steps 6-7 (transport and interaction):

Protocol-specific. A2A uses JSON-RPC over HTTPS, MCP uses JSON-RPC over Streamable HTTP or stdio, ANP uses HTTP.