Agent Passports and Delegation Receipts for Autonomous Software Agents

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

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

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 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"
}

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

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

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

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

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

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

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

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

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

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

11.3. HTTP Field Names

This document requests registration in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":¶

11.4. Well-Known URIs

This document requests registration in the "Well-Known URIs" registry [RFC8615]:¶

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

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

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

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

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

A.1. Passport (Agent B)

{
  "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..."
}

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==: