Agent Passports and Delegation Receipts for Autonomous Software Agents
draft-le-agent-passport-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Ben Le | ||
| Last updated | 2026-10-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-le-agent-passport-00
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": <name>, "val": <base64url
without padding>}, 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.,
<https://www.iso.org/iso-4217-currency-codes.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, DOI 10.17487/RFC2119, March
1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986,
DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
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,
<https://www.rfc-editor.org/rfc/rfc5891>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/rfc/rfc6454>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", RFC 6838,
DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[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,
<https://www.rfc-editor.org/rfc/rfc6920>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/rfc/rfc7638>.
[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,
<https://www.rfc-editor.org/rfc/rfc7800>.
[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,
<https://www.rfc-editor.org/rfc/rfc8037>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
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,
<https://www.rfc-editor.org/rfc/rfc8414>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[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,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", RFC 8725, DOI 10.17487/RFC8725,
February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", RFC 9110, DOI 10.17487/RFC9110,
June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9278] Jones, M. and K. Yasuda, "JWK Thumbprint URI", RFC 9278,
DOI 10.17487/RFC9278, August 2022,
<https://www.rfc-editor.org/rfc/rfc9278>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/rfc/rfc9530>.
[RFC9651] Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/rfc/rfc9651>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
status-list-20>.
12.2. Informative References
[AAUTH] Hardt, D., "AAuth Protocol", Work in Progress, Internet-
Draft, draft-hardt-oauth-aauth-protocol-00, 29 April 2026,
<https://datatracker.ietf.org/doc/html/draft-hardt-oauth-
aauth-protocol-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-klrc-aiagent-
auth-01>.
[IN-TOTO] in-toto project, "in-toto Attestation Framework", n.d.,
<https://github.com/in-toto/attestation>.
[MCP] Model Context Protocol project, "Model Context Protocol
Specification", n.d.,
<https://modelcontextprotocol.io/specification>.
[PSL] Mozilla Foundation, "Public Suffix List", n.d.,
<https://publicsuffix.org/>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[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,
<https://www.rfc-editor.org/rfc/rfc8792>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
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,
<https://www.rfc-editor.org/rfc/rfc9396>.
[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, <https://www.rfc-editor.org/rfc/rfc9449>.
[SPIFFE] CNCF, "Secure Production Identity Framework for Everyone
(SPIFFE)", n.d.,
<https://spiffe.io/docs/latest/spiffe-about/overview/>.
[TLOG-TILES]
C2SP, "C2SP tlog-tiles", n.d.,
<https://c2sp.org/tlog-tiles>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-08>.
[WEB-BOT-AUTH]
IETF, "IETF Web Bot Auth Working Group", n.d.,
<https://datatracker.ietf.org/wg/webbotauth/about/>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
s2s-protocol-07>.
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]