]> Nomotic, Inc.

chris@nomotic.ai

Applications and Real-Time Independent Submission AI agents agent discovery ARD AGTP federated discovery capability advertisement agent registry 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.

Introduction The Agentic Resource Discovery (ARD) specification 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) 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. 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 and .

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 when, and only when, they appear in all capitals, as shown here. This document uses terminology from , , , and . Selected terms relevant to the binding:

Catalog entry:

An object in the ARD entries array describing a single agentic resource, as defined in §4.2.

Trust manifest:

The optional ARD object carrying identity binding, compliance attestations, provenance, and cryptographic signatures, as defined in §5.

Canonical Agent-ID:

The 256-bit hash of an Agent Genesis document that uniquely identifies an AGTP-speaking agent, as defined in .

AGTP endpoint:

A network endpoint addressable via the agtp:// URI scheme that accepts AGTP wire-format requests on the AGTP-registered port (4480).

Scope This document specifies four composition surfaces:

1. An ARD catalog entry type for AGTP-speaking agents, with associated media type and entry semantics ().
2. How AGTP's identity and certificate model composes with the ARD trustManifest object ().
3. How an AGTP-speaking agent fulfills runtime connection from an ARD-discovered endpoint ().
4. How ARD catalogs MAY be published and consumed over AGTP as the transport, in addition to or in place of HTTPS ().

This document does not modify ARD or AGTP. It defines composition only. Implementations conforming to this specification remain conforming to both and .

AGTP Catalog Entry

Framing ARD requires every catalog entry to carry an IANA media type identifying the artifact's type ( §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.

URI Structure for Discovery and Resources AGTP defines the agtp:// URI scheme in . 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.

Agent and Organization Addressing An AGTP-speaking endpoint MAY be addressed by either of two authority forms, both defined in : Canonical Agent-ID form. The authority is the 256-bit Canonical Agent-ID expressed as lower-case hex, addressing one specific agent: Domain-anchored form. The authority is an FQDN or IPv4/IPv6 address, optionally with a port, addressing an organization's AGTP endpoint: 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.

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 §5.1, with path and query parsed as separate tokens. The primary patterns are:

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

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.

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 . This produces transport-symmetric URIs:

HTTPS Path	AGTP Path
https://acme.com/.well-known/ai-catalog.json	agtp://acme.com/.well-known/ai-catalog.json

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.

Registry Search Endpoints ARD registries operating over AGTP expose search and explore endpoints at: /search agtp:///explore agtp:///agents ]]> These paths mirror the ARD REST endpoint paths (POST /search, POST /explore, GET /agents) defined in §7, allowing a registry to expose the same search API over both HTTPS and AGTP transports.

Access Patterns Summary Three primary access patterns emerge from these URI conventions: Pattern A: Direct catalog fetch over AGTP Owner-ID: Authority-Scope: discovery:read ]]> Returns: application/ai-catalog+json (the ARD catalog manifest). Pattern B: Direct agent description fetch over AGTP Owner-ID: Authority-Scope: discovery:read ]]> Returns: application/agtp-agent+json (the AGTP agent document). Pattern C: Registry search over AGTP 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 §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.

Media Type AGTP-speaking endpoints are advertised in ARD catalogs using the media type: The media type SHALL be registered with IANA as specified in . 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.

Entry Schema An AGTP catalog entry conforms to the structure defined in §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:

Required Fields

agentId:

REQUIRED. The Canonical Agent-ID of the agent as a 256-bit lower-case hex-encoded SHA-256 hash, per .

ownerId:

REQUIRED. The Owner-ID of the principal accountable for the agent's existence, per .

endpoints:

REQUIRED. A non-empty array of endpoint objects describing the agtp:// URIs where the agent accepts incoming requests.

Endpoint Object Each endpoint in the endpoints array contains:

uri:

REQUIRED. An agtp:// URI conforming to the URI structure defined in . 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 .

priority:

OPTIONAL. An integer priority for endpoint selection when multiple endpoints are listed (lower is higher priority). Default is 0 (equal priority).

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 .

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 . Valid values: 0 (development), 1 (verified), 2 (federated).

verificationPath:

OPTIONAL. The verification path applicable to this agent, per . Valid values: dns-anchored, log-anchored, hybrid, self-signed, web3-bridge.

capabilities:

OPTIONAL. An array of capability descriptors as defined in §4.2. The semantics are unchanged from ARD: capabilities are strings representing specific skills or tools the agent provides.

Example Catalog Entry A full ARD catalog entry advertising an AGTP-speaking agent:

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 , , and . This section specifies how the two compose.

Identity Composition The ARD trustManifest.identity field accepts a globally unique cryptographic workload identifier ( §5.1). For AGTP-speaking agents, the identity field MAY carry an agtp:// URI as the workload identifier: The identityType value agtp indicates the identity is an AGTP URI resolving to a Canonical Agent-ID per . 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 .
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.

Attestation Composition ARD allows a trustManifest.attestations array of arbitrary attestation types ( §5.2). AGTP-speaking agents MAY include an attestation of type AGTP-CERT referencing the agent's certificate per : 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 . Other attestation types (compliance certifications, SBOMs, third-party audits) compose without modification.

Provenance and Signature AGTP attribution records carry runtime delegation chain information at the wire (per ). 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.

Runtime Connection ARD explicitly steps out of the way once trust metadata has been delivered to the discovery client ( §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:

Pattern 1: AGTP-Native Methods The discovered endpoint exposes AGTP-native methods (QUERY, DISCOVER, DESCRIBE, EXECUTE, DELEGATE, PROPOSE, etc.) as defined in . 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 , with TLS 1.3 or higher.
3. The client presents its own Agent-ID, Owner-ID, and Authority-Scope headers per . 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 .

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

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.

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. This is OPTIONAL behavior. Publishers conforming to 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.

Catalog Manifest Publication An AGTP-speaking publisher SHOULD make its ARD catalog manifest available at a substrate-native path under its 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 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 , with media type application/ai-catalog+json per .

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 regardless of which context-aware decisions the publisher applies.

Registry Search API over AGTP ARD mandates a REST search interface (POST /search, POST /explore, optional GET /agents) at the registry endpoint ( §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: 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 §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 §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.

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

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 .
• Substrate-Native Direct Paths: Discovery resources addressed directly under the AGTP authority, as defined in . 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 . This is an optional convention, not the primary substrate-native pattern.
• DNS-AID Compatibility: ARD references 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 ).

Security Considerations The security considerations of and apply to this binding without modification. This section addresses considerations specific to the composition.

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.

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.

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.

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.

IANA Considerations

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 catalog entry semantics and 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

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

This ALPN identifier permits AGTP endpoints to be advertised in TLS connection negotiation and in DNS-AID SVCB records.

References Normative References Nomotic, Inc. AI agents and agentic systems generate a growing volume of intent- driven, unstructured, and undifferentiated traffic that flows through HTTP indistinguishably from human-initiated requests. HTTP lacks the semantic vocabulary, observability primitives, and identity mechanisms required by agent systems operating at scale. Existing protocols described as Agent Group Messaging Protocols (AGMP), including MCP, ACP, A2A, and ANP, are messaging-layer constructs that presuppose HTTP as their transport. They do not address the underlying transport problem. This document defines the Agent Transfer Protocol (AGTP): a dedicated application-layer protocol for AI agent traffic. AGTP is a runtime contract negotiation substrate (RCNS): a transport that fixes only a eighteen-method protocol floor and negotiates any additional method surface at runtime between agent and server in a single round-trip, governed by the AGTP-API companion specification [AGTP-API], which defines the curated method catalog, path grammar, endpoint primitive, and synthesis semantics. Version 07 confirms the IANA-registered agtp:// URI scheme and IANA-assigned port 4480 for TCP/TLS and QUIC, formalizes Form 1a URI grammar (agtp://{agent-id}@{host}) for direct addressing, renames the Agent Manifest Document to the Agent Identity Document with an enumerated schema, redesigns the protocol-defined method floor to a 12-method set organized as six cognitive verbs (QUERY, DISCOVER, DESCRIBE, SUMMARIZE, PLAN, PROPOSE) and six mechanics verbs (EXECUTE, DELEGATE, ESCALATE, CONFIRM, SUSPEND, NOTIFY), establishes AGTP as a substrate for higher-level agent frameworks (MCP, A2A, ACP) carried as content types inside AGTP method invocations, renumbers AGTP-specific status codes out of HTTP- assigned space to avoid semantic collision, mandates explicit Content-Length framing with a prohibition on TLS socket-level half- close, adds a .well-known/agtp bootstrap convention per RFC 8615, deprecates the AGIS reference and the proposed AGTP-Methods specification by folding both into the unified AGTP-API contract layer, adds status codes 405 (Method Not Allowed), 459 (Method Violation), and 460 (Endpoint Violation) per the AGTP-API contract model, and adopts "Agent Genesis" as the canonical term for the permanent signed origin document. Version 06 prepared the IANA Service Name and Port Number application and consolidated the URI scheme registration. Version 05 restored the canonical Agent-ID as the primary identity primitive and decoupled Trust Tier 1 verification from DNS as a sole requirement. A canonical Agent-ID is derived from the agent's Agent Genesis hash and is authoritative in every AGTP protocol operation. Three equivalent verification paths are recognized for Trust Tier 1: DNS-anchored verification via RFC 8555 ACME challenge, log-anchored verification via Agent Genesis inclusion in an append-only transparency log aligned with RFC 9162 and RFC 9943 (SCITT), and hybrid verification combining DNS control with blockchain address ownership. Version 04 introduced normative integration hooks for the AGTP Merchant Identity and Agentic Commerce Binding specification [AGTP-MERCHANT], which defines the merchant- side identity model that complements AGTP's agent-side identity model. AGTP SHOULD prefer QUIC for new implementations and MUST support TCP/TLS for compatibility and fallback. It is designed to be composable with existing agent frameworks, not to replace them. Nomotic, Inc. This document specifies the AGTP identifier chain: a layered model of identifiers that together produce a tamper-evident chain of custody across every action an AGTP agent takes. The chain is composed of identifiers already established in the AGTP draft family (Agent-ID, Owner-ID, Session-ID, Task-ID, and the Attribution-Record envelope of base AGTP) together with a small set of additional identifiers introduced by this document (Request-ID, Response-ID, Action-ID, Evaluation-ID, Decision-ID, Audit-ID). The Audit-ID is the cryptographic hash of an extended Attribution-Record and provides the per-agent hash chain that links every action an agent takes back to its Agent Genesis. This document defines the identifiers, how they extend the existing Attribution-Record envelope, the construction of the hash chain, and the verification procedure by which a regulator, auditor, or counterparty reconstructs the chain end to end. The identifier chain is the regulatory backbone of AGTP. Without it, the protocol can record that something happened but cannot prove who caused it, what authorized it, or what was decided. Nomotic, Inc. This document specifies the AGTP trust and verification model: the trust tiers an AGTP agent may occupy, the verification paths by which a Tier 1 agent's identity is established, the registration procedures by which a governance platform assigns a tier, and the trust score that is carried alongside an agent's identity to express runtime behavioral assessment. AGTP-TRUST is consumed by AGTP-aware infrastructure components (Scope-Enforcement Points, governance gateways, peer agents) for runtime trust-aware routing and authority decisions, and by registration authorities when issuing or evaluating Agent Genesis documents. This is an early working draft; the dimension catalog, computation methodology, and several aspects of the registration procedure are placeholders pending further work. Nomotic, Inc. The Agent Transfer Protocol (AGTP) base specification defines agent identity headers (Agent-ID, Owner-ID, Authority-Scope) that are self- asserted: present on every request and mandatory for logging, but not cryptographically verified at the transport layer. This document specifies the AGTP Agent Certificate Extension: an optional mechanism that binds Agent-ID, Owner-ID, and Authority-Scope to an X.509 v3 certificate presented during TLS mutual authentication. The extension enables infrastructure components including Scope- Enforcement Points (SEPs), load balancers, and governance gateways to verify agent identity and enforce authority scope without application-layer access, at O(1) cost per request header check. The extension also defines session-level revocation propagation via AGTP NOTIFY broadcast and a Certificate Transparency Log for tamper- evident governance metadata. Note: Certain mechanisms described in this document may be subject to pending patent applications by the author. The licensor is prepared to grant a royalty-free license to implementers consistent with the IETF's IPR framework. See the IPR Notice and Section 7. Nomotic, Inc. The Agent Transfer Protocol (AGTP) enables agents to communicate once they know each other's canonical identifiers. It does not define how agents find each other. This document specifies the AGTP Agent Discovery and Name Service (ANS): a protocol for dynamic agent discovery using the AGTP DISCOVER method and a governed Agent Name Service that returns ranked sets of Agent Manifest Documents matching a discovery query. ANS servers act as Scope-Enforcement Points for discovery queries and enforce behavioral trust score thresholds, trust tier requirements, and governance zone constraints. This document also defines the DISCOVER method, the Discovery Query language, and the Agent Name Service registration and lookup protocol. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Informative References n.d. n.d. n.d. n.d.

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.

Changes from -00 Initial version.