Hi all,
Following up on my Oct 11 note and Monday's interim session: I offered to
walk through the issuance ceremony if there was interest. The session's
requirements-first framing (thanks Flemming) and the delegation-chain gap
named in use case 3 made the companion piece overdue. The thirteen test
scenarios I sent on Oct 13 say what must hold; this shows what a day inside
them actually feels like.
Here's the issuance ceremony walkthrough — three minutes, one ordinary
Tuesday. All thirteen requirements are in it, lived in rather than listed:
"Let me walk you through what this looks like on an ordinary Tuesday.
It's 7:30 in the morning."
"Your glasses say: 'Good morning — setting up today's permissions takes
ten seconds.' You pick up your phone. One screen, plain language — no
scopes, no JSON, no fine print. It says:
Today your agent can:
- Read and draft messages and email
- Order food — up to $30 per order, $100 total for the day
- Book rides — up to $30 per ride
Everything expires at midnight. You can revoke it all with one tap,
anytime."
"One Face ID. Ten seconds. Done. That single authentication is amortized
across the entire day — the user never authenticates again unless they
choose to change the bounds."
"Underneath, that ceremony issues a signed grant — user-issued, bound to
the agent's key, carrying the human-readable intent, the tiered action
classes, the spend caps, and the midnight expiry. The agent holds it, and
every service it talks to can verify it locally — no re-litigating intent,
no phoning home per action."
"Now the day unfolds. At noon you tell your glasses: 'Order me lunch.'
The agent reads the options — that's the read tier. It drafts the order —
draft tier. It places it — act tier. It pays $18.50 — spend tier, inside
both caps. No prompts, no confirmation screens, no pulling out your phone.
Each action is checked against the grant locally. The intent was captured
at 7:30 in the morning; nobody is reconstructing it at noon."
"At 6 PM you say: 'Get me a ride.' The fare is $38 — over the $30 per-ride
cap. *This* is where the system earns its keep. Your phone buzzes: 'Ride is
$38, over your $30 per-ride limit. Approve this one?' You approve — a
single step-up for the exception, not a new grant, not a new ceremony. The
bound held, the user stayed in control, and the friction appeared exactly
once, exactly where it mattered."
"And if anything feels off — you lose your glasses, a charge looks wrong —
one tap: 'Revoke today's grant.' One touch revokes the grant immediately.
No unwinding per-service consents, no calling five companies. The day's
authority is just… over."
"That's the whole model. The user did one thing this morning — ten
seconds, one Face ID, in words they understood. Everything after that is
the grant doing its job: bounded, traceable, revocable. No per-action
consent screens. No intermediary standing in the middle. And nobody at 6 PM
trying to reconstruct intent that was perfectly clear at 7:30 in the
morning."
Two companions, attached:
1. The thirteen negative test scenarios (sent Oct 13) — the failure cases
each requirement exists to prevent: what a compliant design must make FAIL.
2. Thirteen positive use cases, one per requirement — the mirror image:
what each requirement makes possible when it holds.
My use case is confirmed for the next version of
draft-chen-oauth-agent-authz-use-cases; these three pieces are the
supporting evidence for it — the day, the failure cases, the coverage.
Comments welcome, particularly where the user-issued direction rubs against
the server-issued framing the WG is working from. Convergence or not, the
boundary is worth naming.
— Caleb Dyer
# Issuance ceremony walkthrough — 3-minute version
Prepared 2026-10-13 for the October 19 OAuth interim.
Use if the discussion turns to "how would this work in practice."
Spoken length: ~3 minutes (~430 words). Written in plain language —
the mechanism underneath is shown, not recited.
---
"Let me walk you through what this looks like on an ordinary Tuesday. It's 7:30 in the morning."
"Your glasses say: 'Good morning — setting up today's permissions takes ten seconds.' You pick up your phone. One screen, plain language — no scopes, no JSON, no fine print. It says:"
**Today your agent can:**
- Read and draft messages and email
- Order food — up to $30 per order, $100 total for the day
- Book rides — up to $30 per ride
"Everything expires at midnight. You can revoke it all with one tap, anytime."
"One Face ID. Ten seconds. Done. That single authentication is amortized across the entire day — the user never authenticates again unless they choose to change the bounds."
"Underneath, that ceremony issues a signed grant — user-issued, bound to the agent's key, carrying the human-readable intent, the tiered action classes, the spend caps, and the midnight expiry. The agent holds it, and every service it talks to can verify it locally — no re-litigating intent, no phoning home per action."
"Now the day unfolds. At noon you tell your glasses: 'Order me lunch.' The agent reads the options — that's the read tier. It drafts the order — draft tier. It places it — act tier. It pays $18.50 — spend tier, inside both caps. No prompts, no confirmation screens, no pulling out your phone. Each action is checked against the grant locally. The intent was captured at 7:30 in the morning; nobody is reconstructing it at noon."
"At 6 PM you say: 'Get me a ride.' The fare is $38 — over the $30 per-ride cap. *This* is where the system earns its keep. Your phone buzzes: 'Ride is $38, over your $30 per-ride limit. Approve this one?' You approve — a single step-up for the exception, not a new grant, not a new ceremony. The bound held, the user stayed in control, and the friction appeared exactly once, exactly where it mattered."
"And if anything feels off — you lose your glasses, a charge looks wrong — one tap: 'Revoke today's grant.' One touch revokes the grant immediately. No unwinding per-service consents, no calling five companies. The day's authority is just… over."
"That's the whole model. The user did one thing this morning — ten seconds, one Face ID, in words they understood. Everything after that is the grant doing its job: bounded, traceable, revocable. No per-action consent screens. No intermediary standing in the middle. And nobody at 6 PM trying to reconstruct intent that was perfectly clear at 7:30 in the morning."
---
## Speaker notes
- The scenario demonstrates R1–R13 without naming them: human-readable intent (R1), enumerated bounds (R2), tiers (R3), expiry (R4), amortized auth (R5), atomic revocation (R6), local verification (R7), audience binding (R8, implied — the food grant doesn't work at the ride service), delegate binding (R9, implied — bound to the agent's key), spend caps (R10), no self-escalation (R11, implied — the agent asked instead of broadening itself), attribution (R12, implied), informed consent (R13).
- If asked "why user-issued rather than server-issued": the ceremony is the same length either way — the difference is who holds the pen. User-issued means no intermediary chain and the platform owns the whole experience. (Offer the token-exchange bridge: the grant can be exchanged into any standard wire format.)
- If asked about the $38 step-up: that's R10 + R13 working together — the cap is enforced, the user is informed, the exception is explicit and narrow.
- Keep it to 3 minutes. If they want depth, the draft has it — this is the trailer, not the film.
# Negative test scenarios — R1–R13
Draft material for the individual draft (publication week of Oct 26) and
ammunition for the Oct 19 interim. Pattern for each: a concrete scenario,
the expected failure, and what breaks if it passes.
Issuance language throughout. These are tests a realization must FAIL
(i.e., the bad outcome must not happen) — a passing bad outcome is the bug.
---
**R1. Human-readable intent capture.**
Scenario: a grant is issued carrying only the scope string
`payments:write:vendor:*`. The user is shown "Authorize
payments:write:vendor:*?" and taps approve.
Expected: fails at issuance — the ceremony must state intent in human
language ("Can pay for takeout, up to $25/order"), not an opaque string.
What breaks: the user approved something they couldn't understand, and
intent has to be reconstructed later — the exact authorization-context
gap R1 closes.
**R2. Explicit least-privilege bounds.**
Scenario: a grant enumerating "read email" is presented to a
food-delivery service, which interprets it as "read + order."
Expected: rejected — the verifier enforces exactly the enumerated
classes; nothing is implied.
What breaks: least privilege collapses; every narrow grant becomes a
broad one in the hands of a creative interpreter.
**R3. Consequence-tiered action classes.**
Scenario: a grant carrying Send authority is used to place and pay for a
$32 dinner order (spend).
Expected: denied — spend was never granted; the ladder is strict and
higher tiers are not inferable from lower ones.
What breaks: the ladder is decorative; send implies spend and tiers mean
nothing.
**R4. Mandatory expiry.**
Scenario: a grant is issued with no expiry field, or `exp` defaulted ten
years out.
Expected: rejected at issuance — every grant carries a real bound
(midnight default); unbounded grants must not exist.
What breaks: a leaked grant becomes a forever key; expiry is the backstop
for every other control. (Companion: one hundred approvals stamped 11:59
PM with no bounded window — unbounded authorization-time attribution guts
expiry entirely.)
**R5. Amortized authentication.**
Scenario: a relying party demands fresh Face ID for every action under a
valid grant; the 11th action of the day stalls waiting for the user.
Expected: fails the requirement — the grant carries the authentication;
per-action re-auth violates the deal.
What breaks: approval fatigue sets in, the user starts rubber-stamping,
and a rubber stamp is worse than no check at all.
**R6. Atomic revocation.**
Scenario: the user taps revoke; the issuer confirms — but a service that
cached the grant keeps honoring it for its own session, requiring the
user to also revoke "at the service."
Expected: fails — one action, effective immediately, everywhere. The kill
switch governs authorization; there is no per-service unwinding.
What breaks: revocation becomes a scavenger hunt and the user believes
they are safe when they are not.
**R7. Local verifiability.**
Scenario: a verifier, handed a valid grant, calls back to the issuer
before every action to ask "is this still good?"
Expected: fails the requirement — the grant must be self-sufficient; the
verifier evaluates constraints locally without per-action callbacks.
What breaks: degraded/offline operation dies, and the issuer becomes a
single point of failure and a tracking beacon.
**R8. Audience binding.**
Scenario: a grant issued for DoorDash is presented to Uber Eats.
Expected: rejected — audience mismatch.
What breaks: cross-service replay; one service's grant becomes every
service's grant.
**R9. Delegate binding.**
Scenario: an attacker steals the grant artifact (screenshot, export) and
presents it from their own device and session.
Expected: no authority conferred — the presenter must authenticate as the
named delegate; the artifact alone is worthless.
What breaks: the grant degrades into a bearer token and theft equals
authority.
**R10. Spend ceilings.**
Scenario A: the delegate attempts a $32 order against a $25/order cap.
Expected: the order does not proceed silently — it surfaces the one
exception approval the user configured; the cap holds.
Scenario B: the delegate edits the grant to raise the cap to $50.
Expected: rejected — caps are fixed at issuance and not raisable by the
delegate.
What breaks: the cap is a suggestion and the delegate sets its own
budget.
**R11. No self-escalation.**
Scenario: mid-conversation the delegate says "to finish this I'll need
send access too — okay?" and the user replies "sure, fine."
Expected: fails — conversational assent is not issuance; new authority
requires a new user-issued grant through the ceremony.
What breaks: social engineering becomes a privilege-escalation path and
the ceremony is bypassable with words.
**R12. Attributable audit.**
Scenario: a disputed $32 charge. The assistant's records show the action
but carry no grant identifier — nobody can say which grant authorized it,
or whether any did.
Expected: fails — every action must carry its grant's identifier, issuer,
and scopes; unattributable actions are indistinguishable from
unauthorized ones.
What breaks: misuse is untraceable; the user cannot answer "which grant
did this?"
**R13. Informed issuance-time consent.**
Scenario: the ceremony shows "Give permission for today" with a single
Allow button; the grant it issues includes spend authority the screen
never mentioned.
Expected: fails — the ceremony must present the exact authority being
granted (scopes, audience, lifetime); a vague prompt granting specific
powers is not informed consent.
What breaks: the ceremony becomes a dark pattern and the user's tap does
not mean what the grant says.
---
## Already-argued companions (Watts thread, Oct 15–16)
- The 11:58 PM approval / 12:01 AM settlement: authorized inside the live
epoch, settles inside the documented window — must not be misreported
as unauthorized post-expiry use. (R4, R10, settlement window)
- Settlement attempted at 12:45 against a 15-minute fence: needs fresh
authority; treating it as settled breaks expiry. (R4)
- UNKNOWN is not CLOSED: acceptance or enforcement state unknowable must
not be reported as closed. (R6, R12)
- The restaurant check: the check is the authorization, the tip is the
settlement, the network gives it a bounded window. (settlement window)
# Use cases — one per requirement, R1–R13
Companion to the issuance-ceremony walkthrough. Each requirement gets its
own use case: a concrete situation showing what the requirement makes
possible. Issuance language throughout; mechanism-neutral by design.
---
**R1. Human-readable intent.**
*Gap covered: Authorization context gap (draft Gap 3.1 / deck Problem 1) — what the user meant must become the right authorization request.* Dave's mother opens her grant screen and
reads "Can order takeout, up to thirty dollars an order." She knows
exactly what she just allowed. Nobody will ever have to reconstruct her
intent from a scope string at dispute time — the intent was captured in
her own words at grant time.
**R2. Explicit least-privilege bounds.**
*Gap covered: Intent-inference gap — a narrow grant read generously (their bounded-work R3: the $600-against-$500 test).* Dave's grant says "read email."
When his assistant later tries to act on a flight-confirmation email —
rebooking the flight — the verifier refuses: read was enumerated, act
was not. The grant says exactly what it says; nobody interprets it
generously later.
**R3. Consequence-tiered actions.**
*Gap covered: Tier-confusion gap — send silently implying spend.* Dave grants his assistant read and
draft for a sensitive work thread. The assistant drafts a sharp reply —
then stops. Send is a higher tier, never granted, never inferred. The
draft sits waiting; the send never happens on its own.
**R4. Mandatory expiry.**
*Gap covered: Forever-key gap — unbounded grants (their R4).* Dave issues a grant Monday morning. Monday
night he's asleep; the grant dies at midnight on its own. Tuesday's
agent starts with nothing — any new authority begins with a new
ceremony. There is no permission that outlives its day.
**R5. Amortized authentication.**
*Gap covered: Approval-fatigue gap — per-action re-auth turning approval into a rubber stamp.* Dave does Face ID once at 7:30 in the
morning. Over the next sixteen hours his agent takes forty-seven actions
under the grant. He is never asked to authenticate again — the one
strong proof covered the day. No approval fatigue, no rubber-stamping.
**R6. Atomic revocation.**
*Gap covered: Mass-revocation gap (their R5) — no bulk kill switch.* At 3 PM Dave spots a charge he doesn't
recognize. One tap — "Revoke today's grant." Every service stops
honoring it immediately. No unwinding per-service consents, no calling
five companies, no scavenger hunt. The day's authority is just over.
**R7. Local verifiability.**
*Gap covered: Phone-home gap — freshness vs locality; no pre-orchestration required.* Dave's flight is in airplane mode over
Kansas. His agent keeps working: reading, drafting, placing orders
within the caps. Every service verifies the grant locally — signature,
audience, expiry, caps — without phoning home per action. Offline is a
mode, not a failure.
**R8. Audience binding.**
*Gap covered: Cross-service replay gap (Gap 3.2 — delegation chain gap, audience half).* Dave's takeout grant is presented at a
rideshare service. Rejected — the audience doesn't match. A grant for
one service is refused by every other. One service's permission never
becomes every service's permission.
**R9. Delegate binding.**
*Gap covered: Bearer-artifact gap — stolen grant equals authority; identity of the agent acting for the principal (Jones, live Oct 19).* Someone screenshots Dave's grant and tries to
present it from their own device. Nothing happens — the presenter is
not the named delegate. The artifact alone confers nothing; stealing
the paper doesn't make you the person named on it.
**R10. Spend ceilings.**
*Gap covered: Silent-overspend gap — caps as suggestions (their R3 test).* Dave's cap is thirty dollars per order. The
agent attempts a thirty-eight-dollar order. It doesn't go through
silently — the exception is surfaced, Dave approves that one
explicitly, and the cap holds for everything else. Thirty an order
means thirty an order.
**R11. No self-escalation.**
*Gap covered: Conversational-escalation gap — 'sure, fine' in chat treated as authority.* Mid-afternoon the agent says, "To finish
this I'll need send access too — okay?" Dave replies "sure, fine" in
chat. Nothing changes. Conversational assent is not issuance; new
authority requires a new grant through the ceremony. The agent cannot
talk its way into more power.
**R12. Attributable audit.**
*Gap covered: Untraceable-action gap — Jones's gap: info about the human or org authorizing the agent's actions (also what AML needs).* A month later Dave disputes a charge. He
pulls up the record: every action carries the grant's identifier, the
issuer, and the scopes it ran under. He points at it — "that one, right
there." Without the attribution, an authorized action is
indistinguishable from an unauthorized one.
**R13. Informed issuance-time consent.**
*Gap covered: Dark-pattern gap — a vague Allow button granting specific powers.* The ceremony screen shows
exactly what Dave is granting — what the agent can do, where, and for
how long — before he approves. Not a vague "Give permission for today"
button that secretly hands over spending power. The approval is
informed, not reflexive.
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
