Hi Kieran, Glad we're on the same page. You're right that the companion document should specify how fresh an enforcement point's revocation state must be.
Regarding the registry, Rafael and I agree that each name should have a single entry. So it comes down to how the del_max_depth entry is interpreted. Azat's implementation report highlights a second difference beyond the leaf at the maximum. For example, if a root has del_max_depth 8 and its holder delegates with del_max_depth 2, AAT caps everything below it (rejecting a token at depth 3), whereas Asor checks depth only against the root's 8 (passing the same token). I believe our shared definition should retain that cap, as it allows holders to properly restrict their own delegation depth. I agree on reconciling the vectors. J.10.f covers the leaf at the maximum, and I am happy to add a case for the scenario above. Thanks for confirming on the comparison. I will have it ready ahead of IETF 127. Best, -Niki On Mon, Nov 2, 2026 at 6:40 AM Kieran Sweeney <[email protected]> wrote: > 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 >> > -- Niki Aimable Niyikiza Tenuo
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
