ARD Binding for AGTP: Agentic Resource Discovery over the Agent Transfer Protocol

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.¶

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).¶

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.¶

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.¶

agtp://5f3a8d2e9b1c4f6a8d2e9b1c4f6a8d2e9b1c4f6a8d2e9b1c4f6a8d2e9b1c4f6a

agtp://agent.acme.com
agtp://agent.acme.com:4480

agtp://<registry-authority>/search
agtp://<registry-authority>/explore
agtp://<registry-authority>/agents

DISCOVER agtp://agents.acme.com/catalog AGTP/1.0
Agent-ID: <client-agent-id>
Owner-ID: <client-owner-id>
Authority-Scope: discovery:read

DESCRIBE agtp://5f3a8d2e9b1c4f6a... AGTP/1.0
Agent-ID: <client-agent-id>
Owner-ID: <client-owner-id>
Authority-Scope: discovery:read

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" }
}

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:¶

{
  "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.5. Example Catalog Entry

A full ARD catalog entry advertising an AGTP-speaking agent:¶

{
  "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.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"
}

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.¶

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.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.¶

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.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.¶

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.¶

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).¶

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.¶

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.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¶

• Intended usage: COMMON¶

• Restrictions on usage: none¶

• Author: Chris Hood¶

• 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.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>.

[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>.