Deonté, WG —
Following up on the candidate-negative-tests point: here is the full set,
thirteen tests, one per requirement. Each is framed as a test a realization
must fail — the scenario describes the bad outcome, and if that outcome occurs,
that 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 could not understand, and intent
has to be reconstructed later.
**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.
**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 from this thread: the 11:58 PM approval settling at
12:01 AM inside the documented window (must not be misreported as post-expiry
use); settlement attempted at 12:45 against a 15-minute fence (needs fresh
authority); UNKNOWN is not CLOSED; the restaurant check (the check is the
authorization, the tip is the settlement).
Happy to walk through any of these Monday.
Caleb
On Sun, 18 Oct 2026 03:29:37 +0000 (UTC), Deonté O’dell Watts
<[email protected]> wrote:
> Hello OAuth WG,
>
> Thank you to Caleb and other participants for the concrete bounded-settlement
> examples. I am retaining the distinction between authorization recorded
> before expiry, an external party's acceptance, settlement inside a documented
> window, and cases where the downstream state cannot be established.
>
> These examples identify candidate negative tests, not verified results or a
> settled normative status model. A remaining evidence question is how an
> independent relying party can authenticate the pre-expiry acceptance
> timestamp, the governing settlement policy and deadline, and any effective
> revocation exception across administrative domains. If participants know of
> existing specifications or published test cases that make those claims
> interoperable, a precise pointer would be helpful.
>
> The draft is an individual Internet-Draft. I will not infer WG agreement, new
> OAuth protocol requirements, or independent validation from these discussions.
>
> Regards,
> Deonté O’dell Watts
> Independent Researcher | GoodShyt Group Inc.
> ORCID: 0009-0005-8586-3650
> _______________________________________________
> OAuth mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
