[OAUTH-WG] Re: New I-D: Attenuating Authorization Tokens for Agentic Delegation Chains (draft-niyikiza-oauth-attenuating-agent-tokens-01)

[Neil Madden]

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=40tenuo...@dmarc.ietf.org> wrote:  Hi all, I've posted a draft defining Attenuating Authorization Tokens (AATs), 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 -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org

_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org