Niki, Yes, the split matches how I see it. Three points, then a yes to your proposal.
1. Chain-wide budgets. Offline attenuation and a Delegation Server in the call path are complementary. Where a budget spans the whole subtree (max_lifetime, max_subtree), someone has to be the single writer of the running total. In Cred -02 that is the DS ledger, carried as delegation_constraints. It layers on top of an AAT-style chain rather than replacing it. 2. Revocation. Your model, where the enforcement point refuses any chain containing a revoked token, works exactly as far as the enforcement point has current revocation state. For tokens exchanged or verified away from the DS, that is partial until expiry. Cred -02 Section 7 says this directly: revoked_count is invalidation, not closure, cross-DS and cross-domain revocation is out of scope, and the 1-hour token cap is what bounds admission after revocation. So I read this as a split along who holds state, not a disagreement. It would help if the companion document for AAT Section 9.8 stated the freshness bound the enforcement point is expected to meet. 3. del_max_depth. Cred -02 Section 5.5 adopts the Asor agent_delegation format unchanged for tokens verified away from the DS, so the Asor semantics apply there: a leaf at del_depth equal to the root maximum is rejected. AAT J.10.f accepts it. I would like one meaning across the drafts, and I lean toward the Asor registry entry, but I care more that the vectors get reconciled than which way it lands. Kieran On Sun, Nov 01, 2026 03:55 PM, Niki Aimable Niyikiza <[email protected]> wrote: > 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]
