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]
