Independent Implementation and Formal Analysis of Attenuating Delegation Chains for AI Agents

Introduction Several individual Internet-Drafts propose chains of signed tokens in which each link can only narrow the authority of the one before it, so that a verifier can check an agent's authority offline. This report covers two of them, with its revision , and . Other individual drafts propose related mechanisms (a delegation header over HTTP message signatures; an issuer-per-hop chain anchored in a trust registry); they are outside this report. The work began against AAT-01. AAT-02 appeared on 26 October 2026, with changes that its Appendix F describes as breaking -01 implementations, and with a byte-exact test-vector suite and a procedure for comparing results. The verifier gained a separate profile for -02. This report covers both versions and says which of its observations on -01 the -02 text resolves (). What was done: A minimal TypeScript verifier for the chain checks of both drafts, written as an executable specification (see ). A separate verifier profile for AAT-02, written from the -02 text and then run against the author's 229-vector suite: 229 of 229 verdicts agree, with the expected -02 Section 8 step on every denial. A ProVerif model of the shared chain structure (parent-hash linkage, depth, lifetime and capability monotonicity, holder binding and proof of possession), instantiated for both drafts (see ). This report. What was not done: no minting or issuing service, no CBOR encoding, no revocation or status-list handling. The AAT-02 profile was run against the author's published vectors; it has not exchanged tokens with another running implementation. Who did it: an individual, not an author of either draft. The shape and tone of this report follow . The drafts are the object of study; the mechanisms described here are theirs. Source code, model and vectors: (verifier: ; model: ).

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terms, informally, across both drafts.

chain:: An ordered list of tokens, the first a root minted by a trust anchor or issuer and each later one a link attenuating its predecessor.
link:: A token in a chain other than the root.
holder:: The party named by a token's confirmation claim () as able to present it; in AAT-01 and AAT-02 also the only party able to derive from it (I1).
issuer:: The party whose key signs a token. In asor-02 this is the iss of an access token (); in AAT-01 and AAT-02 the root issuer signs the root, and a derived token is signed by its parent's holder, whose key thumbprint is its iss.
attenuation:: Producing a link whose authority (capabilities, depth, lifetime) is no greater than its parent's.
PoP:: Proof of possession of the key a token is bound to, for example a DPoP proof .

"AAT-01" is ; "AAT-02" is ; "asor-02" is . Related documents used below: (JSON Canonicalization Scheme: asor-02 requires the JWS header and payload of every token to be its output, Section 3, and compares a constraint it cannot evaluate by its bytes, Section 4.3; AAT-01 requires it for the PoP JWT payload and for comparing hta with the invocation arguments, Sections 5.2 and 7; -02 drops the payload requirement and compares constraint values and arguments by it, -02 Section 3.4), (JWK thumbprint URI, the iss of a derived AAT; asor-02 binds the holder by a thumbprint in cnf instead) and (rich authorization requests; both drafts carry authority as authorization_details). Finding labels A1 to A7 (asor-02), B1 to B25 (AAT-01), C1 to C10 (AAT-02) and M1, M2 (the two properties of ) are this document's own numbering. They are not used by the drafts or by the reviews cited here.

Reported Drafts

AAT-01 and AAT-02 (Niyikiza) defines Attenuating Authorization Tokens: JWTs whose authorization_details () list the tools a holder may invoke and typed constraints on each argument. A root token is issued by a root issuer and verified under a configured trust anchor key. Each later token is derived offline by the holder of its parent: it is signed by the key the parent names in cnf.jwk, its iss is that key's JWK thumbprint URI (), and its par_hash is the SHA-256 hash of the parent's JWS signing input (Section 4.6). The invariants I1 to I6 (Section 4) let a derived token only narrow tools, argument constraints (by a per-type subsumption relation, Section 4.5), delegation depth and lifetime. At each tool invocation the leaf holder presents a proof-of-possession (PoP) JWT over the tool and its arguments (Section 5); an enforcement point checks the chain and the proof in one algorithm (Section 7). (26 October 2026) keeps this structure and makes normative changes that, by its Appendix F, break -01 implementations. The JWS algorithm is the fully-specified Ed25519 () in place of EdDSA, and typ is required and explicit (aat+jwt for tokens, aat-pop+jwt for the PoP JWT). The PoP JWT carries aat_hash, the hash of the leaf's signing input. Trust anchors are (issuer, public key) pairs, and the root's iss must equal the issuer of the anchor whose key verified it. Parsing rules are strict: duplicate member names are rejected (), NumericDates and depths have no fraction or exponent part, crit is processed, and numbers in arguments and constraints must be admissible (-02 Section 3.4). Constraint maps gain optional arguments and a "*" entry for arguments they do not name (-02 Section 3.3). The subsumption relation is written as a table of valid (parent, derived) pairs, every other pair invalid (-02 Section 4.5). MAX_DELEGATION_DEPTH is at least 8. A presentation object with members aat_chain and aat_pop is defined (-02 Section 7.4). The verification algorithm is -02 Section 8; this report names its steps by number and letter (for example, step 3k). -02 publishes a byte-exact JWS test-vector suite and lists implementations in its Appendix E. Both versions are implemented; the model is of -01 (see ).

asor-02 (Asor) defines the Agent Delegation Chain, a profile of OAuth 2.0 JWT access tokens (). Each Delegation Token carries its authority as authorization_details (), the principal in sub (the same value in every token of the chain), the acting agent in client_id, a del_depth that grows by one per hop and is bounded by del_max_depth, and, below the root, a par_hash: the SHA-256 hash of the parent's JWS signing input. Tokens are verified under keys configured at the verifier (Section 6, step 1). The leaf is bound to its holder by cnf () and a DPoP proof (). The offline verification algorithm (Section 6) enforces monotonic attenuation, bounded depth, monotonic expiry and the same principal throughout. Modelled and implemented.

The Verifier The verifier is a minimal TypeScript implementation, not a product. It verifies a chain under one of three profiles, aat-01, aat-02 and asor-02, with a shared chain walk and a profile that supplies the named, section-tagged checks of the draft. Layout, inputs, failure codes and options are documented in verifier/README.md (). The aat-02 profile is a separate set of files that follows -02 Section 8 step by step; every failure carries the step at which it occurs (for example, 3a or 4p2). The aat-01 profile is kept unchanged next to it, as the implementation the AAT-01 findings of refer to. It checks, for asor-02, the steps of its verification procedure up to the action check; for AAT-01, the root, link and leaf checks of its verification algorithm and the proof of possession; for AAT-02, every step of -02 Section 8, including the PoP JWT, with PoP jti tracking and nonces taken from state the caller supplies. It does not implement: asor-02: status lists (a token carrying a status claim is denied with the distinct code not_implemented), holder binding for x5t#S256 (mTLS) confirmation and for ES256 proofs, or a DPoP jti replay cache; cumulative running totals are taken from the caller. AAT-01: keys other than Ed25519 (OKP), HS256 (never accepted), a PoP jti replay cache, or extension constraint types (denied); and it parses every token before verifying any signature, which is not the order of Section 7. AAT-02: algorithms other than Ed25519 (EdDSA is denied, -02 Section 9.11), cnf.jwk keys other than OKP Ed25519 (denied at steps 3l and 4b2), any crit parameter (denied whenever present, since no extension parameter is understood), or extension constraint types (denied). The complete list is in verifier/README.md. Vectors: asor-02: the 35 offline-verification vectors published with the attenu-guard 0.20.0 source distribution, Apache License 2.0, copied unchanged; all 35 produce the outcome they name. AAT-01: 41 vectors of this work's own, written from its reading of -01, which publishes none. They are not the author's vectors. AAT-02: the author's JWS test-vector suite, 229 vectors (54 permit, 175 deny), copied byte for byte from , commit 99fb00994d8d66b213cd12967d6e8eef45025672, file tests/vectors/aat-jws-vectors.json (SHA-256 b7a42e9dfdce7fbc1f623670bf060f90e6d6b25f64384cbab1bd79363e82209b), Apache License 2.0. Result: 229 of 229 verdicts agree on the first run, 0 skipped, and the expected -02 Section 8 step on all 175 denials. No check was adjusted to a vector. Results were compared with the suite's own compare_results.py, following its INTEROP.md.

The Model The model is a symbolic (Dolev-Yao) model in ProVerif's typed applied pi-calculus. Its roles, abstractions, bound (chains of at most four tokens, depth and expiry bounded by 3, tool sets over a three-tool alphabet) and attacker (controls the network, may compromise any holder key, never the trust anchor's key) are described in model/README.md ().

Properties For both profiles:

P1a:: Every root of a chain that passes the link checks was minted by the anchor.
P1b:: Every link whose parent names an honest holder key was derived from that parent by that holder, unless the key was compromised. For asor-02, the variant P1b' states the same with "some uncompromised configured key" in place of the parent's holder (see A7).
P2:: The invoked tool was granted at the root.
P3:: Leaf depth, maximum depth and expiry are bounded by the root's.
P4:: A leaf naming an honest key is used only by that key's holder (non-injective).
M1:: Parent validity after derivation: a parent is still accepted after its holder has derived a child from it, with no compromise at all.
M2:: Intermediate links carry no proof of possession of their own. Variants (a) an attacker derives a child of a token it merely observed, (b) a request is accepted under such a link, (c) a token is usable without its holder's key.

M1 and M2 are the two points of .

Results Model Seconds Query Result aat01 42 P1a true aat01 42 P1b true aat01 42 P2 true aat01 42 P3 true aat01 42 P4 true aat01-no-i5 16 P1a true aat01-no-i5 16 P1b false aat01-no-i6 12 P4 false aat01-p4-inj 23 P4 injective false aat01-p4-inj 23 P4 true aat01-m1 1 M1 reached aat01-m2 39 M2 (a) true aat01-m2 39 M2 (b) true aat01-m2 39 M2 (c) = P4 true asor02 197 P1a true asor02 197 P1b' true asor02 197 P2 true asor02 197 P3 (depth, expiry) true asor02 197 P3 (maximum depth) true asor02 197 P4 true asor02-p1b 37 P1b false asor02-nodpop 113 P1a true asor02-nodpop 113 P1b false asor02-nodpop 113 P1b' true asor02-nodpop 113 P2 true asor02-nodpop 113 P3 (depth, expiry) true asor02-nodpop 113 P4 false asor02-m1 139 M1 reached asor02-m2 (DPoP on) 475 M2 (a) false asor02-m2 (DPoP on) 475 M2 (b) false asor02-m2 (DPoP on) 475 M2 (c) = P4 true asor02-nodpop-m2 120 M2 (a) false asor02-nodpop-m2 120 M2 (b) false asor02-nodpop-m2 120 M2 (c) = P4 false asor02-holder-signs-m2 (DPoP on, hs) 350 M2 (a) true asor02-holder-signs-m2 350 M2 (b) true asor02-holder-signs-m2 350 M2 (c) = P4 true asor02-nodpop-holder-signs-m2 (hs) 143 M2 (a) true asor02-nodpop-holder-signs-m2 143 M2 (b) true asor02-nodpop-holder-signs-m2 143 M2 (c) = P4 false Each row is one query of one model file. A file without a suffix is a profile with every check in place, and every query of it is expected true. A .expectfalse file is a variant with one check removed (no-i5, no-i6, nodpop) or asks for a property the profile does not claim (p4-inj, asor02-p1b, the asor-02 M2 files), and at least one of its queries is expected false; a .reachable file asks whether an event occurs in a run of honest roles only, and "reached" is the expected answer. A "false" in a variant is therefore the expected outcome of that variant, not a failed proof; each is accompanied by a ProVerif derivation and trace in model/out/, summarized in model/README.md. hs is the holder-signs flag of the asor-02 model (). A "true" is a ProVerif proof for an unbounded number of sessions of the bounded model (), not a statement about the draft text. Seconds are wall-clock per model file on one machine under make -j6, from model/out/SUMMARY.md; they are indicative.

What the Model Does Not Say Nothing about constraint semantics below the tool level, time (freshness, skew, lifetimes; only expiry order), revocation, the trust anchor's key, size and algorithm checks, or chains longer than four tokens. A "true" is a ProVerif proof for unbounded sessions of the bounded model, not for the draft text.

Findings on AAT-01 and Their Status in -02 Section numbers in this section are those of AAT-01 unless marked "-02 Section". Each finding B1 to B25 has a status line, starting "-02:", that gives how the -02 text relates to it:

closed:: The -02 text decides the point.
closed as design:: -02 keeps the behaviour and says it is intended.
partly:: -02 decides part of the point.
moot:: The question no longer arises in -02.
open:: Unchanged in -02.

Where a vector of the author's suite pins the point, the status line names it by its identifier (J.x.y). Step numbers such as 3k are those of -02 Section 8.

Constraints (B1 to B8) B1 (Section 4.5): cross-type subsumption is an allow-list. Section 4.5 of -01 defines subsumption as a fixed list of per-type rules over (derived, parent) constraint-type pairs and declares every other pair invalid (-02 writes the same list as a table). The list leaves out some pairs whose narrowing is decidable from the values alone. For a composite parent the list loses nothing of its own: an exact under an any can be written as a one-clause any (see B2). Two pairs are lost outright: a one_of whose members all fall inside a parent range, and an exact under a not_one_of, have no equivalent in the parent's type. This implementation follows the list and rejects all of them. -02 keeps the pairs and names the choice: the verifier compares types, not values, so that every verifier gives the same verdict. -02: closed as design -- -02 Section 4.5 lists every valid (parent, derived) pair and says "Every other pair is invalid"; J.19.1, J.19.4 to J.19.7 and J.8.4 deny semantically narrower pairs, and their notes call this conservative by design. B2 (Section 4.5): non-composite child under a composite parent. Section 4.5 of -01 gives rules for all and any only against a parent of the same type, so a plain constraint under a composite parent falls under the closing sentence and is invalid. This implementation rejects it. Nothing is lost beyond B1, because the child can be written in the parent's type. Under an any, a one-clause any is valid when the child narrows one of the parent's clauses. Under an all, the child has to narrow every parent clause: -01 matches each parent clause to a distinct derived clause, so the child is repeated once per clause, while -02 lets one derived clause satisfy several. Each step goes through the pairs, so the rewrite fails exactly where a clause meets one of the two pairs of B1, and an all with more clauses meets them more often. -02: closed as design -- J.8.4 (range under all) and J.19.1 (exact under any) are denied; J.18.1 denies all under any. B3 (Section 4.5): empty composite constraints. Section 4.5 of -01 says only that a derived any must contain at least one clause. An empty all is satisfied by every value and an empty any by none, so an empty parent all grants the argument without limit and an empty parent any forbids it; -01 addresses neither. This implementation treats an empty clause list as malformed for both types, in either position. -02: closed -- -02 Section 4.5 makes an empty all or any invalid in both the parent and the derived position; it is denied at steps 3n and 4o (J.21.7, J.16.3). B4 (Section 4.5): range corner cases. Section 4.5 of -01 compares the bounds of a derived range with the parent's, one bound at a time. It does not say what a range that no number satisfies means (min greater than max, or equal bounds with an exclusive side), nor what an inclusivity flag without its bound means. This implementation applies the bound rules literally, which never widens authority. An empty derived range whose bounds lie inside the parent's is accepted and denies every value; one whose bounds lie outside is rejected, although an empty set narrows anything. Under an empty parent every derived range that passes the bound rules is itself empty. A flag without its bound has no effect. A verifier that rejects empty ranges as malformed therefore denies more than this one, never less, and neither grants anything the parent does not. -02: partly -- -02 Section 3.4 well-formedness requires min not greater than max and inclusivity flags only with their bound (J.8.6, J.8.21, J.8.24). An empty range with equal bounds and an exclusive side (min equal to max, min_inclusive false) is still well-formed. B5 (Section 3.4): value model and equality. -01 says only that exact.value is "any scalar" and must be equal "exactly"; it does not say whether null is a scalar, whether 1 equals "1" or 1.0, or what happens to a number a parser cannot hold exactly. This implementation takes string, number and boolean, compares by JCS, and refuses integers beyond 2^53-1 so that a constraint and the tool see the same value. That refusal covers integers only: a fraction such as 1.00000000000000001 is still read as 1. -02: closed -- exact.value may be a string, number, boolean or null, equality is by JCS, and the admissibility rule of -02 Section 3.4 replaces this implementation's refusal of integers above 2^53-1 (J.8.8 permit; J.8.7, J.8.10, J.8.14 deny). B6 (Section 3.4): arrays as sets. -01 does not say whether order or duplicates matter in the arrays of contains and subset, so two verifiers can disagree on the same argument. This implementation treats both arrays as sets. -02: closed -- -02 Section 3.4: contains and subset "treat their arrays as sets" (J.26.11, J.26.12). B7 (Section 3.4): unknown members of a core constraint type. -01 specifies what to do with an unknown constraint type and says that unknown top-level claims are ignored, but not what to do with an unknown member of a known type. Ignoring it would be unsafe: a misspelt bound such as maximum for max would leave the argument unbounded. This implementation rejects such a constraint as malformed. -02: closed -- well-formedness allows "no members other than" those of the type (J.21.12, maximum). The strict reading of -01 taken by this implementation is now the text. B8 (Sections 3.6.2, 4.5): key-set rule and tool omission. Under a non-empty constraint map -01 fixes the shape of an invocation: every named argument must be present and no other may appear. A derived token may drop a whole tool (Section 3.6.2) but must keep exactly the parent's argument keys, because adding or dropping a key yields invocations the parent would reject. The rules are consistent; the cost is rigidity. A holder cannot forbid one argument while keeping the tool, and an argument the issuer wants to leave optional cannot be constrained at all; only a parent with an empty map lets a child choose keys. This implementation follows the rules as written. -02: moot -- optional and "*" (-02 Section 3.3, the key rules of -02 Section 4.5, steps 4p2 and 4p3) give the means the closed-world key rule lacked (J.22.*).

Chain (B9 to B19) B9 (Section 4, Section 7): redundant checks (I2e, step 5). Some checks of -01 Section 7 follow from others. child.del_depth <= parent.del_max_depth (4e) follows from 4g and 4m, child.del_depth <= MAX_DELEGATION_DEPTH (4f) from 3i, 4g and 4m, and the "defense in depth" step 5 from 3c and 4d. No input fails one of them alone; this implementation keeps all of them, and its property tests reach 4e only together with 4g or 4m. Redundant checks are harmless, but a test suite cannot cover them as single faults. -02: open -- unchanged in -02 Section 8. The suite's README names "steps 4e, 4f and 5" among the checks that can never be the only fault. J.10.c reaches 4e only as the first of two faults (4m also fails). B10 (Section 4.4): MAX_TOKEN_LIFETIME is redundant by construction. A child cannot outlive its parent, so a lifetime bound checked on the root holds for every link; the note to step 4l of -01 says as much. This implementation checks it on every token anyway. -02: closed -- the notes to -02 Section 8 say the bound holds by induction (steps 3h, 4h and 4j); -02 has no per-child lifetime step. B11 (Section 7): which anchor key verifies the root and what iss means. In -01 the trust anchors are "a set of public keys" without issuer names; the root verifies under any of them (step 3b), and step 3k requires only that root.iss be a URI. Section 3.2 says that iss identifies the root issuer, but nothing ties it to the key that verified the signature. When an enforcement point trusts more than one issuer, any of them can sign a root that names another as iss, and the chain verifies. Within -01 this does not change a verdict, since nothing else reads root.iss; it matters as soon as audit or local policy relies on the issuer. The aat-01 profile follows -01 and accepts the root under any anchor; the aat-02 profile implements the new step 3k. -02: closed -- trust anchors are (issuer, key) pairs; step 3k compares the root's iss with the issuer of the anchor that verified the signature (J.21.6, J.21.22, J.21.23). B12 (Section 4.2): I1 comparison of a URN as a string. I1 requires child.iss to equal jwk_thumbprint_uri(parent.cnf.jwk), a URN. makes parts of a URN case-insensitive, so "equals" can be read as a string or as a URN comparison. This implementation compares strings exactly; it computes the thumbprint for OKP keys only, with the member order of . An exact comparison can only deny more, never less. -02: open -- step 4c still says "equals"; -02 says nothing about case-insensitive comparison of the URN (). J.27.6 pins only the thumbprint members. B13 (Sections 3.2, 7, 8.13): algorithms and thumbprints. -01 Section 3.2 requires support for Ed25519, while Section 8.13 admits the DPoP algorithm list, including ES256 and RS256, and the closing note of Section 7 mentions Ed448; I1 would then need thumbprints for those key types as well. This implementation accepts only EdDSA with an OKP Ed25519 key and always refuses symmetric algorithms (Section 8.13). -02: closed -- the fully-specified Ed25519 (); -02 forbids accepting EdDSA and requires alg to be consistent with the key's kty and crv (J.7.5, J.7.8, J.7.10, J.14.b). B14 (Section 7): parse before verify. -01 Section 7 forbids reading claims before the signature is verified, but step 4b needs the parent's parsed cnf.jwk, and step 2c lets jti be extracted first. This implementation checks the size limits (2a, 2b), parses every token, and then verifies. The verdict is the same either way; only the reported code for a forged malformed token differs (malformed rather than signature_invalid). -02: closed -- steps 3b, 4b and 7b fix the order per token. With pairs walked in order, the parent's cnf.jwk is parsed before the child's signature is needed. The aat-02 profile follows the order literally; aat-01 keeps parse-first. B15 (Sections 3.2, 3.4): sub. -01 Section 3.2 "intentionally omits" sub, and Section 3.4 says a token must not be rejected solely for claims outside those defined. Rejecting a token with sub is therefore not required, and arguably not allowed. This implementation rejects it by default and has an option to accept it. -02: open -- -02 still "intentionally omits the sub claim" and requires unrecognized top-level claims to be ignored. The aat-02 profile does not reject sub by default (rejectSub false). No vector carries sub (J.27.1 covers other unrecognized claims). B16 (Section 3.2): jti format. -01 says jti SHOULD be a UUIDv7 and, when a UUID is used, MUST be lowercase and hyphenated, but steps 3j and 4b1 check only for a non-empty string. This implementation accepts any non-empty string and rejects a UUID-shaped value with upper-case letters. -02: closed -- the notes to -02 Section 8 say the lowercase UUID form "binds producers and has no verification step". The aat-02 profile checks only for a non-empty string (aat-01 still rejects upper-case UUIDs). B17 (Section 7): limits without defaults. MAX_DELEGATION_DEPTH has no recommended value in -01; the other limits (MAX_IAT_SKEW 30 s, MAX_TOKEN_LIFETIME 90 days, MAX_CONSTRAINT_DEPTH 32, MAX_TOKEN_SIZE 64 KiB, MAX_STACK_SIZE 256 KiB) are RECOMMENDED. Whether a chain is valid then depends on local configuration, and a test vector has to state the limits it assumes. This implementation uses 16 for the depth. -02: closed -- MAX_DELEGATION_DEPTH is at least 8 (J.10.f, J.21.15, J.21.19); the suite states every parameter. B18 (Section 4.6): par_hash covers the signing input, not the signature. Two JWS with the same signing input and different signature bytes are therefore the same parent for I5. With Ed25519 and strict verification this cannot be exploited; the choice is still worth stating in the draft, since a profile with a malleable signature algorithm would inherit it. -02: open -- unchanged design; aat_hash is computed the same way. B19 (Sections 4.2, 4.7, 8.9): the review's points as AAT-01 answers them. , posted on the OAuth list the day -01 appeared, makes two technical points about the chain, apart from the comparison with HMAC-chained Macaroons and SPKI/SDSI: a parent token stays valid after a child has been derived from it, so the design lacks the re-keying of Macaroons; and only the leaf proves possession, so an agent that sees the bytes of an intermediate or root token could use them. The author's reply on the list called additive derivation intended and every token holder-bound. This report names the points M1 and M2 () and checks them in the model rather than in the reply. The second point -01 answers in its text. Section 4.2 (I1) requires the derived token to be signed by the holder of the parent, Section 4.6 (I5) commits it to that parent's bytes, and Section 4.7 (I6) requires the presenter to prove possession of the leaf key. A token observed in transit can therefore neither be extended, since derivation needs its holder's key, nor presented as a leaf, nor moved under another parent. The model confirms this for -01: against an attacker who sees every token and may hold any holder key other than that of the token in question, no link is derived from it (M2 a, P1b), no request is accepted through such a link (M2 b), and no request is accepted with it (M2 c, P4). The first point -01 does not state. Nothing in the text says that a parent remains valid after derivation; Section 8.9 puts revocation out of scope and recommends short lifetimes, and Sections 8.1.2 and 8.4 give the consequence, that a compromised holder key exercises the full authority of every token bound to it until expiry, without the property behind it. The model shows M1 as a run of honest roles alone: a holder derives a child from its token and is then accepted with that same token, with no key compromised. It is how the design works, not an attack on it. This implementation checks I1, I5 and I6 and keeps no state that would retire a parent after derivation, since -01 defines none. -02: closed as design -- -02 Section 9.1.1 says that derivation is additive, that every token in a chain carries a holder key, and that a sub-agent holding its parent's bytes cannot invoke with them; -02 Section 9.4 says that AATs do not re-key, that a compromised holder key exposes every token bound to it, and gives deriving to a fresh key and destroying the parent's key as the approximation (-02 Section 9.4, with the fresh holder key of -02 Section 9.10). M1 and M2 () are this report's independent check of it; the vectors do not bear on it.

Proof of Possession (B20 to B23) B20 (Section 5.2): PoP header and typ. -01 specifies no typ, kid or jwk header parameter for the PoP JWT, so nothing distinguishes it from another JWT signed by the same key. This implementation looks only at alg. -02: closed -- typ is aat-pop+jwt (J.7.1, J.7.2); a jwk header parameter is ignored as a key source (J.7.14). B21 (Sections 5.2, 7): JCS of the whole PoP payload. -01 Section 5.2 requires the holder to serialize the whole PoP payload with JCS, but step 7f compares only hta, and nothing says whether an enforcement point must reject a payload that is not canonical. This implementation rejects it: the payload bytes must equal their JCS re-serialization. -02: closed (requirement dropped) -- -02 Appendix F: "PoP payloads no longer need to be JCS-canonical". Only hta is compared (step 7f). B22 (Section 7): clock tolerance. -01 recommends a PoP window of 30 seconds either side, and separately a one-sided MAX_IAT_SKEW of 30 seconds for tokens; it does not say whether the two are the same parameter. This implementation keeps them apart: the PoP window is its own option, symmetric, with inclusive bounds. -02: closed -- -02 Section 9.9 separates the one-sided MAX_IAT_SKEW from the bilateral PoP window (J.20.4, J.20.15, J.20.16). B23 (Section 5): PoP binds the leaf only. In -01 the PoP JWT names the leaf by aat_id, which must equal the leaf's jti (Section 5.3), a value chosen by whoever derived the leaf; neither the leaf's bytes nor the chain enter the PoP signature. Which chain