Verifiable Attenuated Delegation for AI Agent Chains
draft-asor-wimse-agent-delegation-chain-00

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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              status-list-21>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

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

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

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

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,
              <https://www.rfc-editor.org/rfc/rfc8032>.

   [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", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

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

   [RFC9068]  Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
              Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
              2021, <https://www.rfc-editor.org/rfc/rfc9068>.

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

   [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,
              <https://www.rfc-editor.org/rfc/rfc9864>.

11.2.  Informative References

   [Biscuit]  "Biscuit Authorization Token Specification, v3", n.d.,
              <https://doc.biscuitsec.org/reference/
              specifications.html>.

   [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, <https://datatracker.ietf.org/doc/html/draft-
              coetzee-oauth-spt-txn-tokens-03>.

   [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, <https://datatracker.ietf.org/doc/html/draft-
              ietf-oauth-identity-chaining-17>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-klrc-aiagent-
              auth-03>.

   [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, <https://datatracker.ietf.org/doc/html/draft-
              niyikiza-oauth-attenuating-agent-tokens-01>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-reece-wimse-
              cross-org-delegation-01>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc2693>.

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,
              <https://www.rfc-editor.org/rfc/rfc8693>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc8705>.

   [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, <https://www.rfc-editor.org/rfc/rfc9964>.

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]