WIMSE R. Asor Internet-Draft Attenu Intended status: Standards Track 27 August 2026 Expires: 28 February 2027 Verifiable Attenuated Delegation for AI Agent Chains draft-asor-wimse-agent-delegation-chain-00 Abstract AI agents increasingly delegate tasks to other agents. Each delegation should convey only a subset of the delegating party's authority, that subset should be bounded in scope, magnitude, and time, and any enforcement point should be able to verify -- offline, with no call to an authorization server -- that a token presented at hop N carries authority no greater than the token at hop N-1, back to a trusted root. OAuth 2.0 Token Exchange (RFC 8693) models two-party delegation and records prior actors in a nested "act" claim, but that claim is informational only and cannot enforce attenuation across a chain of depth two or more. This document defines the Agent Delegation Chain: a profile of OAuth 2.0 JWT access tokens (RFC 9068) that carries authority as Rich Authorization Requests (RFC 9396), links each delegation to its parent by a cryptographic byte- commitment, and specifies a deterministic offline verification algorithm that enforces monotonic attenuation, bounded depth, and monotonic expiry. It reuses existing JOSE, proof-of-possession (RFC 9449), and status-list machinery (the OAuth Status List draft) and introduces no new cryptography. 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 28 February 2027. Asor Expires 28 February 2027 [Page 1] Internet-Draft Agent Delegation Chain August 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The gap in existing mechanisms . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Token Format . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Authority Representation . . . . . . . . . . . . . . . . . . 5 4.1. Constraint Vocabulary . . . . . . . . . . . . . . . . . . 5 4.2. Subsumption Rules . . . . . . . . . . . . . . . . . . . . 5 5. Chain Linkage . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Offline Verification Algorithm . . . . . . . . . . . . . . . 6 7. Holder Binding . . . . . . . . . . . . . . . . . . . . . . . 7 8. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9.1. Parent tokens remain valid after attenuation . . . . . . 8 9.2. Chain splicing . . . . . . . . . . . . . . . . . . . . . 8 9.3. Confused deputy and over-broad delegation . . . . . . . . 8 9.4. Unbounded depth and fan-out . . . . . . . . . . . . . . . 8 9.5. Offline verification vs. revocation latency . . . . . . . 8 9.6. Why not macaroons; algorithm agility . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 Appendix B. Reference Implementation and Test Vectors . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Asor Expires 28 February 2027 [Page 2] Internet-Draft Agent Delegation Chain August 2026 1. Introduction An AI agent that receives a task from a user or another agent frequently decomposes it and delegates sub-tasks to further agents or tools. In production deployments this produces delegation chains of depth greater than two. The security requirement is a single invariant: the authority exercised at any hop MUST be a subset of the authority granted at the hop that delegated to it, and this MUST be verifiable by the enforcement point that ultimately honors a tool call, without that point contacting an authorization server. 1.1. The gap in existing mechanisms OAuth 2.0 Token Exchange [RFC8693] defines delegation and impersonation semantics and a nestable "act" claim. However, [RFC8693] Section 4.1 states that a recipient considers only the top- level claims and the current (outermost) actor; the nested chain is history for audit, not enforced authority. Token Exchange also normally contacts the authorization server at each hop. Neither property supports offline, enforced, depth >= 2 attenuation. Cross-domain identity chaining (see [I-D.ietf-oauth-identity-chaining]) and transaction tokens address related but distinct problems (crossing trust domains and propagating immutable context within one domain, respectively) and explicitly do not provide chained cryptographic attenuation. Capability systems that do provide offline attenuation -- macaroons [Macaroons], Biscuit [Biscuit] -- either verify with a shared secret (macaroons: symmetric HMAC, so every verifier holds the minting key) or use a non-IETF wire format (Biscuit: protocol buffers with an embedded Datalog engine). The historical standards-track ancestor is SDSI/SPKI [RFC2693]. This document fills the gap by reusing the JOSE/OAuth stack and adding only the chain linkage and the subsumption-enforcing verification algorithm. It is designed as the attenuation mechanism satisfying requirement R1 of [I-D.reece-wimse-cross-org-delegation] and as a companion to [I-D.klrc-aiagent-auth]. It shares its approach with, and is intended to converge with, [I-D.niyikiza-oauth-attenuating-agent-tokens] and [I-D.coetzee-oauth-spt-txn-tokens]. Asor Expires 28 February 2027 [Page 3] Internet-Draft Agent Delegation Chain August 2026 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. Delegation Token (DT): An OAuth 2.0 JWT access token [RFC9068] profiled by this document, carrying the authority granted to one agent at one hop of a chain. Delegation Chain: An ordered sequence of Delegation Tokens DT_0, DT_1, ... DT_n, where DT_0 is the root, and each DT_i (i > 0) is linked to DT_{i-1} by the mechanism in Section 5. Authority: The set of permitted actions carried in the "authorization_details" claim [RFC9396], together with the constraints in Section 4.1. Attenuation: The construction of a child Delegation Token whose Authority is a subset of its parent's, per the subsumption rules in Section 4.2. Enforcement Point: The component that verifies a Delegation Chain and permits or denies an action. 3. Token Format A Delegation Token is a JWT [RFC7519] signed with JWS [RFC7515] using a fully-specified algorithm [RFC9864]. Implementations MUST support Ed25519 [RFC8032] [RFC8037] and MAY support ES256 and, for post- quantum readiness, ML-DSA [RFC9964]. The token uses the "application/at+jwt" header type of [RFC9068] and includes its required claims (iss, exp, aud, sub, iat, jti). In addition, a Delegation Token contains: authorization_details: REQUIRED. An array of authorization detail objects [RFC9396] expressing the Authority. See Section 4. cnf: REQUIRED. A confirmation claim [RFC7800] binding the token to the holder's key, proven per DPoP [RFC9449]. See Section 7. del_depth: REQUIRED. A non-negative integer; the position of this token in the chain. DT_0 has del_depth 0. del_max_depth: REQUIRED in DT_0. A positive integer; the maximum Asor Expires 28 February 2027 [Page 4] Internet-Draft Agent Delegation Chain August 2026 permitted chain length. MUST NOT be increased by any child (see Section 4.2). par_hash: REQUIRED in every DT_i with i > 0; MUST be absent in DT_0. The base64url-encoded SHA-256 digest of the parent token's JWS Signing Input ([RFC7515] Section 5.1), i.e. of the exact bytes "ASCII(BASE64URL(parent JOSE Header)) || '.' || ASCII(BASE64URL(parent JWS Payload))". This is the byte- commitment that binds a child to one specific parent and prevents chain splicing. 4. Authority Representation Authority is expressed as one or more authorization detail objects [RFC9396]. Each object's "type" identifies an authority class; its "actions" and "locations" fields carry the permitted operations and targets. Numeric and enumerated bounds ("ceilings") that [RFC9396] does not standardize are carried in a "constraints" member defined here. 4.1. Constraint Vocabulary The "constraints" member is an object mapping a constraint name to a typed constraint value. This document defines: * "max" : a number. The value of the associated quantity MUST NOT exceed it. (e.g. {"max_rows": {"max": 5000}}). * "one_of" : an array. The associated value MUST be a member. * "not_one_of" : an array. The associated value MUST NOT be a member. * "prefix" : a string. The associated value MUST have it as a prefix. * "rank" : used for ordered enumerations (e.g. egress none < internal < any); the value's rank MUST NOT exceed the constraint's. The registry in Section 10 allows new constraint types. A verifier that encounters an unknown constraint type MUST treat the action as denied (fail-closed), never as unconstrained. 4.2. Subsumption Rules An Authority C is subsumed by an Authority P (written C <= P) if and only if all of the following hold: Asor Expires 28 February 2027 [Page 5] Internet-Draft Agent Delegation Chain August 2026 1. Every authorization detail in C is subsumed by some authorization detail in P of the same "type": C's "actions" and "locations" are subsets of P's (with prefix and wildcard semantics as defined by the type), and 2. for every constraint present in P, a corresponding constraint is present in C whose admissible set is a subset of P's (e.g. C.max <= P.max; C.one_of subset of P.one_of; C.rank <= P.rank), and 3. a constraint present in P MUST NOT be absent in C (absence means unbounded, which is not a subset), and 4. C.exp <= P.exp (monotonic expiry), and 5. C.del_max_depth <= P.del_max_depth. Attenuation is the construction of C as the greatest lower bound (meet) of P and a request R under these rules. Because the meet can only narrow, C <= P holds by construction for every R. 5. Chain Linkage Each child token commits to its parent by "par_hash" (Section 3). This binds the child to the parent's exact serialized bytes, so a child cannot be re-parented onto a different (e.g. broader) token: doing so changes the parent's Signing Input and thus its SHA-256 digest, which no longer matches the child's "par_hash". Canonicalization is not required for "par_hash" because it digests the already-serialized JWS Signing Input directly; where this document compares JSON structures (e.g. test vectors), JCS [RFC8785] is used. 6. Offline Verification Algorithm An Enforcement Point presented with a Delegation Chain DT_0 ... DT_n and an attempted action A, and holding the trusted root public key(s), MUST perform the following, denying on the first failure: 1. Verify the JWS signature of every DT_i using a fully-specified algorithm [RFC9864]. DT_0 MUST verify under a trusted root key. 2. For each i > 0, compute SHA-256 of DT_{i-1}'s JWS Signing Input and compare, in constant time, to DT_i's "par_hash". Any mismatch: deny. 3. Check del_depth: DT_0.del_depth == 0; DT_i.del_depth == i; n < DT_0.del_max_depth. Otherwise deny. Asor Expires 28 February 2027 [Page 6] Internet-Draft Agent Delegation Chain August 2026 4. For each i > 0, verify DT_i.Authority <= DT_{i-1}.Authority per Section 4.2. Any violation: deny. 5. Check time: for every i, nbf (if present) <= now <= exp, and exp is monotonic non-increasing along the chain. Otherwise deny. 6. Verify holder binding: the presenter proves possession of the key in DT_n.cnf via a valid DPoP proof [RFC9449] bound to this request. Otherwise deny. 7. Check revocation: consult the Token Status List [I-D.ietf-oauth-status-list] reference in each DT_i (if present) against a cached list; if any is revoked, deny (and, by local policy, treat the whole subtree as revoked). 8. Authorize A against DT_n.Authority (scope, actions, locations, and every constraint in Section 4.1). Permit only if A is within it. The algorithm is deterministic, side-effect free, and requires no network call except the (cacheable, offline-checkable) status list of step 7. 7. Holder Binding Every Delegation Token is sender-constrained by a "cnf" claim [RFC7800] carrying the JWK thumbprint of the holder's key, proven per request with DPoP [RFC9449]. mTLS-bound tokens [RFC8705] MAY be used where the transport is controlled end-to-end. A captured token is therefore unusable without its bound private key, which mitigates replay of intermediate tokens. 8. Revocation Delegation Tokens are RECOMMENDED to be short-lived (seconds to minutes for leaf and execution tokens), so that expiry is the common revocation path. For earlier revocation of longer-lived delegations, each token MAY carry a Token Status List [I-D.ietf-oauth-status-list] reference; revoking a token's status entry, and by local policy the entries of its descendants, revokes a delegation or a whole sub-chain while preserving offline verification (the status list is itself cacheable and offline-checkable). An online revocation endpoint (RFC 7009) MAY additionally be offered. 9. Security Considerations Asor Expires 28 February 2027 [Page 7] Internet-Draft Agent Delegation Chain August 2026 9.1. Parent tokens remain valid after attenuation Attenuation produces a new child token but does not, by itself, invalidate the parent. A party holding the parent still holds the parent's (broader) authority. This is mitigated by three mechanisms that MUST be considered together: (a) tokens are short-lived and holder-bound (Section 7), so a leaked parent is both time-boxed and non-replayable without its key; (b) the "par_hash" byte-commitment (Section 5) prevents splicing a child onto a different parent; and (c) status-list revocation (Section 8) allows early invalidation of a parent and its subtree. Deployments that require immediate parent invalidation on delegation MUST use short TTLs and status lists accordingly. 9.2. Chain splicing Without the byte-commitment, an attacker could present a valid child together with a broader token as its purported parent. Step 2 of Section 6 prevents this: the child's "par_hash" digests the parent's exact Signing Input, so only the intended parent verifies. 9.3. Confused deputy and over-broad delegation Because each hop's authority is the meet of parent and request (Section 4.2), a child cannot be induced (e.g. by prompt injection) to exercise authority the parent lacked. Tool audiences ("aud", "locations") are pinned, so a token minted for one resource cannot be replayed at another. 9.4. Unbounded depth and fan-out "del_max_depth" (checked in step 3) bounds chain length; deployments SHOULD set it low (e.g. 5). Fan-out (a parent delegating to many children) is not limited by the token format and MUST be bounded by the issuing infrastructure if required. 9.5. Offline verification vs. revocation latency Offline verification means an enforcement point may honor a token that has been revoked but whose status-list update it has not yet fetched. Deployments trade this window against TTL: shorter TTLs bound the exposure. This is the standard status-list trade-off and MUST be documented for each deployment. Asor Expires 28 February 2027 [Page 8] Internet-Draft Agent Delegation Chain August 2026 9.6. Why not macaroons; algorithm agility Macaroons [Macaroons] verify with the root secret, precluding public offline verification at an untrusted edge; this document uses public- key signatures. Algorithms are fully specified [RFC9864] and agile via the JOSE "alg" registry, with a migration path to ML-DSA [RFC9964]. 10. IANA Considerations This document requests registration, in the JSON Web Token Claims registry, of: "del_depth", "del_max_depth", and "par_hash" (with the semantics in Section 3). It requests a new "Agent Delegation Constraint Types" registry (initial entries: "max", "one_of", "not_one_of", "prefix", "rank"; registration policy Specification Required; unknown types fail closed per Section 4.1). It requests an "authorization_details" type value for delegated agent authority, coordinated with [I-D.niyikiza-oauth-attenuating-agent-tokens] to avoid divergence. 11. References 11.1. Normative References [I-D.ietf-oauth-status-list] Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf- oauth-status-list-21, 21 June 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 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, . Asor Expires 28 February 2027 [Page 9] Internet-Draft Agent Delegation Chain August 2026 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [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", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [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, . [RFC9864] Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, October 2025, . 11.2. Informative References [Biscuit] "Biscuit Authorization Token Specification, v3", n.d., . [I-D.coetzee-oauth-spt-txn-tokens] Coetzee, R. J., "Transaction-Bound Authorization Tokens for Software and AI Agents (SPT-Txn)", Work in Progress, Asor Expires 28 February 2027 [Page 10] Internet-Draft Agent Delegation Chain August 2026 Internet-Draft, draft-coetzee-oauth-spt-txn-tokens-03, 19 July 2026, . [I-D.ietf-oauth-identity-chaining] Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19 July 2026, . [I-D.klrc-aiagent-auth] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft- klrc-aiagent-auth-03, 6 July 2026, . [I-D.niyikiza-oauth-attenuating-agent-tokens] Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, Internet-Draft, draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026, . [I-D.reece-wimse-cross-org-delegation] Reece, M., "Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements", Work in Progress, Internet-Draft, draft-reece-wimse-cross- org-delegation-01, 30 July 2026, . [Macaroons] "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud", NDSS 2014 , 2014. [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, DOI 10.17487/RFC2693, September 1999, . Asor Expires 28 February 2027 [Page 11] Internet-Draft Agent Delegation Chain August 2026 [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, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC9964] Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May 2026, . Appendix A. Acknowledgments This work builds directly on, and seeks convergence with, [I-D.niyikiza-oauth-attenuating-agent-tokens], [I-D.coetzee-oauth-spt-txn-tokens], [I-D.klrc-aiagent-auth], and the requirements of [I-D.reece-wimse-cross-org-delegation]. The capability-token lineage of [Macaroons], [Biscuit], and [RFC2693] is gratefully acknowledged. Appendix B. Reference Implementation and Test Vectors A permissively licensed reference implementation (the "attenu-guard" library) and a set of offline-verification test vectors (chains that MUST verify and adversarial chains that MUST be rejected: widened scope, exceeded ceiling, spliced parent, exceeded depth, non- monotonic expiry, revoked entry, replayed token) accompany this draft and are intended for interoperability testing across independent implementations. Author's Address Rafael Asor Attenu Email: rafael.asor@gmail.com URI: https://attenu.io/ Asor Expires 28 February 2027 [Page 12]