]> Google

jbu@google.com

guha@guha.com

Ericsson

jari.arkko@ericsson.com

Ericsson

jaime.jimenez@ericsson.com

Internet agent discovery autonomous agents artificial intelligence model context protocol agent-to-agent federated search tool registry DAWN This document describes the high-level architecture for Agent Resource Discovery (ARD), an open, federated framework for publishing, indexing, discovering, and invoking software agent capabilities (such as Model Context Protocol servers, Agent-to-Agent agents, programmatic skills, and web APIs) across local networks, enterprise domains, and the public Internet. It defines the system roles, deployment topologies, core architectural principles, and end-to-end interaction flows that connect the ARD specifications for establishing Initial Contact and the Discovery Interface for capability lookup in the ARD catalog. The Registration interface will be specified in a later document. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Discovery of Agents With Names (DAWN) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Software agents and automated orchestrators increasingly rely on external, callable capabilities such as Model Context Protocol (MCP) servers , Agent-to-Agent (A2A) agents , web APIs, and agent skills. This document refers to these capabilities as agentic resources. Early agent deployments rely on manual configuration or pre-installing candidate tools into client prompts. As the number of available resources expands across organizations, static configuration becomes impractical: injecting extensive schemas into orchestration prompts incurs token and processing overhead, while single-operator centralized directories cannot readily accommodate decentralized multi-organization environments. The Agent Resource Discovery (ARD) architecture addresses this by decoupling capability discovery from execution runtimes. Agentic resources are described in manifests, indexed by registries, and found at runtime through standard Internet protocols. The ARD Registry has two interfaces, discovery and registration. A client locates a manifest or registry through initial contact. The manifest lists entries directly or consists of an entry that points to a registry. The mechanisms are specified in the following documents:

• Initial Contact (): Specifies how a client or agent initially locates the entry point URI of an ARD manifest or an ARD Registry starting from a domain name, a local network attachment, or configuration — using DNS Service Binding (SVCB / HTTPS) records , DNS-Based Service Discovery (DNS-SD / mDNS), well-known URIs , and HTTP/HTML link relations.
• Discovery Interface (): Specifies the discovery interface through which a consumer performs structured lookup, faceted exploration, and natural-language search on an ARD Registry. It also specifies the manifest and entry format: an application/ard+json document composed of ARD entries, each describing one agentic resource with its discovery identifier, media type, url or inline data, and an optional trustManifest that binds the entry to its publisher.
• Registration: Specifies how a publisher registers entries with an ARD Registry. Registration requires identification and authentication of the publisher against the registry. Mechanisms include W3C Decentralized Identifiers , WIMSE workload identities , SPIFFE, or other identification mechanisms, depending on the deployment. This interface is to be specified in a later document.

Conventions and Definitions The following terms are used throughout the ARD documents:

Agentic Resource (or Resource):

A network-accessible capability — such as an autonomous agent (A2A), an MCP server, a static AI skill, an API service, or an ARD Registry — that a consumer discovers and interacts with. In ARD, each resource is described by a protocol-specific descriptor (e.g., an A2A Agent Card, an MCP server card, or a skill document) referenced by the entry's url or carried inline in data.

ARD Entry:

An entry in a registry or manifest that describes one agentic resource for discovery, or that points to another ARD Registry. Its format is specified in .

Manifest:

A static or dynamically generated application/ard+json document containing an array of ARD entries (). A manifest is reached at an entry point discovered via (including a well-known URI), may contain entries from one or multiple publishers, and may include or consist of an entry that points to an ARD Registry.

Entry Point:

The URI of an ARD manifest, together with the source from which the client learned it (). An entry point is unverified until the client has retrieved the manifest and authenticated the origin.

Initial Contact:

The process by which a client obtains one or more entry points, starting from a domain name, a local network attachment, or configuration ().

ARD Registry:

The component that holds entries and offers two interfaces, discovery of entries and registration of entries. A registry may also populate itself by crawling and ingesting manifests. The discovery interface is specified in ; the registration interface is to be specified separately ().

Publisher:

The party that controls a domain name and publishes resources under it, by serving a manifest that lists them or by registering entries with an ARD Registry. The domain name appears as <publisher> in the discovery identifiers of its entries. In its interactions with a registry, a publisher acts as a client.

Consumer:

A client that discovers entries through a manifest or an ARD Registry and retrieves or invokes the described resource at its url. Consumers include agents, applications whose behavior is driven by a language model acting on a user's intent, orchestrators, and other workloads.

Domain Owner:

The party that controls the DNS domain name under which a manifest or an ARD Registry is reached. For a publisher's own manifest, the domain owner is the publisher. For an aggregator or a third-party registry, the domain owner operates the manifest or registry while each entry identifies its own publisher.

Discovery Identifier:

A persistent, location-independent identifier that uniquely identifies an agentic resource across manifests and registries. In , it uses the Uniform Resource Name (URN) syntax urn:air:<publisher>:<namespace>:<agent-name>, decoupling publisher identity (<publisher>) from both the manifest or registry host (Domain Owner) and the runtime endpoint (url). Local or non-DNS deployments may bind identifiers to their respective trust domain anchors.

Trust Manifest:

An optional cryptographic envelope within an ARD entry that asserts publisher or third-party verifier identity, software provenance, and compliance attestations ().

System Architecture and Interaction Flows shows the components of the architecture and the interfaces between them, with the specification that defines each interface. Arrows start at the party that initiates an interaction. A consumer may discover entries directly by retrieving a manifest via initial contact, or by querying an ARD Registry (which may itself be discovered via an entry in a manifest). The registration interface is to be specified in a later document (); runtime access to a resource is outside the scope of ARD.

Agent Resource Discovery Architecture and Protocol Mapping | | | | | Publisher | | Consumer | +----------------+ Crawl | / Domain | | | | |-------------->| Owner | | |--------->| ARD Registry | | | | | Lookup, | |<--------------| | | | Search +----------------+ Register +-----------+ | | [ARD] [TBD] | +----------+ | | | | Access (at Entry `url`) Publishes | v v +------------------------------------------------------------------+ | Agentic Resource (Hosted on Same or Separate Domain) | +------------------------------------------------------------------+ ]]>

The architecture separates discovery from runtime execution across four lifecycle phases:

1. Publishing and Initial Contact: A domain owner or publisher serves a manifest at a well-known URI or advertises its manifest or ARD Registry through the DNS, HTTP link, and local-link mechanisms of ; a manifest lists entries directly or includes an entry that points to an ARD Registry. A client obtains the entry point through initial contact or configuration. Publishers, live workloads, or Commissioning Tools can also register entries dynamically with an ARD Registry through the Registration interface ().
2. Indexing: An ARD Registry may serve a single domain or aggregate entries across domains. It populates its indices through registrations or by crawling manifests located through the mechanisms of .
3. Lookup and Search: Consumers discover entries either by querying an ARD Registry using structured filters, faceted exploration, or natural-language queries (), or by reading a manifest obtained through initial contact ().
4. Descriptor Resolution and Access: The consumer retrieves the protocol descriptor at the entry's url (or reads it from inline data), optionally verifies it against the entry's digest and trustManifest, and accesses the resource using its native protocol. The host at url may be in the publisher's domain or in a third-party hosting domain; the entry's identifier, digest, and trustManifest bind the resource to <publisher>. The registry takes no part in runtime access.

Manifest Data Model A manifest is a JSON document of media type application/ard+json with one top-level member, entries, an array of ARD entries (). A publisher serves it at /.well-known/ard.json. An ARD Registry is also a collection of entries, reached through its discovery interface. A registry obtains its entries by reading manifests or through dynamic registration. An entry describes a single agentic resource, combining core descriptive metadata, payload delivery references, discovery signals, and cryptographic trust assertions (). shows the data model of a manifest. A manifest contains any number of entries, and each entry references exactly one resource. An ARD entry comprises:

• Core Envelope: The discovery identifier (a globally unique URI or domain-anchored URN, such as urn:air), the artifact media type (e.g., application/mcp-server-card+json, application/a2a-agent-card+json), and exactly one of url (hypermedia reference to the capability descriptor) or data (inline artifact payload). An entry may also include an algorithm-prefixed cryptographic digest to lock referenced descriptor contents.
• Descriptive Metadata: Human-readable attributes including displayName, description, version, and categorical tags.
• Discovery Signals: Search attributes that enable high-performance indexing without pre-fetching external artifacts:
  • representativeQueries: A list of natural language prompts or queries that the capability satisfies, serving as the primary input for semantic vector and hybrid search indices.
  • capabilities: Structured tokens or vocabulary terms identifying specific tools or skills for precise filtering.
• Provenance and Trust: An optional trustManifest signed by <publisher>, binding publisher identity, claims, and the artifact digest. The publisher of an entry is established from its trustManifest; the host that serves a manifest or operates a registry establishes nothing about the publishers of the entries it holds.
• Open Extensibility: As a JSON-LD node (), an entry inherits the ARD base context and can be extended with domain-specific terms via @context.

Manifest Data Model

The resource is served by the publisher in its native format, for example an A2A Agent Card, an MCP server description, a skill, or an API description. Manifests and registries hold entries; a consumer that needs the resource follows the url. An entry that carries the resource inline as data is the exception. A manifest may consist of a single entry whose url is the base URI of a registry; a consumer that retrieves such a manifest proceeds through the registry's discovery interface.

Deployment Topologies ARD is deployed in three settings, which differ in how a consumer reaches a registry and in which party attests to the publisher of an entry:

• Local network: A home or small office network without an administrator. Consumers find manifests and registries on the link through Multicast DNS and DNS-SD, or through a network-provided domain name, as specified in . Resources on the network register with a local registry through the Registration interface, and their entries expire when the resources leave the network. Entry points learned over multicast are the least trusted source, and local policy determines which of them a consumer uses.
• Private network: The infrastructure of a single organization, within one administrative and trust domain. A registry indexes the organization's resources and is reached through configured entry points or the organization's own DNS. Publisher authority and the authorization to register are established by the organization's identity infrastructure, and the registry is reachable only within the organization.
• Internet: Publishers and registries on the public Internet, anchored in the DNS. A consumer starts from a domain name and reaches a publisher's manifest through the organization index record, DNS-SD, the well-known URI, or the ard link relation (). A registry may crawl manifests across domains and accept registrations from publishers in other domains. Each entry carries its publisher's domain in its discovery identifier and an optional trustManifest signed by the publisher, so a consumer can verify the publisher of an entry regardless of which registry returned it.

In every setting a publisher serves its manifest at /.well-known/ard.json; the well-known URI is mandatory to implement in , and the other mechanisms supplement it. A manifest that lists entries directly is the simplest form of the registry role and supports discovery of entries only. A manifest that consists of a single entry pointing at a registry directs the consumer to the registry's discovery interface.

Core Architectural Principles ARD is designed according to seven foundational principles:

Hypermedia-Based Discovery Discovery in ARD is hypermedia-based. A consumer follows links: from an entry point to a manifest, from a manifest to its entries or to a registry, from a registry response to entries, and from an entry to the resource at its url. A registry offers a lookup interface over its entries with structured filters and, where the registry supports it, natural-language or semantic search (). The entries in a registry are maintained either by the registry itself, which crawls and ingests manifests, or by publishers, which register and refresh their entries through the Registration interface. An entry is discoverable as soon as the registry has indexed it.

Search-First Dynamic Discovery Capabilities are discovered on demand at runtime based on natural language task descriptions and structured constraints, rather than pre-installed statically. Registries maintain continuously refreshed semantic and structured indices, allowing newly published capabilities to be discovered immediately without client recompilation or manual reconfiguration.

Scalability Beyond Context Windows Traditional tool selection relies on injecting every candidate tool description into the model's context window, which does not scale as collections grow to thousands or millions of resources. While a client can rank a small, pre-fetched set of tools locally, local ranking still requires each client to know, fetch, and index the candidate corpus in advance. ARD moves candidate discovery outside the model into a dedicated search service (whether deployed over a curated enterprise catalog or across open domains), where richer signals such as representativeQueries, publisher identity, compliance metadata, and structured attributes can be indexed, and where publisher identity and trust attestations (trustManifest) can be verified ahead of time during ingestion rather than by each client at runtime. The client queries the registry and receives only the top-k relevant entries to inject into its context window.

Artifact-Agnostic Envelope ARD does not define or standardize the internal schemas of specific resource architectures. Instead, it serves as a protocol-neutral envelope. The entry's type field uses IANA Media Types to declare whether the resource is an MCP server (application/mcp-server-card+json), an A2A agent (application/a2a-agent-card+json), an AI skill (application/ai-skill+md), or an Agent Registry (application/ai-registry+json).

Open Namespace Extensibility via JSON-LD Every ARD entry is a JSON-LD node. Core discovery terms are defined in the default ARD base context. Publishers may enrich entries with terms from arbitrary external namespaces (e.g., industry taxonomies, regulatory tags, or pricing models) through @context declarations. Registries index known terms and preserve unrecognized terms, enabling open evolution without revisions to the core specifications.

Universal HTTP REST Baseline To guarantee universal interoperability regardless of execution environments, every ARD Registry exposes a standard HTTP REST interface over HTTPS conforming to . While registries may additionally offer protocol-specific wrappers (such as an MCP tool or A2A skill wrapper), the HTTPS REST API represents the universal baseline.

Strict Separation of Concerns Operational and architectural concerns are decoupled across layers:

• Discovery vs. Resolution: ARD identifies what capabilities exist and where their authoritative descriptors or endpoints reside. Lower-level name resolution and transport routing remain delegated to standard DNS and network primitives.
• Discovery vs. Execution: ARD is link-based. Once an agentic resource is discovered, the client follows the artifact reference (url) and invokes the resource directly via its native protocol (e.g., JSON-RPC over HTTP/SSE for MCP, HTTP/REST for A2A, or gRPC). The discovery registry never sits in the runtime execution data path.
• Identification vs. Network Location: An agentic resource's discovery identifier (urn:air:<publisher>:...) is decoupled from both the manifest/registry hosting origin (Domain Owner) and the physical execution endpoint (url). This allows registries and manifests to aggregate entries across publishers, and allows a resource's runtime endpoint to be hosted on or migrated across cloud providers without changing its identifier.
• Search Relevance vs. Security Evaluation: Semantic search scores indicate textual relevance only and do not represent trust, safety, or compliance assertions.
• Discovery vs. Authorization: Authentication, token negotiation, and runtime access control are handled by the resource endpoint during invocation, while cryptographic provenance (trustManifest) allows registries and consumers to verify publisher authority independently of where a manifest or registry is hosted.

Security Considerations

Decoupling of Administrative Domains A central security property of ARD is that a single discovery flow may span three distinct administrative domains ():

1. Domain Owner (Serving Origin): The host serving the manifest or registry API (e.g., registry.example.org or a CDN target catalog.example.net), authenticated at the transport layer via TLS (and optionally DNSSEC during initial contact).
2. Entry Publisher (<publisher> in urn:air:<publisher>:...): The organization claiming authorship of the agentic resource (e.g., abc.com in urn:air:abc.com:agent:flight-finder), authenticated at the entry layer via trustManifest.identity (e.g., did:web:abc.com) and trustManifest.signature (or via same-origin HTTPS when fetched directly from https://abc.com/.well-known/ard.json).
3. Runtime Endpoint Host (url): The infrastructure hosting the capability descriptor or execution endpoint (e.g., xyz.execute-api.amazonaws.com), whose descriptor content is locked to the publisher's signed entry via the cryptographic content digest.

Three-Domain Trust Model in ARD = abc.com) | | | | - Signed by trustManifest (identity = did:web:abc.com) | | | | - Pins descriptor content via digest = sha256:9f86... | | | +-----------------------------------------------------------+ | +---------------------------------|---------------------------------+ | | Follows `url` & verifies `digest` v +-------------------------------------------------------------------+ | 3. Runtime Endpoint Host (e.g., xyz.execute-api.amazonaws.com) | | - TLS cert belongs to cloud host; content bound by `digest` | +-------------------------------------------------------------------+ ]]>

Defense-in-Depth Layers Because discovery spans untrusted networks, multi-tenant origins, and third-party aggregators, the ARD architecture applies defense-in-depth across the three companion specifications:

1. Authenticated Transport and Hint Validation (): Entry points obtained from DNS records, multicast responses, or third-party links are treated as untrusted hints until the client fetches the resource over HTTPS (TLS) and authenticates the serving origin.
2. Entry-Level Publisher and Artifact Integrity Binding (): Because the origin hosting a manifest or registry (Domain Owner), the <publisher> domain in an entry's URN (urn:air:<publisher>:...), and the host in the entry's runtime url field may belong to three different administrative domains, an unverified URN string carries no implicit trust. When an entry is served directly from https://<publisher>/.well-known/ard.json, same-origin HTTPS establishes domain authority for entries under <publisher>. When entries are aggregated across domains, cached, or federated across registries, cryptographic publisher binding is established via the entry's signed trustManifest (binding <publisher> to the entry's identifier, type, version, and content digest). Independent security auditors may attach additional third-party trustManifest signatures to endorse compliance or evaluation claims without altering the publisher's signature.
3. Workload Authentication for Active Registration: Registries that accept dynamic registrations authenticate the registering workload or Commissioning Tool using mutually authenticated TLS or workload identity tokens (such as ) and may verify whether the registrant is authorized for the <publisher> domain in the entry's URN to assign verified status indicators or enforce admission policy.

Detailed protocol-specific security and privacy considerations are specified in and .

IANA Considerations This document has no IANA actions. IANA registrations for well-known URIs, HTTP link relations, DNS-SD service names, media types, and URN namespaces are specified in and .

Informative References A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. 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. 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. W3C W3C IETF Anthropic Linux Foundation Google Hugging Face Ericsson Amazon Ericsson Google Ericsson

Acknowledgments The authors would like to thank Mirja Kühlewind, Shaun Smith, Jeffrey Damick, Wes Hardaker, Warren Kumari, and the participants of the Agent Resource Discovery community and IETF DAWN discussions for their architectural contributions and feedback.