Hi Neil, Thanks for the quick look, and I'm glad the Macaroons lineage resonates.
> why not actually just use (HMAC) macaroons? Are you envisioning these tokens traversing organisation boundaries? Yes, crossing trust boundaries is the target case. HMAC Macaroons work well when the verifier has access to the verification secret, or can rely on a service that does. In the AAT target model, the enforcement point checking a chain is often not the root issuer and should not require a shared secret or a call back to the issuer. Asymmetric signatures let any enforcement point verify the full chain against the root trust anchor's public key alone. Biscuit makes a similar move away from HMAC for this reason. > nothing is removed when creating a derived token, so the parent AATs remain valid ... What prevents a Tool Invoking Agent from replaying the Root AAT back to the Orchestrating Agent? Derivation is indeed additive in our protocol and the parent stays valid. That's deliberate for the agent setting, where an orchestrator often derives several narrower child tokens for different sub-agents while retaining its own authority to make tool calls or delegate further. Replay of a parent token is prevented by holder binding: every AAT carries a `cnf` key, and invocation requires PoP under the leaf token's key. Possessing a parent's token bytes is therefore not sufficient to invoke with that parent; the presenter would also need the corresponding parent holder key. The intermediates are holder-bound even though only the leaf is invoked, and I should state that more clearly. The residual risk is the usual one: compromising a holder key exposes that token's authority until expiry or revocation. AATs bound that risk with holder binding, attenuation, and short lifetimes. They do not provide the re-keying/backtracking property that HMAC macaroons get from attenuation, and I'll add that comparison to the security considerations. The protocol assumes holder private keys are not shared across delegation boundaries. Key generation, storage, rotation, and recovery are deployment concerns rather than chain-verification semantics. > you may find it useful to look at SDSI/SPKI (RFC 2693) Thank you for the pointer. The overlap is real, especially key-as-principal authorization, validity intersection, and attenuation by reduction. I'll read RFC 2693 properly and reflect what I learn in the draft. Best, Niki On Mon, Jun 15, 2026 at 11:57 AM Neil Madden <[email protected]> wrote: > I’ve had a brief look. I’m a big fan of macaroons, so I like the idea of > this. However, why not actually just use (HMAC) macaroons? Are you > envisioning these tokens traversing organisation boundaries? > > The solution presented seems to lack the backtracking resistance present > in macaroons - that appending a caveat removes the previous HMAC tag/key. > In the approach you’ve described nothing is removed when creating a derived > token, so the parent AATs remain valid. The final leaf token is > PoP-constrained, but the intermediates are not (as far as I can tell). What > prevents a Tool Invoking Agent from replaying the Root AAT (or any parent > token) back to the Orchestrating Agent (or Planning Agent)? > > As well as macaroons and capabilities, you may find it useful to look at > SDSI/SPKI (RFC 2693) for related work and ideas. > > Best wishes, > Neil > > On 15 Jun 2026, at 17:20, Niki Aimable Niyikiza <niki= > [email protected]> wrote: > > > > Hi all, > > I've posted a draft defining Attenuating Authorization Tokens (AATs) > <https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/>, > a token format for delegation across multi-agent systems that draws on > capability-based authorization. It profiles existing OAuth mechanisms where > possible, and I'd value the WG's review. > > The problem: in multi-agent workflows, an agent receives authority scoped > to a session, principal, or workflow and carries it unchanged, across every > tool call it makes and every sub-agent it delegates to. > > The draft defines: > > - a profile of RFC 9396 authorization_details for tool-level capability > claims, with typed argument constraints; > > - offline derivation of child tokens by a token holder, with no AS round > trip; > > - attenuation invariants enforcing that derived tokens can only narrow > authority across capability, delegation depth, and lifetime; > > - cryptographic parent-to-child linkage, verifiable against the root trust > anchor; and > > - proof-of-possession binding at invocation time. > > It builds on RFC 9396 and RFC 9201, differs from RFC 8693 Token Exchange > in making the attenuation chain offline-verifiable rather than AS-mediated, > and is meant to complement WIMSE's workload-identity work. > > There is also a reference implementation covering token derivation and > chain verification; the draft's Implementation Status section has details. > > I'd particularly welcome review of the attenuation invariants, the > constraint-subsumption model, and the offline chain-verification model, > along with views on whether the WG sees this problem space as in scope. > > Draft: > https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/ > > > > Thanks, > > > Niki > > -- > Niki Aimable Niyikiza > Tenuo > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
