Hi Caleb, Thanks for sharing this scenario and your implementation experience. The consumer use case you describe—allowing a user to express their intended delegation in understandable terms, set clear authority limits and a validity period, and revoke related authority together—is a useful input to the use-cases discussion.
I think it would be valuable to capture this scenario and its underlying requirements in the document, while keeping the choice of authorization mechanism open. In particular, whether user-minted grants are the appropriate approach, and how intent interpretation, delegation, enforcement, and revocation would work, still need further discussion in the WG. Including the use case would help inform that discussion without implying agreement on a particular solution. Best regards, Xiang Liu > 2026年10月11日 22:12，Caleb Dyer <[email protected]> 写道： > > Hi all, > > I can't attend the Oct 19 session, but I wanted to add a data point to > the use-cases discussion, since it bears directly on the gaps > draft-chen-oauth-agent-authz-use-cases identifies. > > The draft's analysis assumes the classic OAuth direction: an > authorization server issues, the user consents in a front channel, the > agent holds a token. The three core gaps it names — the authorization > context gap (the AS can't see the user's intent at request time), the > delegation chain gap, and mass revocation — are all framed from that > direction. > > I've been building in the opposite direction, with a working system: > the user mints their own authority grant in about ten seconds, in > plain language, one authentication amortized across the whole day. The > grant carries an explicit authority ladder (read, draft, send, act, > spend — each rung strictly more powerful, each requiring explicit > grant), and it expires at midnight local time. The enforcement point > verifies the grant, not a server's consent record. I described the > model on this list on Oct 6 and in my draft > (draft-dyer-delegation-token-00 — written, not yet submitted; happy to > share the text). > > The reason I'm raising it here: in the use-cases taxonomy this pattern > addresses the context gap from the other side. Instead of asking the > AS to reconstruct the user's intent at request time, the intent is > captured in human-readable form at mint time — "can order and pay for > takeout" rather than a scope string — so the question "did the user > mean this?" never reaches the protocol. Revocation also collapses: > short-lived grants plus an explicit revoke that kills the whole day's > authority, with no per-server consent ledger to unwind. > > I'm not proposing this as the answer to the WG's work — it complements > the plumbing drafts (delegate SD-JWT, token exchange with may_act) > rather than replacing them. But if the use-cases document is going to > be the shared map of the problem space, it's worth recording that some > consumer use cases are better served by user-minted, time-bounded, > human-readable grants than by server-issued tokens with user-present > consent flows. > > Happy to walk through the minting ceremony and the enforcement model > at a future interim if there's interest. > > — Caleb Dyer > daybadge.com
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
