Independent Submission C. Hood Internet-Draft Nomotic, Inc. Intended status: Informational 18 June 2026 Expires: 20 December 2026 ARD Binding for AGTP: Agentic Resource Discovery over the Agent Transfer Protocol draft-hood-agtp-ard-00 Abstract The Agentic Resource Discovery (ARD) specification defines a federated, domain-anchored model for cataloging, discovering, and searching agentic resources across organizational boundaries. ARD is artifact-protocol-agnostic: it advertises capabilities and trust metadata, then steps out of the way to let agents connect over each artifact's native protocol. This document specifies how the Agent Transfer Protocol (AGTP) composes with ARD. It defines an AGTP catalog entry type for ARD manifests, the agtp:// endpoint URI as a valid runtime connection target, the composition of AGTP's wire-level identity model with the ARD trustManifest object, and an AGTP-native binding for publishing and consuming ARD catalogs over the AGTP substrate rather than HTTPS. The result is a clean composition. ARD operates at the application layer and answers the discovery question: where is the capability, can it be trusted before connection. AGTP operates at the transport substrate beneath application-layer protocols (MCP, A2A, API, and others ARD catalogs) and carries structural identity, authority scope, and attribution at the wire. ARD and the application protocols it catalogs can run over AGTP as substrate, the same way they currently run over HTTP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Hood Expires 20 December 2026 [Page 1] Internet-Draft AGTP-ARD June 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. AGTP Catalog Entry . . . . . . . . . . . . . . . . . . . . . 5 3.1. Framing . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. URI Structure for Discovery and Resources . . . . . . . . 6 3.2.1. Agent and Organization Addressing . . . . . . . . . . 6 3.2.2. Substrate-Native Resource Paths . . . . . . . . . . . 6 3.2.3. Well-Known Paths as a Transport-Symmetric Option . . 7 3.2.4. Registry Search Endpoints . . . . . . . . . . . . . . 8 3.2.5. Access Patterns Summary . . . . . . . . . . . . . . . 8 3.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Entry Schema . . . . . . . . . . . . . . . . . . . . . . 9 3.4.1. Required Fields . . . . . . . . . . . . . . . . . . . 10 3.4.2. Endpoint Object . . . . . . . . . . . . . . . . . . . 10 3.4.3. Optional Fields . . . . . . . . . . . . . . . . . . . 11 3.5. Example Catalog Entry . . . . . . . . . . . . . . . . . . 11 4. Trust Composition . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Identity Composition . . . . . . . . . . . . . . . . . . 12 4.2. Attestation Composition . . . . . . . . . . . . . . . . . 13 4.3. Provenance and Signature . . . . . . . . . . . . . . . . 14 5. Runtime Connection . . . . . . . . . . . . . . . . . . . . . 14 5.1. Pattern 1: AGTP-Native Methods . . . . . . . . . . . . . 14 5.2. Pattern 2: Application-Layer Protocol over AGTP . . . . . 15 5.3. Discovery-Runtime Boundary . . . . . . . . . . . . . . . 15 6. ARD over AGTP . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Catalog Manifest Publication . . . . . . . . . . . . . . 16 6.2. Wire-Level Context . . . . . . . . . . . . . . . . . . . 16 Hood Expires 20 December 2026 [Page 2] Internet-Draft AGTP-ARD June 2026 6.3. Registry Search API over AGTP . . . . . . . . . . . . . . 17 6.4. Federation Across HTTPS and AGTP . . . . . . . . . . . . 17 7. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8.1. Trust Domain Alignment . . . . . . . . . . . . . . . . . 19 8.2. Discovery vs Runtime Separation . . . . . . . . . . . . . 19 8.3. Wire-Level Context Disclosure . . . . . . . . . . . . . . 19 8.4. ARD Catalog Tampering . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.1. Media Type Registration . . . . . . . . . . . . . . . . . 20 9.2. ALPN Protocol ID Registration . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 23 Appendix B. Changes from -00 . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The Agentic Resource Discovery (ARD) specification [ARD] defines how agentic resources are cataloged, discovered, and searched across federated networks. ARD is built on three architectural commitments worth restating here, because they motivate this binding: 1. ARD is artifact-protocol-agnostic. The catalog uses an IANA media type field to identify artifact types (MCP servers, A2A agent cards, OpenAPI tools, others) without defining how those artifacts are accessed at runtime. 2. ARD delegates authentication to the artifact protocol. Discovery metadata is decoupled from the security and identity primitives the runtime connection uses. 3. ARD is designed for federation. Domain-anchored URN identifiers, trust metadata sufficient for cross-organizational verification, and a mandatory HTTP REST search interface enable interoperability across independently operated registries. The Agent Transfer Protocol (AGTP) [AGTP] defines a dedicated transport substrate for agent traffic. AGTP carries Canonical Agent- ID, Owner-ID, Authority-Scope, and Attribution-Records as wire-level facts on every request and response, operating on IANA-registered port 4480 with the agtp:// URI scheme. Application-layer protocols including MCP, A2A, and HTTP-based APIs run over AGTP as substrate the same way they currently run over HTTP. Hood Expires 20 December 2026 [Page 3] Internet-Draft AGTP-ARD June 2026 ARD and AGTP occupy different architectural layers and compose cleanly: * ARD operates at the application layer. It answers: where does the capability live, and can the publisher be trusted before I connect? * AGTP operates at the transport substrate beneath the application- layer protocols ARD catalogs. It answers: how does my agent's identity, authority, and attribution travel to the discovered endpoint structurally during the runtime connection? This specification defines two surfaces of the composition: * AGTP-speaking endpoints can be advertised in ARD catalogs as a distinct entry type, because ARD identifies entries by media type and requires a media type per entry. This is an ARD cataloging convention, not a claim that AGTP is peer to the application-layer protocols also cataloged. * ARD catalogs and registry APIs *MAY* be published and consumed over AGTP as the transport substrate, in addition to or in place of HTTPS. This is the substrate composition: ARD itself running over AGTP rather than over HTTP. This document does not modify ARD or AGTP. It defines composition only. Implementations conforming to this specification remain conforming to both [ARD] and [AGTP]. 1.1. Terminology The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses terminology from [ARD], [AGTP], [AGTP-IDENTIFIERS], and [AGTP-TRUST]. Selected terms relevant to the binding: Catalog entry: An object in the ARD entries array describing a single agentic resource, as defined in [ARD] §4.2. Trust manifest: The optional ARD object carrying identity binding, compliance attestations, provenance, and cryptographic signatures, as defined in [ARD] §5. Hood Expires 20 December 2026 [Page 4] Internet-Draft AGTP-ARD June 2026 Canonical Agent-ID: The 256-bit hash of an Agent Genesis document that uniquely identifies an AGTP-speaking agent, as defined in [AGTP-IDENTIFIERS]. AGTP endpoint: A network endpoint addressable via the agtp:// URI scheme that accepts AGTP wire-format requests on the AGTP- registered port (4480). 2. Scope This document specifies four composition surfaces: 1. An ARD catalog entry type for AGTP-speaking agents, with associated media type and entry semantics (Section 3). 2. How AGTP's identity and certificate model composes with the ARD trustManifest object (Section 4). 3. How an AGTP-speaking agent fulfills runtime connection from an ARD-discovered endpoint (Section 5). 4. How ARD catalogs *MAY* be published and consumed over AGTP as the transport, in addition to or in place of HTTPS (Section 6). This document does not modify ARD or AGTP. It defines composition only. Implementations conforming to this specification remain conforming to both [ARD] and [AGTP]. 3. AGTP Catalog Entry 3.1. Framing ARD requires every catalog entry to carry an IANA media type identifying the artifact's type ([ARD] §3.3, §4.2). This is a cataloging convention that allows ARD registries to index heterogeneous artifacts uniformly. ARD's catalog entries currently include application-layer protocols such as MCP servers (application/ mcp-server+json), A2A agent cards (application/a2a-agent-card+json), OpenAPI tools, and others. This document defines a media type for AGTP-speaking endpoints so that they can be advertised in ARD catalogs alongside the other entries publishers expose. This is an ARD cataloging requirement, not a claim that AGTP is peer to the application-layer protocols also cataloged. AGTP is a transport substrate beneath the application- layer protocols ARD catalogs (see the Introduction); the catalog entry type defined here identifies endpoints reachable via the AGTP substrate. Hood Expires 20 December 2026 [Page 5] Internet-Draft AGTP-ARD June 2026 3.2. URI Structure for Discovery and Resources AGTP defines the agtp:// URI scheme in [AGTP]. This binding uses that scheme for two distinct purposes that implementers should understand explicitly: addressing an agent (or organization) for runtime invocation, and addressing discovery resources (catalogs, registries, capability documents) over the AGTP substrate. The following URI patterns are normative for this binding. 3.2.1. Agent and Organization Addressing An AGTP-speaking endpoint *MAY* be addressed by either of two authority forms, both defined in [AGTP]: *Canonical Agent-ID form.* The authority is the 256-bit Canonical Agent-ID expressed as lower-case hex, addressing one specific agent: agtp://5f3a8d2e9b1c4f6a8d2e9b1c4f6a8d2e9b1c4f6a8d2e9b1c4f6a8d2e9b1c4f6a *Domain-anchored form.* The authority is an FQDN or IPv4/IPv6 address, optionally with a port, addressing an organization's AGTP endpoint: agtp://agent.acme.com agtp://agent.acme.com:4480 Both forms accept the same path conventions defined in this section. The canonical form is preferred when an agent's identity is known and stable. The domain-anchored form is preferred for discovery, registry operations, and organization-level addressing. 3.2.2. Substrate-Native Resource Paths AGTP-speaking endpoints expose discovery and capability resources directly at substrate-native paths. The path syntax follows the AGTP request line grammar defined in [AGTP] §5.1, with path and query parsed as separate tokens. The primary patterns are: Hood Expires 20 December 2026 [Page 6] Internet-Draft AGTP-ARD June 2026 +============================================+======================+ | URI Pattern | Purpose | +============================================+======================+ | agtp:///catalog | ARD catalog | | | manifest for the | | | publisher | +--------------------------------------------+----------------------+ | agtp:///discover | DISCOVER endpoint | | | for capability | | | queries | +--------------------------------------------+----------------------+ | agtp:///resources | Capability | | | listing for the | | | agent | +--------------------------------------------+----------------------+ | agtp:///resources/ | A specific named | | | resource | +--------------------------------------------+----------------------+ | agtp:///cert | The AGTP-CERT | | | certificate | +--------------------------------------------+----------------------+ | agtp:///genesis | The Agent Genesis | | | document | +--------------------------------------------+----------------------+ Table 1 These patterns are substrate-native: the path is addressed directly over AGTP rather than borrowed from HTTP conventions. The catalog at agtp://agents.acme.com/catalog and the discovery endpoint at agtp://mcp.acme.com/discover are typical examples. Resource path conventions are not exhaustive. Publishers *MAY* define their own path structures. Discovery clients *SHOULD* rely on the catalog or DISCOVER response to learn the available resource paths rather than guessing them by convention. 3.2.3. Well-Known Paths as a Transport-Symmetric Option For deployments where the same catalog content is served over both HTTPS and AGTP, publishers *MAY* also expose discovery resources at well-known paths per [RFC8615]. This produces transport-symmetric URIs: Hood Expires 20 December 2026 [Page 7] Internet-Draft AGTP-ARD June 2026 +=========================+========================+ | HTTPS Path | AGTP Path | +=========================+========================+ | https://acme.com/.well- | agtp://acme.com/.well- | | known/ai-catalog.json | known/ai-catalog.json | +-------------------------+------------------------+ Table 2 The well-known path is an optional convention for publishers who want the same path semantics across HTTP and AGTP. It is not the primary substrate-native pattern. Substrate-native publishers *SHOULD* prefer direct paths (/catalog, /discover) which align with the AGTP method vocabulary and avoid carrying HTTP convention baggage into the substrate. 3.2.4. Registry Search Endpoints ARD registries operating over AGTP expose search and explore endpoints at: agtp:///search agtp:///explore agtp:///agents These paths mirror the ARD REST endpoint paths (POST /search, POST /explore, GET /agents) defined in [ARD] §7, allowing a registry to expose the same search API over both HTTPS and AGTP transports. 3.2.5. Access Patterns Summary Three primary access patterns emerge from these URI conventions: *Pattern A: Direct catalog fetch over AGTP* DISCOVER agtp://agents.acme.com/catalog AGTP/1.0 Agent-ID: Owner-ID: Authority-Scope: discovery:read Returns: application/ai-catalog+json (the ARD catalog manifest). *Pattern B: Direct agent description fetch over AGTP* DESCRIBE agtp://5f3a8d2e9b1c4f6a... AGTP/1.0 Agent-ID: Owner-ID: Authority-Scope: discovery:read Hood Expires 20 December 2026 [Page 8] Internet-Draft AGTP-ARD June 2026 Returns: application/agtp-agent+json (the AGTP agent document). *Pattern C: Registry search over AGTP* DISCOVER agtp://registry.example.com/search AGTP/1.0 Agent-ID: Owner-ID: Authority-Scope: discovery:search Content-Type: application/ard-search-query+json { "query": { "text": "find me a flight booking agent" } } Returns: the ARD search response schema defined in [ARD] §7.2. All three patterns carry wire-level Agent-ID, Owner-ID, and Authority-Scope on the request, so the responding endpoint can apply context-aware policy without reconstructing identity from session state or application-layer headers. 3.3. Media Type AGTP-speaking endpoints are advertised in ARD catalogs using the media type: application/agtp-agent+json The media type SHALL be registered with IANA as specified in Section 9.1. A catalog entry of type application/agtp-agent+json describes an endpoint that accepts incoming requests over the AGTP substrate at one or more agtp:// URIs. 3.4. Entry Schema An AGTP catalog entry conforms to the structure defined in [ARD] §4.2, with the AGTP-specific document structure delivered via the url or data field. The artifact document conforms to the schema in this section. The minimal AGTP agent document contains: Hood Expires 20 December 2026 [Page 9] Internet-Draft AGTP-ARD June 2026 { "specVersion": "1.0", "agentId": "5f3a8d2e9b1c4f6a8d2e9b1c4f6a8d2e9b1c4f6a8d2e9b1c4f6a8d2e9b1c4f6a", "ownerId": "urn:agtp:owner:acme.com", "endpoints": [ { "uri": "agtp://agent.acme.com:4480", "transport": "tcp-tls" } ], "supportedMethods": [ "QUERY", "DISCOVER", "DESCRIBE", "PROPOSE", "EXECUTE", "DELEGATE", "NEGOTIATE" ], "supportedScopes": [ "calendar:read", "calendar:write", "booking:purchase" ], "trustTier": 1, "verificationPath": "dns-anchored" } 3.4.1. Required Fields agentId: *REQUIRED*. The Canonical Agent-ID of the agent as a 256-bit lower-case hex-encoded SHA-256 hash, per [AGTP-IDENTIFIERS]. ownerId: *REQUIRED*. The Owner-ID of the principal accountable for the agent's existence, per [AGTP-IDENTIFIERS]. endpoints: *REQUIRED*. A non-empty array of endpoint objects describing the agtp:// URIs where the agent accepts incoming requests. 3.4.2. Endpoint Object Each endpoint in the endpoints array contains: uri: *REQUIRED*. An agtp:// URI conforming to the URI structure defined in [AGTP]. The URI *MAY* address the agent by Canonical Agent-ID (agtp://<256-bit-hex-id>) or by domain-anchored authority (agtp://[:port]). transport: *OPTIONAL*. A transport binding identifier (tcp-tls, quic, or a value registered in the AGTP Transport Bindings registry). If omitted, the agent supports the AGTP default transport requirements per [AGTP]. Hood Expires 20 December 2026 [Page 10] Internet-Draft AGTP-ARD June 2026 priority: *OPTIONAL*. An integer priority for endpoint selection when multiple endpoints are listed (lower is higher priority). Default is 0 (equal priority). 3.4.3. Optional Fields supportedMethods: *OPTIONAL*. An array of AGTP method names the agent accepts. Useful for discovery clients narrowing their search. If absent, clients *SHOULD* assume the agent supports the AGTP floor methods defined in [AGTP]. supportedScopes: *OPTIONAL*. An array of Authority-Scope tokens the agent is prepared to operate under. Clients *MAY* filter discovery results by required scopes. trustTier: *OPTIONAL*. The AGTP trust tier of the agent, per [AGTP-TRUST]. Valid values: 0 (development), 1 (verified), 2 (federated). verificationPath: *OPTIONAL*. The verification path applicable to this agent, per [AGTP-TRUST]. Valid values: dns-anchored, log- anchored, hybrid, self-signed, web3-bridge. capabilities: *OPTIONAL*. An array of capability descriptors as defined in [ARD] §4.2. The semantics are unchanged from ARD: capabilities are strings representing specific skills or tools the agent provides. 3.5. Example Catalog Entry A full ARD catalog entry advertising an AGTP-speaking agent: Hood Expires 20 December 2026 [Page 11] Internet-Draft AGTP-ARD June 2026 { "identifier": "urn:ai:acme.com:agent:travel-concierge", "displayName": "Travel Concierge", "type": "application/agtp-agent+json", "url": "agtp://agents.acme.com/travel-concierge", "description": "AI-powered travel planning and booking agent.", "tags": ["travel", "booking", "concierge"], "capabilities": ["FlightBooking", "HotelBooking", "ItineraryPlanning"], "representativeQueries": [ "book me a flight to Tokyo next Tuesday", "find a hotel near the conference venue" ], "trustManifest": { "identity": "agtp://agents.acme.com/travel-concierge", "identityType": "agtp", "attestations": [ { "type": "AGTP-CERT", "uri": "agtp://agents.acme.com/travel-concierge/cert" }, { "type": "SOC2-Type2", "uri": "https://trust.acme.com/reports/soc2.pdf" } ] } } 4. Trust Composition ARD defines a trustManifest object that carries identity binding, attestations, provenance, and signatures separately from the artifact document. AGTP defines its own identity and certificate model in [AGTP-IDENTIFIERS], [AGTP-TRUST], and [AGTP-CERT]. This section specifies how the two compose. 4.1. Identity Composition The ARD trustManifest.identity field accepts a globally unique cryptographic workload identifier ([ARD] §5.1). For AGTP-speaking agents, the identity field *MAY* carry an agtp:// URI as the workload identifier: "trustManifest": { "identity": "agtp://acme.com/agents/travel-concierge", "identityType": "agtp" } Hood Expires 20 December 2026 [Page 12] Internet-Draft AGTP-ARD June 2026 The identityType value agtp indicates the identity is an AGTP URI resolving to a Canonical Agent-ID per [AGTP-IDENTIFIERS]. When identityType is agtp, the cross-reference between the URN identifier and the cryptographic identity is verified by: 1. Resolving the agtp:// URI to a Canonical Agent-ID per [AGTP]. 2. Verifying the Agent Genesis document signature against the issuing authority's key chain. 3. Checking that the authority domain in the discovery URN identifier ( segment of urn:ai::...) matches the authority encoded in the AGTP URI or the Agent Genesis. Implementations *MAY* alternatively use did:web or spiffe identifiers in the trustManifest.identity field where AGTP composes with existing decentralized identity or workload identity systems. The AGTP identity remains the wire-level fact carried on every request; the ARD identity is the discovery-level binding. 4.2. Attestation Composition ARD allows a trustManifest.attestations array of arbitrary attestation types ([ARD] §5.2). AGTP-speaking agents *MAY* include an attestation of type AGTP-CERT referencing the agent's certificate per [AGTP-CERT]: { "type": "AGTP-CERT", "uri": "agtp://agents.acme.com/travel-concierge/cert" } The attestation uri *SHOULD* be an agtp:// URI addressing the certificate directly over the substrate. An https:// URL *MAY* also be used where the publisher needs the certificate to be fetchable by ARD clients operating over HTTP. The referenced document *MUST* be an AGTP-CERT certificate per [AGTP-CERT]. Other attestation types (compliance certifications, SBOMs, third- party audits) compose without modification. Hood Expires 20 December 2026 [Page 13] Internet-Draft AGTP-ARD June 2026 4.3. Provenance and Signature AGTP attribution records carry runtime delegation chain information at the wire (per [AGTP-IDENTIFIERS]). ARD provenance describes publication-time lineage. The two address different temporal layers and *MUST NOT* be conflated: * ARD trustManifest.provenance records how a catalog entry was derived or published (e.g., from a parent catalog, from a source repository). * AGTP Attribution-Records on responses record who acted, on whose behalf, with what authority, at the moment of the request. Both *MAY* be present in a deployment. Verifiers consuming both should treat them as complementary records of different events, not as redundant. ARD trustManifest.signature carries a JWS signature over the trust manifest content. AGTP-CERT carries its own signature chain through X.509 v3. These signatures verify different artifacts and *MUST* both be validated independently when both are present. 5. Runtime Connection ARD explicitly steps out of the way once trust metadata has been delivered to the discovery client ([ARD] §1). The client then establishes a direct connection using the artifact's native protocol. For endpoints discovered as application/agtp-agent+json entries, the runtime connection uses the AGTP substrate. Two patterns are possible and both are covered by this binding: 5.1. Pattern 1: AGTP-Native Methods The discovered endpoint exposes AGTP-native methods (QUERY, DISCOVER, DESCRIBE, EXECUTE, DELEGATE, PROPOSE, etc.) as defined in [AGTP]. The client invokes these methods directly over the AGTP substrate. This is the AGTP-native runtime case. Connection proceeds as follows: 1. The client selects an endpoint from the endpoints array of the AGTP agent document. If multiple endpoints are present, selection *SHOULD* prefer lower-priority values. 2. The client opens an AGTP connection to the selected endpoint per [AGTP], with TLS 1.3 or higher. Hood Expires 20 December 2026 [Page 14] Internet-Draft AGTP-ARD June 2026 3. The client presents its own Agent-ID, Owner-ID, and Authority- Scope headers per [AGTP]. Where ARD trust metadata indicated AGTP-CERT verification, the client *SHOULD* verify the server's certificate chain against the AGTP-CERT attestation retrieved during discovery. 4. The client issues AGTP methods per [AGTP]. 5.2. Pattern 2: Application-Layer Protocol over AGTP The discovered endpoint exposes an application-layer protocol (MCP, A2A, or another) that runs over AGTP as substrate rather than over HTTP. In this pattern, the catalog entry *MAY* carry an additional ARD entry type identifying the application protocol (e.g., application/mcp-server+json), with the endpoint URI in agtp:// form indicating that the application protocol runs over the AGTP substrate. Connection proceeds as follows: 1. The client opens an AGTP connection to the endpoint per [AGTP]. 2. The client and endpoint negotiate the application-layer protocol (MCP, A2A, etc.) over the established AGTP substrate. 3. AGTP carries wire-level identity, scope, and attribution for every request, regardless of the application-layer protocol semantics being exchanged on top. This pattern is the substrate composition: existing application-layer protocols gain wire-level identity, scope, and attribution by running over AGTP without requiring changes to their own semantics. 5.3. Discovery-Runtime Boundary The discovery handoff is the boundary between ARD and the runtime protocols. After connection establishment, ARD plays no further role. The application-layer protocol semantics and the substrate- level wire context are carried independently and compose without coordination through the discovery layer. 6. ARD over AGTP This section specifies how ARD catalog manifests and registry search APIs *MAY* be published and consumed over AGTP as the transport, rather than HTTPS. Hood Expires 20 December 2026 [Page 15] Internet-Draft AGTP-ARD June 2026 This is OPTIONAL behavior. Publishers conforming to [ARD] *MAY* continue to publish solely over HTTPS as the universal baseline. The AGTP transport binding is provided for environments where AGTP- speaking agents prefer AGTP-native discovery, where wire-level identity context during catalog fetching is desired, or where AGTP is the dominant substrate in the deployment. 6.1. Catalog Manifest Publication An AGTP-speaking publisher *SHOULD* make its ARD catalog manifest available at a substrate-native path under its AGTP authority: agtp:///catalog Where is either the Canonical Agent-ID of the publishing agent (agtp://<256-bit-hex-id>/catalog) or a domain-anchored authority (agtp://agents.acme.com/catalog). Publishers *MAY* additionally expose the manifest at the well-known path agtp:///.well-known/ai-catalog.json for transport- symmetric publication with HTTPS deployments. See Section 3.2 for the full URI pattern reference. When fetched over AGTP, the catalog manifest is returned as the response body to an AGTP DISCOVER method per [AGTP-DISCOVERY], with media type application/ai-catalog+json per [AI-CATALOG]. 6.2. Wire-Level Context A significant property of publishing ARD catalogs over AGTP is that the fetching request carries Agent-ID, Owner-ID, Authority-Scope, and optional Principal-ID at the wire. The publishing endpoint *MAY* use this context to: * Return different catalog views to different agent identity classes (e.g., exposing internal agents only to clients with verified organizational identity). * Apply rate limits or access policies based on the fetching agent's attribution. * Record structural attribution for catalog access in AGTP-LOG per the audit log infrastructure. These behaviors are deployment policy decisions, not protocol- mandated behaviors. The catalog content returned *MUST* conform to the ARD schema in [ARD] regardless of which context-aware decisions the publisher applies. Hood Expires 20 December 2026 [Page 16] Internet-Draft AGTP-ARD June 2026 6.3. Registry Search API over AGTP ARD mandates a REST search interface (POST /search, POST /explore, optional GET /agents) at the registry endpoint ([ARD] §7). The mandate is to ensure universal interoperability; it does not prohibit additional protocol wrappers. An AGTP-speaking registry *MAY* additionally expose its search capability via the AGTP DISCOVER method: DISCOVER agtp://registry.example.com:4480/search AGTP/1.0 Agent-ID: Owner-ID: Authority-Scope: discovery:search Content-Type: application/ard-search-query+json { "query": { "text": "find me a flight booking agent", "filter": { "type": ["application/agtp-agent+json"] } }, "federation": "referrals", "pageSize": 5 } The response body *MUST* conform to the ARD search response schema in [ARD] §7.2. The AGTP transport binding adds wire-level identity, scope, and attribution context to the request without altering the search semantics. This is consistent with [ARD] §7.3 (Protocol Wrappers), which permits registries to expose search capability via additional protocol wrappers beyond the REST baseline, provided the catalog entry format is preserved. 6.4. Federation Across HTTPS and AGTP A registry indexing catalogs from both HTTPS and AGTP publishers *MUST* treat the entries uniformly. The catalog schema is identical regardless of transport; only the publication and consumption paths differ. Hood Expires 20 December 2026 [Page 17] Internet-Draft AGTP-ARD June 2026 When a registry returns search results that include endpoints reachable via both HTTPS and AGTP, the catalog entries themselves remain unchanged. The endpoints field of an AGTP agent document lists the AGTP endpoints; the url field of the catalog entry points to where the agent document is retrieved (which may be HTTPS or AGTP). 7. Discovery Mechanisms ARD lists four discovery mechanisms in §6.1: well-known URI, agentmap directive, HTML link tag, and DNS Service Binding records. This binding adds AGTP-native DISCOVER as the substrate-native mechanism for AGTP-speaking clients: * *AGTP DISCOVER Method (primary)*: A client invokes the DISCOVER method on a known agent or registry endpoint, retrieving capability information in ARD catalog format or any other discovery payload the endpoint exposes. The DISCOVER method works against direct paths (agtp://agents.acme.com/catalog, agtp://mcp.acme.com/discover) and is the primary substrate-native discovery mechanism. Specified in [AGTP-DISCOVERY]. * *Substrate-Native Direct Paths*: Discovery resources addressed directly under the AGTP authority, as defined in Section 3.2. Primary patterns include agtp:///catalog and agtp:///discover. * *Well-Known URI over AGTP*: Hosting the manifest at agtp:///.well-known/ai-catalog.json for transport- symmetric publication with HTTPS deployments, as specified in Section 6. This is an optional convention, not the primary substrate-native pattern. * *DNS-AID Compatibility*: ARD references DNS-AID [DNS-AID] as a federated routing mechanism (§7.2.1). DNS-AID SVCB records *MAY* point to AGTP endpoints using the agtp ALPN identifier (subject to ALPN registration; see Section 9.2). 8. Security Considerations The security considerations of [ARD] and [AGTP] apply to this binding without modification. This section addresses considerations specific to the composition. Hood Expires 20 December 2026 [Page 18] Internet-Draft AGTP-ARD June 2026 8.1. Trust Domain Alignment ARD §5.1 requires that the cryptographic trust domain in trustManifest.identity align with the authority domain root embedded in the discovery identifier namespace. For AGTP-speaking agents using the agtp identity type, implementations *MUST* verify that: 1. The segment of the catalog entry's URN identifier (urn:ai::...) corresponds to the authority domain resolvable from the AGTP URI in trustManifest.identity. 2. The Agent Genesis document referenced by the resolved Canonical Agent-ID is signed by an authority that controls the publisher domain. Failure to verify trust domain alignment *MUST* result in the catalog entry being rejected as unverifiable. 8.2. Discovery vs Runtime Separation ARD explicitly delegates authentication to the artifact protocol. AGTP authentication occurs at runtime, not during discovery. Implementations *MUST NOT* rely on ARD-discovered trust metadata as a substitute for runtime AGTP identity verification. Specifically: * ARD trust metadata indicates what verification is possible at runtime. * The runtime AGTP connection performs the actual verification. * A client trusting an ARD catalog entry without performing runtime AGTP verification has not satisfied AGTP's trust requirements. 8.3. Wire-Level Context Disclosure Publishing ARD catalogs over AGTP exposes the fetching agent's Agent- ID, Owner-ID, and Authority-Scope to the publishing endpoint. This is the same disclosure that occurs for any AGTP request and is not unique to catalog access. Publishers receiving catalog fetches over AGTP *MUST* treat the wire-level context per their normal AGTP privacy and logging policies. Hood Expires 20 December 2026 [Page 19] Internet-Draft AGTP-ARD June 2026 8.4. ARD Catalog Tampering ARD catalogs published over AGTP benefit from AGTP's transport encryption (TLS 1.3) and optional Attribution-Records on responses. Catalog content tampering at intermediaries is structurally prevented by AGTP's TLS 1.3 mandatory requirement, the same way ARD over HTTPS prevents tampering through TLS. 9. IANA Considerations 9.1. Media Type Registration This document requests IANA to register the following media type in the "Media Types" registry: * Name: agtp-agent+json * Type name: application * Subtype name: agtp-agent+json * Required parameters: none * Optional parameters: none * Encoding considerations: 8bit; JSON content is UTF-8 encoded * Security considerations: See Security Considerations of this document * Interoperability considerations: This media type identifies AGTP agent documents in ARD catalogs. Consumers must conform to [ARD] catalog entry semantics and [AGTP] runtime semantics. * Published specification: This document * Applications that use this media type: ARD catalog publishers and consumers, ARD registries, AGTP-speaking agents * Person and email address to contact for further information: Chris Hood chris@nomotic.ai (mailto:chris@nomotic.ai) * Intended usage: COMMON * Restrictions on usage: none * Author: Chris Hood Hood Expires 20 December 2026 [Page 20] Internet-Draft AGTP-ARD June 2026 * Change controller: IETF 9.2. ALPN Protocol ID Registration This document requests IANA to register the following ALPN Protocol ID in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry: * Protocol: Agent Transfer Protocol * Identification Sequence: agtp (0x61 0x67 0x74 0x70) * Reference: This document and [AGTP] This ALPN identifier permits AGTP endpoints to be advertised in TLS connection negotiation and in DNS-AID [DNS-AID] SVCB records. 10. References 10.1. Normative References [AGTP] Hood, C., "Agent Transfer Protocol (AGTP)", Work in Progress, Internet-Draft, draft-hood-independent-agtp-08, 25 May 2026, . [AGTP-CERT] Hood, C., "AGTP Agent Certificate Extension", Work in Progress, Internet-Draft, draft-hood-agtp-agent-cert-02, 1 June 2026, . [AGTP-DISCOVERY] Hood, C., "AGTP Agent Discovery and Name Service", Work in Progress, Internet-Draft, draft-hood-agtp-discovery-00, 23 March 2026, . [AGTP-IDENTIFIERS] Hood, C., "AGTP Identifier Chain", Work in Progress, Internet-Draft, draft-hood-agtp-identifiers-02, 1 June 2026, . Hood Expires 20 December 2026 [Page 21] Internet-Draft AGTP-ARD June 2026 [AGTP-TRUST] Hood, C., "AGTP Trust and Verification Specification", Work in Progress, Internet-Draft, draft-hood-agtp-trust- 01, 25 May 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [RFC9943] "*** BROKEN REFERENCE ***". 10.2. Informative References [AI-CATALOG] "AI Catalog Specification", n.d., . [ARD] Bu, J., R.V.Guha, and S. Smith, "Agentic Resource Discovery Specification", 28 May 2026, . [DID] "Decentralized Identifiers (DIDs) v1.0", n.d., . [DNS-AID] "DNS for AI Discovery", n.d., . [SPIFFE] "SPIFFE - Secure Production Identity Framework for Everyone", n.d., . Hood Expires 20 December 2026 [Page 22] Internet-Draft AGTP-ARD June 2026 Appendix A. Acknowledgements The author thanks the ARD specification authors and contributors, particularly Junjie Bu, R.V.Guha, Shaun Smith, and the broader AI Catalog working group whose work this binding builds upon. The composition between application-layer discovery and substrate-level transport that this document specifies is only possible because ARD was designed as a clean, artifact-protocol-agnostic discovery layer from the outset. The author also thanks Scott Courtney and the DNS-AID authors whose parallel work on DNS-based agent discovery informs the discovery mechanisms section. Appendix B. Changes from -00 Initial version. Author's Address Chris Hood Nomotic, Inc. Email: chris@nomotic.ai Hood Expires 20 December 2026 [Page 23]