Internet Engineering Task Force R. Sharif Internet-Draft CyberSecAI Ltd Intended status: Standards Track March 29, 2026 Expires: September 29, 2026 ATTP: Agent Trust Transport Protocol for Secure Agent-to-Server Communication draft-sharif-attp-agent-trust-transport-00 Abstract This document specifies ATTP (Agent Trust Transport Protocol), a synchronous request-response protocol for communication between autonomous AI agents and web API servers. ATTP operates as an application-layer protocol over HTTP, adding mandatory cryptographic identity verification, per-message signing, trust-gated access control, and tamper-evident audit trail generation to every agent-server interaction. ATTP defines five protocol-layer headers for requests (X-Agent-Trust, X-Agent-Signature, X-Agent-Nonce, X-Agent-Timestamp, X-ATTP-Version) and three for responses (X-Server-Signature, X-Server-Nonce, X-Server-Timestamp) that carry an Agent Passport (JWT-based identity credential), ECDSA P-256 digital signatures, cryptographic nonces, and timestamps. Server middleware verifies all cryptographic properties before application code executes. ATTP has no insecure mode. Every request MUST carry a valid Agent Passport. Every request body MUST be signed. Every response body MUST be signed. Every interaction MUST be recorded in a hash-chained audit trail. The protocol defines a URL scheme (attp://) and is fully backward-compatible with existing HTTP infrastructure. ATTP is the synchronous counterpart to the Agent Transport Protocol (ATP). ATP handles asynchronous store-and-forward agent delivery; ATTP handles real-time request-response API communication. Both share the same identity model, trust framework, and cryptographic primitives. 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/. 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 September 29, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . 3 1.2. Design Goals . . . . . . . . . . . . . . . . . . . . 4 1.3. Relationship to ATP . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 7 3.1. Architecture . . . . . . . . . . . . . . . . . . . . 7 3.2. Mandatory Security . . . . . . . . . . . . . . . . . 7 3.3. URL Scheme . . . . . . . . . . . . . . . . . . . . . 8 4. ATTP Headers . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Request Headers . . . . . . . . . . . . . . . . . . . 8 4.2. Response Headers . . . . . . . . . . . . . . . . . . 10 5. Request Lifecycle . . . . . . . . . . . . . . . . . . . . 10 6. Trust-Gated Access Control . . . . . . . . . . . . . . . 13 6.1. Trust Level Definitions . . . . . . . . . . . . . . . 14 6.2. Per-Endpoint Trust Declaration . . . . . . . . . . . 14 6.3. Rejection Semantics . . . . . . . . . . . . . . . . . 15 7. Per-Message Signing . . . . . . . . . . . . . . . . . . . 15 7.1. Request Signing . . . . . . . . . . . . . . . . . . . 16 7.2. Response Signing . . . . . . . . . . . . . . . . . . 16 7.3. Canonical JSON . . . . . . . . . . . . . . . . . . . 17 7.4. Signature Verification . . . . . . . . . . . . . . . 17 8. Agent Passport . . . . . . . . . . . . . . . . . . . . . 17 8.1. Passport Structure . . . . . . . . . . . . . . . . . 18 8.2. Mandatory Fields . . . . . . . . . . . . . . . . . . 18 8.3. Verification Procedure . . . . . . . . . . . . . . . 19 8.4. Relationship to MCPS Agent Passports . . . . . . . . 20 9. Key Discovery . . . . . . . . . . . . . . . . . . . . . . 20 9.1. JWKS Endpoint . . . . . . . . . . . . . . . . . . . . 20 9.2. Key Caching . . . . . . . . . . . . . . . . . . . . . 21 9.3. Key Rotation . . . . . . . . . . . . . . . . . . . . 21 10. Replay Protection . . . . . . . . . . . . . . . . . . . . 22 10.1. Nonce Requirements . . . . . . . . . . . . . . . . . 22 10.2. Timestamp Window . . . . . . . . . . . . . . . . . . 22 10.3. Nonce Store Requirements . . . . . . . . . . . . . . 22 11. Audit Trail . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Automatic Recording . . . . . . . . . . . . . . . . . 23 11.2. Hash-Chained Records . . . . . . . . . . . . . . . . 23 11.3. Export Formats . . . . . . . . . . . . . . . . . . . 24 12. URL Scheme . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Scheme Definition . . . . . . . . . . . . . . . . . . 24 12.2. Default Port . . . . . . . . . . . . . . . . . . . . 25 12.3. URI Format . . . . . . . . . . . . . . . . . . . . . 25 13. Backward Compatibility . . . . . . . . . . . . . . . . . 25 13.1. HTTP Infrastructure . . . . . . . . . . . . . . . . . 25 13.2. Upgrade Path . . . . . . . . . . . . . . . . . . . . 26 14. Error Handling . . . . . . . . . . . . . . . . . . . . . 26 15. Security Considerations . . . . . . . . . . . . . . . . . 28 16. IANA Considerations . . . . . . . . . . . . . . . . . . . 29 16.1. ATTP URI Scheme Registration . . . . . . . . . . . . 29 16.2. Port Number Registration . . . . . . . . . . . . . . 30 16.3. ATTP Header Field Registration . . . . . . . . . . . 30 17. References . . . . . . . . . . . . . . . . . . . . . . . 31 17.1. Normative References . . . . . . . . . . . . . . . . 31 17.2. Informative References . . . . . . . . . . . . . . . 32 Appendix A. Example ATTP Exchange . . . . . . . . . . . . . 33 Appendix B. Comparison with HTTP/OAuth . . . . . . . . . . . 35 Appendix C. Server Middleware Implementation Guide . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction 1.1. The Problem The Hypertext Transfer Protocol (HTTP) [RFC9110] was designed in 1991 for human users operating web browsers to request and receive hypertext documents from servers. HTTP provides no built-in mechanism for caller identity verification, no per-message signing, no trust-level evaluation, and no audit trail generation. Over three decades, security was progressively bolted on: TLS [RFC8446] for transport encryption (1995), HTTP Authentication [RFC7235] for basic credentials (1999), OAuth 2.0 [RFC6749] for delegated authorization (2012), and DPoP [RFC9449] for proof-of- possession (2023). This layered approach created a protocol stack where security is optional, fragmented, and human-centric. HTTP has both insecure (http://) and secure (https://) variants. OAuth assumes a human who can interact with browser-based consent flows. TLS protects the transport channel but not the application-layer message -- once a request passes through a TLS-terminating proxy, CDN, or load balancer, the message is decrypted and forwarded in plaintext within the server's infrastructure. Autonomous AI agents are now the fastest-growing consumers of web APIs. Industry projections indicate that agent- initiated API calls will exceed human-initiated API calls by 2028. These agents cannot participate in browser-based OAuth consent flows, do not have browser sessions, and require machine-to-machine identity credentials rather than human-delegated access tokens. There exists a need for a synchronous request-response protocol purpose-built for autonomous AI agents that mandates cryptographic identity verification, signs every message at the application layer, evaluates trust at the protocol layer, generates audit trails automatically, and operates over existing HTTP infrastructure. 1.2. Design Goals ATTP is designed with the following goals: o Mandatory security: no insecure mode, no optional signing, no anonymous access. o Bidirectional signing: both request and response are signed at the application layer. o Trust-gated access: protocol-layer trust evaluation before application code executes. o Automatic audit: every interaction recorded in a tamper- evident hash-chained trail. o Backward compatibility: ATTP messages are valid HTTP messages that traverse existing infrastructure. o Minimal integration: single middleware registration line in existing web frameworks. o Federated identity: no central authority required for Agent Passport issuance or key discovery. 1.3. Relationship to ATP ATTP is the synchronous counterpart to the Agent Transport Protocol (ATP) [draft-sharif-agent-transport-protocol]. The relationship can be summarized as: o ATP is to ATTP as SMTP is to HTTP. o ATP handles asynchronous, store-and-forward agent delivery (analogous to email). o ATTP handles synchronous, real-time request-response API communication (analogous to phone calls). Both protocols share the same identity model (Agent Passports), the same trust level framework (L0 through L4), the same cryptographic primitives (ECDSA P-256), and the same design philosophy (mandatory security, no insecure mode). They differ in delivery semantics: ATP uses a dedicated session protocol with DNS-based routing via Agent eXchange (AX) records, while ATTP runs over existing HTTP infrastructure. An agent operating in a complex environment might use both protocols: ATTP to call web APIs for real-time data retrieval and transaction processing, and ATP to transmit itself to a different runtime for continued execution. 2. 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. Agent: An autonomous software entity that makes independent decisions about which APIs to call and operates without direct human interaction for each request. Agent Passport: A JWT-structured credential signed with ECDSA P-256 that binds an agent's identity, trust level, capabilities, and public key into a single verifiable credential. ATTP Agent: The client-side component within an autonomous agent that constructs ATTP-compliant requests, including signing the request body and attaching the Agent Passport. ATTP Middleware: The server-side component that intercepts incoming requests, performs all ATTP verification steps (passport verification, trust evaluation, signature verification, replay protection), and either forwards verified requests to application code or rejects them. ATTP Server: A web API server configured with ATTP middleware that enforces ATTP protocol requirements. Trust Level: A hierarchical classification (L0 through L4) reflecting the cryptographic verification strength of an agent's identity and message integrity. Trust levels are asserted by the passport issuer and signed into the Agent Passport. Passport Issuer: An entity that verifies agent identities, assigns trust levels, and issues signed Agent Passports. Any entity MAY operate as a passport issuer (federated model). Nonce: A cryptographically random value (minimum 128 bits, hex-encoded) included in each request to prevent replay attacks. JWKS: JSON Web Key Set, a document containing one or more public keys used for signature verification, as defined in [RFC7517]. Canonical JSON: JSON serialized according to JSON Canonicalization Scheme (JCS) [RFC8785], providing deterministic byte-level representation for signing. Hash Chain: A sequence of records where each record contains a SHA-256 hash of the previous record, making the sequence tamper-evident. 3. Protocol Overview 3.1. Architecture ATTP operates as an application-layer protocol over HTTP. ATTP messages are standard HTTP messages with additional headers and body-level signing. ATTP does not define a new transport mechanism; it leverages existing HTTP transport infrastructure (TCP connections, TLS encryption, HTTP/1.1 or HTTP/2 or HTTP/3 framing) while adding mandatory security properties at the application layer. The architecture comprises three components: o ATTP Agent: constructs signed requests with Agent Passport and transmits them over HTTPS. o ATTP Middleware: server-side interceptor that verifies all cryptographic properties before forwarding to application code. o Application Code: the API endpoint handler that processes verified requests, unaware of ATTP verification details. Every request carries an Agent Passport and a message signature. Every response is signed by the server. The middleware enforces these requirements; application code receives only verified requests. 3.2. Mandatory Security ATTP has no insecure mode. The following properties are non-optional protocol requirements: o Every request MUST carry a valid Agent Passport. o Every request body MUST be signed by the agent. o Every response body MUST be signed by the server. o Every interaction MUST be recorded in the audit trail. o Trust level MUST be evaluated before application code executes. There is no anonymous mode, no unsigned mode, and no bypass mechanism. Unlike HTTP, which has both http:// (insecure) and https:// (secure), ATTP has only attp:// which inherently implies mandatory cryptographic signing, identity verification, and trust evaluation. 3.3. URL Scheme ATTP defines the URL scheme attp:// to distinguish agent- to-server requests from conventional HTTP requests. An ATTP URL takes the form: attp://hostname[:port]/path[?query] Example: attp://api.example.com/v1/charges The attp:// scheme signals that: (a) the request originates from an autonomous agent; (b) ATTP security requirements are mandatory; and (c) the server MUST process the request through ATTP middleware. At the transport level, ATTP requests are transmitted over HTTPS. The attp:// scheme is resolved to an HTTPS connection by the ATTP agent component. The default port is 8443. 4. ATTP Headers 4.1. Request Headers ATTP defines five mandatory request headers: X-Agent-Trust: Contains the agent's Agent Passport, a JWT-structured credential signed with ECDSA P-256. The passport carries identity claims including subject, issuer, trust level, capabilities, public key, and expiration. Format: Base64url-encoded JWT (header.payload.signature) Example: X-Agent-Trust: eyJhbGciOiJFUzI1NiIsInR5cCI6IkpX VCIsImtpZCI6InRhLWtleS0wMDEifQ.eyJzdWIiOiJhZ2 VudC1hbHBoYS0wMDEiLCJpc3MiOiJ0cnVzdC5leGFtcG xlLmNvbSIsInRydXN0X2xldmVsIjoiTDIiLCJleHAiOjE 3NDMzMDAwMDB9.MEUCIQDx... X-Agent-Signature: Contains the Base64url-encoded ECDSA P-256 signature over the request body. For JSON bodies, the signature is computed over the JCS-canonicalized [RFC8785] form. For non-JSON bodies, the signature is computed over the raw bytes. For bodiless requests (GET, HEAD), the signature covers a canonical string comprising method, path, nonce, and timestamp. Encoding: IEEE P1363 fixed-length r||s format per [RFC7518] Section 3.4, with low-S normalization. Format: Base64url string X-Agent-Nonce: Contains a cryptographically random nonce, hex-encoded, with a minimum of 128 bits of entropy (32 hex characters). The nonce MUST be unique per request. Format: Hex-encoded string, minimum 32 characters Example: X-Agent-Nonce: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 X-Agent-Timestamp: Contains an ISO 8601 timestamp [RFC3339] recording the moment the agent signed the request. Format: ISO 8601 / RFC 3339 timestamp Example: X-Agent-Timestamp: 2026-03-29T14:30:00.000Z X-ATTP-Version: Contains the ATTP protocol version string. Format: Major.Minor version string Example: X-ATTP-Version: 1.0 4.2. Response Headers ATTP defines three mandatory response headers: X-Server-Signature: Contains the Base64url-encoded ECDSA P-256 signature over the response body, computed by the server using its private key. The agent verifies this signature using the server's public key obtained from the JWKS endpoint. X-Server-Nonce: Contains a cryptographically random nonce generated by the server, hex-encoded, minimum 128 bits. X-Server-Timestamp: Contains an ISO 8601 timestamp recording the moment the server signed the response. 5. Request Lifecycle The ATTP request lifecycle comprises eleven steps. Each step is mandatory and MUST NOT be skipped or deferred. Step 1: Request Construction The ATTP agent constructs the request payload (HTTP request body) containing the data to be sent. The payload MAY be JSON, form data, binary, or any content type supported by HTTP. Step 2: Request Body Signing The ATTP agent computes a digital signature over the request body using its ECDSA P-256 private key. For JSON payloads, the canonical form is computed using JCS [RFC8785]: keys sorted lexicographically, no extraneous whitespace, UTF-8 encoding. For non-JSON payloads, the raw byte sequence is signed. The signature uses IEEE P1363 fixed-length r||s encoding with low-S normalization. The resulting signature is Base64url- encoded. For bodiless requests (GET, HEAD, DELETE without body), the agent signs a canonical string: METHOD + "\n" + PATH + "\n" + NONCE + "\n" + TIMESTAMP Step 3: Agent Passport Attachment The ATTP agent attaches its Agent Passport in the X-Agent-Trust header. The passport is a JWT containing the agent's identity claims, signed by the passport issuer. Step 4: Nonce and Timestamp Generation The ATTP agent generates a cryptographically random nonce (minimum 128 bits, hex-encoded) and an ISO 8601 timestamp. The nonce is placed in X-Agent-Nonce; the timestamp in X-Agent-Timestamp. Both values are included in the signed content (Step 2) to bind the signature to a specific moment and prevent replay. Step 5: Request Transmission The ATTP agent transmits the HTTP request to the server's URL with all ATTP headers (X-Agent-Trust, X-Agent-Signature, X-Agent-Nonce, X-Agent-Timestamp, X-ATTP-Version) alongside standard HTTP headers. The request is transmitted over HTTPS. Step 6: Server Middleware Interception The ATTP middleware intercepts the incoming request before it reaches the application's route handler. The middleware checks for X-ATTP-Version to determine if the request is an ATTP request. If absent, behavior is configurable: o Strict mode: reject (ATTP-only server). o Permissive mode: pass through as regular HTTP. o Upgrade mode: respond with protocol upgrade suggestion. Step 7: Agent Passport Verification The middleware extracts the Agent Passport from X-Agent-Trust, decodes the JWT, and verifies its ECDSA P-256 signature against the issuer's public key. The middleware verifies: o The passport has not expired. o The passport's issuer is in the server's trusted list. o The passport's claims are internally consistent. The issuer's public key is resolved via the issuer's JWKS endpoint or a locally cached copy. Step 8: Trust Level Evaluation The middleware extracts the agent's trust level from the verified passport and compares it against the minimum trust level required by the target endpoint. If the agent's trust level is below the minimum, the middleware rejects the request with HTTP 403 and a structured error response (see Section 6.3). Step 9: Request Signature Verification The middleware extracts the signature from X-Agent-Signature and verifies it against the request body using the agent's public key from the passport. The middleware also verifies: o The nonce has not been previously used. o The timestamp is within the acceptable window. If verification fails, the request is rejected. Step 10: Response Signing After application code generates a response, the middleware intercepts the outgoing response. The middleware computes an ECDSA P-256 signature over the response body using the server's private key, generates a server nonce and timestamp, and attaches: X-Server-Signature, X-Server-Nonce, X-Server-Timestamp. Step 11: Audit Trail Recording The middleware records the complete request-response pair in the tamper-evident audit trail. The audit record includes the agent's identity, trust level, request and response hashes, signatures, and a hash pointer to the previous record. 6. Trust-Gated Access Control ATTP enforces trust-level-based access control at the protocol layer, before application code executes. This is fundamentally different from application-layer authorization (such as OAuth scope checking): ATTP trust evaluation occurs in protocol middleware and rejects untrusted requests before they consume application resources. Trust levels reflect the cryptographic verification strength of the agent's identity, not the permissions granted. Trust answers "how confident is the server in the agent's identity and message integrity?" while permissions answer "what is the agent allowed to do?" ATTP addresses the former; the application layer addresses the latter. 6.1. Trust Level Definitions ATTP defines five hierarchically ordered trust levels, derived from the MCPS trust level framework [draft-sharif-mcps-secure-mcp]: L0 (No Verification): The agent has presented a passport but the issuer cannot be verified, or the agent has no established history. L0 is the floor; ATTP does not permit passportless requests. L1 (Identity Verified): The agent's passport is signed by a trusted issuer that has verified the agent's identity. L2 (Signed Messages): The agent's passport is verified and the request is signed with a valid ECDSA P-256 signature. L2 is the baseline for most API operations. L3 (Full Verification with Revocation Checking): Passport verified, request signed, and revocation checking performed against the issuer's revocation endpoint. Appropriate for sensitive operations such as financial transactions. L4 (Mutual Authentication with Hardware-Backed Keys): All L3 requirements plus attestation that the agent's private key resides in a hardware security module (HSM) or secure enclave. Appropriate for critical infrastructure operations. 6.2. Per-Endpoint Trust Declaration Each API endpoint declares its minimum trust level as part of its configuration, not its application code. The ATTP middleware reads the declared minimum and compares it against the agent's trust level (where L0=0, L1=1, L2=2, L3=3, L4=4). Examples: o Public product catalogue: L1 minimum o Standard API operations: L2 minimum o Payment processing: L3 minimum o Critical infrastructure: L4 minimum 6.3. Rejection Semantics When the agent's trust level is below the endpoint's minimum, the middleware MUST respond with HTTP 403 Forbidden and the following JSON body: { "error": "insufficient_trust_level", "required_level": "L3", "agent_level": "L1", "message": "Agent trust level insufficient" } This rejection occurs at the protocol layer. Application code is never invoked for insufficient-trust requests. 7. Per-Message Signing ATTP mandates per-message signing for both requests and responses, providing bidirectional application-layer message integrity. This is a distinguishing property: HTTP does not sign messages, TLS signs only the transport channel, and most API authentication schemes sign only the request. ATTP signs both directions. 7.1. Request Signing The agent computes an ECDSA P-256 signature over the canonicalized request body, the nonce, and the timestamp. The signature binds the message content to the agent's identity (via its private key) and to a specific point in time (via nonce and timestamp). If any byte of the request body is modified after signing -- by a proxy, CDN, API gateway, or any other intermediary -- the signature verification at the server will fail. The signing input for JSON request bodies: JCS(request_body) + "\n" + nonce + "\n" + timestamp The signing input for non-JSON request bodies: raw_bytes(request_body) + "\n" + nonce + "\n" + timestamp All signatures use ECDSA P-256 with IEEE P1363 r||s encoding and low-S normalization per [RFC7518] Section 3.4. 7.2. Response Signing The server computes an ECDSA P-256 signature over the response body using the server's private key. The agent verifies this signature using the server's public key obtained from the JWKS endpoint (Section 9). Bidirectional signing provides end-to-end integrity from agent to server and from server to agent, regardless of intermediaries in the network path. 7.3. Canonical JSON For JSON payloads, ATTP uses JSON Canonicalization Scheme (JCS) as specified in [RFC8785] to produce deterministic byte-level representations for signing: o Object keys sorted lexicographically by Unicode code point. o No extraneous whitespace. o UTF-8 encoding. o Number serialization per ECMAScript rules. JCS ensures that semantically identical JSON documents produce identical byte sequences, preventing signature verification failures caused by formatting differences. 7.4. Signature Verification Verification MUST fail-closed: any verification error MUST result in request rejection. The middleware MUST NOT fall back to unsigned processing. ECDSA P-256 was selected for its combination of 128-bit equivalent security strength, performance, compact key size (suitable for HTTP headers), and ubiquity (supported by all major cryptographic libraries, HSMs, and cloud KMS services). 8. Agent Passport The Agent Passport is the cornerstone of ATTP identity verification. Every ATTP request MUST carry a valid Agent Passport. There is no anonymous mode and no bypass. 8.1. Passport Structure The passport is a JWT [RFC7519] comprising three sections: Header: Specifies the signing algorithm (ES256 for ECDSA P-256) and the key identifier (kid) of the issuer's signing key. Payload: Contains identity claims (see Section 8.2). Signature: Computed by the issuer over the header and payload using the issuer's ECDSA P-256 private key. 8.2. Mandatory Fields The Agent Passport payload MUST contain: sub (Subject): The agent's unique identifier. Example: "agent-alpha-001" iss (Issuer): The identity provider that issued the passport. Example: "trust.example.com" iat (Issued At): Unix timestamp of passport issuance. exp (Expiration): Unix timestamp of passport expiration. trust_level: One of "L0", "L1", "L2", "L3", "L4". capabilities: Array of capability strings the agent possesses. Example: ["read", "write", "payment"] The passport payload SHOULD contain: owner: The individual or organization that owns the agent. agent_type: Classification: "autonomous", "semi-autonomous", or "supervised". pub_key: The agent's ECDSA P-256 public key in JWK format [RFC7517] or a URI reference to the key. origin: The domain from which the agent operates, for origin binding. 8.3. Verification Procedure The ATTP middleware MUST verify the Agent Passport through the following steps: 1. Decode the JWT and extract header, payload, and signature. 2. Extract the issuer (iss) claim and resolve the issuer's public key via the issuer's JWKS endpoint or a locally cached copy. 3. Verify the JWT signature against the header and payload using the issuer's public key. 4. Verify that the current time is between iat and exp. 5. Verify that the issuer is in the server's list of trusted issuers. 6. Optionally perform origin binding verification: confirm that the agent's declared origin matches the network origin of the request. 7. For L3 and L4 trust levels, perform revocation checking by querying the issuer's revocation endpoint. If any step fails, the middleware MUST reject the request with HTTP 401 and an appropriate error code. 8.4. Relationship to MCPS Agent Passports ATTP uses the Agent Passport format defined in MCPS [draft-sharif-mcps-secure-mcp] Section 4, extended with HTTP-specific claims for transport context. MCPS defines how to issue, sign, and verify passports; ATTP defines when and where these operations occur within the HTTP request-response lifecycle. 9. Key Discovery 9.1. JWKS Endpoint ATTP servers MUST publish their public keys at: /.well-known/agent-trust-keys This endpoint serves a JSON Web Key Set (JWKS) document [RFC7517] containing one or more ECDSA P-256 public keys used for response signing. The JWKS document contains JWK objects with: o kty: "EC" (Elliptic Curve) o crv: "P-256" o x, y: public key coordinates, Base64url-encoded o kid: key identifier for key selection o use: "sig" (signing) o alg: "ES256" (ECDSA P-256) Example JWKS document: { "keys": [{ "kty": "EC", "crv": "P-256", "kid": "server-key-001", "use": "sig", "alg": "ES256", "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU", "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0" }] } The well-known path follows [RFC8615] conventions. The path "agent-trust-keys" avoids collision with other well-known endpoints such as /.well-known/jwks.json. 9.2. Key Caching Agents SHOULD cache the JWKS document to avoid fetching it on every request. The HTTP Cache-Control header on the JWKS response indicates the cache duration. A typical cache duration is one hour. Agents MUST refresh the cached JWKS document if they encounter a response signed with a key identifier (kid) not present in their cached document. 9.3. Key Rotation Key rotation is supported through the JWKS endpoint. When a server rotates its signing key: 1. Publish both old and new keys in the JWKS document. 2. Begin signing responses with the new key. 3. After a transition period, remove the old key. This allows agents with cached old keys to continue verifying responses during the transition. 10. Replay Protection 10.1. Nonce Requirements Each ATTP request MUST carry a unique nonce in the X-Agent-Nonce header. The nonce MUST be cryptographically random with a minimum of 128 bits of entropy, hex-encoded to a 32-character string. The nonce is included in the signed content, binding it cryptographically to the request. An attacker who captures a valid ATTP request cannot modify the nonce without invalidating the signature. 10.2. Timestamp Window The X-Agent-Timestamp header MUST contain an ISO 8601 timestamp [RFC3339]. The server MUST reject requests whose timestamp is outside the acceptable window. The default window is plus or minus 300 seconds (5 minutes) from the server's current time. Servers MAY configure a different window but MUST NOT exceed plus or minus 600 seconds. The timestamp window bounds replay vulnerability: even if an attacker captures a request, they have at most the window duration to attempt replay, and the nonce cache prevents even that. 10.3. Nonce Store Requirements The server MUST maintain a nonce store that records all nonces received within the timestamp validity window. o On receipt: check if nonce exists in store. If yes, reject as replay (HTTP 409). If no, add to store. o Nonce entries MUST be expired after the timestamp window closes, bounding memory requirements. o For multi-instance deployments, the nonce store MUST be shared across instances (e.g., Redis). The combination of nonce uniqueness and timestamp window provides robust replay protection with bounded resource consumption. 11. Audit Trail 11.1. Automatic Recording The ATTP middleware MUST record every request-response pair in a tamper-evident audit trail. This recording is automatic; application code MUST NOT need to implement logging for ATTP interactions. Each audit record contains: o Record identifier (UUID v4) [RFC9562] o Agent identifier (from verified passport) o Agent trust level o Agent owner (from passport) o Request timestamp o HTTP method and request path o SHA-256 hash of request body o Request signature (from X-Agent-Signature) o Response status code o SHA-256 hash of response body o Response signature (from X-Server-Signature) o Processing duration (milliseconds) o Hash pointer to previous audit record The body itself is not stored (to avoid retaining sensitive payloads); the SHA-256 hash enables later verification. 11.2. Hash-Chained Records Each audit record contains a SHA-256 hash of the previous record's serialized content, creating a hash chain per [draft-sharif-agent-audit-trail]. The first record has a null hash pointer. This hash chain is tamper-evident: if any record is modified, deleted, or inserted, the chain breaks and tampering is detectable by any party that verifies it. 11.3. Export Formats ATTP audit trails MUST support export in the following formats: JSONL: One JSON object per line, suitable for log aggregation systems and streaming processors. Syslog: RFC 5424 structured data format, suitable for enterprise SIEM integration. 12. URL Scheme 12.1. Scheme Definition ATTP defines the URI scheme "attp" for identifying resources accessible via the Agent Trust Transport Protocol. The scheme is registered per [RFC7595]. Scheme syntax: attp-URI = "attp://" authority path-abempty [ "?" query ] [ "#" fragment ] The "attp" scheme implies: o Mandatory Agent Passport verification o Mandatory per-message signing (both directions) o Mandatory trust-level evaluation o Mandatory audit trail recording o Transport over HTTPS (TLS required) There is no insecure counterpart. Unlike HTTP (http:// vs https://), the attp:// scheme inherently implies full security. 12.2. Default Port The default port for ATTP is 8443. This port is selected to avoid conflict with the standard HTTPS port (443) while remaining within the common range for secure services. When the port is omitted from the URI, the ATTP agent component MUST connect to port 8443. 12.3. URI Format attp://host[:port]/path[?query] Examples: attp://api.example.com/v1/charges attp://api.example.com:9443/v1/users?limit=10 attp://trust.internal.corp/agents/register 13. Backward Compatibility 13.1. HTTP Infrastructure ATTP messages are standard HTTP messages. All ATTP- specific information is carried in HTTP headers and in the cryptographic relationship between headers and body. No modifications to HTTP framing, body encoding, or transport semantics are required. Existing infrastructure forwards ATTP transparently: o Load balancers (HAProxy, NGINX, AWS ALB) forward all headers including X-Agent-* headers. o CDNs (Cloudflare, Fastly, Akamai) cache and forward ATTP responses, preserving X-Server-* headers. o Reverse proxies and API gateways forward ATTP traffic. o WAFs inspect ATTP as standard HTTP traffic with additional headers available for custom rules. o Monitoring tools capture ATTP as standard HTTP with ATTP headers available for agent-specific analysis. ATTP's per-message signing provides security that survives transit through TLS-terminating intermediaries. When a request passes through a TLS-terminating load balancer, the ATTP signature remains verifiable at the backend server, confirming the body was not modified in transit. 13.2. Upgrade Path Servers transitioning from HTTPS to ATTP can operate in three modes: Strict: Reject all non-ATTP requests (HTTP 426 Upgrade Required). Permissive: Accept both ATTP and standard HTTP requests, applying ATTP verification only when ATTP headers are present. Upgrade: Accept standard HTTP requests but include an Upgrade header in responses suggesting ATTP. Non-ATTP servers that receive requests with X-Agent-* headers will ignore the unknown headers and process the request as standard HTTP. This enables gradual adoption. 14. Error Handling ATTP defines specific error responses for protocol-level failures, using standard HTTP status codes with structured JSON error bodies. All error responses are machine- readable for autonomous agent consumption. 400 Bad Request - missing_attp_headers: { "error": "missing_attp_headers", "missing_headers": ["X-Agent-Trust", "X-Agent-Signature"] } Remedial action: agent adds missing headers. 401 Unauthorized - invalid_passport: { "error": "invalid_passport", "reason": "expired" } Reasons: "signature_invalid", "expired", "issuer_untrusted", "malformed". Remedial action: obtain new passport from issuer. 401 Unauthorized - invalid_signature: { "error": "invalid_signature", "reason": "signature_mismatch" } Reasons: "signature_mismatch", "key_mismatch", "canonicalization_error". 403 Forbidden - insufficient_trust_level: { "error": "insufficient_trust_level", "required_level": "L3", "agent_level": "L1" } Remedial action: request higher trust level or find alternative endpoint. 408 Request Timeout - timestamp_expired: { "error": "timestamp_expired" } Indicates clock skew or delayed request. 409 Conflict - nonce_reuse: { "error": "nonce_reuse" } Indicates potential replay attack. No additional detail to avoid information leakage. 426 Upgrade Required - attp_required: { "error": "attp_required", "upgrade": "ATTP/1.0", "documentation": "https://example.com/attp" } Server operates in strict mode; ATTP headers required. 15. Security Considerations Mandatory security model: ATTP eliminates the "forgot to enable TLS" class of vulnerabilities. There is no insecure mode, no optional signing, and no configuration that disables security. Every protocol interaction requires identity, signing, and audit. Trust evaluation at protocol layer: Trust-gated access prevents application-layer bypasses. An application vulnerability cannot bypass trust evaluation because trust is enforced in protocol middleware before application code executes. Bidirectional signing: Response signing prevents response tampering by intermediaries. Unlike TLS, which protects only the transport channel, ATTP signatures survive transit through TLS-terminating proxies, CDNs, and load balancers. Replay protection: The combination of unique nonce and bounded timestamp window prevents replay attacks with bounded resource consumption for the nonce store. Privacy: Agent identity is visible to the server by design. This is intentional for audit and accountability purposes. Servers MUST protect agent identity data per applicable privacy regulations. Agents operating in privacy-sensitive contexts SHOULD use pseudonymous identifiers in their passports. Clock skew: The timestamp window (default 300 seconds) accommodates reasonable clock drift. Agents and servers SHOULD synchronize clocks via NTP [RFC5905]. Key compromise: If an agent's private key is compromised, the passport issuer SHOULD revoke the agent's passport. Servers performing L3+ verification will detect the revocation. Key rotation procedures are specified in Section 9.3. Algorithm agility: The X-ATTP-Version header enables future protocol versions to introduce post-quantum signature algorithms without breaking backward compatibility with existing deployments. Nonce store exhaustion: Attackers may attempt to exhaust the nonce store by sending large volumes of unique nonces. The timestamp window bounds the store's memory requirements. Servers SHOULD implement rate limiting on ATTP requests. 16. IANA Considerations 16.1. ATTP URI Scheme Registration This document requests registration of the "attp" URI scheme per [RFC7595]: Scheme name: attp Status: Permanent Applications/protocols that use this scheme: Agent Trust Transport Protocol (ATTP) Contact: R. Sharif (contact@agentsign.dev) Change Controller: IESG References: This document 16.2. Port Number Registration This document requests registration of a TCP port number for ATTP: Service Name: attp Transport Protocol: TCP Assignee: R. Sharif (contact@agentsign.dev) Contact: R. Sharif (contact@agentsign.dev) Description: Agent Trust Transport Protocol Reference: This document Port Number: 8443 16.3. ATTP Header Field Registration This document requests registration of the following HTTP header fields in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained by IANA: +---------------------+----------+-----------+ | Header Field Name | Status | Reference | +---------------------+----------+-----------+ | X-Agent-Trust | standard | this doc | | X-Agent-Signature | standard | this doc | | X-Agent-Nonce | standard | this doc | | X-Agent-Timestamp | standard | this doc | | X-ATTP-Version | standard | this doc | | X-Server-Signature | standard | this doc | | X-Server-Nonce | standard | this doc | | X-Server-Timestamp | standard | this doc | +---------------------+----------+-----------+ 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7595] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . [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, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . 17.2. Informative References [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [draft-sharif-mcps-secure-mcp] Sharif, R., "MCPS: Cryptographic Security Layer for the Model Context Protocol", Internet-Draft draft-sharif-mcps-secure-mcp-02, March 2026, . [draft-sharif-agent-payment-trust] Sharif, R., "Agent Payment Trust: Cryptographic Payment Authorization for Autonomous AI Agents", Internet-Draft draft-sharif-agent-payment-trust-00, March 2026, . [draft-sharif-agent-audit-trail] Sharif, R., "Agent Audit Trail: Hash-Chained Interaction Records for AI Agent Systems", Internet-Draft draft-sharif-agent-audit-trail-00, March 2026, . [draft-sharif-agent-transport-protocol] Sharif, R., "ATP: Agent Transport Protocol for Asynchronous Agent Delivery", Internet-Draft draft-sharif-agent-transport-protocol-00, March 2026, . Appendix A. Example ATTP Exchange The following is a complete ATTP request-response exchange for a payment processing endpoint. A.1. Request POST /v1/charges HTTP/1.1 Host: api.example.com Content-Type: application/json X-ATTP-Version: 1.0 X-Agent-Trust: eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIs ImtpZCI6InRhLWtleS0wMDEifQ.eyJzdWIiOiJwYXltZW50 LWJvdC0wMDEiLCJpc3MiOiJ0cnVzdC5leGFtcGxlLmNvbSI sImlhdCI6MTcxMTcwMDAwMCwiZXhwIjoxNzExNzg2NDAwLCJ 0cnVzdF9sZXZlbCI6IkwzIiwiY2FwYWJpbGl0aWVzIjpbIn JlYWQiLCJ3cml0ZSIsInBheW1lbnQiXSwib3duZXIiOiJBY2 1lIENvcnAiLCJhZ2VudF90eXBlIjoiYXV0b25vbW91cyJ9. MEUCIQDxR2s...signature... X-Agent-Signature: MEUCIQCvK7n...signature-over-body X-Agent-Nonce: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 X-Agent-Timestamp: 2026-03-29T14:30:00.000Z {"amount":5000,"currency":"usd","description":"Widget"} A.2. Decoded Agent Passport Payload { "sub": "payment-bot-001", "iss": "trust.example.com", "iat": 1711700000, "exp": 1711786400, "trust_level": "L3", "capabilities": ["read", "write", "payment"], "owner": "Acme Corp", "agent_type": "autonomous", "pub_key": { "kty": "EC", "crv": "P-256", "x": "f83OJ3D2xF1Bg8vub9tLe...", "y": "x_FEzRu9m36HLN_tue659L..." }, "origin": "agents.acme.com" } A.3. Response HTTP/1.1 200 OK Content-Type: application/json X-Server-Signature: MEQCIFhN...server-signature... X-Server-Nonce: f1e2d3c4b5a6f7e8d9c0b1a2f3e4d5c6 X-Server-Timestamp: 2026-03-29T14:30:00.150Z {"id":"ch_abc123","amount":5000,"currency":"usd", "status":"succeeded"} A.4. Middleware Verification Sequence 1. Extract X-ATTP-Version: "1.0" - PASS 2. Decode X-Agent-Trust JWT 3. Fetch issuer JWKS: trust.example.com /.well-known/agent-trust-keys 4. Verify passport signature - PASS 5. Check passport expiration - PASS (not expired) 6. Check issuer trust - PASS (trusted) 7. Extract trust_level: L3 8. Endpoint /v1/charges requires: L3 9. Trust check: L3 >= L3 - PASS 10. Verify X-Agent-Signature against body - PASS 11. Check X-Agent-Nonce not in store - PASS (unique) 12. Check X-Agent-Timestamp within window - PASS 13. Forward to application handler 14. Sign response body with server key 15. Record audit trail entry (hash-chained) Appendix B. Comparison with HTTP/OAuth The following table maps HTTP and OAuth features to their ATTP equivalents. +---------------------------+---------------------------+ | HTTP/OAuth | ATTP Equivalent | +---------------------------+---------------------------+ | URL Scheme | | | http:// (insecure) | (no equivalent, no | | https:// (secure) | insecure mode) | | | attp:// (mandatory | | | security) | +---------------------------+---------------------------+ | Identity | | | OAuth Bearer token | Agent Passport (JWT with | | (delegated human auth) | trust level, signed by | | | issuer, mandatory) | +---------------------------+---------------------------+ | Request Integrity | | | None (HTTP) | X-Agent-Signature (ECDSA | | TLS (transport only) | P-256 over body, survives| | | TLS termination) | +---------------------------+---------------------------+ | Response Integrity | | | None (HTTP) | X-Server-Signature (ECDSA | | TLS (transport only) | P-256 over response) | +---------------------------+---------------------------+ | Access Control | | | OAuth scopes | Trust levels (L0-L4) at | | (application layer) | protocol layer before | | | app code executes | +---------------------------+---------------------------+ | Replay Protection | | | None (HTTP) | X-Agent-Nonce + timestamp | | CSRF tokens (web only) | (cryptographically bound | | | to signature) | +---------------------------+---------------------------+ | Audit | | | Application-layer logs | Automatic hash-chained | | (developer-implemented) | audit trail (protocol | | | layer, no dev effort) | +---------------------------+---------------------------+ | Key Discovery | | | OAuth .well-known/openid | /.well-known/agent-trust | | -configuration | -keys (JWKS, RFC 7517) | +---------------------------+---------------------------+ | Signing Algorithm | | | Varies (RS256, ES256, | ECDSA P-256 only (ES256, | | HS256, etc.) | IEEE P1363, low-S norm) | +---------------------------+---------------------------+ | Security Model | | | Optional (http vs https) | Mandatory (no insecure | | Configurable (OAuth) | mode, no bypass) | +---------------------------+---------------------------+ Appendix C. Server Middleware Implementation Guide This appendix provides guidance for implementing ATTP middleware in common web frameworks. C.1. Express.js (Node.js) const attp = require('attp-middleware'); // Global: all endpoints require L2 minimum app.use(attp({ privateKey: process.env.ATTP_PRIVATE_KEY, keyId: 'server-key-001', trustedIssuers: ['trust.example.com'], minTrust: 'L2', nonceStore: 'redis://localhost:6379' })); // Per-endpoint: payment requires L3 app.post('/v1/charges', attp({ minTrust: 'L3' }), async (req, res) => { // req.agent.id = "payment-bot-001" // req.agent.trustLevel = "L3" // req.agent.owner = "Acme Corp" const charge = await processPayment(req.body); res.json(charge); // Response auto-signed by middleware // Audit record auto-generated } ); C.2. FastAPI (Python) from attp import ATTPMiddleware app = FastAPI() app.add_middleware(ATTPMiddleware, private_key=os.environ["ATTP_PRIVATE_KEY"], key_id="server-key-001", trusted_issuers=["trust.example.com"], min_trust="L2", nonce_store="redis://localhost:6379" ) @app.post("/v1/charges") async def create_charge(request: Request): agent = request.state.agent # agent.id, agent.trust_level, agent.owner return {"id": "ch_abc123", "status": "succeeded"} C.3. JWKS Endpoint Setup The middleware MUST automatically serve the JWKS endpoint at /.well-known/agent-trust-keys. The endpoint returns: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: public, max-age=3600 { "keys": [{ "kty": "EC", "crv": "P-256", "kid": "server-key-001", "use": "sig", "alg": "ES256", "x": "", "y": "" }] } C.4. Operating Modes The middleware supports three operating modes: Strict: Reject non-ATTP requests with HTTP 426. Use for ATTP-only servers. Permissive: Accept both ATTP and regular HTTP. Apply verification only when ATTP headers present. Use during migration. Upgrade: Accept all requests but suggest ATTP in responses via Upgrade header. Use for gradual adoption. C.5. Nonce Store Configuration Single instance: In-memory store (default). Multi-instance: Redis or equivalent distributed cache. Required when running behind a load balancer. Interface: has(nonce: string): boolean add(nonce: string, ttl: number): void Author's Address Raza Sharif CyberSecAI Ltd 205 Regent Street London W1B 4HB United Kingdom Email: contact@agentsign.dev