You can already put whatever you want in the body or headers of a request and an RS can already make whatever validations it wants to ensure that it does what the client asked for.
If we already agree that oauth would not need to change here to accommodate the use case, I'm not sure what else you might be looking to do, as it fully depends on the RS expressing the semantics to allow the client to request what they actually want. On Mon, Sep 14, 2026, 08:38 Altru <[email protected]> wrote: > 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]
