Network Working Group B. Le Internet-Draft Redthread Security Intended status: Standards Track 30 October 2026 Expires: 3 May 2027 Agent Passports and Delegation Receipts for Autonomous Software Agents draft-le-agent-passport-00 Abstract Autonomous software agents call APIs, tools and other agents on behalf of people and organisations. A party receiving such a call today can usually learn only that some bearer credential was presented. It cannot learn which organisation is accountable for the agent, which model, configuration and tools the agent is running, on whose behalf it is acting, or whether any of that has changed since it was approved. This document defines two signed objects and how they travel on HTTP requests. An Agent Passport binds an agent's public key to its accountable controller and to a digest of its build. A Delegation Receipt records one step of authority passing from a principal, through a delegator, to an agent; a chain of receipts can only narrow that authority. Requests carry both, and are signed with the agent's key using HTTP Message Signatures, so a relying party can check, without contacting the issuer per request, who the agent is, what it is running, on whose behalf it acts and what it may do. 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 3 May 2027. Le Expires 3 May 2027 [Page 1] Internet-Draft Agent Passports October 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. Relationship to Other Work . . . . . . . . . . . . . . . 4 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Agent Passport . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Claims . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Configuration Digest . . . . . . . . . . . . . . . . . . 8 4.4. Issuer Metadata . . . . . . . . . . . . . . . . . . . . . 8 4.5. Controller Authorisation . . . . . . . . . . . . . . . . 8 4.6. Validation . . . . . . . . . . . . . . . . . . . . . . . 9 5. Delegation Receipts . . . . . . . . . . . . . . . . . . . . . 9 5.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Claims . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Grants and Attenuation . . . . . . . . . . . . . . . . . 10 5.4. Root Receipts . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Chain Validation . . . . . . . . . . . . . . . . . . . . 12 5.6. Request Matching . . . . . . . . . . . . . . . . . . . . 13 6. Binding to HTTP Requests . . . . . . . . . . . . . . . . . . 13 6.1. Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Verification . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Relationship to Web Bot Auth . . . . . . . . . . . . . . 15 7. Status and Revocation . . . . . . . . . . . . . . . . . . . . 15 8. Transparency . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9.1. Holder Key Compromise . . . . . . . . . . . . . . . . . . 15 9.2. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.3. Build Assertions Are Assertions . . . . . . . . . . . . . 16 9.4. Attenuation and Matching . . . . . . . . . . . . . . . . 16 Le Expires 3 May 2027 [Page 2] Internet-Draft Agent Passports October 2026 9.5. Ceiling, Not Grant . . . . . . . . . . . . . . . . . . . 16 9.6. Controller Domain . . . . . . . . . . . . . . . . . . . . 16 9.7. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 16 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11.1. Media Types . . . . . . . . . . . . . . . . . . . . . . 17 11.2. JSON Web Token Claims . . . . . . . . . . . . . . . . . 17 11.3. HTTP Field Names . . . . . . . . . . . . . . . . . . . . 18 11.4. Well-Known URIs . . . . . . . . . . . . . . . . . . . . 18 11.5. OAuth URI . . . . . . . . . . . . . . . . . . . . . . . 19 11.6. Grant Members . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23 A.1. Passport (Agent B) . . . . . . . . . . . . . . . . . . . 23 A.2. Delegation Chain . . . . . . . . . . . . . . . . . . . . 24 A.3. Request . . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Agents act for someone, through something. A relying party (an API, an MCP server, a payment service, a website) that receives an agent's request needs to answer four questions before it acts: 1. Who is accountable for this agent? 2. Is it the same agent, running the same build, that was approved? 3. On whose behalf is it acting, and within what limits? 4. Is any of that revoked? Existing mechanisms each answer part of this. OAuth 2.0 [RFC6749] and Token Exchange [RFC8693] convey authorisation to a client and can name an actor, but a client is not a build: the same client credential can sit in front of a different model, prompt or tool set. Workload identity, such as [SPIFFE] and the WIMSE workload identity token [WIMSE-S2S], identifies a running workload by where it runs, not by what it is. HTTP Message Signatures [RFC9421] and the work of the IETF Web Bot Auth working group [WEB-BOT-AUTH] let a client prove possession of a key on each request, but say nothing about delegation. Sender-constrained tokens [RFC9449] bind a token to a key, not to a delegation chain. Transaction Tokens [TXN-TOKENS] carry context within one trust domain, not across organisations. Le Expires 3 May 2027 [Page 3] Internet-Draft Agent Passports October 2026 This document composes these pieces into a profile for agents: * An *Agent Passport* (Section 4): a JWT [RFC7519] binding the agent's public key to a controller and a build digest. * A *Delegation Receipt* (Section 5): a JWT naming a principal, bound to a delegate's key, carrying a scoped and time-limited subset of authority. Receipts chain, and each step may only attenuate. * A *request binding* (Section 6): passports and receipts travel in HTTP header fields covered by an HTTP Message Signature made with the acting agent's key. 1.1. Relationship to Other Work Several individual drafts address agent authentication and authorisation. [AIAGENT-AUTH] profiles WIMSE and the OAuth 2.0 family for agents. [AAUTH] defines an authorisation protocol for agent access to resources, with HTTP message signatures and key discovery. This document is complementary to both and adds three things neither defines: 1. *Build binding.* The passport commits to the agent's model, configuration and tools, and receipts can be bound to a build, so authority approved for one build does not carry over to another under the same key. 2. *Cross-organisation attenuation that the relying party verifies.* Each step of a delegation chain is checked by the relying party against the step before it, with a test that never accepts a widening, and intersected with the principal's own access. 3. *Accountability of the controller.* A controller's origin authorises the issuers that may vouch for its agents, so a relying party learns who is answerable for an agent, not only which key it holds. An authorisation server following [AIAGENT-AUTH] or [AAUTH] can issue root receipts as defined here, and a passport's holder key can be the key those protocols already bind. 1.2. Goals * Identify the accountable party and the build, not only the key. * Make delegation verifiable by the party acting on it, across organisational boundaries. Le Expires 3 May 2027 [Page 4] Internet-Draft Agent Passports October 2026 * Guarantee by construction that a delegation chain cannot widen authority. * Allow verification without per-request contact with any issuer. * Compose with existing identity providers rather than replace them. 1.3. Non-goals * This document does not prove that an agent is _actually_ running the build its passport names. The build digest is the issuer's assertion. Remote attestation of the runtime is out of scope; an issuer MAY condition issuance on such evidence. * It does not define how a relying party decides whether to trust a controller, an issuer or a build. That is local policy. * It does not define reputation or scoring. 2. Conventions and Definitions 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: Software that takes actions, including calling other services, without a person approving each action. Controller: The organisation accountable for an agent, identified by an HTTPS origin [RFC6454] it controls. Issuer: The entity that signs Agent Passports: the controller itself, or a third party the controller authorises (Section 4.5). Build: The properties that determine an agent's behaviour: model identifier, configuration (for example system instructions, tool allow-list and policy) and tool set. Holder Key: The key pair whose public half is bound into a passport, and whose private half the agent uses to sign requests and child receipts. Principal: The person or service on whose behalf a chain of agents acts. Delegator: The signer of a Delegation Receipt: an authorisation Le Expires 3 May 2027 [Page 5] Internet-Draft Agent Passports October 2026 server acting for the principal (root receipts), or an agent passing on part of its authority (child receipts). Delegate: The agent a Delegation Receipt is bound to, identified by its holder key. Relying Party (RP): The party that receives an agent's request and verifies it. Tool Attestation: A signed statement by a third party about a tool the agent may call, for example an MCP server [MCP], such as an in-toto statement [IN-TOTO] naming the tool's artifact digest. Digest Object: A JSON object {"alg": , "val": }, where alg is a hash algorithm name from the IANA "Named Information Hash Algorithm Registry" [RFC6920] (implementations MUST support sha-256). Digest Objects are compared by alg and by decoded bytes. 3. Overview Principal/AS Issuer Agent A Agent B RP | | | | | | |<- key + build --| | | | |-- passport A -->| | | |-- root receipt (to A) ------->| | | | | |-- child ---->| | | | | receipt | | | | | |== request ==>| | | | | passports B,A| | | | | receipts r,c | | | | | signed by B | | |<------------ status lists (cached) -----------| | | | |<- decision --| 1. Each agent generates a holder key and obtains a passport from an issuer, presenting its build. 2. An authorisation server acting for the principal signs a root receipt bound to agent A's key. Agent A may pass part of that authority to agent B with a child receipt, signed with A's holder key. 3. Agent B sends its own passport, the passports of every agent above it in the chain, and the receipts, and signs the request with its holder key. Le Expires 3 May 2027 [Page 6] Internet-Draft Agent Passports October 2026 4. The RP validates every passport and receipt, matches the request against the leaf's grants, intersects with what the principal itself may do, and applies local policy. 4. Agent Passport 4.1. Format An Agent Passport is a JWT [RFC7519] in JWS Compact Serialization [RFC7515]. The JOSE header MUST contain typ with the value agent- passport+jwt, alg, and kid. Implementations MUST support EdDSA with Ed25519 [RFC8037], MAY support other asymmetric algorithms, and MUST follow [RFC8725]; none and symmetric algorithms MUST NOT be used. 4.2. Claims iss (REQUIRED): The issuer identifier, an HTTPS URL. The issuer's keys are found through its metadata (Section 4.4). sub (REQUIRED): The JWK Thumbprint URI [RFC9278] of the holder public key, computed with SHA-256 [RFC7638]. cnf (REQUIRED): A confirmation claim [RFC7800] whose jwk member is the holder public key. Its SHA-256 JWK thumbprint MUST equal the thumbprint in sub. agent_controller (REQUIRED): The controller's origin, an HTTPS URL with no path, query or fragment, for example https://example.com. agent_build (REQUIRED): A JSON object describing the build. Members: * model (REQUIRED): a string identifying the model, in the form vendor/model-id. * config (REQUIRED): a Digest Object over the JCS canonicalisation [RFC8785] of the agent's configuration object (Section 4.3). * tools (OPTIONAL): an array of objects, each with id (a tool identifier; for an MCP server, its registry name) and optionally attestation, a Digest Object of the Tool Attestation the build was approved against. * code (OPTIONAL): a Digest Object of the agent's own code artifact. agent_aliases (OPTIONAL): An array of other identifiers for the same Le Expires 3 May 2027 [Page 7] Internet-Draft Agent Passports October 2026 agent, for example a SPIFFE ID or an identity provider's object identifier. Aliases are informational. An RP MUST NOT treat a match on an alias as verification of the passport. iat, exp, jti (REQUIRED): As in [RFC7519]. exp minus iat MUST NOT exceed 86400 seconds. status (RECOMMENDED): A status reference as defined in [STATUS-LIST]. An RP MUST reject a passport whose agent_build contains a member it does not understand, unless local policy names that member as ignorable. 4.3. Configuration Digest The configuration object is a JSON object defined by the agent framework. It SHOULD include at least the system instructions, the tool allow-list and any policy the agent enforces on itself. Hashing its JCS canonical form [RFC8785] gives semantically identical configurations the same digest across implementations. Any change to model, config, tools or code is a new build and MUST result in a new passport. The *build digest* of a passport is the Digest Object, with alg sha-256, over the JCS canonicalisation of its agent_build claim. An RP that pins a build compares build digests. 4.4. Issuer Metadata An issuer publishes metadata at the well-known URI formed by inserting /.well-known/agent-passport-issuer between the host and path of its issuer identifier, as [RFC8414] does for authorisation servers. The metadata is a JSON object with at least issuer (equal to the issuer identifier) and jwks_uri (an HTTPS URL of a JWK Set [RFC7517]). An RP selects the verification key by the passport's kid. 4.5. Controller Authorisation The controller publishes, at /.well-known/agent-controller [RFC8615] on its origin, a JSON object: { "issuers": ["https://issuer.example"], "contact": "mailto:security@example.com" } Le Expires 3 May 2027 [Page 8] Internet-Draft Agent Passports October 2026 An RP verifying a passport MUST check that iss is equal to agent_controller or appears in issuers. Sharing an origin is not sufficient. If the document cannot be retrieved and no cached copy is valid, the RP MUST treat the passport as invalid. An RP MAY cache the document for up to 24 hours, which bounds how long a withdrawn authorisation remains effective (Section 9). 4.6. Validation To validate a passport, an RP: 1. Parses the JWS and checks typ, alg and kid against [RFC8725] and local policy. 2. Obtains the issuer's key (Section 4.4) and verifies the signature. 3. Checks iat, exp and the 86400-second limit, allowing clock skew of at most 60 seconds. 4. Checks that the thumbprint of cnf.jwk equals sub. 5. Checks controller authorisation (Section 4.5). 6. If status is present, checks the referenced status (Section 7). 7. Rejects unknown agent_build members, as described in Section 4.2. 8. Applies local policy to agent_controller, agent_build and iss. 5. Delegation Receipts 5.1. Format A Delegation Receipt is a JWT with JOSE header typ set to agent- delegation+jwt, signed by the delegator. Header and algorithm requirements are as for passports (Section 4). 5.2. Claims iss (REQUIRED): The delegator. In a root receipt, the issuer identifier of the authorisation server that signed it. In a child receipt, the JWK Thumbprint URI of the delegating agent's holder key. sub (REQUIRED): The principal, as identified by the root receipt's authorisation server. Every receipt in a chain MUST carry the same sub as the root. Le Expires 3 May 2027 [Page 9] Internet-Draft Agent Passports October 2026 cnf (REQUIRED): A confirmation claim [RFC7800] whose jkt member is the base64url SHA-256 JWK thumbprint of the delegate's holder key. act (OPTIONAL): As in [RFC8693]: the chain of acting parties, outermost the current delegate. Informational; chain validation does not depend on it. dlg_parent (REQUIRED in a child receipt): A Digest Object, with alg sha-256, over the ASCII bytes of the parent receipt's JWS Compact Serialization. It MUST be absent in a root receipt. dlg_build (OPTIONAL): The build digest (Section 4.3) of the delegate's passport at the time of delegation. If present, the RP MUST reject the receipt unless the delegate's presented passport has the same build digest. dlg_grants (REQUIRED): A non-empty array of grant objects (Section 5.3). dlg_limits (OPTIONAL): An object with max_calls (a positive integer) and/or max_spend (an object with currency, an [ISO4217] code, and amount, a decimal string). purp (OPTIONAL): A human-readable statement of why authority was delegated, as in [TXN-TOKENS]. Recorded, not enforced. aud (OPTIONAL): The RPs the receipt is intended for. If present, an RP not listed MUST reject the receipt. iat, exp, jti (REQUIRED): As in [RFC7519]. status (RECOMMENDED): A status reference as defined in [STATUS-LIST]. An RP MUST reject a receipt containing a member of a grant object or of dlg_limits that it does not understand. Dropping an unknown restriction would widen authority. 5.3. Grants and Attenuation A grant object describes requests the delegate may make: host (REQUIRED): A DNS host name; or a wildcard, "*." followed by a DNS host name, matching that name's proper subdomains; or "*", matching any host. Host names are compared after lowercasing, removing one trailing dot and converting to A-labels [RFC5891]. A "*." pattern whose remainder is a public suffix [PSL] MUST be rejected. IP literals are permitted only as exact values. Le Expires 3 May 2027 [Page 10] Internet-Draft Agent Passports October 2026 port (OPTIONAL): The TCP port. Default 443. methods (OPTIONAL): HTTP methods [RFC9110], case-sensitive. Default ["GET", "HEAD"]. paths (OPTIONAL): An array of path specifiers, each either an exact path or a prefix pattern ending in /*, which matches the path before /* and any path below it. Default ["/*"]. tools (OPTIONAL): Tool or operation names the delegate may invoke, for example MCP tool names. If present, a request that invokes a tool (as determined by the RP's protocol, for example an MCP tools/call) MUST name one of them. max_body_bytes (OPTIONAL): The largest request body allowed. Default 0. A child receipt *attenuates* its parent if and only if all of the following hold: 1. Every grant C in the child is covered by at least one grant P in the parent. C is covered by P when: * Host: C.host equals P.host; or P.host is *; or P.host is *.D and C.host, with any leading *. removed, ends with .D. * C.port equals P.port. * C.methods is a subset of P.methods. * Each path in C.paths is covered by some path in P.paths. If the P path is exact, the C path MUST be the identical exact path. If the P path is a prefix pattern p/*, the C path (exact or pattern) MUST equal p or begin with p/. * If P.tools is present, C.tools is present and a subset of P.tools. * C.max_body_bytes is no greater than P.max_body_bytes. 2. Every limit present in the parent is present in the child with a value no greater, and the same currency. 3. The child's exp is no later than the parent's. 4. If the parent has aud, the child's aud is present and a subset of it. Le Expires 3 May 2027 [Page 11] Internet-Draft Agent Passports October 2026 This test is conservative. It may reject some children that are in fact narrower, but it never accepts one that is broader. Implementations MUST NOT relax it. 5.4. Root Receipts A root receipt has no dlg_parent. It MUST be signed by an authorisation server acting for the principal, whose keys the RP obtains from its metadata [RFC8414], and whose authority to speak for sub the RP accepts by local policy. A root receipt is typically issued through Token Exchange [RFC8693]: the subject token is the principal's, the actor token is the agent's passport, and requested_token_type is urn:ietf:params:oauth:token-type:agent- delegation. An agent MUST NOT issue a root receipt. Agent-to-agent delegation always uses a child receipt, so that every step is checked against the step before it. 5.5. Chain Validation Given the passports and the receipt chain presented with a request (Section 6), an RP: 1. Checks that the chain has at most 8 receipts, ordered from root to leaf. 2. Validates the root receipt's signature with its authorisation server's key, and its iat, exp, aud and status. 3. For each child receipt, in order: 1. Finds the presented passport whose sub equals the child's iss, validates that passport (Section 4.6), and checks that its holder key's thumbprint equals the previous receipt's cnf.jkt. 2. Verifies the child's signature with that passport's cnf.jwk. 3. Checks dlg_parent against the previous receipt, sub against the root's, and attenuation (Section 5.3). 4. Checks iat, exp, aud and status. 4. Checks that the leaf's cnf.jkt is the thumbprint of the key that signed the request. If the leaf has dlg_build, checks it against the acting agent's passport. Le Expires 3 May 2027 [Page 12] Internet-Draft Agent Passports October 2026 5. Matches the request against the leaf's grants (Section 5.6). 6. Checks limits: for every receipt in the chain, keyed by its iss and jti, the RP's count of requests (and spend) accepted under that receipt, including this one, does not exceed its dlg_limits. 7. Authorises the request as the principal sub would be authorised by the RP's own access control, and permits it only if both that check and the grants allow it. Grants are a ceiling, never a grant of access the principal lacks. Limits are counted per RP. Unless a receipt's aud names exactly one RP, the effective limit across RPs may be higher than any single value. 5.6. Request Matching A request matches a grant when: * Its scheme is https. * Its host, normalised as in Section 5.3, matches the grant's host, and its port equals the grant's port. * Its method is in the grant's methods. * Its path, normalised per [RFC3986] Section 6.2.2 (case normalisation, then percent-encoding normalisation, then dot- segment removal, in that order), matches one of the grant's paths. The query component is not matched. A request whose path contains %2F, %5C or %00 after normalisation MUST NOT match any grant. * Its body is no larger than max_body_bytes. * If the grant has tools, any tool the request invokes is listed. 6. Binding to HTTP Requests 6.1. Header Fields This document defines two HTTP header fields, both Structured Fields [RFC9651]: Agent-Passport: A List whose members are Strings, each the JWS Compact Serialization of a passport. The first member is the acting agent's passport. The remaining members are the passports of every agent that signed a child receipt in the presented chain, in any order. Parameters MUST be ignored. Le Expires 3 May 2027 [Page 13] Internet-Draft Agent Passports October 2026 Agent-Delegation: A List whose members are Strings, each a receipt's JWS Compact Serialization, ordered from root to leaf. Parameters MUST be ignored. A request MAY carry Agent-Passport without Agent-Delegation. It then conveys identity only, and no delegated authority; what such a request may do is local policy. Header sizes grow with chain length. Agents SHOULD keep chains short, and RPs SHOULD accept at least 16 KB for the two fields combined. 6.2. Signing The acting agent MUST sign each request with its holder key using HTTP Message Signatures [RFC9421], with: * covered components including at least "@method", "@target-uri" and "agent-passport"; and, when present, "agent-delegation", "content- digest" [RFC9530] and "signature-agent"; * the created, expires and nonce parameters, with expires no more than 300 seconds after created; * keyid set to the base64url SHA-256 JWK thumbprint of the holder key; * tag set to agent-passport. A request with a body MUST carry Content-Digest and cover it. 6.3. Verification An RP: 1. Parses Agent-Passport and validates the first passport (Section 4.6). 2. Verifies the HTTP message signature with that passport's cnf.jwk. It rejects a signature whose created is more than 60 seconds in the future, whose expires has passed, or whose keyid does not match the key. 3. Rejects the request if the nonce has already been accepted for the same keyid within the signature's validity window plus 60 seconds. Le Expires 3 May 2027 [Page 14] Internet-Draft Agent Passports October 2026 4. If Agent-Delegation is present, performs chain validation (Section 5.5). 5. Records the nonce. 6.4. Relationship to Web Bot Auth The Web Bot Auth working group's documents let an agent identify a key directory with a Signature-Agent field. An agent MAY send both Signature-Agent and Agent-Passport and sign once. In that case "signature-agent" MUST be covered, and the key it resolves to MUST be the passport's holder key; an RP that finds otherwise MUST reject the request. 7. Status and Revocation Passports and receipts SHOULD carry a status claim referencing a Token Status List [STATUS-LIST]. RPs SHOULD cache status lists for no longer than their time-to-live. An RP that cannot obtain a valid status list SHOULD treat the token according to local policy, and SHOULD deny for high-value operations. An issuer SHOULD revoke a passport when the controller reports compromise of the holder key, when the build no longer matches (for example because a Tool Attestation named in agent_build.tools has been withdrawn), or when the controller withdraws authorisation. Revoking a passport invalidates every chain in which its holder delegated, because each such passport is validated during chain validation. 8. Transparency Issuers SHOULD append each passport they issue, and each revocation, to an append-only, publicly verifiable log following [RFC9162], for example served as [TLOG-TILES]. A log lets controllers detect passports issued in their name without authorisation, and lets anyone audit an issuer's history. This document does not require RPs to check log inclusion. 9. Security Considerations 9.1. Holder Key Compromise A stolen holder key lets an attacker act as the agent until its passport expires or is revoked. Lifetimes are capped at 24 hours, and holder keys SHOULD be kept in hardware-backed or platform key stores. Le Expires 3 May 2027 [Page 15] Internet-Draft Agent Passports October 2026 9.2. Replay Requests carry a nonce and a short validity window; RPs keep a nonce cache per keyid (Section 6). Passports and receipts are not request- bound. They MUST NOT be accepted without a valid request signature from the key the leaf receipt is bound to. 9.3. Build Assertions Are Assertions agent_build states what the issuer was told or verified about the build. It does not prove the agent is running it. RPs for whom this matters SHOULD accept passports only from issuers whose issuance policy includes runtime attestation, and SHOULD pin build digests. dlg_build lets a delegator bind authority to the build it approved, so a later build under the same key does not inherit it. 9.4. Attenuation and Matching The coverage test (Section 5.3) and request matching (Section 5.6) are defined together. An implementation that matches requests differently from how it tests coverage can be widened by the difference. Normalisation order matters: decoding %2E%2E after dot- segment removal would let a request escape a path prefix. 9.5. Ceiling, Not Grant Grants never give a principal access it lacks. An RP that skipped the principal check in Section 5.5 would let a receipt for /accounts/* reach every account, not only the principal's. 9.6. Controller Domain Controller authorisation relies on the controller's origin. Loss of control of that origin lets an attacker authorise issuers. RPs MAY pin issuers per controller. Withdrawn authorisations remain effective for as long as RPs cache agent-controller documents, up to 24 hours. 9.7. Algorithms Implementations MUST follow [RFC8725], MUST reject none, and SHOULD restrict accepted algorithms by local policy. Le Expires 3 May 2027 [Page 16] Internet-Draft Agent Passports October 2026 10. Privacy Considerations A passport identifies an agent consistently across RPs, which allows correlation of its activity. Controllers that need unlinkability across RPs SHOULD use distinct holder keys and passports per RP. Configuration is disclosed only as a digest. Receipts identify the principal (sub) to every RP they are shown to, and purp may reveal what the principal asked for; delegators SHOULD keep purp minimal and use aud to limit which RPs see a receipt. The passports of intermediate agents are disclosed to the RP of the acting agent. 11. IANA Considerations 11.1. Media Types This document requests registration of the following media types per [RFC6838]: * Type name: application. Subtype name: agent-passport+jwt. Required parameters: none. Optional parameters: none. Encoding considerations: 8bit; a JWS Compact Serialization, which is ASCII. Security considerations: see Section 9. Interoperability considerations: none. Published specification: this document. Applications that use this media type: AI agents and the services that verify them. Fragment identifier considerations: none. Additional information: none. Person and email address to contact: the author. Intended usage: COMMON. Restrictions on usage: none. Author and change controller: IETF. * Type name: application. Subtype name: agent-delegation+jwt. Other fields as above. 11.2. JSON Web Token Claims This document requests registration of the following claims in the "JSON Web Token Claims" registry. For each, the Change Controller is IETF and the Reference is this document. Le Expires 3 May 2027 [Page 17] Internet-Draft Agent Passports October 2026 +==================+========================+=========+ | Claim | Description | Section | +==================+========================+=========+ | agent_controller | Accountable controller | Section | | | origin of an agent | 4.2 | +------------------+------------------------+---------+ | agent_build | Description of an | Section | | | agent's build | 4.2 | +------------------+------------------------+---------+ | agent_aliases | Other identifiers for | Section | | | the same agent | 4.2 | +------------------+------------------------+---------+ | dlg_parent | Digest of the parent | Section | | | delegation receipt | 5.2 | +------------------+------------------------+---------+ | dlg_build | Build digest the | Section | | | delegation is bound to | 5.2 | +------------------+------------------------+---------+ | dlg_grants | Grants conveyed by a | Section | | | delegation receipt | 5.2 | +------------------+------------------------+---------+ | dlg_limits | Limits on a delegation | Section | | | receipt | 5.2 | +------------------+------------------------+---------+ Table 1 11.3. HTTP Field Names This document requests registration in the "Hypertext Transfer Protocol (HTTP) Field Name Registry": +==================+===========+=================+===========+ | Field Name | Status | Structured Type | Reference | +==================+===========+=================+===========+ | Agent-Passport | permanent | List | Section 6 | +------------------+-----------+-----------------+-----------+ | Agent-Delegation | permanent | List | Section 6 | +------------------+-----------+-----------------+-----------+ Table 2 11.4. Well-Known URIs This document requests registration in the "Well-Known URIs" registry [RFC8615]: Le Expires 3 May 2027 [Page 18] Internet-Draft Agent Passports October 2026 +=======================+===================+===========+===========+ | URI Suffix | Change | Reference | Status | | | Controller | | | +=======================+===================+===========+===========+ | agent-controller | IETF | Section | permanent | | | | 4.5 | | +-----------------------+-------------------+-----------+-----------+ | agent-passport-issuer | IETF | Section | permanent | | | | 4.4 | | +-----------------------+-------------------+-----------+-----------+ Table 3 11.5. OAuth URI This document requests registration of urn:ietf:params:oauth:token- type:agent-delegation in the "OAuth URI" registry, with Common Name "Agent Delegation Receipt", Change Controller IETF and Reference Section 5.4. 11.6. Grant Members This document requests creation of an "Agent Delegation Grant Members" registry (Specification Required), initially containing host, port, methods, paths, tools and max_body_bytes. Each registration MUST state how the member is compared for attenuation. Because RPs reject unknown members (Section 5.2), a new member is safe to deploy: RPs that don't understand it refuse the receipt rather than ignore the restriction. 12. References 12.1. Normative References [ISO4217] ISO, "Codes for the representation of currencies", ISO 4217, n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, DOI 10.17487/RFC3986, January 2005, . Le Expires 3 May 2027 [Page 19] Internet-Draft Agent Passports October 2026 [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, DOI 10.17487/RFC8174, May 2017, . Le Expires 3 May 2027 [Page 20] Internet-Draft Agent Passports October 2026 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", RFC 8725, DOI 10.17487/RFC8725, February 2020, . [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", RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9278] Jones, M. and K. Yasuda, "JWK Thumbprint URI", RFC 9278, DOI 10.17487/RFC9278, August 2022, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, . [RFC9651] Nottingham, M. and P-H. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, . Le Expires 3 May 2027 [Page 21] Internet-Draft Agent Passports October 2026 [STATUS-LIST] Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf- oauth-status-list-20, 20 April 2026, . 12.2. Informative References [AAUTH] Hardt, D., "AAuth Protocol", Work in Progress, Internet- Draft, draft-hardt-oauth-aauth-protocol-00, 29 April 2026, . [AIAGENT-AUTH] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., and N. Steele, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft- klrc-aiagent-auth-01, 30 March 2026, . [IN-TOTO] in-toto project, "in-toto Attestation Framework", n.d., . [MCP] Model Context Protocol project, "Model Context Protocol Specification", n.d., . [PSL] Mozilla Foundation, "Public Suffix List", n.d., . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . Le Expires 3 May 2027 [Page 22] Internet-Draft Agent Passports October 2026 [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [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, . [SPIFFE] CNCF, "Secure Production Identity Framework for Everyone (SPIFFE)", n.d., . [TLOG-TILES] C2SP, "C2SP tlog-tiles", n.d., . [TXN-TOKENS] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-08, 2 March 2026, . [WEB-BOT-AUTH] IETF, "IETF Web Bot Auth Working Group", n.d., . [WIMSE-S2S] Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y. Sheffer, "WIMSE Workload-to-Workload Authentication", Work in Progress, Internet-Draft, draft-ietf-wimse-s2s- protocol-07, 16 October 2025, . Appendix A. Examples TP-A and TP-B stand for the JWK Thumbprint URIs (urn:ietf:params:oauth:jwk-thumbprint:sha-256:...) of agents A and B; jkt-A and jkt-B for the corresponding bare base64url thumbprints. Values are shortened with an ellipsis ("..."). A.1. Passport (Agent B) Le Expires 3 May 2027 [Page 23] Internet-Draft Agent Passports October 2026 { "iss": "https://issuer.example", "sub": "TP-B", "cnf": {"jwk": {"kty": "OKP", "crv": "Ed25519", "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrw..."}}, "agent_controller": "https://example.com", "agent_build": { "model": "examplevendor/model-2026-09", "config": {"alg": "sha-256", "val": "X48E9qOokqqrvdts8nOJR..."}, "tools": [{"id": "io.github.example/ledger-mcp", "attestation": {"alg": "sha-256", "val": "Gk1D..."}}] }, "agent_aliases": ["spiffe://example.com/agent/statements"], "iat": 1793270400, "exp": 1793356800, "jti": "5f0c...", "status": {"status_list": { "idx": 4211, "uri": "https://issuer.example/status/1"}} } A.2. Delegation Chain A principal, through their organisation's authorisation server, lets agent A read account data; agent A lets agent B read only one account's statements. { "iss": "https://login.example.com", "sub": "user:4412", "cnf": {"jkt": "jkt-A"}, "dlg_grants": [{"host": "api.bank.example", "methods": ["GET"], "paths": ["/accounts/*"]}], "dlg_limits": {"max_calls": 500}, "purp": "reconcile October statements", "iat": 1793271000, "exp": 1793300000, "jti": "r1..." } { "iss": "TP-A", "sub": "user:4412", "cnf": {"jkt": "jkt-B"}, "act": {"sub": "TP-B", "act": {"sub": "TP-A"}}, "dlg_parent": {"alg": "sha-256", "val": "8Jq3..."}, "dlg_grants": [{"host": "api.bank.example", "methods": ["GET"], "paths": ["/accounts/123/statements/*"]}], "dlg_limits": {"max_calls": 50}, "iat": 1793271100, "exp": 1793280000, "jti": "r2..." } Le Expires 3 May 2027 [Page 24] Internet-Draft Agent Passports October 2026 A.3. Request Agent B sends its own passport first, then agent A's, because agent A signed the child receipt. Long lines are folded as described in [RFC8792]. NOTE: '\' line wrapping per RFC 8792 GET /accounts/123/statements/2026-10 HTTP/1.1 Host: api.bank.example Agent-Passport: "eyJ0eXAiOiJhZ2VudC1wYXNzcG9ydCtqd3Qi...(B)", \ "eyJ0eXAiOiJhZ2VudC1wYXNzcG9ydCtqd3Qi...(A)" Agent-Delegation: "eyJ0eXAiOiJhZ2VudC1kZWxlZ2F0aW9u...(r1)", \ "eyJ0eXAi...(r2)" Signature-Input: ap=("@method" "@target-uri" "agent-passport" \ "agent-delegation");created=1793271200;expires=1793271260;\ nonce="b3k2...";keyid="jkt-B";tag="agent-passport" Signature: ap=:wqcAqbmYJ2ji2glfAMaRy4gruYYnx2nEFN2HN6jrnDnQCK1u02G\ b04v9EDgwUPiu4A0w6vuQv5lIp5WPpBKRCw==: Appendix B. Open Issues * Expressing grants as an RFC 9396 authorization_details type [RFC9396], so that authorisation servers already supporting rich authorisation requests can issue root receipts directly. * Profiling the passport as, or alongside, a WIMSE workload identity token [WIMSE-S2S]. * A claim carrying a transparency-log inclusion proof. * A root receipt form signed directly by the principal's authenticator (WebAuthn). * A registry of agent_build.model identifiers, or leaving them vendor-defined. * Interaction with Transaction Tokens [TXN-TOKENS] for propagation within one trust domain. * Whether dlg_limits accounting should be shared between RPs. Author's Address Ben Le Redthread Security Email: ben.le@redthreadsec.com Le Expires 3 May 2027 [Page 25]