Hi Meiling, Thanks — yes, that summary matches how I see it. Small clarification: the grant itself isn't limited to one domain; it enumerates the permitted applications and action classes, and the tiered ladder applies across them. But "daily small-amount orders" is a fair frame for the use case.
I'd like to contribute the section. I'll work from the existing examples' structure and keep it to scenario plus requirements — mechanism-neutral, so it stays useful regardless of which direction the mechanism discussion goes. I'll post a draft to issue #33 before the interim on Monday so it's part of the discussion going in. Best, Caleb daybadge.com On Wed, 14 Oct 2026 23:38:03 +0800, Meiling Chen <[email protected]> wrote: > Hi Caleb and Xiang > Thank you for your comments on draft-chen-oauth-agent-authz-use-cases. the > usec case you mentioned is interesting, we can frame around "daily > small-amount orders" (e.g., takeout, travel, household services). > To track this, we have created an issue on GitHub: > https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/33 > We would be delighted to invite you to contribute a new section for this use > case, following the structure of the existing examples in the draft. > To ensure we're on the same page, here is our initial understanding of the > key characteristics of this use case, based on your description: > Domain: Daily life services like food delivery, travel booking, and household > chores. > Spending Limit: Authorizations are tied to a limited, small amount of > expenditure. > Functionality: An AI agent assists with searching, selecting, ordering, and > payment, governed by a clear, tiered authorization ladder > Lifecycle: A single grant can authorize multiple operations, typically > lasting for a day but with a configurable expiration. > Permission Model: The permissions are human-readable, but because the domain > is well-defined (e.g., only food delivery), they can be reliably interpreted > and executed by machines. > Please let us know if this summary aligns with your vision. We are very much > looking forward to collaborating with you on this. > > Best, > Meiling > > > [email protected] > > 发件人： Caleb Dyer > 发送时间： 2026-10-13 21:31 > 收件人： Xiang Liu > 抄送： oauth > 主题： [OAUTH-WG]Re: Web Authorization Protocol (oauth) WG Virtual Meeting: > 2026-10-19 — Agent Authorization – Use Cases and Gaps — a bottom-up data point > Hi Xiang, > > Really appreciate the thoughtful reply — and I like your framing. > Let's get the scenario and the requirements it implies into the > document, and keep the mechanism question open. Here's my cut at the > list, distilled from the scenario and written mechanism-neutral on > purpose. Every item is testable, and none of them prescribes > user-minted tokens or anything else — a server-issued design would > have to answer the same list, which I think is exactly the point. > > What the grant has to capture: > > R1. The grant MUST capture the user's delegation intent in > human-readable form at mint time — not an opaque scope string. (This > is what kills the context gap: intent captured up front never needs > reconstructing at request time.) > R2. The grant MUST enumerate permitted applications and action > classes; no authority implied, and narrow grants never read as broader > ones. > R3. Actions MUST be tiered by consequence (read < draft < act < send < > spend, say), each tier explicitly granted, higher never inferred from > lower. > > Time and authentication: > > R4. Every grant MUST carry an explicit expiry; unbounded grants MUST NOT > exist. > R5. One strong authentication at grant creation MUST cover the grant's > whole lifetime — no per-session or per-action re-auth while a valid > grant exists. > > Enforcement: > > R6. The user MUST be able to revoke the entire grant in one action, > effective promptly, without unwinding per-service consent records. > (This is the mass-revocation gap, closed.) > R7. A relying party MUST be able to verify the grant and check its > constraints locally — no re-litigating intent per action, no phoning > home to the minter per action. > R8. A grant minted for one service MUST be rejected by any other. > > Theft and money: > > R9. The grant MUST name its delegate and SHOULD only be usable by that > delegate — stealing the artifact alone MUST NOT confer authority. > R10. Anything involving money MUST support a per-transaction cap and a > cumulative cap, set at mint time, not raisable by the delegate. > R11. The delegate MUST NOT be able to talk its way into broader > authority; new authority takes a new grant from the user. > > Trust: > > R12. Actions under a grant SHOULD be traceable to the grant's > identifier, minter, and scopes. > R13. The minting ceremony MUST show the user exactly what authority > they're granting, so the approval is informed rather than reflexive. > > If any of these don't hold up against how the WG sees the problem > space, happy to rework them — the goal is a list everyone can design > against, not my list specifically. > > And the offer stands — glad to walk through the minting ceremony and > the enforcement model at a future interim if that'd be useful. > > Best, > Caleb > daybadge.com > > > On Tue, 13 Oct 2026 17:21:09 +0800, Xiang Liu <[email protected]> wrote: > > 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]
