Attenuating Authorization Tokens for Agentic Delegation Chains

1.1. Limitations of Existing OAuth Mechanisms for Agentic Delegation

OAuth 2.0 Token Exchange [RFC8693] enables a principal to obtain a new token with reduced scope by contacting the authorization server. The server enforces the scope reduction. This requires a synchronous round-trip to the authorization server at each delegation hop. In multi-agent chains, this makes the authorization server a participant in every delegation decision, coupling the delegation topology to authorization server (AS) availability. [RFC8693] supports representing prior delegation actors via nested act claims, but those claims are informational for access control decisions rather than a cryptographically self-verifiable attenuation chain. The AS mediates each grant independently, and no mechanism ensures that downstream delegation intent remains consistent with the original authorization scope.¶

Rich Authorization Requests (RAR) [RFC9396] extend OAuth tokens with structured authorization detail objects, enabling expressive capability descriptions. RAR addresses the expressiveness problem. It does not define how a token holder can produce a narrower token, or how a chain of such derivations can be verified.¶

Proposals to extend the authorization code flow with explicit agent consent, such as introducing a requested_actor parameter at the authorization endpoint, address who the agent is and whether the user approved the delegation. They do not constrain which tools the agent may invoke or with what argument values. AATs are complementary: they scope authority to specific tools and arguments after identity and consent have been established.¶

To the author's knowledge, no existing OAuth standard defines a delegation chain protocol with a cryptographically enforced attenuation invariant and offline chain verification.¶

1.2. Design Goals

1. Least privilege at the invocation boundary. An agent's authorization token encodes which tools it may call and with what argument constraints, scoped to the task, not to the full authority of the calling principal.¶

2. Offline derivation. A token holder can derive a more restrictive token without contacting the root issuer.¶

3. Independent chain verification. Any enforcement point holding the trust anchor can verify the complete delegation chain without network calls.¶

4. Cryptographically enforced attenuation. A derived token cannot grant broader authority than its parent.¶

5. JWT interoperability. Tokens are representable as signed JWTs [RFC7519], allowing deployments to verify chains using existing JSON Object Signing and Encryption (JOSE) infrastructure without new cryptographic dependencies.¶

1.3. Relationship to Prior Work

Macaroons [MACAROONS] introduced the concept of attenuating tokens with contextual caveats. Macaroons use HMAC chaining, which provides attenuation but not proof of possession, and express caveats as free-form predicates evaluated at the target service at runtime. This specification adds asymmetric proof of possession, structured tool-level capability claims, and a typed constraint vocabulary. It defines a normative subsumption relation, enabling any party holding the chain to verify monotonicity structurally, without predicate evaluation at a central service.¶

Biscuit [BISCUIT] extends the Macaroons model with asymmetric public key signatures and offline attenuation, addressing the proof-of-possession gap. Biscuit expresses authorization policies in a Datalog variant, requiring a logic engine at verification time. This specification uses structured constraint types decidable by structural analysis and defines a typed delegation-chain model with explicit token roles and chain-position claims. A detailed comparison appears in Appendix A.¶

The capability-based security model underlying AATs draws on [DENNIS66], which introduced capabilities as unforgeable tokens of authority, and [MILLER06], which formalized the principle of least authority (POLA) and the attenuation property in object-capability systems. AATs apply these principles at the protocol layer: each token is a capability scoped to specific tools and arguments, and derivation can only attenuate, never amplify, the authority it carries.¶

[DEEPMIND26] argues that safe multi-agent delegation requires explicit transfer of authority, responsibility, and trust at each delegation step, with bounded operational scope. [CAMEL25] shows that capability-based controls enforced at the tool boundary can provide provable security properties in an agentic framework. These results motivate a protocol-layer mechanism that encodes delegation scope in verifiable credential artifacts enforced independently of model behavior. AATs realize one protocol-layer approach to that goal.¶

3.1. Token Types

This specification defines two token types, distinguished by the aat_type claim.¶

Delegation Tokens (aat_type: "delegation") enumerate the tools for which the holder may derive further tokens; they do not authorize tool invocation. A delegation token holder MUST NOT present a delegation token to an enforcement point to invoke a tool. Root delegation tokens are typically issued by a root issuer to orchestrating agents, but delegation tokens may also appear at intermediate hops in a chain, derived from a parent delegation token with narrower scope. A derived token from a delegation token MUST NOT authorize tools absent from the delegation token's authorization_details. The capability monotonicity invariant (I4, Section 4.5) applies at every delegation step: derived tokens can only narrow the authorized tool set and argument constraints relative to the delegation token.¶

Execution Tokens (aat_type: "execution") authorize tool invocation. They enumerate specific tools and the argument constraints that apply to each. Execution tokens are presented to enforcement points at tool invocation boundaries.¶

The separation between delegation and execution authority is a structural property of the token, not a policy decision left to enforcement points. This moves the authorization boundary from something an enforcement point must judge to something any enforcement point can read directly from the chain, and enables type-transition key separation (Section 8.12) to be structurally enforced rather than left to convention.¶

Any type transition is permitted, provided del_depth < del_max_depth in the parent token. A holder of either token type may derive a token of either type, narrowing or maintaining the authorized tool set and argument constraints. The capability monotonicity invariant (I4, Section 4.5) applies at every derivation step regardless of the type transition.¶

A derived token whose aat_type differs from its parent's aat_type MUST have a cnf.jwk whose JWK Thumbprint ([RFC7638]) differs from the parent's cnf.jwk thumbprint. This ensures structural separation between planning authority and invocation authority: an entity that delegates cannot use the same key to invoke, and an entity that invokes cannot use the same key to delegate. When aat_type is preserved across a derivation step, same-key derivation is permitted. The security rationale for type-transition key separation is discussed in Section 8.12.¶

A root issuer MAY issue an execution token directly, bypassing the delegation step, when an agent requires immediate tool invocation authority without intermediate planning authority.¶

3.2. Common Claims

The following claims appear in both token types. All claims listed as REQUIRED MUST be present. Claims listed as OPTIONAL MAY be omitted; their absence carries the semantics described in the table.¶

Implementations MUST support Ed25519 [RFC8032] for token signing and verification. Implementations MAY support additional algorithms.¶

In both root and derived tokens, iss is a URI. For root tokens, iss is a URI identifying the root issuer, consistent with conventional OAuth usage. For derived tokens, iss is a JWK Thumbprint URI [RFC9278] that encodes the SHA-256 thumbprint of the signing key. This makes I1 verifiable offline: the enforcement point can confirm that the thumbprint embedded in derived.iss matches parent.cnf.jwk without any external lookup.¶

This specification intentionally omits the sub claim. In conventional OAuth tokens, sub identifies the resource owner or principal on whose behalf the token is issued. In an AAT chain, the holder's identity is fully determined by cnf.jwk: the entity presenting the token proves possession of the private key corresponding to cnf.jwk. Including a sub claim would introduce an additional identity binding that is not cryptographically enforced by this specification and could be set arbitrarily by any delegating party. Implementations that require a human-readable subject identifier MAY convey one in additional JWT claims outside this specification (see Appendix B.7).¶

3.3. Capability Claims via authorization_details

This specification profiles [RFC9396] for tool-level capability claims. Each entry in the authorization_details array MUST have type set to "attenuating_agent_token". The entry MUST include a tools member that maps tool names to argument constraint sets.¶

{
  "authorization_details": [
    {
      "type": "attenuating_agent_token",
      "tools": {
        "read_file": {
          "path": {
            "constraint_type": "pattern", "value": "/data/*"
          }
        },
        "search_index": {
          "query": {
            "constraint_type": "pattern", "value": "*public*"
          },
          "limit": { "constraint_type": "range", "max": 100 }
        }
      }
    }
  ]
}

A tool entry with an empty constraint map {} is valid and indicates that the tool is authorized without argument restrictions.¶

When a tool entry contains one or more argument constraints, the enforcement point operates in closed-world mode for that tool invocation: any argument not named in the constraint map MUST be rejected. A constrained argument that is absent from the invocation MUST also be rejected. The presence of a constraint asserts that the issuer has reasoned about that argument. An invocation that omits it has not been validated against that reasoning. This is a security property, not a configuration option.¶

Issuers who wish to permit an argument to be omitted MUST NOT include a constraint for it in the constraint map. There is no "optional constraint" mechanism; the constraint map is a closed specification of the required invocation shape. To authorize an argument without restricting its value, use a wildcard constraint (see below).¶

A token issuer that wishes to allow unconstrained arguments alongside constrained ones MUST explicitly include a wildcard constraint for each argument that should be unrestricted. A wildcard constraint satisfies closed-world mode while permitting any value for that argument (see Section 3.4). Enforcement points MUST enforce closed-world mode and MUST NOT permit unconstrained arguments when any constraint is present for the tool (see Section 7, step 6b).¶

The authorization_details array MAY contain entries of other types alongside attenuating_agent_token entries, consistent with the extensibility model of [RFC9396]. Enforcement points implementing this specification process only entries with type set to attenuating_agent_token and MUST ignore entries of other types. An authorization_details array containing multiple entries with type: "attenuating_agent_token" is invalid; the tools map in a single entry provides sufficient structure for all tool-level capability claims.¶

https://billing-agent.example.com/tools/charge/v2

3.4. Argument Constraints

Each argument constraint is an object with a constraint_type member and type-specific members. The following constraint types are defined normatively. The check predicate and subsumes relation for each type are normative: two independent implementations MUST produce identical results when evaluating either predicate against the same inputs.¶

For constraint types where this specification does not define a general containment algorithm (specifically pattern, regex, cel, not, and any), this specification prescribes a conservative syntactic strategy. The strategy is sound: it never incorrectly accepts a non-subsuming constraint. It is conservative: it may reject constraints that are semantically subsuming but cannot be proven so syntactically. Deployments requiring richer policy expressiveness with full subsumption support SHOULD use a registered extension constraint type built on a language with a decidable containment algorithm (see Section 3.5 and Appendix C).¶

Pattern glob syntax. The pattern constraint uses the following glob syntax. * matches any sequence of characters not containing a path separator. ? matches any single character. [abc] matches any single character in the set. [!abc] matches any single character not in the set. The token ** (double-star) has no defined semantics in this specification and MUST NOT appear in pattern values. Brace alternation (e.g., {a,b}) has no defined semantics in this specification and MUST NOT appear in pattern values; deployments requiring alternation SHOULD use any with multiple pattern constraints. See Section 4.5 for subsumption rules.¶

Regex dialect and subsumption. The regex constraint does not standardize a dialect; implementations MUST document the dialect they support. This specification does not define a portable containment algorithm for regular expressions; equality of pattern strings is the normative conservative subsumption strategy. See Section 4.5.¶

CEL check predicate. The cel expression MUST evaluate to a boolean. The subsumption strategy for cel uses balanced-parentheses conjunction; see Section 4.5 for the normative rules and Section 8.13 for the security rationale.¶

Enforcement points MUST reject invocations where any argument violates its associated constraint. Enforcement points MUST deny authorization if they encounter a constraint_type they do not recognize (fail-closed behavior). This fail-closed rule applies only to constraint types within authorization_details. Enforcement points MUST ignore unrecognized top-level JWT claims; a token MUST NOT be rejected solely because it contains claims outside those defined in this specification.¶

Composite constraint types (all, any, not) are recursive. MAX_CONSTRAINT_DEPTH is an implementation-defined finite integer specifying the maximum nesting depth of a constraint tree. Implementations MUST enforce a finite MAX_CONSTRAINT_DEPTH to prevent resource exhaustion from pathologically deep constraint trees. A value of 32 is RECOMMENDED. Enforcement points MUST reject any constraint tree whose nesting depth exceeds MAX_CONSTRAINT_DEPTH.¶

Domain-specific constraint types such as path containment, URL safety, or IP range matching may be registered in the extension registry (Section 3.5).¶

3.5. Extension Constraint Registry

Implementations MAY define extension constraint types beyond those listed in Section 3.4. Extension constraint types MUST be registered in the IANA AAT Constraint Type Registry defined in Section 9.3. The registry exists to preserve security and interoperability in the presence of domain-specific constraints; it is not a requirement that all implementations support arbitrary extensions. An enforcement point that does not recognize a registered extension type MUST deny authorization (Section 3.5.2), but it is not required to implement that type.¶

3.6. Examples

{
  "jti": "01957a3f-4e23-7b01-a9d1-0050569c2e4f",
  "iss": "https://auth.example.com",
  "iat": 1741600000,
  "exp": 1741603600,
  "aat_type": "delegation",
  "del_depth": 0,
  "del_max_depth": 3,
  "cnf": {
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"
    }
  },
  "authorization_details": [
    {
      "type": "attenuating_agent_token",
      "tools": {
        "read_file": {
          "path": {
            "constraint_type": "pattern", "value": "/data/*"
          }
        },
        "search_index": {}
      }
    }
  ]
}

{
  "jti": "01957a41-0081-7c20-bf3a-00a0c91e1234",
  "iss": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:KAKnRDlMQVIKCfS5JhHlABCHjAFLdyEVVHdpnGnLLg8",
  "iat": 1741600120,
  "exp": 1741601920,
  "aat_type": "execution",
  "del_depth": 1,
  "del_max_depth": 3,
  "par_hash": "sha256_base64url_of_parent_jws_signing_input",
  "cnf": {
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "rAl9xvTDAeUADPnIWlGpFHtGg4Y8OqcQE5N4XYNdLPs"
    }
  },
  "authorization_details": [
    {
      "type": "attenuating_agent_token",
      "tools": {
        "read_file": {
          "path": {
            "constraint_type": "exact",
            "value": "/data/q3-report.pdf"
          }
        }
      }
    }
  ]
}

3.7. Root Issuer Support and Root Token Issuance

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&authorization_details=%5B%7B%22type%22%3A%22attenuating_agent_
  token%22%2C...%7D%5D
&cnf=%7B%22jwk%22%3A%7B%22kty%22%3A%22OKP%22%2C...%7D%7D

{
  "access_token": "<compact-serialized AAT JWT>",
  "token_type": "aat",
  "expires_in": <seconds until exp>
}

4.1. Capability Lattice Model (Non-Normative)

The attenuation invariants in this section are instances of a single abstract structure: a capability lattice. This subsection states that structure informally to give readers a mental model for interpreting the normative rules that follow.¶

For a token T, define its capability set C(T) as the set of (tool, args) pairs that T authorizes (that is, the pairs for which T would permit invocation). The core security property of this protocol is:¶

C(child) ⊆ C(parent)

Every delegation step moves down or stays at the same position in this partial order. A derived token can only authorize a subset of what its parent authorized. It cannot add tools, loosen argument constraints, or extend the chain's authority in any dimension.¶

The ⊆ relation is not defined by enumerating (tool, args) pairs (argument spaces are typically infinite) but by the structural subsumption rules in Section 4.5. At the tool level, the derived token's tool set must be a subset of the parent's. At the argument level, when the parent's constraint map is non-empty, the derived token must preserve the parent's key set exactly (Section 4.5 explains why closed-world semantics require this).¶

When the parent's map is empty, the derived token may introduce keys, transitioning from open-world to closed-world. Each per-key constraint must be at least as restrictive. A derived constraint c_child subsumes a parent constraint c_parent (written c_child ⊑ c_parent) if every argument value that satisfies c_child also satisfies c_parent.¶

Two boundary cases complete the structure. The empty capability set ∅ is the bottom element: a token with no tools authorized is a valid but useless terminal token. The root token's capability set is the ceiling for the entire chain: no derived token at any depth can exceed what the root authorized.¶

Token lifetime (I3) is a mandatory attenuation dimension orthogonal to the capability lattice. A derived token with C(child) == C(parent) is still strictly more constrained if its exp is earlier than its parent's. Time-to-live (TTL) bounds are enforced independently of capability monotonicity. Both must hold for a chain to be valid.¶

Invariants I1 through I6 are the normative enforcement mechanism for this property. I4 (Section 4.5) directly enforces C(child) ⊆ C(parent). The remaining invariants enforce the conditions under which that comparison is meaningful: that the chain is cryptographically linked (I1, I5), that depth and time bounds are respected (I2, I3), and that the presenter holds the key (I6).¶

4.2. I1: Delegation Authority

derived.iss == jwk_thumbprint_uri(parent.cnf.jwk)

where jwk_thumbprint_uri constructs the [RFC9278] URI from the key's SHA-256 thumbprint. The entity that signed the derived token MUST be the holder of the parent token. Authority flows from parent holder to derived token issuer. This invariant establishes an unambiguous audit trail: each link in the chain was signed by the party that held the preceding token.¶

4.3. I2: Depth Monotonicity

derived.del_depth == parent.del_depth + 1
derived.del_depth <= parent.del_max_depth
derived.del_depth <= derived.del_max_depth
derived.del_depth <= MAX_DELEGATION_DEPTH
derived.del_max_depth <= parent.del_max_depth

Delegation depth increments exactly by one at each link. The chain cannot skip depths, branch, or exceed the maximum depth established in the root token. del_max_depth is an absolute ceiling, not a remaining count. A token is terminal (its holder cannot derive further tokens) when del_depth == del_max_depth. A root token with del_max_depth: 0 is therefore immediately terminal and cannot produce any derived tokens.¶

The del_max_depth claim serves two related purposes. First, it is a security boundary: each delegation hop is a trust extension, delegating authority through another agent whose key, runtime, and behavior must be trusted to maintain the attenuation invariant. Unbounded chains mean unbounded trust extensions; the depth limit constrains how far authority can propagate before it must be reissued from the root. Second, it is a policy expression by the root issuer: a root delegation token with del_max_depth: 2 asserts that this grant of authority should pass through no more than two intermediate agents, regardless of what those agents might prefer. Intermediate token holders can only lower del_max_depth, never raise it (I2), so the root issuer's topology constraint is cryptographically enforced across the entire chain.¶

MAX_DELEGATION_DEPTH is an implementation-defined finite integer specifying the maximum permitted delegation chain depth. Implementations MUST enforce a finite maximum delegation depth to prevent resource exhaustion from pathologically deep chains. The appropriate value depends on the deployment topology; swarm architectures with deep fan-out may require significantly larger values than linear delegation chains. See Appendix B.5 for guidance.¶

The del_max_depth claim in any token in the chain MUST NOT exceed the implementation's MAX_DELEGATION_DEPTH.¶

4.4. I3: TTL Monotonicity

derived.exp  <= parent.exp
derived.exp  >  now
derived.exp  >  derived.iat
derived.iat  >= parent.iat
derived.iat  <= now + MAX_IAT_SKEW
derived.exp  <= derived.iat + MAX_TOKEN_LIFETIME

MAX_IAT_SKEW is an implementation-defined finite integer specifying the maximum number of seconds a token's iat may be in the future relative to the enforcement point's clock. Implementations MUST enforce a finite MAX_IAT_SKEW. A value of 30 seconds is RECOMMENDED.¶

MAX_TOKEN_LIFETIME is an implementation-defined finite integer specifying the maximum permitted duration in seconds between a token's iat and exp. Implementations MUST enforce a finite MAX_TOKEN_LIFETIME. A value of 90 days is RECOMMENDED as an upper bound; deployments SHOULD use significantly shorter lifetimes in practice (see Appendix B.8).¶

A derived token cannot outlive its parent. Authority cannot extend beyond the lifetime of the token that granted it. A derived token's issuance time MUST NOT precede its parent's issuance time. A token with an earlier iat indicates clock manipulation or chain forgery. Tokens with iat more than MAX_IAT_SKEW in the future relative to the enforcement point's clock MUST be rejected. A token's lifetime MUST NOT exceed MAX_TOKEN_LIFETIME.¶

4.5. I4: Capability Monotonicity

tools(derived) ⊆ tools(parent)
∀ tool ∈ tools(derived):
  constraints(derived, tool) ⊑ constraints(parent, tool)

A derived token MUST NOT authorize tools that the parent did not authorize. For each tool that appears in both parent and derived token:¶

• If the parent's constraint map for that tool is non-empty, the derived token's constraint map MUST contain exactly the same set of argument keys. Under closed-world semantics (Section 3.3), the constraint map keys define the required invocation shape: any argument not named is forbidden, and any named argument must be present. Adding a key would produce invocations that the parent's closed-world check rejects (the extra argument is unknown). Dropping a key would produce invocations that omit a parent-required argument. In both cases the derived invocation set is disjoint from the parent's, not a subset.¶

• If the parent's constraint map is empty (open-world), the derived token MAY introduce constraint keys, transitioning to closed-world. Any closed-world constraint set is a subset of the unrestricted open-world set.¶

For each argument constraint key present in both parent and derived token, the derived constraint MUST be at least as restrictive as the parent's constraint.¶

Constraint subsumption is defined per constraint type. The normative rules are:¶

• exact: A derived exact constraint subsumes a parent constraint of the same or different type as follows: it subsumes a parent exact if the values are identical; it subsumes a parent pattern if the exact value matches the parent pattern; it subsumes a parent range if the exact value falls within the parent range; it subsumes a parent one_of if the exact value is a member of the parent set; it subsumes a parent regex if the exact value matches the parent regex pattern; it subsumes a parent wildcard unconditionally. All other parent types are invalid cross-type targets for a derived exact constraint.¶

• pattern: This specification does not define a general containment algorithm for glob patterns; therefore it uses a conservative syntactic strategy. Enforcement points MUST apply the following rules, in order:¶

  1. A derived exact constraint subsumes a parent pattern if the exact value matches the parent pattern.¶

  2. If the parent pattern ends with a single * wildcard (a terminal wildcard), a derived pattern subsumes it if the derived pattern also ends with a single * wildcard and the derived pattern's fixed prefix (the portion before the terminal *) is equal to or longer than the parent's fixed prefix, and the derived prefix begins with the parent prefix. For example, a derived pattern /data/reports/* subsumes a parent pattern /data/* because /data/reports/ begins with /data/ and is longer.¶

  3. In all other cases, a derived pattern subsumes a parent pattern if and only if the pattern strings are identical.¶

  This strategy applies to patterns containing character classes ([abc], [!abc]) without exception: a derived pattern with a different character class than its parent MUST be treated as non-subsuming even if semantically narrower. Enforcement points MUST NOT attempt semantic evaluation to determine pattern subsumption. Deployments requiring richer containment analysis SHOULD use a registered extension constraint type (see Appendix C).¶

• range: A derived range constraint is valid only if its bounds are at least as restrictive as the parent's (derived min >= parent min, derived max <= parent max). A missing bound on the parent is treated as unbounded; a missing bound on the derived constraint is only valid if the parent bound is also missing. A derived bound's inclusivity may only become more restrictive: a derived min_inclusive: false is valid when the parent has min_inclusive: true at the same min value (exclusive is strictly tighter), but the reverse is not. The same applies to max_inclusive.¶

• one_of: A derived one_of constraint is valid only if its value set is a subset of the parent's value set. Cross-type pairs involving a derived not_one_of against a parent one_of are invalid: a not_one_of constraint accepts values outside the parent's permitted set and cannot be verified as subsuming a one_of without domain knowledge. Enforcement points MUST reject this cross-type pair.¶

• not_one_of: A derived not_one_of constraint is valid only if its excluded set is a superset of the parent's excluded set (can only add exclusions, never remove them).¶

• regex: This specification does not standardize a regex dialect or portable containment algorithm; equality of pattern strings is the normative conservative subsumption strategy. A derived regex constraint is valid attenuation of a parent regex constraint if and only if the pattern strings are identical. A derived exact constraint subsumes a parent regex constraint if and only if the exact value matches the parent regex pattern. All other cross-type pairs involving regex are invalid. Deployments requiring richer containment analysis SHOULD use a registered extension constraint type.¶

• cel: This specification does not define a general semantic containment algorithm for CEL expressions. The normative subsumption strategy requires balanced-parentheses conjunction: a derived cel constraint subsumes a parent cel constraint if and only if the derived expression string is exactly (parent_expression) && (additional_clause). The parent expression MUST appear verbatim inside the leading parentheses. Each additional clause MUST be individually wrapped in balanced parentheses. Multiple additional clauses are permitted: (parent) && (clause1) && (clause2). No other form is considered subsuming.¶

  This requirement is a security invariant, not a style guideline. CEL's && operator binds tighter than ||. Without balanced parentheses around the additional clause, an attacker can append || evil_predicate after the conjunction, which CEL parses as (parent && clause) || evil_predicate, a top-level disjunction that widens rather than narrows authority. Wrapping each additional clause in balanced parentheses ensures that any || inside the clause is contained within the conjunction and cannot widen authority.¶

  Enforcement points MUST verify balanced parentheses by bracket counting, not by semantic evaluation. Enforcement points MUST NOT attempt semantic evaluation to determine subsumption.¶

  Issuers constructing a derived cel constraint MUST copy the parent expression string verbatim inside the leading parentheses and MUST wrap each additional clause in balanced parentheses. If the issuer requires a structurally different expression that is semantically narrower, it MUST request a new root token from the root issuer rather than attempting to rewrite the parent clause.¶

  Deployments requiring richer policy expressiveness with full subsumption support SHOULD use a registered extension type built on a language with a decidable containment algorithm (see Appendix C).¶

• wildcard: A derived wildcard is valid only if the parent is also wildcard. Any other constraint type subsumes a parent wildcard.¶

• all: A derived all constraint is valid attenuation of a parent all if the derived constraint contains all clauses present in the parent (none may be dropped) and each corresponding clause satisfies the subsumption relation. The derived constraint MAY add additional clauses at any position, which only further restrict the accepted value set. Dropping any parent clause from the derived all would expand authority and MUST be rejected.¶

  Clause matching for all is subsumption-keyed: for each clause C_p in the parent array, the enforcement point MUST find at least one clause C_d in the derived array with the same constraint_type such that C_d subsumes C_p per this section. Each parent clause MUST be matched to a distinct derived clause (one-to-one assignment); a single derived clause MUST NOT be used to satisfy more than one parent clause. If any parent clause cannot be matched, the check MUST fail. Unmatched additional clauses in the derived array are permitted.¶

  The following pseudocode describes the matching algorithm. Because the one-to-one assignment requirement is order- sensitive when multiple clauses share the same constraint_type, the algorithm backtracks when a greedy match leads to a dead end. (When each constraint_type appears at most once in the parent, no backtracking occurs and the algorithm reduces to a linear scan.)¶

  function check_all_subsumption(parent_clauses, derived_clauses):
    used = set()
    return match(parent_clauses, 0, derived_clauses, used)
  
  function match(parents, idx, derived, used):
    if idx == len(parents):
      return PASS
    C_p = parents[idx]
    for i, C_d in enumerate(derived):
      if i not in used and
         C_d.constraint_type == C_p.constraint_type and
         subsumes(C_d, C_p):
        used.add(i)
        if match(parents, idx + 1, derived, used) == PASS:
          return PASS
        used.remove(i)    // backtrack
    return FAIL
  

  ¶

  The search space is bounded by the number of clauses sharing a constraint_type. In typical usage each type appears at most once, giving O(n) behavior. Implementations MAY employ Hopcroft-Karp or similar maximum matching algorithms for the general case.¶

• any: A derived any constraint subsumes a parent any constraint if every clause in the derived constraint is subsumed by at least one clause in the parent constraint, using the per-type subsumption rules defined in this section. Formally: for each clause_d in derived.any.constraints, there MUST exist a clause_p in parent.any.constraints such that clause_d ⊑ clause_p. Removing clauses is valid (it narrows the accepted set). Adding clauses is invalid (it widens it). The derived any MUST contain at least one clause. Cross-type subsumption between clauses is permitted: for example, a derived clause of exact("pdf") is subsumed by a parent clause of pattern("*.pdf") under the cross-type rules in this section.¶

  Example: a parent token carries any([exact("pdf"), exact("csv"), exact("xlsx")]). A derived token MAY carry any([exact("pdf"), exact("csv")]) because each derived clause is subsumed by a parent clause. A derived token MUST NOT carry any([exact("pdf"), exact("docx")]) because exact("docx") is not subsumed by any parent clause.¶

• not: This specification prescribes a conservative strategy for not → not attenuation. A derived not constraint is valid attenuation of a parent not constraint if and only if the two constraints are structurally identical, compared as JCS-canonical JSON ([RFC8785]). Although widening the inner constraint semantically narrows the negation and restricts authority, verifying this direction requires recursive subsumption in reverse, which introduces significant implementation complexity and risk of divergence. Implementations MUST NOT attempt semantic evaluation to determine not → not subsumption. Issuers that need to tighten a not constraint SHOULD re-issue from the root issuer or use a registered extension type with defined negation semantics. Cross-type pairs involving not (for example, exact → not(X) or not(X) → exact) are not valid attenuations and MUST be rejected.¶

  Example: a parent token carries not(one_of(["a", "b"])), meaning the argument must not be "a" or "b". A derived token MAY carry an identical not(one_of(["a", "b"])) constraint (identity is valid).¶

  A derived token MUST NOT carry not(one_of(["a"])). That inner set is narrower, so the negation is wider: the derived token accepts "b", which the parent denies. This is a privilege escalation and the JCS-identity check rejects it because the two constraints are not structurally identical.¶

  Conversely, a derived token MUST NOT carry not(one_of(["a", "b", "c"])). That inner set is wider, so the negation is narrower: the derived token is genuinely more restrictive (it additionally denies "c"). However, verifying this direction requires reversing the subsumption check on the inner constraint, which introduces implementation complexity and risk of divergence. Implementations MUST NOT attempt semantic evaluation to determine not → not subsumption. The issuer MUST re-issue from root.¶

• contains: A derived contains constraint is valid attenuation of a parent contains if the derived required set is a superset of the parent's required set. Requiring additional elements is a restriction; removing required elements would expand the set of accepted argument arrays and MUST be rejected.¶

• subset: A derived subset constraint is valid attenuation of a parent subset if the derived allowed set is a subset of the parent's allowed set. Shrinking the allowed set is a restriction; adding allowed elements would expand the set of accepted argument arrays and MUST be rejected.¶

Any (parent constraint type, derived constraint type) pair not explicitly permitted by the above rules, or by a registered extension constraint's cross-type subsumption declaration (Section 3.5.1), MUST be rejected.¶

4.6. I5: Cryptographic Linkage

derived.par_hash ==
  base64url-nopad(SHA-256(parent JWS Signing Input))

Each derived token is cryptographically bound to its parent by including the SHA-256 digest of the parent token's JWS Signing Input in the par_hash claim. The JWS Signing Input is the ASCII string BASE64URL(JWS Protected Header) || '.' || BASE64URL(JWS Payload) as defined in [RFC7515] Section 5.1.¶

This binding prevents chain splicing: an attacker cannot substitute a different parent token to weaken the attenuation constraints visible at a given depth.¶

4.7. I6: Proof of Possession

pop_signature verifies under derived.cnf.jwk

The presenter of a token chain MUST demonstrate control of the private key corresponding to the leaf token's cnf.jwk. Proof of Possession is defined in Section 5.¶

5.1. Rationale

A token without proof of possession can be replayed by any party that obtains a copy of the token. In agent systems, tokens flow through model context, tool invocation results, and inter-agent message channels, all of which are observable by other components. PoP binds a specific invocation to the private key of the leaf token's holder.¶

5.2. PoP Token Structure

The holder of the leaf execution token produces a PoP JWT for each tool invocation. The PoP JWT is a compact serialization signed with the holder's private key. It MUST contain the following claims.¶

The PoP JWT payload MUST be serialized as JCS-canonical JSON ([RFC8785]) before JWS signing. This is a whole-payload requirement, not specific to the hta member. The JWS signing input is therefore BASE64URL(JWS Protected Header) || '.' || BASE64URL(JCS(PoP claims)). Whole-payload JCS canonicalization ensures a deterministic byte representation; in particular, it gives hta stable equality semantics so that argument map comparison is unambiguous across implementations and languages regardless of JSON serialization choices.¶

The PoP JWT MUST be signed using the private key corresponding to the leaf execution token's cnf.jwk. The enforcement point verifies the PoP JWT signature against the leaf token's cnf.jwk.¶

{
  "jti": "c980f2a1-4a37-4e88-bb3c-9defd37c1a45",
  "iat": 1741600300,
  "aat_id": "01957a41-0081-7c20-bf3a-00a0c91e1234",
  "aat_tool": "read_file",
  "hta": { "path": "/data/q3-report.pdf" }
}

5.3. Verification

PoP verification is only meaningful against a leaf token whose chain has been fully verified per Section 7. An enforcement point MUST complete chain verification (Section 7, steps 1-6) before evaluating the PoP JWT. A valid PoP JWT against an unverified or invalid chain MUST NOT result in authorization.¶

The enforcement point MUST reject a PoP JWT that:¶

1. Has a signature that does not verify under the leaf token's cnf.jwk.¶

2. References an aat_id that does not match the jti of the presented leaf token.¶

3. Names a tool in aat_tool that is not authorized by the leaf token.¶

4. Presents arguments in hta that violate constraints in the leaf token, per the verification algorithm in Section 7 (step 6b).¶

5. Has iat that is outside the enforcement point's accepted clock tolerance window (RECOMMENDED: ±30 seconds).¶

The PoP JWT iat timestamp and clock tolerance window bound the replay surface to a short interval. Implementations that wish to avoid shared state MAY use fixed-width time buckets (for example, accepting PoP JWTs whose iat falls within the current or immediately preceding 30-second bucket) to simplify enforcement point implementation.¶

Note: The time bucket approach is stateless but probabilistic: a PoP JWT captured early in a bucket remains usable until the end of the following bucket. This approach MUST NOT be used for tool invocations that have side effects or are not idempotent. For any tool invocation where duplicate execution causes unintended side effects, stateful jti tracking MUST be used.¶

Full replay prevention — guaranteeing that a given PoP JWT is accepted at most once — requires stateful tracking of presented jti values across all enforcement points in a deployment. The mechanism for that state (shared cache, database, token-binding infrastructure) is deployment-specific and outside the scope of this specification. Deployments with strong replay prevention requirements SHOULD consult the security considerations in Section 8.6.¶

8.1. Threat Model

This section characterizes the threats that AATs mitigate and the threats that are outside the scope of this mechanism. Implementations SHOULD use this characterization to evaluate whether AATs are sufficient for their threat environment and to identify what complementary controls are required.¶

8.2. Attenuation as the Security Invariant

The security guarantee of this specification rests entirely on the enforcement of the capability monotonicity invariant (I4). An enforcement point that fails to check I4, or that checks it incorrectly, provides no blast radius containment. Implementers MUST test I4 enforcement against the full constraint attenuation matrix in Section 4.5, including all (parent type, child type) pairs, and MUST reject all pairs not explicitly permitted.¶

The other invariants (I1, I2, I3, I5, I6) rely on well-established cryptographic primitives and validation patterns with substantial prior art in deployed systems. I4 is novel. Formal verification of the I4 subsumption rules is in progress, using bounded model checking ([ALLOY]) for set-theoretic constraint types and SMT solving ([Z3]) for domain-specific types requiring arithmetic or string reasoning. For the remaining constraint types, which use conservative syntactic strategies (Section 4.5), model-level verification is ongoing. Implementers are encouraged to treat the subsumption logic for those types with corresponding caution and to publish independent analyses.¶

The reference implementation includes a test suite covering monotonicity of the attenuation invariants under arbitrary sequences, normalization idempotence across encode/decode round-trips, and enforcement agreement between in-memory and deserialized constraint evaluation. See Appendix E for implementation status.¶

8.3. Root Key Compromise

A compromised trust anchor key allows an attacker to issue arbitrary root tokens. This breaks the security guarantees of all chains anchored to that key. Deployments SHOULD implement key rotation procedures and revocation mechanisms appropriate to their risk model. The specific mechanism for root key revocation, including revocation list formats, distribution protocols, and enforcement point update procedures, is outside the scope of this specification.¶

8.4. Holder Key Compromise

A compromised holder key allows an attacker to present existing tokens issued to that holder. The attacker cannot derive tokens with broader scope than the compromised token grants. Mitigation is revocation of tokens bound to the compromised key, or expiry-based recovery for short-lived tokens.¶

8.5. Chain Splicing

The par_hash invariant (I5) is the primary defense against chain splicing, as described in Section 8.1.1. Enforcement points MUST verify par_hash at every chain link per step 4r of the verification algorithm (Section 7).¶

8.6. Replay Attacks

The PoP JWT binds a specific invocation to a nonce, a timestamp, the target tool, and the presented arguments. The timestamp window limits the interval during which a captured PoP JWT remains usable to approximately twice the clock tolerance (RECOMMENDED: ±30 seconds, giving a window of roughly 60 seconds). This provides probabilistic replay resistance and is appropriate only for idempotent, read-only tool invocations where duplicate execution is harmless.¶

For tool invocations that are irreversible or have significant side effects, including financial transactions, data deletion, writes to external systems, and any operation that cannot be undone: enforcement points MUST implement stateful jti tracking for PoP JWTs and MUST NOT rely solely on the timestamp window for replay protection.¶

This specification requires stateful jti tracking for irreversible operations but does not define the storage backend, consistency model, or distribution protocol for that state. The required consistency properties depend on the deployment topology and the risk tolerance of the application. Deployments SHOULD treat the time-windowed PoP as a probabilistic control and layer additional idempotency mechanisms at the application level for high-value operations.¶

8.7. Constraint Evaluation

Several constraint types introduce potential for denial-of-service through expensive evaluation. regex patterns can cause catastrophic backtracking. cel expressions execute arbitrary logic at argument check time. Enforcement points SHOULD impose evaluation timeouts on any constraint type whose check predicate is not O(n) in the length of the argument value.¶

The subsumption check for cel constraints (the balanced-parentheses bracket counting described in Section 4.5) is O(n) in expression length and does not evaluate the expression. Only the runtime check predicate, which evaluates the CEL expression against actual argument values at invocation time, carries unbounded cost. These are distinct operations; implementations MUST NOT conflate them.¶

Extension constraint types registered under Section 3.5 MUST document their computational complexity and any resource limits implementations SHOULD enforce.¶

8.8. Depth Limit

Enforcement points MUST enforce a finite MAX_DELEGATION_DEPTH to prevent resource exhaustion from artificially deep chains. The appropriate value is deployment-specific: linear orchestration chains require far fewer hops than swarm architectures with deep fan-out delegation. Implementations SHOULD choose a value that reflects the maximum chain depth their deployment topology requires, without imposing an artificial ceiling on legitimate use cases. See Appendix B.5 for guidance on selecting an appropriate value.¶

The security rationale for depth limiting goes beyond resource exhaustion. Each delegation hop introduces an additional agent into the trust chain: the enforcement point necessarily trusts not only that the leaf token holder is honest, but that every intermediate holder made sound attenuation decisions. A compromised or misdirected intermediate agent can narrow constraints in ways that serve an attacker's goals while remaining within the invariants. The depth limit bounds the number of such trust extensions that a single root grant can produce.¶

The del_max_depth claim in the root token is the root issuer's explicit policy on chain topology. An implementation that ignores del_max_depth or enforces only a global implementation limit without checking per-token values violates this policy. Enforcement points MUST check both the per-token del_max_depth value (step 4f of Section 7) and the global MAX_DELEGATION_DEPTH (step 4g of Section 7). Neither check alone is sufficient.¶

8.9. Unknown Constraint Types

Enforcement points MUST deny authorization when they encounter an unknown constraint type. Permitting invocation in the presence of an unrecognized constraint would silently remove a restriction the issuer intended to enforce.¶

8.10. Token Revocation

Revocation of individual AATs, including derived tokens, is outside the scope of this specification. The offline delegation model trades per-token revocation granularity for verifiability without authorization server availability. This is a deliberate design choice, not an oversight.¶

Deployments SHOULD use short token lifetimes as the primary recovery mechanism. A short-lived execution token provides a bounded damage window that is operationally equivalent to revocation for most threat models, without the availability and consistency requirements that a revocation list imposes. Root tokens SHOULD be issued with the shortest lifetime compatible with the intended delegation chain depth.¶

Root trust anchor rotation (replacing the trust anchor signing key and re-issuing root tokens) is the appropriate response to a root key compromise. Enforcement points SHOULD support configurable trust anchor sets to enable rotation without downtime.¶

Revocation list distribution, token status list integration, and per-token introspection mechanisms are deferred to a companion document.¶

8.11. Clock Skew

This specification uses clock-based checks in two distinct contexts with different semantics. MAX_IAT_SKEW (Section 4.4, RECOMMENDED: 30 seconds) is a one-sided future-dating tolerance applied to token iat values: it prevents a token issued slightly in the future from being rejected due to minor clock drift between issuer and enforcement point. The PoP JWT timestamp window (Section 5.3, RECOMMENDED: ±30 seconds) is a bilateral replay window applied to PoP JWT iat values: it bounds how long a captured PoP JWT remains usable. These are independent parameters enforced at different points in the verification algorithm and SHOULD be configured separately.¶

PoP JWT timestamp verification requires synchronized clocks. The RECOMMENDED tolerance window is ±30 seconds, which accommodates typical Network Time Protocol (NTP) synchronized deployments with generous margin. Deployments running on cloud infrastructure with guaranteed NTP synchronization SHOULD target ±5 to ±10 seconds. Deployments with stricter security requirements MAY reduce this window further.¶

Implementations MUST enforce a finite maximum tolerance window. Values beyond ±60 seconds provide negligible additional clock skew tolerance while meaningfully expanding the PoP replay window and are NOT RECOMMENDED. A value of ±30 seconds is the conservative baseline; the ±60 second ceiling is intended only for heterogeneous environments such as embedded systems or degraded connectivity scenarios.¶

8.12. Type-Transition Key Separation

The requirement that any type transition use a distinct key (Section 3.1) is not an architectural preference; it closes specific escalation paths. In traditional capability systems, same-key self-issuance across authority types is often benign because the principal model is static and the runtime is trusted. Agentic systems have neither property: agents operate autonomously across untrusted environments, may be subject to prompt injection or context manipulation, and act on behalf of humans without per-action confirmation.¶

If a single key can move between planning authority and tool invocation authority, the delegation/execution boundary collapses under any compromise. The restriction ensures that a compromised orchestrator holding a delegation token cannot directly invoke tools without involving a distinct execution-bound key, and that a compromised executor cannot create new delegation branches under the same identity. This preserves the accountability boundary between authority types and ensures that key separation is enforced structurally rather than by policy.¶

8.13. CEL Conjunction Privilege Escalation

The cel constraint subsumption strategy (Section 4.5) requires that additional clauses in a derived expression be individually wrapped in balanced parentheses: (parent) && (clause). This requirement is a security invariant.¶

Without balanced parentheses, an attacker constructing a derived cel constraint can append a top-level disjunction to widen authority. For example, given a parent expression amount < 10000, the derived expression (amount < 10000) && true || amount < 1000000 passes a naive prefix check but CEL parses it as ((amount < 10000) && true) || (amount < 1000000), which simplifies to amount < 1000000, a 100x privilege escalation.¶

Enforcement points MUST implement the subsumption check using balanced-parentheses bracket counting as specified in Section 4.5. Implementations MUST reject any derived cel expression where the additional clause is not wrapped in balanced parentheses, regardless of whether the expression appears semantically narrower. Implementations MUST NOT attempt semantic evaluation to determine subsumption.¶

8.14. Algorithm Confusion

AATs are signed JWTs. Implementations are subject to the full class of JWT algorithm confusion attacks, including alg: "none" acceptance, symmetric/asymmetric key confusion (RS256/HS256 key reuse), and algorithm substitution across tokens in the same chain.¶

Enforcement points MUST maintain an explicit allowlist of permitted signature algorithms and MUST reject any token whose alg header value is not on that list. Implementations MUST reject tokens with alg: "none" unconditionally and MUST NOT treat the absence of an alg header as equivalent to any permitted algorithm.¶

In chains where multiple token types are verified, implementations MUST apply the algorithm allowlist independently to each token. Accepting a weaker algorithm on an intermediate token because the leaf token used a strong algorithm is a verification failure.¶

The RECOMMENDED algorithm set is the same as for DPoP [RFC9449]: ES256, ES384, ES512, RS256, RS384, RS512, PS256, PS384, PS512, EdDSA. Symmetric algorithms (HS256, HS384, HS512) MUST NOT be used for AAT signatures; symmetric keys cannot provide the per-holder key binding that PoP requires.¶

8.15. Token Content Visibility

AAT payloads are integrity-protected but not encrypted. Token contents, including tool identifiers, argument constraints, and delegation chain structure, are visible to any party that observes the token in transit or at rest. Deployments SHOULD transmit AAT chains over encrypted transport (e.g., TLS) and SHOULD treat stored tokens as sensitive material. Token encryption is outside the scope of this specification.¶

9.1. JWT Claims Registry

This document requests registration of the following claims in the IANA JSON Web Token Claims Registry [RFC7519].¶

AAT claims:¶

The tools map is not a top-level JWT claim; it is a member nested inside the authorization_details array entry with type: "attenuating_agent_token", as defined in Section 3.3. Its structure and semantics are governed by the AAT Constraint Type Registry (Section 9.3) and the RAR profile defined in this document, not by the JWT Claims Registry.¶

PoP JWT claims:¶

9.2. OAuth Authorization Details Types Registry

This document requests registration of the following type in the IANA OAuth Authorization Details Types Registry established by [RFC9396].¶

9.3. AAT Constraint Type Registry

This document requests IANA create the "Attenuating Authorization Token Constraint Types" registry. The registration policy for this registry is Specification Required [RFC8126].¶

Type name:
  (A lowercase string. Example: "path_containment")

Additional members:
  (List each JSON member name, its JSON type, whether it is required
  or optional, its default value if optional, and its semantics.
  Example: "root (string, required): An absolute path prefix.")

check predicate:
  (A complete, unambiguous specification of the boolean predicate
  evaluated against an argument value at invocation time. Must
  cover all edge cases including null, empty, and out-of-range
  inputs.)

subsumes verification procedure:
  (A complete formal definition of what it means for one instance
  of this constraint type to be at least as restrictive as another.
  Must state whether the procedure is conservative and, if so, which
  semantically subsuming pairs it rejects. Must include a soundness
  argument: if the procedure returns true for (C_parent, C_child),
  then for all values v: C_child.check(v) implies C_parent.check(v).)

cross-type subsumption rules:
  (An explicit enumeration of every (parent type, child type) pair
  involving this type that is a valid attenuation, and the conditions
  under which it is valid. List both directions: this type as parent
  and this type as child. All unlisted pairs are implicitly invalid.
  Example:
    - (exact, this_type): valid if the exact value satisfies this
      type's check predicate.
    - (this_type, exact): invalid.
    - (this_type, this_type): valid if [condition].)

security considerations:
  (Any security properties, limitations, or attack surfaces specific
  to this constraint type, including known cases where the check
  predicate or subsumption procedure can be bypassed or confused.)

reference:
  (A stable, publicly accessible document defining all of the above.)

9.4. OAuth Authorization Server Metadata Registry

This document requests registration of the following parameter in the IANA OAuth Authorization Server Metadata registry established by [RFC8414].¶

aat_issuer is a boolean value. When present and true, it indicates that the root issuer supports issuance of AAT root tokens as described in Section 3.7. When absent, the AS is assumed not to support AAT issuance.¶

9.5. OAuth Token Type Registration

This document requests registration of the following token type in the OAuth Token Type Registry ([RFC6749] Section 11.1):¶

• Type name: aat¶

• Additional Token Endpoint Response Parameters: (none)¶

• HTTP Authentication Scheme(s): (none; not a bearer token)¶

• Change controller: IETF¶

• Specification document(s): This document¶

9.6. OAuth Token Endpoint Parameters Registry

This document requests registration of the following parameter in the OAuth Parameters Registry established by [RFC6749] Section 11.2:¶

• Parameter name: cnf¶

• Parameter usage location: token request¶

• Change controller: IETF¶

• Specification document(s): This document, [RFC7800] Section 3.1¶

The cnf parameter carries a key confirmation object as defined in [RFC7800]. When used at the token endpoint, its value MUST be a JSON object containing a jwk member with the requesting agent's public key. The authorization server binds this key into the issued AAT's cnf.jwk claim. The semantics of the cnf object are defined by [RFC7800]; this registration documents its use at the OAuth token endpoint for AAT issuance.¶

10.1. Normative References

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[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/info/rfc7515>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/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/info/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/info/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/info/rfc7800>.

[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/info/rfc8032>.

[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/info/rfc8785>.

[RFC9278]

Jones, M. and K. Yasuda, "JWK Thumbprint URI", RFC 9278, DOI 10.17487/RFC9278, August 2022, <https://www.rfc-editor.org/info/rfc9278>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

[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/info/rfc9396>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/info/rfc9562>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.

[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/info/rfc2119>.

[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/info/rfc8174>.

10.2. Informative References

[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/info/rfc8414>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/info/rfc8392>.

[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/info/rfc8693>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/info/rfc9052>.

[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/info/rfc9449>.

[BISCUIT]

Eclipse Foundation, "Biscuit: Distributed Authorization Tokens", n.d., <https://doc.biscuitsec.org/reference/specifications.html>.

[MACAROONS]

Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A., Vrable, M., and M. Lentczner, "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud", NDSS 2014, 2014, <https://research.google/pubs/pub41892/>.

[SALTZER75]

Saltzer, J. H. and M. D. Schroeder, "The Protection of Information in Computer Systems", Proceedings of the IEEE Vol. 63, No. 9, 1975, <https://doi.org/10.1109/PROC.1975.9939>.

[HARDY88]

Hardy, N., "The Confused Deputy (or why capabilities might have been invented)", ACM SIGOPS Operating Systems Review Vol. 22, No. 4, 1988, <https://dl.acm.org/doi/10.1145/54289.871709>.

[CAMEL25]

Debenedetti, E., Shumailov, I., Fan, T., Hayes, J., Carlini, N., Fabian, D., Kern, C., Shi, C., Terzis, A., and F. Tramèr, "Defeating Prompt Injections by Design", 2025, <https://arxiv.org/abs/2503.18813>.

[DEEPMIND26]

Tomašev, N., Franklin, M., and S. Osindero, "Intelligent AI Delegation", 2026, <https://arxiv.org/abs/2602.11865>.

[WIMSE-ARCH]

Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", March 2026, <https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.

[WIMSE-S2S]

Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y. Sheffer, "WIMSE Workload-to-Workload Authentication", October 2025, <https://datatracker.ietf.org/doc/draft-ietf-wimse-s2s-protocol/>.

[DENNIS66]

Dennis, J. B. and E. C. Van Horn, "Programming Semantics for Multiprogrammed Computations", Communications of the ACM Vol. 9, No. 3, 1966, <https://doi.org/10.1145/365230.365252>.

[MILLER06]

Miller, M. S., "Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control", PhD Dissertation Johns Hopkins University, 2006, <http://www.erights.org/talks/thesis/>.

[ALLOY]

Jackson, D., "Alloy: A Lightweight Object Modelling Notation", ACM Transactions on Software Engineering and Methodology Vol. 11, No. 2, 2002, <https://doi.org/10.1145/505145.505149>.

[Z3]

de Moura, L. and N. Bjørner, "Z3: An Efficient SMT Solver", TACAS 2008, LNCS 4963, 2008, <https://github.com/Z3Prover/z3>.

A.1. Token Exchange (RFC 8693)

RFC 8693 allows a client to exchange one token for another, potentially with reduced scope, by contacting the authorization server. The server enforces scope reduction. This requires network connectivity to the authorization server at each delegation hop and cannot be performed offline.¶

This specification allows a token holder to derive a new token locally, without contacting the authorization server. The attenuation invariant is enforced by the chain verification algorithm, not by a server-side policy check.¶

A.2. Rich Authorization Requests (RFC 9396)

RFC 9396 defines a structured format for expressing fine-grained authorization details in OAuth tokens. This specification uses the authorization_details claim format from RFC 9396 and extends it with: (1) a delegation chain model that links tokens via cryptographic hashes, (2) monotonic attenuation invariants that constrain what derived tokens may express, and (3) proof-of-possession binding that ties invocations to specific key holders.¶

A.3. DPoP (RFC 9449)

DPoP ([RFC9449]) is a token theft prevention mechanism that binds an existing OAuth access token to a holder key, ensuring that a stolen token cannot be presented without the corresponding private key. DPoP does not change what the access token authorizes; the token's authorization claims are unchanged. The resource server grants whatever the access token permits; DPoP adds a cryptographic proof that the presenter holds the bound key.¶

AATs encode the authorization itself. The token specifies which tools may be invoked, with what argument constraints, and by which key holder. Holders can derive tokens with authority equal to or narrower than their own, without contacting the authorization server. The PoP JWT in Section 5 serves a similar cryptographic role to a DPoP proof, binding a specific invocation to the leaf token's holder key, but operates in a different context. Everything else in this specification (the chain model, the attenuation invariants, the constraint type registry, the subsumption matrix) addresses questions outside DPoP's scope.¶

Structurally, DPoP is a two-party protocol between a client and a resource server. There is no delegation model, no parent-child chain, and no attenuation invariant. The chain model of this specification (del_depth, par_hash, del_max_depth, and the six attenuation invariants) has no DPoP analog.¶

At the proof level, DPoP binds to an HTTP method (htm) and URI (htu). AAT PoP JWTs bind to a tool name (aat_tool) and a structured argument map (hta). Tool invocations are function calls, not HTTP requests, and a URI alone carries insufficient information for argument-level constraint evaluation. This is why aat_tool and hta differ structurally from htm and htu: (1) hta carries the full argument map required for constraint evaluation at the enforcement point; (2) aat_id binds the proof to a specific leaf token jti and chain position, for which DPoP has no equivalent.¶

The cryptographic mechanism is the same: an asymmetric key in cnf.jwk, compact JWT serialization, verified against the leaf token's bound key. DPoP could in principle be layered alongside AATs as a transport-level binding for chain delivery, but that combination is outside the scope of this specification.¶

A.4. Biscuit

Biscuit [BISCUIT] is a capability-based authorization token format that combines asymmetric public key signatures with offline attenuation, building on the Macaroons model. Like AATs, Biscuit tokens support offline derivation and monotonic attenuation: a holder can produce a more restricted token without contacting the original issuer, and the resulting token cannot exceed the authority of its parent.¶

The primary structural difference is the policy language. Biscuit encodes authorization logic in a Datalog variant that is evaluated at verification time, requiring a logic engine at the enforcement point. This enables expressive relational policies but introduces a runtime dependency and non-trivial computational bounds to manage.¶

AATs encode authorization as a structured capability map with typed argument constraints. The core constraint types are decidable by structural analysis, requiring no logic engine. For cases where structural constraints are insufficient, CEL expressions provide a bounded escape hatch, and a registered extension type mechanism supports domain-specific constraint types. This tradeoff favors simplicity and predictability at the enforcement point, at the cost of the relational expressiveness Datalog provides.¶

A second difference is scope. Biscuit is a general-purpose authorization token format. It does not natively encode token roles such as delegation versus execution authority, depth-limit claims, or explicit chain position declarations. This specification defines a typed delegation-chain structure with those properties in the token model itself, making the chain independently verifiable as a delegation protocol rather than as a sequence of policy blocks.¶

B.1. Algorithm Recommendations

• Signing algorithm: Ed25519 [RFC8032]. The normative requirement is in Section 3.2. EdDSA provides compact 64-byte signatures suitable for constrained agent environments. The JWS alg header value for Ed25519 is "EdDSA".¶

• Key representation: JWK [RFC7517] with "kty": "OKP" and "crv": "Ed25519".¶

• Token identifier: UUIDv7 is recommended for jti values, providing time-ordered identifiers without central coordination.¶

The algorithm allowlist requirement is normatively defined in Section 7 (steps 3a and 4a) and discussed in Section 8.14.¶

Post-quantum migration: the cnf.jwk key type is not hardcoded to Ed25519. Implementations should be designed to support key type migration. NIST finalized ML-DSA (FIPS 204, formerly Dilithium) in 2024 as a post-quantum digital signature standard. Deployments with long-term security requirements should design their key management infrastructure to support algorithm migration without requiring changes to token structure.¶

B.2. Performance

Chain verification requires one signature verification per chain link. Ed25519 verification is computationally lightweight; for typical chain depths of 3 to 5 links, verification overhead is negligible relative to network latency in most deployment contexts. Constraint evaluation for exact, one_of, range, and similar structural types is O(n) in the number of constraints. For regex and cel, evaluation cost depends on expression complexity and input size; see Section 8.7 for resource limit guidance.¶

B.3. Recognizing Derived Token iss Values in Middleware

In both root and derived AATs, iss is a URI. For root tokens it is a conventional issuer URI. For derived tokens it is a JWK Thumbprint URI ([RFC9278]) with the urn:ietf:params:oauth:jwk-thumbprint:sha-256: prefix. Middleware that routes or policy-evaluates based on iss should recognize the JWK Thumbprint URI scheme and apply chain-aware processing rather than attempting to resolve the URI as an issuer endpoint. The verification key for derived tokens is parent.cnf.jwk, resolved from the preceding chain link.¶

B.4. Relationship to WIMSE

The WIMSE architecture [WIMSE-ARCH] and service-to-service protocol [WIMSE-S2S] address workload identity and authentication for entities that hold and present AATs. A WIMSE workload credential identifies an agent; the iss claim in a root AAT issued to that agent may reference the agent's WIMSE workload identifier. The two specifications are complementary: WIMSE establishes workload identity and authentication; this specification defines a holder-derivable, invocation-scoped delegation and attenuation mechanism that WIMSE does not standardize.¶

B.5. Delegation Depth Guidance

The normative requirement is only that implementations enforce a finite MAX_DELEGATION_DEPTH. This appendix provides non-normative guidance for selecting an appropriate value.¶

The appropriate MAX_DELEGATION_DEPTH depends on the deployment topology. Linear orchestration chains — root issuer, one or two planning layers, leaf executor — require few hops. Swarm architectures with dynamic fan-out, sub-task delegation, or hierarchical agent groups may require significantly deeper chains. The implementation ceiling should reflect the maximum depth the deployment actually needs, not an arbitrary conservative default.¶

Regardless of the implementation ceiling, issuers should set del_max_depth in individual tokens to the minimum depth the specific workflow requires. A grant with a lower del_max_depth than the implementation ceiling is always permitted and limits blast radius if a token is misused. The security value comes from tight per-chain policy, not from a low implementation ceiling.¶

B.6. Implementation Size Limits

The normative requirement is only that implementations enforce finite limits on token size, chain size, constraint nesting depth, and tool count to prevent resource exhaustion. This appendix provides non-normative recommended defaults for implementations with no specific deployment constraints:¶

Deployments should document their enforced limits. Interoperating parties should verify that their respective limits are compatible before deployment.¶

Implementations should prefer exact and one_of constraints over pattern, regex, or cel where the policy permits, as these types produce significantly more compact tokens and simpler subsumption checks.¶

Implementations concerned about parser exposure on unverified payloads in step 2c of the chain verification algorithm (Section 7) may extract jti using a length-limited byte scan rather than a full JSON parser, provided the extraction correctly handles JSON whitespace and string escaping.¶

A single AAT is typically 1-4 KB when base64url-encoded. Chains of two or more tokens will commonly exceed the 4-8 KB header size limits enforced by common reverse proxies and load balancers, resulting in 431 errors. Deployments should transmit AAT chains in a request body field rather than an HTTP header. For size-constrained environments, the CBOR/CWT profile in Appendix D reduces chain size by 30-50% and is recommended when HTTP header transport is required.¶

B.7. Signed Passthrough Metadata

Deployments may need to convey additional signed metadata through the delegation chain, such as a request trace identifier, a tenant context used for logging or routing, or a human-readable subject identifier. This specification does not define a mechanism for such metadata, but the JWT format accommodates it naturally.¶

Implementations may include additional JWT claims in AATs beyond those defined in Section 3. Claims used for passthrough metadata should use collision-resistant names (e.g., reverse domain notation such as com.example.trace_id) and should not encode tool permissions or argument constraints that this specification models in authorization_details.¶

Because additional claims are included in the token's JWS signature, they are integrity-protected within each individual token. However, this specification's chain verification algorithm (Section 7) does not enforce preservation of unrecognized claims across derivation steps. Per Section 3.4, enforcement points ignore unrecognized top-level JWT claims; the fail-closed rule applies only to constraint types within authorization_details. A token carrying a com.example.trace_id claim will not be rejected solely for containing that claim. Deployments that require chain-wide preservation of passthrough metadata must define and enforce their own derivation and verification rules for those claims, either through deployment-specific policy or in a companion profile.¶

B.8. TTL Guidance

The normative requirement is only that derived tokens cannot outlive their parents and that token lifetime does not exceed MAX_TOKEN_LIFETIME (Section 4.4). This appendix provides non-normative guidance for selecting appropriate TTL values.¶

TTL is the primary revocation mechanism in this specification. A token that has expired cannot be used regardless of whether a revocation list exists. Short lifetimes reduce the window of exposure from key compromise, token theft, or scope misconfiguration. The operational cost of short TTLs is re-issuance frequency; this cost is low when the root issuer is available and derivation is offline.¶

The appropriate TTL for each token role depends on the deployment context. Root delegation tokens should be long enough to cover the full orchestration and execution window for the task, but no longer. Leaf execution tokens should be scoped to the expected duration of a single tool invocation. Deployments with intermittent connectivity (edge, embedded, or air-gapped) may need longer lifetimes, with the awareness that longer lifetimes expand the compromise window.¶

Deployments should treat TTL as a policy expression rather than a convenience parameter. A root delegation token with a 24-hour TTL effectively grants the holder 24 hours of authority regardless of how narrowly the capability scope is defined.¶

D.1. CWT Representation

CBOR Web Tokens [RFC8392] and COSE message signing [RFC9052] are the IETF-native binary analogs of JWT and JOSE respectively. An AAT can be represented as a CWT with no change to its semantic content. The attenuation invariants in Section 4 apply identically. The chain verification algorithm in Section 7 applies identically, substituting COSE_Sign1 verification for JWS signature verification.¶

CBOR encoding offers meaningful size advantages over base64url-encoded JSON for token payloads. In typical AAT payloads with several constraint entries, CBOR encoding reduces token size by 30-50% relative to compact JWT serialization. For high-throughput agent pipelines or resource-constrained edge deployments, this difference is operationally significant.¶

D.2. Deterministic Encoding

CWT implementations of this protocol MUST use deterministic CBOR encoding as defined in [RFC8949] Section 4.2. Deterministic encoding requires that integer keys be used for all map entries where assignments exist, that map keys be sorted in length-first, bytewise lexicographic order, and that the shortest-form encoding be used for all values. This ensures that two compliant implementations produce identical byte sequences for the same AAT payload, which is required for correct par_hash computation and cross-implementation chain verification.¶

The hta map within a CWT PoP token MUST also use deterministic CBOR encoding. Implementations MUST NOT use indefinite-length encoding for any AAT or PoP token structure.¶

D.3. Claim Key Assignments

JWT uses string claim names. CWT uses integer claim keys for registered claims to achieve compact encoding. The AAT-specific claims defined in Sections 3 and 5 — namely aat_type, del_depth, del_max_depth, par_hash, aat_tool, hta, and aat_id — require integer key assignments in the IANA CWT Claims Registry [RFC8392] before a normative CWT profile can be published.¶

Those registrations, along with COSE algorithm guidance and CWT-specific serialization rules, are deferred to a companion Internet-Draft. That companion document will reference [RFC8392] and [RFC9052] normatively; this document references them informatively. This document makes no CWT claim key assignments.¶

D.4. Companion Document

A normative CWT profile is intended to be published as a companion Internet-Draft. That document will define integer CWT claim key assignments for all AAT-specific claims, COSE algorithm requirements, and any CWT-specific serialization considerations. The protocol defined in this document serves as the common specification that both profiles reference.¶

E.1. Reference Implementation

A reference implementation of this protocol exists. The chain verification algorithm (Section 7) and token derivation procedure (Section 6) are both implemented. The implementation uses CBOR encoding for the wire format, with Ed25519 signatures carried in COSE_Sign1 structures, and demonstrates that the Section 7 verification algorithm operates correctly over both JWT and CWT representations of the same chain, confirming format independence of the core protocol.¶

RFC Editor Note: Implementation attribution will be updated or removed prior to WG adoption per IETF norms.¶

E.2. Formal Verification

Formal verification of the attenuation algebra is in progress, using three complementary techniques: bounded model checking ([ALLOY]) for set-theoretic constraint types, SMT solving ([Z3]) for domain-specific types requiring arithmetic or string reasoning, and property-based testing against the Rust implementation for all constraint types. Bounded model checking has found no counterexamples for scopes up to 8 constraints and 8 values. The combination is intended to provide evidence toward monotonicity of the I4 invariant across the full constraint attenuation matrix.¶

RFC Editor Note: Implementation details will be updated or removed per IETF norms prior to publication.¶