Warren, I think that distinction is important, and I agree that application state such as available funds should not be captured in the authorization grant itself. The issue I am trying to isolate is narrower. Using the withdrawal example: OAuth can establish that the actor is authorized to request a withdrawal. The application defines predicates such as sufficient funds.
The execution path must ensure that any predicate required for the operation is still true when the protected state transition commits. If the application evaluates that predicate atomically as part of the commit — for example through a transaction, conditional mutation, or equivalent mechanism — then that particular problem is already closed. I am not suggesting OAuth should duplicate it. What I am testing is the weaker case where a decision depends on state observed before execution, but that observation is not actually bound to the subsequent mutation. In that case the authorization can remain valid while one of the conditions under which execution was approved has become stale. So I think the separation is: authorization establishes authority; application semantics define the required execution predicates; the execution mechanism determines whether those predicates and the resulting mutation are bound strongly enough to prevent an invalidated decision from committing. The probe is intended to distinguish those cases, not to establish that OAuth itself needs to understand balances, compliance state, or other domain-specific semantics, and not yet to claim a standards gap. If existing HTTP/application mechanisms already provide that binding wherever it is required, that is a perfectly valid outcome of the investigation. The interesting question for me is whether that remains true when authorization, state observation, policy evaluation, and execution are separated across components. Best, Valentyn On Sun, Sep 13, 2026, 23:30 Warren Parad <[email protected]> wrote: > I don't understand why we are trying to put what is essentially API > semantics into the authorization check. > > Surely access to do a thing like withdraw money from an account is > predicated on their being available funds in the first place. > > This has no business being captured in the authorization. > > On Mon, Sep 14, 2026, 08:16 Iman Schrock <team= > [email protected]> wrote: > >> Hi Valentyn, >> >> Thanks for sending the probe. I checked the SHA-256 and reran it. All >> eight scenario outputs match your results.json. >> >> > [VR] fresh observation != commit-time guarantee >> >> [IS] T7b demonstrates that ordering in the model: the final read >> passes, the approved compliance version changes, and the target >> mutation still occurs. The unchanged-state control commits too. >> >> There is one test I'd strengthen before using this to compare >> implementations. T4 calculates all_ok but never calls a guarded >> execution path, so its zero effect doesn't yet test enforcement. Could >> it call that path and assert refusal with zero effect, alongside a >> no-race case that commits through the same path? That would catch a >> guard being bypassed. >> >> For T7b, the code changes compliance.version but leaves >> compliance.value at 1. I'd describe the current case as invalidation >> of the approved version. If you mean an actual change from approved to >> suspended, could that state change and its predicate be explicit too? >> >> > [VR] I can put it in a public GitHub commit next if that is the most >> useful form for comparison. >> >> [IS] Yes, a pinned commit with the probe and results would give us a >> shared baseline. Your README is right that this doesn't establish a >> standards gap. I'd also say explicitly that these are in-memory cases >> modeling the checks, not tests against OAuth, HTTP servers or >> participating providers. >> >> Best, >> Iman >> _______________________________________________ >> 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]
