Hi Kieran, Thanks, this is a helpful way to frame it, and I agree that offline attenuation and a server in the call path are complementary.
Chain-wide budgets are a good example of what offline verification can't give on its own, and you're right that they need a single writer that sees every exercise. I see them as a layer on top of AAT rather than part of the core, since core AAT keeps no running totals. ARCP already adds them as a profile (Appendix E.4), and your Delegation Server is a natural home for them, especially when a budget spans several enforcement points. Revocation is where I'd draw the line a little differently. You're right that revoking anything below the root needs a party in the path, but in AAT the enforcement point already is one. It sees the whole chain on every invocation, so refusing any chain that contains a revoked token also cuts off everything derived from it. Section 9.8 leaves the details to a companion document. Does that split match how you see it? The del_max_depth semantics differ by one hop. Under a root with del_max_depth 8, AAT accepts a leaf at del_depth 8 (J.10.f in the AAT test vectors) and asor -03 rejects it. Now that Rafael's draft settles on a single registry entry for the name, I'd like it to have a single meaning too. I agree that one subsumption rule per constraint type is the right goal, and the three drafts are already close on the types they all have (set membership and numeric bounds). Where they really differ is whether a child can narrow to a different type (AAT lets a child pin a single value from a parent's one_of or range), how numbers are compared, and what a constraint applies to. Comparing asor's vectors with AAT's is how the depth difference came to light, and I'd be happy to do the same for the constraint types across all three drafts before IETF 127. If you, Rafael and others working on this will be in San Francisco, it would be great to go through it together. Best, -Niki On Fri, Oct 30, 2026 at 6:26 PM Kieran Sweeney <[email protected]> wrote: > Niki, > > You asked how AATs fit for people building agent delegation. I work on the > server-side half (draft-sweeney-wimse-credential-delegation), and I think > the two compose: holder-derived attenuation offline, and a server in the > call path where a deployment needs what offline verification cannot give. > > -02 already states the two limits where that line falls. Chain-wide > cumulative budgets, which Appendix E.4 lists for ARCP, need a single writer > that sees every exercise; holders and separate enforcement points cannot > hold the total between them. Revocation finer than the root, which 9.8 > leaves to lifetimes, needs a party in the path. Section 5.5 of my -02 > covers both for tokens verified away from the issuing server. > > One thing worth settling before 127: there are now three offline > attenuation formats with typed constraints (AATs, > draft-asor-wimse-agent-delegation-chain and > draft-hulea-wimse-agent-mandate), each with its own subsumption rules, and > asor reuses your chain claim names with a different del_max_depth > semantics. My draft uses the asor ceilings. I am not asking anyone to pick > a winner, but one subsumption rule per constraint type across the three > would save verifiers from implementing the same comparison three ways. > > Kieran > > On Tue, Oct 27, 2026 10:57 AM, Niki Aimable Niyikiza <niki= > [email protected]> wrote: > >> Hi all, >> >> I've posted -02 of Attenuating Authorization Tokens (AATs): >> >> https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/ >> >> Since -01: >> >> - Twelve Internet-Drafts now cite AATs, and Appendix E lists 3 new >> independent implementations. >> - Section 8 specifies chain verification step by step, and -02 comes >> with 229 public test vectors for it: >> https://github.com/tenuo-ai/tenuo/blob/main/ietf/vectors/INTEROP.md >> - Section 1.3 describes how AATs complement transaction tokens, >> identity chaining and WIMSE's AIMS draft, and how they differ from >> Macaroons, SPKI/SDSI, Biscuit and UCAN. >> >> >> Appendix F lists the changes from -01, and the diff is here: >> >> https://author-tools.ietf.org/iddiff?url2=draft-niyikiza-oauth-attenuating-agent-tokens-02 >> >> Thanks to Neil Madden for the review of -01 on this list, and to everyone >> who reviewed and implemented -01. >> >> Reviews are welcome, especially of Section 8. If you're building agent >> delegation, I'd be glad to hear how AATs fit your deployment. >> >> >> Thanks, >> -Niki >> >> -- >> Niki Aimable Niyikiza >> Tenuo >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > -- Niki Aimable Niyikiza Tenuo
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
