]> Google

jbu@google.com

guha@guha.com

Hugging Face

shaun.smith@huggingface.co

Ericsson

jaime.jimenez@ericsson.com

Amazon

jdamick@amazon.com

Internet agent discovery autonomous agents artificial intelligence model context protocol agent-to-agent federated search tool registry DAWN This document specifies the catalog representation and lookup protocol for Agent Resource Discovery (ARD), an open architecture for publishing, discovering, and searching software agent capabilities across federated networks. ARD defines a JSON-LD capability description envelope (the ARD Entry) and catalog container (the ARD Manifest) identified by domain-anchored Uniform Resource Names (URNs), cryptographic publisher authority bindings (the Trust Manifest), and an HTTP query interface supporting structured, semantic, and federated search across registries. Initial contact for discovering catalog entry points and active agent registration are specified in companion ARD documents. 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) Proposed 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 interact with external, callable capabilities — such as Model Context Protocol (MCP) servers , Agent-to-Agent (A2A) agents , web APIs, and modular skills. In this document, callable capabilities providing programmatic services to automated systems are referred to generically as "agentic resources." The overall Agent Resource Discovery (ARD) architecture, deployment topologies, and design principles are described in . Within the ARD protocol suite, initial contact for locating a domain's manifest or registry entry point URI is specified in , and active registration of live workloads with an Agent Directory is specified in . This document specifies the Manifest Representation and Lookup Protocol for ARD:

• The ARD Entry and Manifest Format (): Defines the JSON-LD capability description envelope (ARD Entry), the application/ard+json container format (ARD Manifest), and the domain-anchored Uniform Resource Name (URN) syntax (urn:air:<publisher>:<namespace>:<agent-name>) .
• Cryptographic Trust and Authority Binding (): Defines the optional trustManifest envelope (sealed using RFC 8785 JCS and RFC 7515 detached JWS ) and artifact digest binding that allow consumers and multi-domain aggregators to verify publisher authority and third-party evaluations independently of the serving origin.
• Lookup, Search, and Federated Discovery (): Defines the HTTP REST interface (POST /search, POST /explore, and GET /agents) for structured filtering, semantic vector search, faceted exploration, and federated routing (auto, referrals, and none) across ARD Registries.

Conventions and Definitions 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 BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the architectural terminology (Agentic Resource, ARD Entry, Manifest, Registry, Publisher, Domain Owner, Consumer, Discovery Identifier, and Trust Manifest) defined in .

The ARD Entry and Manifest Format The primary information model of ARD is the ARD Entry — the description of a single agentic resource carrying both core descriptive metadata and the discovery signals (representativeQueries and structured capabilities) required to make resources comparable and discoverable across publishers. ARD is defined over ARD entries; the container an entry travels in (a hosted manifest/catalog or a registry API response) is a transport concern.

JSON-LD Representation and Base Context An ARD entry is a JSON-LD node. The authoritative ARD base context is published at: The base context maps core terms to Internationalized Resource Identifiers (IRIs) under the namespace https://agenticresourcediscovery.org/ns#. A conforming ARD consumer or registry MUST interpret an entry by applying the ARD base context as the initial expansion context (the JSON-LD expandContext option). An entry's local @context, when present, is layered on top of the base context: it MAY introduce new namespace prefixes or override existing ones, but does not discard the base. Under this rule, core terms resolve to their standard IRIs, while namespaced extension terms resolve through the prefixes declared in the entry. Including @context in an entry is OPTIONAL when served within an ARD manifest, as compliant processors automatically inject the base context. An entry SHOULD include @context when exchanged outside an ARD manifest (such as in generic JSON-LD documents or third-party feeds) where generic processors might otherwise lack the base context.

Entry Fields The following fields comprise an ARD entry:

Required Fields

identifier (String, MUST):

A globally unique, domain-anchored URN following the syntax defined in (e.g., urn:air:example.com:agent:flight-finder) that identifies a specific agentic resource instance published under the <publisher> domain's authority (rather than an abstract capability class shared across independent vendors). The JSON-LD @id MAY mirror this identifier.

displayName (String, MUST):

A human-readable display name for the agentic resource.

type (String, MUST):

The artifact media type formatted as an IANA Media Type string (e.g., application/mcp-server-card+json, application/a2a-agent-card+json).

url OR data (MUST, exactly one):

The capability payload delivery mechanism. An entry MUST specify either url or data, but MUST NOT specify both (see ).

Recommended Discovery Signals

representativeQueries (Array of Strings, SHOULD):

A list of 2 to 5 representative natural language user prompts or queries that this capability is designed to fulfill — the primary signal from which registries build semantic vector indices. Omitting this field severely degrades search discoverability. Conformance tooling flags missing or under-populated queries as a warning rather than a hard failure to accommodate entries originating from basic catalogs.

capabilities (Array of Strings, MAY):

Strings naming specific skills or tools exported by the resource (e.g., ["WeatherQuery", "ForecastLookup"]) or JSON-LD vocabulary terms mapped via @context that enable high-performance structured filtering without fetching the complete artifact card.

Optional Descriptive Fields

description (String, OPTIONAL):

A detailed natural language summary of the capability, its purpose, and operational characteristics.

tags (Array of Strings, OPTIONAL):

Categorical tags for indexing (e.g., ["travel", "finance", "utility"]).

version (String, OPTIONAL):

A version identifier (e.g., SemVer 1.2.0).

digest (String, OPTIONAL):

An algorithm-prefixed cryptographic digest (<alg>:<hex>, e.g., sha256:9f86d08...) of the target artifact referenced by url (or inline data). Implementations MUST support sha256 and MAY support additional collision-resistant hash algorithms (such as sha384 or sha512).

updatedAt (String, OPTIONAL):

An or ISO 8601 UTC timestamp indicating when the record was last modified.

metadata (Object, OPTIONAL):

An open key-value mapping for arbitrary operational metadata (e.g., rate limits, region availability).

trustManifest (Object, OPTIONAL):

A cryptographic trust envelope containing publisher identity assertions, provenance chains, and compliance attestations (see ).

Value-or-Reference Pattern and Hypermedia Linking An entry delivers its capability manifest through either reference (url) or value (data):

• Reference (url - Primary Link-Based Model): A URI pointing directly to the external artifact descriptor (such as an Agent Card, OpenAPI schema, or MCP server manifest). ARD is fundamentally link-based: the registry indexes discovery metadata and returns reference links, leaving the client to fetch operational descriptors directly from the capability host. This ensures that the registry remains strictly decoupled from the runtime execution data path and avoids serving as a proxy or single point of failure. When an entry using url carries content-bound attestations in trustManifest, the entry SHOULD include digest to lock the referenced descriptor's content against post-publication modification at url.
• Value (data - Inline Fallback): The complete artifact document embedded directly inline as a JSON object. This is provided as an optional mechanism for standalone, isolated, or air-gapped environments where an additional network resolution round-trip is impossible or undesirable.

An entry MUST carry exactly one of url or data, and MUST NOT include both.

Domain-Anchored URN Syntax The discovery identifier MUST be a Uniform Resource Name (URN) adhering to using the formal urn:air: namespace prefix: :: ]]> Where:

• urn:air: The assigned ARD namespace identifier.
• <publisher>: The fully qualified domain name (FQDN) of the publishing authority (e.g., example.com, cloud.google.com).
• <namespace>: A sub-organization, project, or category identifier defined by the publisher (e.g., travel, devtools, hr).
• <agent-name>: A unique name identifying the agentic resource instance within that publisher's namespace.

This domain-anchored structure guarantees global uniqueness without requiring a centralized naming committee, leverages existing DNS ownership for authority, and allows registries to parse publisher boundaries deterministically. Separating the logical resource identifier (urn:air:...) from physical content delivery (url or data) serves several protocol requirements:

• Uniform Identity Across url and Inline data: Entries delivered by value via data (such as inline skills, prompt templates, or embedded MCP configurations) do not have a separate artifact url. The urn:air identifier provides a uniform primary key regardless of delivery mode.
• Origin Independence and Deduplication: A resource's physical hosting url may change across staging and production environments, CDN mirrors, or cloud providers without changing the logical resource. The (identifier, version) tuple enables crawlers, registries, and federated peers to deduplicate entries and correlate third-party trustManifest evaluations across catalogs, while keeping provenance links (provenance[].sourceId) stable across hosting migrations.
• Cryptographic Publisher Binding vs. Hosting Origin: Note that the HTTP origin hosting the manifest (/.well-known/ard.json), the <publisher> domain in the URN, and the host in the entry's url field do not need to be the same domain. For example, a catalog hosted at https://example.com/.well-known/ard.json may include an entry published by abc.com (urn:air:abc.com:agent:flight-finder) whose descriptor url is hosted on a cloud provider (https://xyz.execute-api.us-east-1.amazonaws.com/agent.json), where the TLS certificate of url belongs to the cloud provider rather than abc.com. An unverified urn:air:<publisher>:... string carries no implicit trust; binding the URN to <publisher> requires verifying a trustManifest signed by a key authorized by <publisher> (e.g., did:web:<publisher>). Because a manifest or registry response can contain entries from multiple publishers, each entry carries its full urn:air:<publisher>:... URN rather than a relative suffix.
• Separation from Runtime Workload Identity: Whereas runtime workload identifiers (such as spiffe:// or WIMSE Workload Identity Tokens) authenticate live execution instances during active registration () or runtime invocation, urn:air identifies the published catalog artifact across versions and registries.

Identity and the Trust Manifest To satisfy enterprise compliance, supply-chain verification, and zero-trust policies, an ARD entry MAY carry a trustManifest object (or a trustManifests array when multiple parties — such as the original publisher and an independent security auditor — attach separate signed manifests to the same entry): Each trustManifest object is a self-contained signed envelope with the following core fields and signature semantics:

• identity (String, MUST): The cryptographic signer identifier (for example, did:web:example.com, resolved over HTTPS from https://example.com/.well-known/did.json).
• issuedAt (String, SHOULD) and expiresAt (String, MAY): ISO 8601 timestamps indicating when the manifest was signed and, for periodic third-party evaluations, when the assertion expires.
• subject (Object, MUST): A self-contained block containing the target entry's release coordinates (identifier, type, digest, and version when present on the entry). Including subject directly inside trustManifest allows the manifest to be canonicalized and verified as a standalone JSON object without cross-level JSON stitching.
• attestations (Array, MAY) and provenance (Array, MAY): Hash-pinned references (uri + digest) to external supply-chain or compliance evidence (such as SLSA build provenance, SPDX SBOMs, SARIF vulnerability scans, or SOC 2 audit reports) and artifact lineage links (sourceId + sourceDigest).
• signature (String, MUST): A JSON Web Signature (JWS) computed over the JSON Canonicalization Scheme (JCS) serialization of the trustManifest object with the signature member removed. The JWS Protected Header specifies the signing algorithm (alg, with ES256 Mandatory-to-Implement) and key identifier (kid).

Publisher and Verifier Authority Binding A trustManifest signature cryptographically binds the signer (identity) to the artifact coordinates in subject (identifier, type, version, digest) and to the referenced attestations and provenance digests. Verifiers distinguish two roles:

1. Publisher Authority (Publisher Profile): To establish that the entry was genuinely published by <publisher> in urn:air:<publisher>:..., the entry MUST include a trustManifest whose identity matches or is cryptographically authorized by <publisher> (e.g., did:web:<publisher>). Verifying registries and consumers MUST confirm that (a) trustManifest.subject (identifier, type, digest, and version) matches the parent entry, (b) trustManifest.identity binds to <publisher>, and (c) trustManifest.signature is valid over the JCS-canonicalized trustManifest. Entries failing these checks MUST be rejected.
2. Third-Party Verifier Attestations (Signer Profile): Independent security auditors, compliance bodies, or evaluation services (whose identity domain differs from <publisher>, e.g., did:web:auditor.example.org) MAY attach an additional trustManifest in trustManifests[] over the same subject coordinates to endorse third-party evaluation results without altering the publisher's manifest. A third-party manifest attests only the evaluator's claims and does not substitute for the publisher's trustManifest.

Cryptographic Subject Binding and Integrity Digests Attestations in trustManifest.attestations involve two distinct integrity bindings:

1. Binding the Attestation to the Target Artifact: To prevent attestation transplantation (where an attacker copies a valid attestation from one agent into another entry's metadata), each third-party attestation statement MUST either be a direct cryptographic signature over the artifact or include a signed subject claim that identifies the resource's identifier and/or the artifact's content digest. When the artifact is referenced via url rather than inline data, the ARD entry MUST include the top-level digest field so that the referenced bytes at url are bound to the attested digest.
2. Pinning the External Attestation Document (attestations[].digest): Because external attestation documents referenced by attestations[].uri (such as PDF compliance reports, SARIF scan results, or SLSA provenance files) may be hosted on external servers or in formats that do not carry self-contained signatures, the optional digest field inside each attestations[] item records the cryptographic hash of the external attestation document itself. Sealed under trustManifest.signature, this acts as a subresource integrity pin ensuring the external file at attestations[].uri cannot be replaced or modified after the trustManifest is signed.

All digest strings (digest, attestations[].digest, and provenance[].sourceDigest) use the algorithm-prefixed <alg>:<hex> format (e.g., sha256:...) to support hash agility; sha256 is Mandatory-to-Implement (MTI).

The ARD Manifest Container When published as a static catalog document (at an entry point URI discovered via , such as https://{domain}/.well-known/ard.json), ARD entries are packaged in an application/ard+json document containing a top-level entries array: A publisher is not required to enumerate its capabilities in a static manifest; it MAY instead operate a dynamic Agent Registry exposing the query interface () directly, or publish a minimal manifest containing a single application/ai-registry+json entry whose url advertises the Base URI of its dynamic Agent Registry service. For web crawlers, publishers MAY also signal their manifest in HTML <head> elements using <link rel="ard" type="application/ard+json" href="...">.

Lookup, Search, and Federated Discovery Whether a publisher exposes a dynamic Agent Registry directly or third-party registries aggregate entries across domains, clients query Agent Registries to perform structured, semantic, and faceted discovery.

Registry Ingestion and Companion Protocols An Agent Registry may operate as a publisher's own dynamic discovery endpoint, as a standalone search service that ingests entries via web crawling, or as a dual-role Agent Directory that pairs lookup with an active registration service. This document specifies the Lookup and Search Interface ( and ), which builds upon two companion specifications:

• Initial Contact and Entry Point Discovery (): Clients and registry crawlers obtain manifest or registry entry point URIs using the mechanisms defined in — including DNS Service Binding (SVCB / HTTPS) records under _entries._agents.<domain> or _search._agents.<domain>, DNS-Based Service Discovery (_ard._tcp) over unicast DNS or Multicast DNS, the baseline well-known URI (/.well-known/ard.json), and the ard HTTP link relation.
• Active Registration and Soft-State Lifecycle (): For dual-role Agent Directories that accept active registrations from live agent workloads or Commissioning Tools (CTs), the registration wire protocol, soft-state lifetime (lt) renewals, and workload identity authentication (such as IETF WIMSE Workload Identity Tokens and Workload Proof Tokens, SPIFFE IDs, or ID-JAG assertions) are specified in (drawing from ). A registry MAY verify whether the asserted workload identity or trustManifest binds to the <publisher> domain declared in the entry's URN (see ) and use the outcome for verified status indicators, filtering, ranking, or admission decisions.

Ingestion and Crawling Pipelines Registries populate and refresh their discovery indices through automated ingestion and crawling pipelines that:

• Discover and fetch publisher /.well-known/ard.json manifests, HTTP ard link relations, HTML <link rel="ard"> tags, and DNS-advertised entry points over TLS 1.3 (per ).
• Ingest validated manifests and entries from software repositories, package registries, and federated peer registries.

As in and the CoRE Resource Directory architecture (Section 7.2 of ), a discovery channel or registry is authoritative for its own lookup and search responses, not for the third-party agent resources it lists. Entry point URIs and entries ingested from static manifests, HTML <link rel="ard"> tags, package registries, or federated peer registries serve as discovery hints until publisher authority and artifact integrity are verified via the entry's signed trustManifest and the target resource at url (see and ).

The Search and Query HTTP API In accordance with BCP 56 , compliant Agent Registries MUST expose an HTTP query interface over HTTPS conforming to (supporting HTTP/1.1 and HTTP/2, and optionally HTTP/3), MAY additionally offer protocol-specific wrappers, and MAY document their endpoints using the OpenAPI Specification . A registry discovers peer registries by recognizing entries whose type is application/ai-registry+json. To avoid squatting on root URI paths (, Section 4.3 of ), the endpoint paths /search, /explore, and /agents defined in this section are relative to the Registry's discovered Base URI (advertised in the url field of the registry's application/ai-registry+json entry, e.g., https://registry.example.com/ard/v1). Requests with a message body and successful responses use the application/json media type unless a specific profile media type is negotiated via Accept / Content-Type headers.

Universal Query Model Search and introspection endpoints accept a unified query object comprising three optional elements: @context, text, and filter:

• @context: Defines JSON-LD prefix mappings used for keys inside filter.
• text: Natural language user intent used for semantic relevance matching and vector search.
• filter: Key-value map of exact structural constraints. Keys represent term paths (resolved via @context and the base context). Values are arrays combined with OR logic; multiple keys are combined with AND logic.

Search Endpoint (POST /search) The Search endpoint executes semantic ranking combined with structured filtering over the registry index.

Search Request Schema Parameters:

• query.text (String, MUST): The semantic search prompt.
• query.filter (Object, OPTIONAL): Structured filter constraints.
• federation (String, OPTIONAL): Federation routing mode ("auto", "referrals", or "none", default: "auto").
• pageSize (Integer, OPTIONAL): Maximum results to return (default: 10, max: 100).
• pageToken (String, OPTIONAL): Pagination cursor token.

Search Response Schema The score integer parameter (0 to 100) indicates informational semantic relevance calculated by the registry.

Explore Endpoint (POST /explore) The Explore endpoint allows clients to introspect registry contents, aggregate distributions, and inspect available facets without returning full entry records.

Explore Request Schema

Explore Response Schema

Deterministic List Endpoint (GET /agents) A lightweight, cacheable HTTP GET endpoint for administrative browsing, catalog synchronization, and developer tooling. Supports standard query parameters: pageSize, pageToken, and a deterministic filter query string.

Standard Error Responses When a query fails or cannot be processed, conforming registries MUST return an appropriate HTTP status code and SHOULD return an HTTP Problem Details object (application/problem+json) conforming to (per Section 4.7 of ), including a machine-readable error code extension member:

HTTP Status	Error Code	Description
400 Bad Request	INVALID_ARGUMENT	Malformed query JSON, missing required fields, or invalid filter syntax.
401 Unauthorized	UNAUTHENTICATED	Missing or invalid authentication credentials.
403 Forbidden	PERMISSION_DENIED	Caller lacks sufficient access permissions for the registry or resource.
404 Not Found	NOT_FOUND	Specified agent identifier, registry, or endpoint does not exist.
429 Too Many Requests	RATE_LIMIT_EXCEEDED	Request rate limit exceeded; server SHOULD include a Retry-After header field () and client SHOULD retry with backoff.
500 Internal Server Error	INTERNAL_ERROR	Internal server or unhandled storage failure.
501 Not Implemented	NOT_IMPLEMENTED	Requested feature (e.g., Explore endpoint or unsupported federation mode) is not implemented.

Federated Routing and Scalability Registries coordinate in a decentralized mesh using the federation parameter:

• auto: The queried registry forwards the query to its upstream peer registries, aggregates and de-duplicates the result sets, and returns a unified response to the client.
• referrals: The registry returns its own local matches along with a list of referrals pointing to downstream or domain-specific registries. The client decides which registries to query next.
• none: The registry queries only its locally indexed entries.

illustrates the query flows for the auto and referrals modes (whereas none restricts search to Registry A's local index):

Federated Registry Query Flows | Registry | | Consumer |------->| Registry | | |<-------| A | | |<-------| A | +----------+ Agg. +----------+ +----------+ Local +----------+ Results | ^ | ^ + Referrals Fwd | | Peer | | Query | | Results | +--- Follow Referral v | | Query / Results +----------+ | +----------+ | Peer | +------->| Peer | | Registry | | Registry | +----------+ +----------+ ]]>

To prevent infinite loops and denial-of-service amplification across federated registries, registries MUST maintain a hopCount and reject or truncate queries exceeding a maximum hop limit (default: 3 hops).

Federation Trust Model and Origin Binding Federated discovery introduces two distinct verification boundaries:

1. Non-Authoritative Downstream Registries: In both "auto" and "referrals" modes, peer registries act as non-authoritative discovery intermediaries (analogous to Section 7.2 of ). A TLS connection to a registry authenticates only that registry (source), not the <publisher> of the entries it returns. Consequently, neither an aggregating registry in "auto" mode nor a client following "referrals" MUST rely on transport trust in a downstream registry to establish publisher authority. Instead, consumers and verifying registries MUST validate each entry's signed trustManifest against the <publisher> domain (and any third-party verifier trustManifest against the verifier's identity); entries lacking a verified publisher trustManifest MUST be treated as unverified discovery hints. In "referrals" mode, clients can also evaluate the referred registry's identity before transmitting sensitive query text.
2. Binding Location url to the Target Origin: A valid trustManifest signature from <publisher> proves that <publisher> authorized the entry (urn:air:<publisher>:...), but if url points to a different origin (for example, urn:air:attacker.example:agent:foo specifying "url": "https://victim.example.com/service"), <publisher>'s signature alone does not prove that the target origin (victim.example.com) consented to host that resource. When the origin of url differs from https://<publisher>, consumers and verifying registries MUST verify that the artifact descriptor retrieved from url matches the entry's signed cryptographic digest and explicitly declares the matching identifier (urn:air:<publisher>:...) or publisher identity (trustManifest.identity) before invoking the resource.

Referrals Federation Example When a consumer specifies "federation": "referrals", the registry returns its direct capability matches in results alongside an array of referrals pointing to downstream or specialized registries matching the query scope: Request: Response:

Formal CDDL Specification The normative grammar of the ARD manifest, entry, and REST payloads is defined in Concise Data Definition Language (CDDL) : any } ; --- The ARD Entry --- ard-entry = { ard-entry-required, ard-entry-descriptive, * tstr => any } ard-entry-required = ( ; URN: urn:air:{publisher}:{namespace}:{agent-name} identifier: tstr, displayName: tstr, type: tstr, ; IANA Media Type content-delivery ; value-or-reference ) ard-entry-descriptive = ( ? "@context" => any, ? "@id" => tstr, ? description: tstr, ? tags: [+ tstr], ? capabilities: [+ tstr], ? representativeQueries: [* tstr], ? version: tstr, ? digest: tstr, ? updatedAt: tstr, ? metadata: {* tstr => any}, ? trustManifest: trust-manifest, ? trustManifests: [+ trust-manifest] ) content-delivery = ( url: tstr // data: {* tstr => any} ) ; --- Trust Envelope --- trust-manifest = { identity: tstr, ? issuedAt: tstr, ? expiresAt: tstr, ? subject: trust-subject, ? identityType: tstr, ? trustSchema: trust-schema, ? attestations: [* attestation], ? provenance: [* provenance-link], ? signature: tstr, * tstr => any } trust-subject = { identifier: tstr, type: tstr, ? version: tstr, ? digest: tstr, ? url: tstr, * tstr => any } trust-schema = { ? identifier: tstr, ? version: tstr, ? governanceUri: tstr, ? verificationMethods: [* tstr], * tstr => any } attestation = { type: tstr, uri: tstr, ? mediaType: tstr, ? digest: tstr, * tstr => any } provenance-link = { relation: tstr, sourceId: tstr, ? sourceDigest: tstr, * tstr => any } ; --- Search API Payloads --- query-model = { ? text: tstr, ? "@context" => any, ? filter: {* tstr => ([+ tstr] / tstr)} } search-request = { query: query-model, ? federation: "auto" / "referrals" / "none", ? pageSize: uint, ? pageToken: tstr } search-response = { results: [* search-result-item], ? referrals: [* registry-referral], ? nextPageToken: tstr } search-result-item = { identifier: tstr, ? displayName: tstr, ? type: tstr, ? url: tstr, ? digest: tstr, ? trustManifest: trust-manifest, score: 0..100, source: tstr, * tstr => any } registry-referral = { identifier: tstr, displayName: tstr, type: "application/ai-registry+json", url: tstr } ; Helper types any = any-cbor / any-json any-cbor = bool / int / float / tstr / bstr / [* any-cbor] / {* any-cbor => any-cbor} any-json = bool / int / float / tstr / null / [* any-json] / {* tstr => any-json} null = nil ]]>

Security Considerations Discovery protocols for autonomous systems operate in adversarial environments where malicious capability advertisements could misdirect automated actions, trigger unauthorized tool invocations, or exfiltrate private conversation contexts.

Threat Model The ARD security architecture considers the following primary threat vectors:

1. Namespace Squatting and Impersonation: An attacker advertises an agent under a reputable organization's domain name (e.g., asserting urn:air:google.com:... without holding administrative control over google.com).
2. Relevance Score Poisoning (SEO Injection): An attacker injects deceptive, highly generic, or adversarial terms into representativeQueries or description to artificially inflate the agent's ranking in response to high-value user prompts (such as financial or credential-handling queries).
3. Attestation Transplantation: An attacker extracts a cryptographically valid compliance attestation (e.g., SOC2 or security audit) from a legitimate agent and embeds it into a malicious entry's metadata.
4. Federation Amplification and Query Loops: A hostile registry initiates recursive queries across federated peers designed to trigger exponential request explosion or denial-of-service loops.
5. Prompt and Intent Snooping: Eavesdroppers or untrusted intermediary registries harvest sensitive user query prompts (query.text) to extract proprietary enterprise context, personal data, or system prompts.

Publisher Authority Verification To counter namespace squatting and record tampering, registries and consumers MUST enforce domain authority binding:

• The <publisher> segment of the urn:air:<publisher>:... identifier MUST correspond to an authentic FQDN.
• Cryptographic Publisher and Verifier Verification (trustManifest): For end-to-end publisher authentication and tamper protection across registries, third-party catalogs, and federated hops, the entry MUST carry a trustManifest signed by a cryptographic identity authorized by <publisher> (e.g., via W3C did:web:{publisher} or X.509 SAN certificates; third-party evaluators MAY attach additional trustManifest signatures bound to their own verifier domains), and the target resource at url MUST be bound via its cryptographic content digest. Verifying registries and consumers MUST reject signed entries whose cryptographic proof or domain binding fails.
• Cross-Origin Target url Binding: Signing an entry under <publisher> does not authorize the publisher to claim an unconsenting third-party origin in url. When the origin of url differs from https://<publisher>, consumers and verifying registries MUST verify bidirectional binding at the target url by confirming that the artifact descriptor retrieved from url matches the entry's signed digest and declares the matching identifier (urn:air:<publisher>:...) or publisher identity (see ).
• No Implicit Authority from Manifest Host or Transport Origin: Retrieving an entry from https://{domain}/.well-known/ard.json (even when {domain} matches <publisher>), via HTML <link rel="ard">, or from a discovery registry establishes only transport security to the serving host and MUST NOT be treated as proof of publisher authority. Any entry lacking a verified trustManifest signature bound to <publisher> MUST be treated by registries and consumers as an unverified discovery hint.

Decoupling of Semantic Relevance and Trust The score returned by POST /search represents solely mathematical text/semantic similarity between query.text and the indexed capability. Orchestrators and clients:

• MUST NOT interpret score as an indicator of safety, quality, or authenticity.
• MUST NOT execute privileged operations or expose sensitive credentials to an agent solely based on high search scores.
• MUST evaluate security policies, verified trust manifests, and sandbox restrictions independently of the discovery ranking.

Attestation Integrity and Subject Binding To prevent attestation transplantation and post-publication content substitution:

• Artifact Subject Binding: Signed attestations referenced in trustManifest.attestations (such as SLSA or in-toto statements) MUST either directly sign the target artifact or bind to the resource's identifier and/or the artifact's algorithm-prefixed digest (<alg>:<hex>, with sha256 Mandatory-to-Implement). When an entry delivers its artifact by reference (url), consumers MUST compute the digest of the retrieved artifact and verify that it matches the entry's digest and the attestation subject before honoring any audit or provenance claims.
• External Attestation Pinning: When an entry in trustManifest.attestations includes digest, consumers fetching the external attestation document from attestations[].uri MUST verify that the fetched document's digest matches attestations[].digest sealed by trustManifest.signature.

Mandatory Transport Layer Security (TLS 1.3) All ARD communications — including static manifest retrieval, DNS over HTTPS (DoH), registration endpoints, and search API queries — MUST use Transport Layer Security (TLS) 1.3 or later in accordance with BCP 195 . Implementations MUST use ephemeral key exchange providing forward secrecy and enforce strict certificate validation. Cleartext HTTP (plaintext) MUST NOT be permitted for any public discovery endpoint.

DoS Protection and Federation Limits To prevent distributed denial-of-service amplification:

• Registries implementing "auto" federation MUST decrement a Hop-Count header (maximum initial value: 3). Queries reaching Hop-Count: 0 MUST NOT be forwarded.
• Registries MUST implement referral loop detection by tracking visited registry URIs in a query trail header.
• Public registries SHOULD implement rate-limiting per client IP and authenticated identity.

Workload Identity and Token Scoping When dynamic registration interfaces are exposed, registries SHOULD integrate with standard workload identity protocols such as WIMSE . Registration tokens MUST be short-lived, audience-restricted, and cryptographically verified against trusted identity providers.

Privacy Considerations Natural language queries submitted to POST /search inherently reflect the user's immediate intent, tasks, and potentially confidential context.

1. Query Eavesdropping: Queries transmitted over open networks can reveal user activities. Mandatory TLS 1.3 protects query confidentiality in transit.
2. Registry Logging and Profile Building: Third-party public registries could aggregate queries across time to build behavioral profiles of individuals or corporate entities. Conforming public registries SHOULD adopt strict data minimization, zero-retention, and query anonymization policies.
3. Client-Side Intent Filtering: Client orchestrators SHOULD sanitize query.text before transmission to external registries, stripping proprietary source code, credentials, personally identifiable information (PII), and session identifiers.

IANA Considerations The ard.json Well-Known URI, ard Link Relation, and ard Service Name registrations are requested in the companion initial contact specification . This document requests the Media Type and URN Sub-Namespace registrations below.

Media Type Registrations IANA is requested to register the following media types in the "Media Types" registry:

application/ard+json

• Type name: application
• Subtype name: ard+json
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: binary (JSON UTF-8)
• Security considerations: See of this document.
• Interoperability considerations: Fully compliant with RFC 8259 JSON and JSON-LD 1.1.
• Specification document: This document

application/ai-registry+json

• Type name: application
• Subtype name: ai-registry+json
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: binary (JSON UTF-8)
• Security considerations: See of this document.
• Specification document: This document

URN Sub-Namespace Registration: urn:air IANA is requested to register the formal URN sub-namespace air within the IETF URN registry adhering to :

• Namespace ID: air (Agentic Information Resource)
• Structure: urn:air:<publisher>:<namespace>:<agent-name>
• Specification: This document

References Normative References JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. 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 document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. 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. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. 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. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. 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. Informative References 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. W3C IETF Anthropic Linux Foundation OpenAPI Initiative OpenSSF Google Ericsson Ericsson Ericsson Google Ericsson Ericsson Ericsson Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.

Acknowledgments The authors would like to thank Eric Rescorla, Jari Arkko, Mirja Kühlewind, Warren Kumari, Wes Hardaker, Luca Muscariello, Darrel Miller, and Jonathan Hefner for their valuable architectural reviews, security feedback, and interoperability discussions.