]> Attenu

rafael.asor@gmail.com https://attenu.io/

Security WIMSE agent delegation attenuation authorization capability 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.

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.

The gap in existing mechanisms OAuth 2.0 Token Exchange defines delegation and impersonation semantics and a nestable "act" claim. However, 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 ) 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 , 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 . 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 and as a companion to . It shares its approach with, and is intended to converge with, and .

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 when, and only when, they appear in all capitals, as shown here.

Delegation Token (DT):

An OAuth 2.0 JWT access token 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 .

Authority:

The set of permitted actions carried in the "authorization_details" claim , together with the constraints in .

Attenuation:

The construction of a child Delegation Token whose Authority is a subset of its parent's, per the subsumption rules in .

Enforcement Point:

The component that verifies a Delegation Chain and permits or denies an action.

Token Format A Delegation Token is a JWT signed with JWS using a fully-specified algorithm . Implementations MUST support Ed25519 and MAY support ES256 and, for post-quantum readiness, ML-DSA . The token uses the "application/at+jwt" header type of 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 expressing the Authority. See .

cnf:

REQUIRED. A confirmation claim binding the token to the holder's key, proven per DPoP . See .

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 permitted chain length. MUST NOT be increased by any child (see ).

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

Authority Representation Authority is expressed as one or more authorization detail objects . 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 does not standardize are carried in a "constraints" member defined here.

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 allows new constraint types. A verifier that encounters an unknown constraint type MUST treat the action as denied (fail-closed), never as unconstrained.

Subsumption Rules An Authority C is subsumed by an Authority P (written C <= P) if and only if all of the following hold:

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.

Chain Linkage Each child token commits to its parent by "par_hash" (). 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 is used.

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 . 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.
4. For each i > 0, verify DT_i.Authority <= DT_{i-1}.Authority per . 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 bound to this request. Otherwise deny.
7. Check revocation: consult the Token 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 ). 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.

Holder Binding Every Delegation Token is sender-constrained by a "cnf" claim carrying the JWK thumbprint of the holder's key, proven per request with DPoP . mTLS-bound tokens 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.

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

Security Considerations

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 (), so a leaked parent is both time-boxed and non-replayable without its key; (b) the "par_hash" byte-commitment () prevents splicing a child onto a different parent; and (c) status-list revocation () 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.

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 prevents this: the child's "par_hash" digests the parent's exact Signing Input, so only the intended parent verifies.

Confused deputy and over-broad delegation Because each hop's authority is the meet of parent and request (), 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.

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.

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.

Why not macaroons; algorithm agility Macaroons verify with the root secret, precluding public offline verification at an untrusted edge; this document uses public-key signatures. Algorithms are fully specified and agile via the JOSE "alg" registry, with a migration path to ML-DSA .

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 ). 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 ). It requests an "authorization_details" type value for delegated agent authority, coordinated with to avoid divergence.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. MATTR Bundesdruckerei SPRIND This specification defines a status mechanism called Token Status List (TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. Informative References This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. This memo defines an Experimental Protocol for the Internet community. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. TowerGuardian Consulting Autonomous software agents increasingly act on behalf of human principals by invoking tools, services, and other agents, frequently across organizational boundaries. Existing workload and token-based authorization mechanisms were designed for a single trust domain and a small number of delegation hops. They do not adequately express, constrain, or verify authority that is delegated recursively among agents and that crosses the boundary between independently administered organizations. This document describes the problem of cross-organizational agent delegation, identifies the gaps in current mechanisms, and enumerates requirements that any solution within the scope of the Workload Identity in Multi-System Environments (WIMSE) working group should satisfy. It does not specify a solution. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Tenuo This document defines Attenuating Authorization Tokens (AATs), a signed credential format for task-scoped delegation in AI agent systems. An AAT encodes the tools an agent may invoke and the argument constraints that apply to those invocations. A token holder authorized to delegate can derive a token offline with equal or narrower authority, subject to the parent token's depth and lifetime limits. The resulting delegation chain is verifiable offline by any enforcement point that has the root issuer's trust anchor key. This specification profiles the OAuth Rich Authorization Requests format (RFC 9396) for tool-level capability claims, adds delegation- chain claims, and defines a core constraint vocabulary for argument restrictions. The chain verification algorithm authenticates each delegation step and enforces monotonic attenuation without network contact with the root issuer. Violet Sky Security SEZC Current authorization is role-scoped: an actor is granted a role whose authority persists across every action it takes. This fails exactly when actors fail -- under compromise, prompt injection, or goal hijacking -- because a compromised actor retains full role authority. This document specifies SPT-Txn, a family of transaction- bound authorization tokens in which authority exists only inside a short-lived token bound to one declared action, on one resource, under one jurisdictional policy, verified against how the requesting workload was attested. Delegation across agents and tools is expressed as a cryptographically sealed chain that can only narrow authority and is verifiable offline. Each authorization decision emits a signed, tamper-evident receipt as a byproduct of enforcement. This document specifies normative intent binding, transaction receipts and their transparency log, attested issuance via OAuth 2.0 Token Exchange, per-token status-list revocation, and cryptographic algorithm agility including hybrid post-quantum signing. It also hardens attested issuance in response to an adversarial security review of the reference implementation: it makes an audience and a verifiable expiry mandatory on the presented attestation, requires the issuer to bound the delegated depth it grants, and clamps a token's lifetime to the attestation it was minted on. The issuer- side requested-versus-permitted scope intersection is retained; the enforcement point re-checks the chain independently. n.d.

Acknowledgments This work builds directly on, and seeks convergence with, , , , and the requirements of . The capability-token lineage of , , and is gratefully acknowledged.

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.