Independent Submission C. Hood Internet-Draft Nomotic, Inc. Intended status: Informational 30 October 2026 Expires: 3 May 2027 AGTP Transport Bindings: TCP/TLS, QUIC, and HTTP/3 draft-hood-agtp-bindings-01 Abstract The Agent Transfer Protocol (AGTP) is a transfer protocol whose semantics are defined independently of any transport. This document specifies three transport bindings: TCP with TLS 1.3, QUIC, and HTTP/3 (with WebTransport where a browser or an HTTP intermediary is in the path). Each binding defines how AGTP requests and responses are carried, how TLS mutual authentication composes with AGTP identity, and how the transport's connection lifecycle relates to the agent-level session defined in the AGTP session companion, which a connection carries and never is. A central concern for the QUIC binding is replay safety. QUIC supports 0-RTT early data, which is replayable by design. AGTP requests carry authority-scoped actions; a replayed action method could re-trigger authorized work without the requesting agent's intent. This document defines an AGTP-specific replay-safety profile: early data is permitted only for the two safe idempotent methods whose replay has no observable effect (QUERY, DISCOVER), *MUST NOT* be used for action methods (EXECUTE, DELEGATE, PURCHASE, TRANSACT, the lifecycle methods, and the session methods), and always carries the per-request signature that bounds replay of even an eligible method. This document follows the pattern established by HTTP: protocol semantics defined independently of transport ([RFC9110] for HTTP), with transport-specific bindings in separate documents. AGTP semantics are defined in [AGTP]; this document defines the transport mechanics. 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 3 May 2027 [Page 1] Internet-Draft AGTP-BINDINGS October 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 3 May 2027. 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. Why Transport Bindings Are Separate . . . . . . . . . . . 4 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 4 2. AGTP Identity Across the Bindings . . . . . . . . . . . . . . 5 3. TCP/TLS Binding . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. TLS Requirements . . . . . . . . . . . . . . . . . . . . 6 3.3. Connection Establishment . . . . . . . . . . . . . . . . 7 3.4. Request/Response Framing . . . . . . . . . . . . . . . . 7 3.5. Connection Lifecycle and Sessions . . . . . . . . . . . . 8 3.6. Connection Reuse and Pooling . . . . . . . . . . . . . . 8 4. QUIC Binding . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. QUIC Version . . . . . . . . . . . . . . . . . . . . . . 9 4.3. ALPN Identifier . . . . . . . . . . . . . . . . . . . . . 9 4.4. Stream Usage . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Connection Migration . . . . . . . . . . . . . . . . . . 9 4.6. QUIC-Specific Replay Safety Profile . . . . . . . . . . . 10 4.6.1. Methods Eligible for Early Data . . . . . . . . . . . 10 4.6.2. Request Signature in Early Data . . . . . . . . . . . 11 4.6.3. Methods Prohibited from Early Data . . . . . . . . . 11 4.6.4. Server Enforcement . . . . . . . . . . . . . . . . . 12 4.6.5. Client Behavior . . . . . . . . . . . . . . . . . . . 12 4.6.6. Anti-Replay Defense in Depth . . . . . . . . . . . . 12 4.7. Connection Establishment Sequence . . . . . . . . . . . . 13 4.8. Connection Lifecycle and Sessions . . . . . . . . . . . . 13 5. HTTP/3 and WebTransport Binding . . . . . . . . . . . . . . . 13 5.1. Purpose and Status . . . . . . . . . . . . . . . . . . . 14 Hood Expires 3 May 2027 [Page 2] Internet-Draft AGTP-BINDINGS October 2026 5.2. Framing over an HTTP/3 Connection . . . . . . . . . . . . 14 5.3. WebTransport . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Early Data . . . . . . . . . . . . . . . . . . . . . . . 15 5.5. Identity and Intermediaries . . . . . . . . . . . . . . . 15 6. Connection Selection Between Bindings . . . . . . . . . . . . 15 7. Implementation Considerations . . . . . . . . . . . . . . . . 16 7.1. TLS Library Choice . . . . . . . . . . . . . . . . . . . 16 7.2. Certificate Provisioning . . . . . . . . . . . . . . . . 16 7.3. Idle Timeout Tuning . . . . . . . . . . . . . . . . . . . 17 7.4. Connection Multiplexing . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.1. 0-RTT Replay Attack Surface . . . . . . . . . . . . . . . 17 8.2. TLS Downgrade Attacks . . . . . . . . . . . . . . . . . . 18 8.3. QUIC Connection Migration Identity Verification . . . . . 18 8.4. Certificate Validation Across Bindings . . . . . . . . . 18 8.5. Idle Connection and Suspended Session Resource Exhaustion . . . . . . . . . . . . . . . . . . . . . . . 18 8.6. Intermediaries on the HTTP/3 Binding . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9.1. ALPN Identifier . . . . . . . . . . . . . . . . . . . . . 19 9.2. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 19 9.3. Port Assignment . . . . . . . . . . . . . . . . . . . . . 19 10. Engagement Invitation . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix B. Changes from v00 . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The Agent Transfer Protocol [AGTP] is a transfer protocol for AI agent traffic: it defines the semantics of an exchange, and the transport delivers the bytes. The base specification defines AGTP methods, headers, status codes, identity model, and the wire format for requests and responses. The base specification is transport- neutral by design: AGTP semantics are independent of which transport carries them. This document specifies three transport bindings: TCP with TLS 1.3, QUIC, and HTTP/3 with WebTransport. The first two are implemented; the third is specified so that AGTP can be carried where an HTTP intermediary or a browser is in the path, and so that the question raised on the IETF agentproto list, whether HTTP/3 or WebTransport can carry the AGTP session goal, has a written answer. Each binding defines: Hood Expires 3 May 2027 [Page 3] Internet-Draft AGTP-BINDINGS October 2026 * How AGTP requests and responses are framed on the transport. * How the transport's connection lifecycle relates to the agent- level session of [AGTP-SESSION]. * How TLS mutual authentication composes with AGTP identity per [AGTP-CERT]. * Any transport-specific security and operational considerations. Bindings to other transports may be defined in separate documents that follow the same pattern as this one. 1.1. Why Transport Bindings Are Separate The base AGTP specification separates protocol semantics from transport mechanics. This separation has three benefits: *Transport neutrality.* AGTP semantics stay the same when the transport changes. An agent invoking QUERY against another agent operates the same way whether the connection runs over TCP/TLS or QUIC. The base specification can be reviewed and reasoned about without entangling transport-specific concerns. *Independent evolution.* Transport technology evolves on its own timeline. The TCP/TLS binding can be refined as TLS evolves. The QUIC binding can be refined as QUIC evolves. The base AGTP specification has no need to track these changes. *Clear interoperability requirements.* Implementers know that supporting "AGTP" means supporting the base specification plus at least one transport binding. Different implementations may support different bindings (one supports both, another supports only TCP/ TLS); interoperability is determined at the binding boundary. This pattern mirrors HTTP, where semantics live in [RFC9110] and transport-specific bindings live in separate RFCs (HTTP/1.1 in RFC 9112, HTTP/2 in RFC 9113, HTTP/3 in RFC 9114). 1.2. Conventions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Hood Expires 3 May 2027 [Page 4] Internet-Draft AGTP-BINDINGS October 2026 This document uses terminology from [AGTP] and [AGTP-CERT]. Selected additional terms: Transport Binding: A specification defining how AGTP requests and responses are carried over a specific transport. This document defines bindings for TCP/TLS, QUIC, and HTTP/3. Connection: What a transport binding provides: a TCP/TLS connection, a QUIC connection, or an HTTP/3 connection or WebTransport session. A connection has the lifecycle the transport gives it and carries zero or more AGTP sessions. Session: The agent-level context of [AGTP-SESSION], identified by Session-ID, bound to its two participants by a signed session token and to the live sender of every request by Request-Signature ([AGTP]). A session may span several connections over its lifetime and is never identified with any one of them. In this document "session" means this; the transport's own notion (a TLS session or a WebTransport session) is called a connection throughout. Safe Idempotent Method: An AGTP method whose invocation has no observable side effects on agent state and whose repeated invocation produces equivalent results. The safe property is defined in [AGTP-METHODS]; QUERY, DISCOVER, DESCRIBE, INSPECT, SUMMARIZE, and PLAN are safe per [AGTP]. This document admits a narrower set to early data (Section 4.6.1). Action Method: An AGTP method whose invocation produces observable side effects. EXECUTE, DELEGATE, PURCHASE, TRANSACT, ACTIVATE, DEACTIVATE, REVOKE, REINSTATE, DEPRECATE, ESTABLISH, RESUME, TERMINATE, and similar methods are action methods per [AGTP] and [AGTP-SESSION]. Replaying an action method may produce duplicate effects. Early Data: Application data sent before the TLS handshake completes, supported by TLS 1.3 ([RFC8446]) and QUIC ([RFC9001]). Early data is replayable by design; an attacker who captures early data may replay it. 2. AGTP Identity Across the Bindings Every binding carries AGTP identity in two complementary ways: 1. *At the TLS layer* through mutual authentication using AGTP Agent Certificates per [AGTP-CERT], when the agent certificate extension is deployed. Hood Expires 3 May 2027 [Page 5] Internet-Draft AGTP-BINDINGS October 2026 2. *At the AGTP wire layer* through the Agent-ID and Authority-Scope headers and the Request-Signature header carried on every non- anonymous request per [AGTP], with Owner-ID resolved from the Identity Document the Agent-ID references ([AGTP-IDDOC]). The two layers compose. The certificate (when present) provides cryptographic identity at the TLS layer that infrastructure components (load balancers, SEPs, governance gateways) can verify without parsing AGTP headers. The signature provides proof, on every request and on every binding, that the sender holds the agent's current key, so AGTP identity is the same on every binding, with or without a certificate. Both bindings *MUST* verify that AGTP identity headers, when combined with a presented Agent Certificate, are consistent. A mismatch between the certificate's agent-id extension and the request's Agent- ID header *MUST* be treated as a protocol error per [AGTP-CERT]. 3. TCP/TLS Binding 3.1. Overview AGTP over TCP/TLS runs on a persistent TCP connection wrapped by TLS 1.3 or later. A connection carries zero or more AGTP sessions; a session may move to a new connection through RESUME ([AGTP-SESSION]). AGTP requests and responses are sequential within the connection: a server processes requests in the order received and returns responses in the same order. This binding is the baseline AGTP transport. Implementations *MUST* support TCP/TLS as the universal fallback. Implementations *MAY* additionally support the QUIC binding per Section 4. 3.2. TLS Requirements All AGTP TCP connections *MUST* use TLS 1.3 ([RFC8446]) or higher. Implementations *MUST* reject connections using TLS 1.2 or below. TLS-level mutual authentication *MAY* be required by the server per [AGTP-CERT]. When mutual authentication is required, both the client (calling agent) and the server (target agent) present certificates. The server's certificate *MUST* be valid per [RFC5280]. The client's certificate, when presented, *SHOULD* be an AGTP Agent Certificate per [AGTP-CERT] for high-assurance deployments. Hood Expires 3 May 2027 [Page 6] Internet-Draft AGTP-BINDINGS October 2026 Server Name Indication ([RFC6066]) *SHOULD* be used by clients to allow servers to present the correct certificate when multiple agents share a serving infrastructure. The SNI value carries the agent's authority hostname per the URI structure in [AGTP]. 3.3. Connection Establishment The TCP/TLS connection establishment sequence: 1. The client establishes a TCP connection to the target server on port 4480 (or the configured port). 2. The client initiates a TLS 1.3 handshake. Server name indication carries the target agent's authority hostname. 3. If mutual authentication is required, the client presents its Agent Certificate during the handshake. The server verifies the certificate against its trust anchors per [RFC5280]. 4. The server presents its certificate. The client verifies the certificate per [RFC5280]. 5. Upon successful handshake, the connection is ready to carry AGTP requests and responses. Implementations *MUST NOT* use TLS False Start or any early-data mechanism over TCP/TLS. AGTP over TCP/TLS carries no 0-RTT data; all AGTP messages *MUST* be sent only after the TLS handshake completes. 3.4. Request/Response Framing AGTP requests and responses over TCP/TLS use the wire format defined in [AGTP]. Each message consists of: 1. A request line (for requests) or response line (for responses) terminated by CRLF. 2. Zero or more header lines, each terminated by CRLF. 3. An empty line (CRLF only) signaling the end of headers. 4. A message body whose length is specified by the Content-Length header. The Content-Length header is the sole signal of message completion per [AGTP]. Receivers *MUST* treat a message as complete when, and only when, the declared number of body octets has been read after the header terminator. Hood Expires 3 May 2027 [Page 7] Internet-Draft AGTP-BINDINGS October 2026 AGTP over TCP/TLS *MUST NOT* use HTTP-style chunked transfer encoding. Streaming responses are framed by repeated Content-Length- delimited messages within a single connection per [AGTP]. 3.5. Connection Lifecycle and Sessions A TCP/TLS connection begins with the completion of the TLS handshake and ends with either: * Inactivity timeout (default 60 seconds, configurable). * TCP connection close, by either side. Connection close is never session termination. A session established on the connection ([AGTP-SESSION]) persists in the Suspended-by- transport state for its resume window and is re-bound to a new connection by RESUME; it ends only by TERMINATE, by expiry, or by the resume window elapsing. A connection that closes with sessions open *SHOULD* be logged by the server with the affected Session-ID values so that a RESUME that never arrives can be reconciled against the log. Implementations *MUST NOT* use socket-level half-close (shutdown(SHUT_WR) or equivalent) to signal end-of-request per the Wire-Format Framing section of [AGTP]. The TLS close_notify alert that results from a half-close terminates the secure session before the peer can transmit a response, producing a truncation that is indistinguishable at the application layer from a malicious downgrade. When a connection closes normally, the TLS connection terminates per [RFC8446]. The TCP connection then closes. 3.6. Connection Reuse and Pooling A single TCP/TLS connection *MAY* carry several AGTP sessions, sequentially or interleaved by Session-ID. The binding keeps no per- session state of its own: which session a request belongs to is the Session-ID header, and the server *MUST* check that the request's Agent-ID is a participant in that session per [AGTP-SESSION]; the connection the request arrived on says nothing about membership. Connection pools *MAY* maintain pre-established connections to frequent counterparties to reduce handshake overhead. Pooled connections *MUST* be validated as live before reuse (typically by sending a low-cost AGTP DISCOVER request). Hood Expires 3 May 2027 [Page 8] Internet-Draft AGTP-BINDINGS October 2026 4. QUIC Binding 4.1. Overview AGTP over QUIC runs on QUIC connections per [RFC9000], with QUIC's built-in TLS 1.3 per [RFC9001]. QUIC provides multiplexed streams, reduced connection establishment latency, and connection migration. The QUIC binding is *OPTIONAL* for AGTP implementations. Implementations *MAY* support QUIC in addition to TCP/TLS. Implementations *MUST NOT* support QUIC without also supporting TCP/ TLS. 4.2. QUIC Version AGTP over QUIC *MUST* use QUIC version 1 ([RFC9000]) or higher. Negotiation of higher QUIC versions follows the QUIC version negotiation procedure ([RFC9000] Section 6). 4.3. ALPN Identifier AGTP over QUIC *MUST* negotiate the application-layer protocol using ALPN per [RFC9001]. The ALPN identifier for AGTP over QUIC is agtp. Implementations *MUST* include agtp in the ClientHello's ALPN extension and *MUST* select agtp in the ServerHello when offered. 4.4. Stream Usage AGTP requests and responses over QUIC are carried on bidirectional client-initiated streams. Each AGTP request initiates a new stream; the response is carried on the same stream. This document defines no multi-stream coordination beyond what [AGTP-SESSION] specifies. A single AGTP session *MAY* carry multiple concurrent requests on separate QUIC streams, and a single QUIC connection *MAY* carry several sessions. The Session-ID header identifies the session across streams and connections. QUIC connection-level concerns (flow control, congestion control, loss recovery per [RFC9002]) are handled by the QUIC implementation and are transparent to AGTP. AGTP implementations *MUST NOT* rely on stream-level acknowledgment or loss-recovery semantics. 4.5. Connection Migration QUIC supports connection migration: a connection can move between network paths (e.g., from Wi-Fi to cellular) without disruption per [RFC9000] Section 9. AGTP over QUIC inherits this property. Hood Expires 3 May 2027 [Page 9] Internet-Draft AGTP-BINDINGS October 2026 A migrated QUIC connection is the same connection, so the sessions it carries continue without a RESUME; migration is the case in which the transport itself preserves the session's connection. When a QUIC connection is lost outright (idle timeout, stateless reset, path failure the transport cannot recover), the resumption procedure of [AGTP-SESSION] applies exactly as over TCP/TLS. Implementations *SHOULD* treat migration as transparent and *MUST NOT* treat it as a resumption event. When a QUIC connection migration changes the apparent client network location, AGTP implementations *MAY* apply additional verification (e.g., re-checking the Agent Certificate, requesting attestation per trust posture per [AGTP-CERT]) for sensitive sessions, but this is operator policy and no protocol requirement. 4.6. QUIC-Specific Replay Safety Profile QUIC supports 0-RTT early data per [RFC9001]. Early data is sent before the QUIC handshake completes. Early data is replayable: an attacker who captures early data may replay it, and the server cannot distinguish a replay from the original. AGTP requests carry authority-scoped actions. A replayed EXECUTE, DELEGATE, PURCHASE, or other action method could re-trigger authorized work, transfer funds, modify state, or produce duplicate side effects. This document defines an AGTP-specific replay-safety profile governing early data use. 4.6.1. Methods Eligible for Early Data Safety is a property of a method's definition ([AGTP-METHODS]). Admission to early data is a property of a deployment's replay exposure, and this binding admits a narrower set than the safe methods of [AGTP]. The methods eligible for early data are: * *QUERY*: information retrieval. Replays return equivalent results and touch no agent state. * *DISCOVER*: capability and presence discovery. Replays return equivalent results and touch no agent state. Hood Expires 3 May 2027 [Page 10] Internet-Draft AGTP-BINDINGS October 2026 DESCRIBE, INSPECT, SUMMARIZE, and PLAN are safe per [AGTP] and are excluded here for cause: INSPECT reads audit records whose access is scoped and logged, SUMMARIZE and PLAN invoke model inference whose cost a replay multiplies, and DESCRIBE is cheap but gains nothing from 0-RTT a cached result cannot give. Any of them *MAY* become eligible through an update to this document once implementation evidence shows replay to be harmless in deployment. 4.6.2. Request Signature in Early Data An early-data request carries Request-Signature like any other request ([AGTP]). The server *MUST* verify the signature, the iat window, and the (Agent-ID, nonce) replay cache before honoring the request, even for an eligible method; an early-data request whose signature fails is rejected with 401 and reason possession-unproven and is never retried as early data. The signature's nonce bounds replay of an eligible request to one acceptance per nonce per window, so the eligibility list limits what a replay can do and the signature limits how often it can do it. The two defenses compose and neither substitutes for the other. 4.6.3. Methods Prohibited from Early Data AGTP action methods *MUST NOT* be sent as early data. The currently defined action methods prohibited from early data are: * *EXECUTE*: carries arbitrary agent operations including framework payloads (MCP tool calls, A2A tasks, etc.). May have arbitrary side effects. * *DELEGATE*: delegates authority. Creates state. * *PURCHASE*: commerce action. Moves value. * *TRANSACT*: commits to commerce transaction per AGTP-COMMERCE. * *ACTIVATE*, *DEACTIVATE*, *REVOKE*, *REINSTATE*, *DEPRECATE*: lifecycle methods. Modify agent governance state. * *NOTIFY*: delivers messages with at-least-once semantics. Replays could produce duplicate delivery. * *PROPOSE*: proposes runtime contracts. Creates negotiation state. * *ESTABLISH*, *RESUME*, *TERMINATE*: session methods per [AGTP-SESSION]. Create, re-bind, or end session state; a replayed RESUME would re-bind a session to a connection the initiator no longer holds. Hood Expires 3 May 2027 [Page 11] Internet-Draft AGTP-BINDINGS October 2026 * *CREATE*, *REPLACE*, *MODIFY*, *REMOVE*: when used as resource- affecting methods per the legacy mapping in [AGTP-METHODS]. * *CONFIRM*, *ESCALATE*: mechanics methods with external effect. * *DESCRIBE*, *INSPECT*, *SUMMARIZE*, *PLAN*: safe per [AGTP] but excluded from early data per Section 4.6.1. Servers receiving an early-data request carrying any method absent from the eligible list *MUST* reject the request with status code 425 (Too Early) per [RFC8470] and *MUST* require the client to retransmit the request after the QUIC handshake completes. 4.6.4. Server Enforcement QUIC implementations supporting AGTP *MUST* make the AGTP method visible to the server's request dispatcher before the dispatcher applies any side-effectful logic. The server's AGTP layer *MUST* verify that any request received as early data carries a method on the eligibility list, and *MUST* verify its Request-Signature per Section 4.6.2, before processing. A server *MAY* reject all early data unconditionally, regardless of method. This is a conforming and conservative implementation choice. The replay-safety profile defines the maximum permitted early data; servers *MAY* be more restrictive. 4.6.5. Client Behavior Clients sending AGTP requests over QUIC *MUST NOT* send action methods as early data. Clients that wish to use 0-RTT for latency reduction *MUST* restrict early-data usage to the eligible methods. If a client receives a 425 Too Early response, the client *MUST* retry the request after the handshake completes. The client *MUST NOT* retry the same request as early data on the same or a future connection unless the AGTP method becomes eligible (a specification change this document would document). 4.6.6. Anti-Replay Defense in Depth The replay-safety profile is the primary defense against early-data replay attacks for AGTP. Implementations *SHOULD* also use QUIC- level anti-replay mechanisms per [RFC9001], including per-server anti-replay caches that detect duplicate early-data records. These mechanisms compose with the AGTP replay-safety profile: even on eligible methods, defense in depth limits exploitability of any future protocol-level oversight. Hood Expires 3 May 2027 [Page 12] Internet-Draft AGTP-BINDINGS October 2026 4.7. Connection Establishment Sequence The QUIC connection establishment sequence: 1. The client constructs a QUIC ClientHello including ALPN extension advertising agtp. 2. The QUIC handshake proceeds per [RFC9001]. If the client has a valid resumption ticket and the deployment policy allows, the client *MAY* send 0-RTT early data subject to the replay-safety profile in Section 4.6. 3. If mutual authentication is required, the client presents its Agent Certificate during the handshake. The server verifies the certificate against its trust anchors per [RFC5280] and [AGTP-CERT]. 4. The server completes the handshake, selecting agtp in the ALPN extension. 5. Upon successful handshake, the connection is ready to carry normal AGTP requests and responses on QUIC streams. 4.8. Connection Lifecycle and Sessions A QUIC connection is ready to carry AGTP requests when the handshake completes; eligible early data *MAY* precede that point per Section 4.6. A session *MUST NOT* be established in early data ([AGTP-SESSION]). The connection ends with either: * Inactivity timeout (default 60 seconds, configurable). * QUIC connection close or stateless reset. As over TCP/TLS (Section 3.5), connection close is never session termination; the sessions the connection carried enter Suspended-by- transport and are re-bound by RESUME. Connection migration ends nothing. 5. HTTP/3 and WebTransport Binding Hood Expires 3 May 2027 [Page 13] Internet-Draft AGTP-BINDINGS October 2026 5.1. Purpose and Status The TCP/TLS and QUIC bindings present AGTP as a distinct wire image on its own port. Two deployment situations need AGTP carried inside an HTTP/3 connection instead: a browser, which can open HTTP/3 and WebTransport but cannot open a raw QUIC connection to port 4480; and an HTTP intermediary (a CDN edge, an API gateway, a corporate egress proxy) that the operator wants AGTP traffic to traverse without a protocol exception. This binding carries unmodified AGTP messages over an HTTP/3 connection ([RFC9114]), using WebTransport ([RFC9220]) where the client is a browser. AGTP semantics are unchanged: the request line, headers, Request-Signature, status codes, and session model are exactly those of [AGTP] and [AGTP-SESSION]; only the framing beneath them differs. Status: the framing in this section is specified. Interoperability details marked planned are to be settled against implementation experience, and the reference implementation has yet to ship this binding. A server *MAY* omit it and remain conformant; TCP/TLS remains the universal fallback. 5.2. Framing over an HTTP/3 Connection An AGTP client that has an HTTP/3 connection to a server advertising AGTP support opens one bidirectional HTTP/3 stream per AGTP request and sends the AGTP message on that stream as the body of a single HTTP/3 request: :method = CONNECT :protocol = agtp :scheme = https :authority = :path = / The extended CONNECT form of [RFC9220] is used so that the stream is handed to AGTP in place of HTTP request interpretation. After the server answers with :status = 200, the stream carries AGTP messages framed exactly as over TCP/TLS: the AGTP request line, headers, and Content-Length-delimited body in one direction and the AGTP response in the other. The HTTP/3 layer sees opaque bytes. Servers *MUST* advertise support with the SETTINGS_ENABLE_CONNECT_PROTOCOL setting per [RFC9220]. A client *MAY* reuse one such stream for several sequential AGTP exchanges, as over a TCP/TLS connection, or open one stream per exchange for concurrency. The stream is the AGTP connection for the purposes of Section 3.5: its close is never session termination. Hood Expires 3 May 2027 [Page 14] Internet-Draft AGTP-BINDINGS October 2026 5.3. WebTransport Where the client is a browser, the client opens a WebTransport session to the server per [RFC9220] and carries each AGTP exchange on a WebTransport bidirectional stream, framed as above. The WebTransport session is a connection in this document's vocabulary; the AGTP session rides on it and survives it through RESUME. A browser client authenticates as an agent through Request-Signature with a key the page holds; Agent Certificates at the TLS layer are unavailable to a browser client, so such a deployment is at Level 2 of [AGTP] and never Level 3. 5.4. Early Data HTTP/3 0-RTT applies to the HTTP/3 request that opens the stream, and the AGTP message inside it is early data if the stream is opened in 0-RTT. The replay-safety profile of Section 4.6 applies unchanged: only QUERY and DISCOVER *MAY* be sent on a stream opened in early data, every such request carries Request-Signature, and a server receiving any other method on such a stream rejects it with 425 per [RFC8470]. 5.5. Identity and Intermediaries An HTTP intermediary in the path sees an extended CONNECT to the server and opaque stream data; it sees no AGTP headers and cannot act on them. Infrastructure that needs to enforce Authority-Scope at line rate (an SEP) therefore sits at the AGTP server, beyond the intermediary, when this binding is in use, or terminates the CONNECT itself and becomes the AGTP server. The Request-Signature is verified end to end by whichever party is the AGTP server, so an intermediary cannot forge or alter a request without detection; it can only refuse to carry it. Planned: a well-known path for advertising AGTP support on an HTTPS origin, so that a browser can discover that an origin accepts this binding before opening a WebTransport session; the ALPN and :protocol token registrations (Section 9); and test vectors for the stream framing. 6. Connection Selection Between Bindings When several bindings are available on the server, the client selects the binding based on its own operational requirements. AGTP defines no normative preference among them. Clients *MAY* use any of the following selection strategies: Hood Expires 3 May 2027 [Page 15] Internet-Draft AGTP-BINDINGS October 2026 * *TCP/TLS only.* Conservative choice. Universal availability. * *QUIC with TCP/TLS fallback.* Attempt QUIC first; fall back to TCP/TLS if the QUIC handshake fails or 0-RTT replay-safety considerations apply. Common in deployments where QUIC offers latency or multiplexing benefits. * *QUIC only.* Appropriate where the deployment ecosystem fully supports QUIC. Limits interoperability with TCP/TLS-only counterparties. * *HTTP/3 or WebTransport.* Required for browser clients and for paths through HTTP intermediaries; otherwise a choice the operator makes to reuse HTTP/3 infrastructure (Section 5). Servers *MAY* advertise their supported bindings through DNS SRV records (separate records for _agtp._tcp and _agtp._udp) or through AGTP Identity Document fields. Discovery of binding support is outside wire-layer protocol concern. The earlier "SHOULD prefer QUIC" guidance of base v08 is withdrawn. Transport preference is a deployment-time choice; the protocol expresses none. Operators make the choice based on their infrastructure, their counterparty ecosystem, and their latency requirements. 7. Implementation Considerations 7.1. TLS Library Choice Both bindings depend on TLS 1.3 implementations. Common production TLS libraries (OpenSSL 3.x, BoringSSL, rustls, Go's crypto/tls) provide TLS 1.3 with appropriate cipher suites. Implementations *SHOULD* use TLS libraries with active maintenance and security review. For QUIC, the TLS implementation *MUST* integrate with the QUIC implementation per [RFC9001]. Some QUIC libraries (quiche, msquic, quinn) bundle TLS; others integrate with external TLS libraries. 7.2. Certificate Provisioning AGTP Agent Certificates per [AGTP-CERT] are provisioned through Agent Certificate Authority infrastructure. The same certificate *MAY* be presented across every binding that carries TLS; the certificate is never binding-specific. Hood Expires 3 May 2027 [Page 16] Internet-Draft AGTP-BINDINGS October 2026 Implementations supporting several bindings *MAY* maintain separate TLS configurations for each binding, but the certificate and trust anchor material *SHOULD* be shared to simplify operational management. 7.3. Idle Timeout Tuning Default idle timeouts (60 seconds for AGTP sessions) *MAY* be adjusted by deployment. For interactive agent workloads where sessions pause between requests, longer idle timeouts reduce reconnection overhead. For high-throughput batch workloads, shorter idle timeouts free server resources more quickly. QUIC's longer per-connection idle tolerance ([RFC9000]) makes QUIC particularly suitable for sessions with bursty traffic patterns. 7.4. Connection Multiplexing QUIC's stream multiplexing supports concurrent AGTP requests within a session without head-of-line blocking. TCP/TLS deployments needing concurrency *MAY* open multiple TCP/TLS connections; head-of-line blocking on a single TCP/TLS connection will block subsequent requests until the in-flight request completes. 8. Security Considerations This document inherits the security considerations of [AGTP], [AGTP-CERT], [RFC8446] (TLS 1.3), and [RFC9001] (QUIC-TLS). This section addresses considerations specific to the binding choice. 8.1. 0-RTT Replay Attack Surface The 0-RTT replay-safety profile in Section 4.6 is the primary defense against 0-RTT replay attacks. Implementations that allow early data *MUST* enforce the eligibility list and *MUST* verify Request- Signature on early data (Section 4.6.2). Implementations that support neither QUIC nor HTTP/3 are outside the 0-RTT replay surface because TCP/TLS carries no early data per this document. A specification oversight that mistakenly classifies an action method as eligible for early data would be a protocol-level vulnerability. Implementations *SHOULD* subject any update to the eligibility list to rigorous review. Hood Expires 3 May 2027 [Page 17] Internet-Draft AGTP-BINDINGS October 2026 8.2. TLS Downgrade Attacks AGTP implementations *MUST* reject TLS 1.2 and below per the TLS Requirements section. Implementations *MUST NOT* accept downgrade negotiation that would establish a session using a deprecated TLS version. Implementations *SHOULD* enable TLS 1.3 downgrade protection ([RFC8446] Section 4.1.3) for additional defense. 8.3. QUIC Connection Migration Identity Verification QUIC connection migration changes the network path the connection uses; the connection's TLS keys and the agent identity are the same before and after. An attacker on a new network path cannot impersonate the client because the attacker lacks the keys. However, deployment policies for sensitive operations *MAY* require additional verification after migration. Operators *SHOULD* consider whether migration tolerance is appropriate for their threat model. 8.4. Certificate Validation Across Bindings The same Agent Certificate may be presented across the TCP/TLS, QUIC, and HTTP/3 bindings. Implementations *MUST* apply the same validation rules in every binding. A vulnerability allowing a certificate accepted on one binding but rejected on another could be exploited; all bindings *MUST* use identical certificate validation logic. 8.5. Idle Connection and Suspended Session Resource Exhaustion Long idle timeouts accumulate connection state, and the resume window of [AGTP-SESSION] accumulates suspended-session state after the connection is gone. An attacker establishing many connections and sessions and abandoning them could exhaust both. Implementations *SHOULD* apply per-agent connection limits, *MAY* reduce idle timeouts under resource pressure, and *SHOULD* cap the number of suspended sessions retained per Agent-ID, releasing the oldest first and logging each release with its Session-ID. 8.6. Intermediaries on the HTTP/3 Binding An intermediary carrying the HTTP/3 binding cannot read or alter AGTP messages without detection, because Request-Signature is verified end to end, but it can observe which agents talk to which servers and when. Deployments for which that metadata is sensitive *SHOULD* prefer the TCP/TLS or QUIC binding direct to the server. Hood Expires 3 May 2027 [Page 18] Internet-Draft AGTP-BINDINGS October 2026 9. IANA Considerations 9.1. ALPN Identifier This document requests registration of the ALPN identifier agtp for AGTP over QUIC in the IANA TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry per [RFC8446]: * Protocol: AGTP * Identification Sequence: 0x61 0x67 0x74 0x70 ("agtp") * Reference: This document The TCP/TLS binding requires no separate ALPN identifier because TCP/ TLS deployments traditionally rely on port-based protocol identification (port 4480 carries AGTP traffic). However, implementations *MAY* also use the agtp ALPN identifier on TCP/TLS connections for additional clarity in mixed-protocol deployments. 9.2. HTTP Upgrade Token This document requests registration of agtp in the HTTP Upgrade Token Registry for use as the :protocol value of the extended CONNECT form in Section 5, with this document as the reference. 9.3. Port Assignment This document references the existing IANA port assignment for AGTP (port 4480 for both TCP and UDP) per [AGTP]. The port assignment is unmodified by this document. The service names agtp (TCP/TLS) and agtp-quic (QUIC) are retained per the existing registration. 10. Engagement Invitation This document is published as an Internet-Draft to invite engagement from transport experts, TLS practitioners, QUIC implementers, and operators deploying AGTP infrastructure. The replay-safety profile in particular benefits from review by participants familiar with 0-RTT security analysis. Feedback from the IETF QUIC working group on the AGTP-specific replay-safety profile is welcome, and feedback from the agentproto working group on the HTTP/3 and WebTransport binding, which is the binding-target form its charter contemplates, is sought. The profile follows the established pattern (per [RFC9001] and HTTP/3 deployment) of restricting early data to safe methods, applied to AGTP's specific method catalog. Hood Expires 3 May 2027 [Page 19] Internet-Draft AGTP-BINDINGS October 2026 11. References 11.1. Normative References [AGTP] Hood, C., "Agent Transfer Protocol (AGTP)", Work in Progress, Internet-Draft, draft-hood-independent-agtp-10, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, . 11.2. Informative References Hood Expires 3 May 2027 [Page 20] Internet-Draft AGTP-BINDINGS October 2026 [AGTP-CERT] Hood, C., "AGTP Agent Certificate Extension", Work in Progress, Internet-Draft, draft-hood-agtp-agent-cert-04, 2026, . [AGTP-IDDOC] Hood, C., "AGTP Agent Identity Document", Work in Progress, Internet-Draft, draft-hood-agtp-identity- document-00, 2026, . [AGTP-METHODS] Hood, C., "AGTP Methods (AGTP Verbs): Method Vocabulary, Path Grammar, and Endpoints", Work in Progress, Internet- Draft, draft-hood-agtp-methods-00, 2026, . [AGTP-SESSION] Hood, C., "AGTP Session Protocol", Work in Progress, Internet-Draft, draft-hood-agtp-session-01, 2026, . [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . [RFC9220] Hamilton, R., "Bootstrapping WebSockets with HTTP/3", RFC 9220, DOI 10.17487/RFC9220, June 2022, . Hood Expires 3 May 2027 [Page 21] Internet-Draft AGTP-BINDINGS October 2026 Appendix A. Acknowledgments This document responds to feedback from Akira Okutomi on draft-hood- independent-agtp-08, who identified the inappropriate inclusion of transport-specific guidance and 0-RTT-as-benefit language in the base specification. The transport-neutrality of the base specification and the explicit replay-safety profile defined here both originate from that review. The replay-safety profile draws on the precedent established by HTTP over QUIC (HTTP/3) regarding 0-RTT data and safe methods. The AGTP profile follows the same architectural principle, applied to AGTP's specific method taxonomy. Appendix B. Changes from v00 * Connection and session separated. v00 identified an AGTP session with a TCP/TLS or QUIC connection and ended it on connection close or on SUSPEND or REVOKE. A session is now the agent-level context of [AGTP-SESSION], carried by a connection and surviving it through RESUME; both lifecycle sections are rewritten as connection lifecycle (Section 3.5, Section 4.8), connection migration is stated as the case needing no RESUME, and connection reuse no longer speaks of session state leaking between sessions. * Request-Signature on every binding and on early data (Section 4.6.2), with the identity section restated around it. * Eligibility list kept at QUERY and DISCOVER with the reason stated; the four other safe methods of [AGTP] are excluded, with the reason for each (Section 4.6.1). ESTABLISH, RESUME, and TERMINATE added to the prohibited list. * HTTP/3 and WebTransport binding added (Section 5): extended CONNECT framing, WebTransport for browsers, early data under the same profile, intermediary considerations, and the planned items. * References: base to draft-hood-independent-agtp-10; AGTP-API replaced by AGTP-METHODS; AGTP-SESSION and AGTP-IDDOC added; RFC 9114 and RFC 9220 added. * Transfer-protocol wording; house style pass. Wire format compatibility: the TCP/TLS and QUIC framing is unchanged. A v00 client that treats connection close as session end will never RESUME, which is permitted. The HTTP/3 binding is new and optional. Hood Expires 3 May 2027 [Page 22] Internet-Draft AGTP-BINDINGS October 2026 Author's Address Chris Hood Nomotic, Inc. Email: chris@nomotic.ai URI: https://nomotic.ai Hood Expires 3 May 2027 [Page 23]