Verifiable Attenuated Delegation for AI Agent Chains

1.1. The gap in existing mechanisms

OAuth 2.0 Token Exchange [RFC8693] defines delegation and impersonation semantics and a nestable "act" claim. However, [RFC8693] Section 4.1 states that a recipient considers only the top-level claims and the current (outermost) actor; the nested chain is history for audit, not enforced authority. Token Exchange also normally contacts the authorization server at each hop. Neither property supports offline, enforced, depth >= 2 attenuation.¶

Cross-domain identity chaining (see [I-D.ietf-oauth-identity-chaining]) and transaction tokens address related but distinct problems (crossing trust domains and propagating immutable context within one domain, respectively) and explicitly do not provide chained cryptographic attenuation.¶

Capability systems that do provide offline attenuation -- macaroons [Macaroons], Biscuit [Biscuit] -- either verify with a shared secret (macaroons: symmetric HMAC, so every verifier holds the minting key) or use a non-IETF wire format (Biscuit: protocol buffers with an embedded Datalog engine). The historical standards-track ancestor is SDSI/SPKI [RFC2693].¶

This document fills the gap by reusing the JOSE/OAuth stack and adding only the chain linkage, the principal binding, and the subsumption-enforcing verification algorithm. It is designed as the attenuation mechanism satisfying requirements R1 and R5 of [I-D.reece-wimse-cross-org-delegation] and as a companion to [I-D.ietf-wimse-aims], whose placement of the acting agent in "client_id" and the on-behalf-of party in "sub" this profile follows. It shares its approach with, and is intended to converge with, [I-D.niyikiza-oauth-attenuating-agent-tokens] and [I-D.coetzee-oauth-spt-txn-tokens]. Its offline verification model is complementary to the online Delegation Server and synchronous revocation model in [I-D.sweeney-wimse-credential-delegation]. The two are halves of one design, separated by a single axis: whether a server is in the path. The in-token mechanisms this document requires -- constraints carried in the token, parent-hash verification, and a child expiry bounded by its parent's -- are how a verifier with no network reconstructs what such a server would otherwise know first-hand; where a server is in every hop, they are redundant rather than absent. The verifier-side evaluation rules of [I-D.jackson-wimse-evaluation] describe the receiving half of the same problem; this document cites that work informatively, and no requirement here depends on it.¶

3.1. Principal and Acting Agent

A Delegation Chain answers two questions that a holder key alone does not: who is accountable for what the chain does, and which agents took part. The first is answered by "sub", which names the Principal and is invariant along the chain: a child token is issued under the same grant as its parent, so it names the same Principal, and a token that names a different one is not a member of the chain. The second is answered by "client_id", which names the agent acting at each hop. Together they make a chain auditable as well as verifiable.¶

The "par_hash" commitment (Section 5) already prevents a child from being re-parented onto a different token. It does not, by itself, prevent a child from carrying a different "sub" than its parent, because the child is a new token with its own payload. The invariance check in step 3 of Section 6 is what closes that gap, and it is a comparison of two strings, not new machinery.¶

This revision defines no transition mode for chains shaped by the previous revision. A chain whose tokens carry no "client_id" or no "cnf", or whose "aud" is null, is malformed under this revision. A verifier that also accepts such chains under the previous revision's rules does so outside this document and reports which revision's rules it applied.¶

4.1. Scope Syntax and Wildcards

Each member of "scopes" MUST match the following ABNF [RFC5234]:¶

lower          = %x61-7A
digit          = %x30-39
segment        = lower *(lower / digit / "_" / "-")
literal-scope  = segment "." segment *("." segment)
wildcard-scope = segment *("." segment) ".*"
opaque-scope   = 1*( %x21 / %x23-29 / %x2B-5B / %x5D-7E )
scope          = literal-scope / wildcard-scope / opaque-scope

The "opaque-scope" form is the "scope-token" of [RFC6749] Section 3.3 with the asterisk (%x2A) removed. It exists so that a chain can carry a scope string issued by an OAuth authorization server under that server's own naming, which the two structured forms do not admit.¶

A verifier classifies each scope value by its bytes alone, trying the forms in this order: a value that matches "literal-scope" is a literal scope; otherwise, a value that matches "wildcard-scope" is a wildcard scope; otherwise, a value that matches "opaque-scope" is an opaque scope. A value that matches none of the three, for example one that contains an asterisk anywhere other than as a complete final segment following a dot, is invalid. Thus crm.read is a literal scope, crm.* is a wildcard scope, User.Read and openid are opaque scopes, and the bare value *, the partial-segment form crm.re*, and the non-terminal form crm.*.read are invalid. A producer MUST NOT emit an invalid scope. A verifier that encounters one MUST reject the Delegation Token as malformed before evaluating subsumption. There is no case folding: User.Read and user.read are two different scopes.¶

The covering relation between a parent scope and a child scope is:¶

• A parent literal scope covers only an identical child scope.¶

• A parent wildcard scope covers any child scope, literal or wildcard, whose value begins with the parent value after removing only the final * and retaining the dot. Therefore crm.* covers "crm.read", "crm.x.y.z", and crm.x.*; it does not cover the bare name "crm" or the adjacent namespace "crmx.read". Wildcard coverage is segment-bounded and extends to any depth below the named prefix, and a wildcard covers a narrower wildcard under its prefix.¶

• A parent opaque scope covers only a byte-identical child scope. No wildcard scope covers an opaque scope, and an opaque scope covers no wildcard scope.¶

One consequence of classifying by bytes alone is stated here so that deployments can plan for it: a scope string issued by an authorization server that happens to match "literal-scope" is treated as a literal scope, and a wildcard over its prefix covers it. A deployment that needs such a scope to match exactly should not grant a wildcard over its prefix; doing so also gives up wildcard coverage for every other scope under that prefix. This document provides no registry by which a verifier could tell a dotted provider string from a structured literal, and does not add one.¶

This covering relation belongs to the "agent_delegation" authorization detail type; see Section 4.4 for how the relation is bound to the type.¶

4.2. Constraint Vocabulary

The "constraints" member is an array of objects. Each object contains a REQUIRED "key" member, a string identifying the constrained dimension, and exactly one typed constraint value, whose member name is the constraint type. A constraint object is closed: its members are "key", that one type member, and any member the type's definition adds ("order" for "rank"). A constraint object carrying any other member is malformed, and a verifier MUST reject the token. This document defines:¶

• "max" : a number. The value of the associated quantity in one authorized action MUST NOT exceed it (e.g. {"key": "max_rows", "max": 5000}). It is measured per action: nothing in this type aggregates across actions, tokens, siblings, or a subtree.¶

• "max_lifetime" : a number. The sum of the associated quantity over every action authorized under the token carrying it, identified by "jti", MUST NOT exceed it (e.g. {"key": "max_calls", "max_lifetime": 50}). It is measured per token lifetime. A re-issued token (Section 5) is a new "jti" and starts a new total; an issuer that needs a bound to span re-issuance issues the new token with the bound reduced by the amount already consumed.¶

• "max_subtree" : a number. The sum of the associated quantity over every action authorized under the token carrying it and under every token descended from it MUST NOT exceed it. It is measured per subtree. Enforcing it requires accounting across tokens; see Section 9.4 for what an offline verifier can and cannot do with it.¶

• "min" : a number. The value of the associated quantity in one authorized action MUST NOT be less than it (e.g. {"key": "tenure_years", "min": 2}). Where "max" carries a ceiling tightened downward, "min" carries a floor tightened upward.¶

• "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" : a string naming a position in an ordered enumeration. The constraint object additionally carries an "order" member: an array of two or more distinct strings listing the enumeration from least to most permissive, of which "rank" MUST be one (e.g. {"key": "egress", "rank": "internal", "order": ["none", "internal", "any"]}). The associated value MUST be a member of "order" whose position does not exceed that of "rank". The ordering travels with the constraint so that a verifier needs no registry entry per key; a constraint of type "rank" that lacks "order", or whose "rank" is not a member of "order", is malformed.¶

The three measurement scopes -- per action, per token lifetime, per subtree -- are distinct constraint types because they are enforced by different machinery: a per-action bound is decided from the request alone, a per-lifetime bound needs a running total held by the component that authorizes actions under that token, and a per-subtree bound needs a total that spans tokens. A producer MUST NOT emit a cumulative bound under the "max" type. A per-action "max" on a quantity that exists only as a running count, such as a count of calls, bounds nothing, since each action contributes one; a producer bounds a count with "max_lifetime" or "max_subtree". A verifier that holds only the chain checks that a child's per-lifetime and per-subtree bounds are no wider than its parent's (Section 4.3); whether the spend is under the bound is checked only where the running total is held, and an enforcement point that has no access to that total denies (Section 6, step 8). The running total is supplied by the component that holds it, through a channel separate from the request's own parameters; a value the request asserts about its own total is not a total.¶

Within one authorization detail object, the pair (key, type) identifies a constraint. A detail MUST NOT carry two constraints with the same key and the same type, and a verifier MUST reject a token that does as malformed, rather than choosing one of them. Two constraints with the same key and different types (for example a "min" and a "max" on one quantity, forming a range) are permitted and are evaluated independently.¶

The registry in Section 10 allows new constraint types. A verifier that encounters an unknown constraint type MUST treat the action as denied (fail-closed), never as unconstrained.¶

4.3. 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 scope in C's "agent_delegation" detail is covered by at least one scope in P's "agent_delegation" detail according to Section 4.1, and¶

2. for every constraint (key, type) present in P, a constraint with the same key and the same type is present in C whose admissible set is a subset of P's: for "max", "max_lifetime", and "max_subtree", C.value <= P.value; for "min", C.value >= P.value; for "one_of", C's array is a subset of P's; for "not_one_of", C's array is a superset of P's; for "prefix", C's string begins with P's; for "rank", C's "order" is identical to P's, element for element, and the position of C's "rank" in it does not exceed the position of P's, and¶

3. a constraint (key, type) 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.¶

No inference is made across constraint types: a "max_lifetime" in C does not satisfy a "max" in P, and a "max" in C does not satisfy a "max_lifetime" in P, whatever their values. A verifier that does not implement the type of a constraint present in P cannot evaluate rule 2 for it; it MUST treat the chain as not subsumed unless C carries a constraint with the same key and type whose JCS serialization [RFC8785] is byte-identical to P's, and even then the action is denied at step 8 of Section 6 under the fail-closed rule of Section 4.2.¶

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

4.4. Authorization Detail Types and the Verifier

[RFC9396] does not maintain a registry of authorization detail type values; its Section 2.1 recommends that an API designer use a collision-resistant namespace under the designer's control, such as a URI. The type value "agent_delegation" is the one this document and its test vectors use; whether a later revision moves it to a URI-form value under such a namespace is an open question, and the wire value is unchanged by this revision.¶

The covering relation a verifier applies at step 4 of Section 6 is specified per authorization detail type. For "agent_delegation" it is the relation in Section 4.1 together with the constraint rules of Section 4.3. Another authorization detail type, if defined, specifies its own relation, and that relation is what a verifier applies to details of that type. The type selects the relation.¶

A verifier MUST evaluate every authorization detail object in every DT_i, or reject the token. A detail whose type the verifier does not implement is one it cannot evaluate, and the token MUST be rejected as malformed; a verifier that skips a detail it does not understand has reported success on a token it did not read. The verifier classifies detail types when it parses a token, before step 1 of Section 6, so that DT_0 is subject to the rule as every other token is. Under this revision the only type a token may carry is "agent_delegation", and it may carry exactly one detail (Section 4); a later revision may define chains whose tokens carry details of several types, and the per-type binding of the covering relation stated above is what such a definition would build on. A resource server SHOULD declare the types it implements in the "authorization_details_types_supported" member of its protected resource metadata ([RFC9728], Section 2), so that an issuer can learn which chains it will accept. [I-D.jackson-wimse-evaluation] states the same process-every-entry-or-refuse rule from the verifier's side; the requirement here stands on its own.¶

Which chains a verifier accepts across deployments is a trust decision the verifier already makes by the root keys it holds (Section 6, step 1); two verifiers that both implement "agent_delegation" apply the same covering relation to the same chain.¶

4.5. Open Issue: Scope Vocabulary

Subsumption is syntactic. Two deployments that both implement "agent_delegation", and attach different meanings to the same scope verbs, both verify the same chain clean and read it differently, because nothing in the token says what "crm.read" permits. A profile or registry of common operation verbs would close that gap. This document states the limit and supplies neither.¶

A companion document that does supply one is expected to take the result of the native verification in Section 6 as an input rather than re-implement it; to map a scope family to an action definition explicitly; and, where a mapping is ambiguous, to refuse rather than resolve. A companion document is cited from this one when it is an Internet-Draft, so that every reader can cite it by a stable name.¶

6.1. What Verification Establishes

A Verifier is not always an Enforcement Point. An auditor re-checking a recorded chain, an issuer validating a parent before minting a child, or a component that holds a chain but no request, can run steps 1 to 5 and, if a status list is available, step 7. Table 1 states what such a Verifier may and may not conclude.¶

The "subset" row holds for the constraint types the Verifier implements. A constraint type it does not implement fails closed under the rule in Section 4.3, so it can turn a "yes" into a "no" and never the reverse.¶

A Verifier that has not performed step 6 has established that the chain is valid, not that the party presenting it is its holder, and MUST NOT report the chain as authorizing anything. A Verifier that has not performed step 8 has established the leaf Authority as a set and MUST NOT report any action as permitted. Such a Verifier SHOULD report its result as the chain's validity together with the steps it did not perform.¶

6.2. Verification Outcomes

Independent implementations are compared by their outcomes on shared test vectors (Appendix B), and the comparison is only as good as the agreement on how a denial is named. A verifier SHOULD report a denial under the name that Table 2 gives for the check that failed, which is the vocabulary the test vectors declare; since the algorithm denies on the first failure, one denial carries one name. A verifier MAY add detail of its own beside the name. The names are not carried in any token and have no effect on the wire.¶

6.3. Several Chains Reaching One Agent

This document defines the verification of one chain. An agent may hold Delegation Tokens issued along more than one path from one or more roots, and so hold more than one chain. For each request the presenter presents one chain, the Enforcement Point verifies that chain alone, and the action is permitted only if that chain permits it. An Enforcement Point MUST NOT combine the Authority of tokens from different chains, and a chain that fails verification has no effect on the evaluation of another chain the same agent presents. A presenter holding several valid chains chooses which to present; one valid chain that permits the action suffices. [I-D.jackson-wimse-evaluation] treats the same situation from the verifier's side, in its rule that each delegation path is evaluated independently and fails closed on its own; this document cites that rule informatively and does not depend on it.¶

6.4. Open Issue: Trust-Anchor Provenance

Step 1 assumes the verifier already holds the trusted root key or keys. This document says nothing about how a verifier comes to hold that key, how the key is bound to the party it is trusted as, or under which algorithm that binding was made; the algorithm rule of step 1 reaches every token in the chain and stops at the root key. A chain can be post-quantum at every hop and still rest on a root key whose provenance the verifier cannot check. That is a property of every delegation chain design, not of this one, and the author's view is that it belongs to the working group rather than to this document. It is recorded here as open and is not solved here.¶

9.1. Parent tokens remain valid after attenuation

Attenuation produces a new child token but does not, by itself, invalidate the parent. A party holding the parent still holds the parent's (broader) authority. This is mitigated by three mechanisms that MUST be considered together: (a) tokens are short-lived and holder-bound (Section 7), so a leaked parent is both time-boxed and non-replayable without its key; (b) the "par_hash" byte-commitment (Section 5) prevents splicing a child onto a different parent; and (c) status-list revocation (Section 8) allows early invalidation of a parent and its subtree. Deployments that require immediate parent invalidation on delegation MUST use short TTLs and status lists accordingly.¶

9.2. Chain splicing

Without the byte-commitment, an attacker could present a valid child together with a broader token as its purported parent. Step 2 of Section 6 prevents this: the child's "par_hash" digests the parent's exact Signing Input, so only the intended parent verifies. The same check is what denies a child presented with a re-issued parent rather than the instance it was issued under (Section 5).¶

9.3. Confused deputy and over-broad delegation

Because each hop's authority is the meet of parent and request (Section 4.3), a child cannot be induced (e.g. by prompt injection) to exercise authority the parent lacked. The principal invariance check (step 3 of Section 6) adds that a child cannot be induced to act under a different grant than its parent: a token that names another Principal is not a member of the chain.¶

9.4. Unbounded depth, fan-out, and aggregate budgets

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

Quantity constraints compose across siblings, and subsumption is checked per edge. A "max" constraint bounds one authorized action and nothing else (Section 4.2). A parent holding {"key": "max_spend", "max": 100} can mint any number of children each carrying max_spend 100; every parent-child edge satisfies C <= P, and a subtree of N children can spend N x 100. The same holds at a single enforcement point and across several: against a root ceiling of 100, two valid children can each authorize 60 at two different gateways; both chains verify, each gateway sees a request within bound, and the combined spend is 120. Individually permitted delegations compose into an outcome nobody permitted. The "max_subtree" type names that total, and a chain-only verifier checks only that a child's "max_subtree" is no wider than its parent's; verification is side-effect free by design, so a signed ceiling names a limit while nothing in verifying it reserves against that limit or sees another gateway's balance. A signed ceiling alone provides none of the protection an aggregate budget needs.¶

An aggregate budget over a consequential resource therefore needs machinery outside the token, and that machinery has two separable parts. Allocation -- deciding how much of a parent's budget each child may consume -- requires coordination: an allocator that splits a budget at delegation time only keeps the total under bound if it is a single writer, since two issuers allocating offline from the same budget can each allocate the same units. Spending afterwards does not require coordination once allocations are disjoint: each enforcement point debits its own durable balance for the allocation it holds and contacts no shared service per action. Two deployment shapes follow, and a deployment that enforces aggregate budgets uses one of them:¶

• Shared accounting: one ledger, consulted by every enforcement point, that checks and debits atomically at authorization time. A ledger that is read at authorization and debited afterwards, or debited by more than one writer without coordination, does not close the hole; the check and the debit are one operation or the budget is not enforced. An online Delegation Server through which every action is exercised, as in [I-D.sweeney-wimse-credential-delegation], is one place such accounting can be held.¶

• Coordinated allocation with local enforcement: a single-writer allocator reserves disjoint allocations for the children (for example 60 units to the child acting at gateway A and 40 to the child acting at gateway B, leaving none at the parent, since allocating to a child reduces what remains available to the parent), and each enforcement point enforces its own allocation locally against a durable balance. This path has to protect against three hazards that a signed ceiling does not: duplicate allocation of the same units to two children; local rollback, where an enforcement point loses or reverts a debit it has already honored; and premature reuse of allocated units before the action that consumed them is settled.¶

Either way, the division is the one this document is built on: the offline chain bounds each action and produces the audit trail; the online half holds the aggregates.¶

9.5. Offline verification vs. revocation latency

Offline verification means an enforcement point may honor a token that has been revoked but whose status-list update it has not yet fetched. Deployments trade this window against TTL: shorter TTLs bound the exposure, and step 7 of Section 6 fixes the window at the cached answer's time to live. This is the standard status-list trade-off and MUST be documented for each deployment.¶

The lifetimes Section 8 recommends have a second cost, which is on the issuing side rather than the verifying side. A token that lives for seconds to minutes and is still needed must be re-issued, so a platform with many live agent instances sustains a refresh rate proportional to the number of live instances, continuously, not only at startup. That rate is a property of the deployment and a deployment MUST size its authorization server for it, and for the resynchronisation case in which many instances refresh at once after an outage of the issuer or of the network between them. Offline verification is preserved under these lifetimes; offline operation is not, because an agent whose issuer is unreachable stops receiving tokens when its current ones expire.¶

The refresh rate counts every token in a chain, not only the roots, and grows with fan-out. Rule 4 of Section 4.3 and step 5 of Section 6 cap a child's "exp" at its parent's when the child is issued, so at the recommended lifetimes every child that keeps working is re-issued at least once per parent lifetime, whichever instance of the parent it commits to (Section 5). A deployment that revokes the previous parent instance at refresh adds a burst on top of that rate: every child of that instance at once. Both the sustained rate and the burst belong in the sizing above, and the fan-out bound of Section 9.4 is what bounds them.¶

9.6. Why not macaroons; algorithm agility

Macaroons [Macaroons] verify with the root secret, precluding public offline verification at an untrusted edge; this document uses public-key signatures. Algorithms are fully specified [RFC9864] and agile via the JOSE "alg" registry, with a migration path to ML-DSA [RFC9964]. The algorithm list of step 1 in Section 6 is the agility mechanism on the verifying side. A deployment that retires an algorithm, for example a quantum-vulnerable one after a transition date, removes it from the verifier's list, and chains that still use it are then denied whatever their remaining lifetime. Because every hop's "alg" sits in a protected header that the child's "par_hash" covers, a verifier holding the full chain sees every hop's algorithm, and a parent whose algorithm was swapped after the fact no longer matches its child's commitment.¶

9.7. Root issuance is the policy decision point

DT_0's Authority is asserted by whoever holds the root key. Every guarantee in this document begins downstream of that minting: each child is a deterministic attenuation of DT_0, and verification can establish that no hop exceeded the root, never that the root was right. Approval policy therefore belongs at root issuance. A deployment that requires a human decision before an agent may act with consequential authority places that decision where DT_0 is minted, not at a later hop, because no later hop can widen what DT_0 granted and no verification step can tighten it. The Principal named in DT_0's "sub" is the party that decision is taken on behalf of, and the "client_id" of each hop records which agent acted under it.¶

12.1. Normative References

[I-D.ietf-oauth-status-list]

Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf-oauth-status-list-21, 21 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-21>.

[RFC2119]

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

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>.

[RFC6749]

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

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8037]

Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, <https://www.rfc-editor.org/rfc/rfc8037>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9068]

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

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

[RFC9864]

Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, October 2025, <https://www.rfc-editor.org/rfc/rfc9864>.

12.2. Informative References

[Biscuit]

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

[I-D.coetzee-oauth-spt-txn-tokens]

Coetzee, R. J., "Transaction-Bound Authorization Tokens for Software and AI Agents (SPT-Txn)", Work in Progress, Internet-Draft, draft-coetzee-oauth-spt-txn-tokens-03, 19 July 2026, <https://datatracker.ietf.org/doc/html/draft-coetzee-oauth-spt-txn-tokens-03>.

[I-D.hamr-oauth-agent-delegation]

Hassan, A., "An Attenuated Delegation Profile for Automated Agents", Work in Progress, Internet-Draft, draft-hamr-oauth-agent-delegation-02, 20 September 2026, <https://datatracker.ietf.org/doc/html/draft-hamr-oauth-agent-delegation-02>.

[I-D.ietf-oauth-identity-chaining]

Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-17>.

[I-D.ietf-wimse-aims]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf-wimse-aims-00, 15 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-00>.

[I-D.ietf-wimse-identifier]

Rosomakho, Y. and J. A. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse-identifier-03, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-identifier-03>.

[I-D.jackson-wimse-evaluation]

Jackson, W., "Verifier-Side Evaluation Semantics for Delegated Authority Chains", Work in Progress, Internet-Draft, draft-jackson-wimse-evaluation-04, 10 October 2026, <https://datatracker.ietf.org/doc/html/draft-jackson-wimse-evaluation-04>.

[I-D.niyikiza-oauth-attenuating-agent-tokens]

Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, Internet-Draft, draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026, <https://datatracker.ietf.org/doc/html/draft-niyikiza-oauth-attenuating-agent-tokens-01>.

[I-D.reece-wimse-cross-org-delegation]

Reece, M., "Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements", Work in Progress, Internet-Draft, draft-reece-wimse-cross-org-delegation-02, 31 August 2026, <https://datatracker.ietf.org/doc/html/draft-reece-wimse-cross-org-delegation-02>.

[I-D.sweeney-wimse-credential-delegation]

Sweeney, K., "Credential Delegation Protocol for AI Agents in Multi-System Environments", Work in Progress, Internet-Draft, draft-sweeney-wimse-credential-delegation-01, 13 October 2026, <https://datatracker.ietf.org/doc/html/draft-sweeney-wimse-credential-delegation-01>.

[Macaroons]

"Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud", NDSS 2014 , 2014.

[RFC2693]

Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, DOI 10.17487/RFC2693, September 1999, <https://www.rfc-editor.org/rfc/rfc2693>.

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.

[RFC9964]

Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May 2026, <https://www.rfc-editor.org/rfc/rfc9964>.