ARD Binding for AGTP: Agentic Resource Discovery over the Agent Transfer Protocol
draft-hood-agtp-ard-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Chris Hood | ||
| Last updated | 2026-06-17 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hood-agtp-ard-00
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://<authority>/catalog | ARD catalog |
| | manifest for the |
| | publisher |
+--------------------------------------------+----------------------+
| agtp://<authority>/discover | DISCOVER endpoint |
| | for capability |
| | queries |
+--------------------------------------------+----------------------+
| agtp://<authority>/resources | Capability |
| | listing for the |
| | agent |
+--------------------------------------------+----------------------+
| agtp://<authority>/resources/<resource-id> | A specific named |
| | resource |
+--------------------------------------------+----------------------+
| agtp://<authority>/cert | The AGTP-CERT |
| | certificate |
+--------------------------------------------+----------------------+
| agtp://<authority>/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://<registry-authority>/search
agtp://<registry-authority>/explore
agtp://<registry-authority>/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: <client-agent-id>
Owner-ID: <client-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: <client-agent-id>
Owner-ID: <client-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: <client-agent-id>
Owner-ID: <client-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://<fqdn>[: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 (<publisher> segment of urn:ai:<publisher>:...)
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://<authority>/catalog
Where <authority> 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://<authority>/.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: <client-agent-id>
Owner-ID: <client-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://<authority>/catalog and
agtp://<authority>/discover.
* *Well-Known URI over AGTP*: Hosting the manifest at
agtp://<authority>/.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 <publisher> segment of the catalog entry's URN identifier
(urn:ai:<publisher>:...) 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, <https://datatracker.ietf.org/doc/html/draft-
hood-independent-agtp-08>.
[AGTP-CERT]
Hood, C., "AGTP Agent Certificate Extension", Work in
Progress, Internet-Draft, draft-hood-agtp-agent-cert-02, 1
June 2026, <https://datatracker.ietf.org/doc/html/draft-
hood-agtp-agent-cert-02>.
[AGTP-DISCOVERY]
Hood, C., "AGTP Agent Discovery and Name Service", Work in
Progress, Internet-Draft, draft-hood-agtp-discovery-00, 23
March 2026, <https://datatracker.ietf.org/doc/html/draft-
hood-agtp-discovery-00>.
[AGTP-IDENTIFIERS]
Hood, C., "AGTP Identifier Chain", Work in Progress,
Internet-Draft, draft-hood-agtp-identifiers-02, 1 June
2026, <https://datatracker.ietf.org/doc/html/draft-hood-
agtp-identifiers-02>.
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, <https://datatracker.ietf.org/doc/html/
draft-hood-agtp-trust-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/rfc/rfc8141>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
[RFC9943] "*** BROKEN REFERENCE ***".
10.2. Informative References
[AI-CATALOG]
"AI Catalog Specification", n.d.,
<https://github.com/Agent-Card/ai-catalog>.
[ARD] Bu, J., R.V.Guha, and S. Smith, "Agentic Resource
Discovery Specification", 28 May 2026,
<https://github.com/ards-project/ard-spec>.
[DID] "Decentralized Identifiers (DIDs) v1.0", n.d.,
<https://www.w3.org/TR/did-core/>.
[DNS-AID] "DNS for AI Discovery", n.d.,
<https://datatracker.ietf.org/doc/draft-mozleywilliams-
dnsop-dnsaid/>.
[SPIFFE] "SPIFFE - Secure Production Identity Framework for
Everyone", n.d., <https://spiffe.io>.
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]