Hi Kieran, Thanks — that distinction is helpful, and I agree that RAR + If-Match appears to cover the simple case where the relevant precondition is the current representation of the target resource.
The case I am trying to isolate is one where the target resource has not changed, but the validity of the transition depends on independently changing state outside that representation. For example, suppose an agent is authorized using RAR to create a purchase order for vendor V, item X, up to a specified amount. The agent obtains the target resource with: ETag: "po-state-41" and later submits the action with: If-Match: "po-state-41". At execution time the ETag still matches, and the requested action still conforms to the RAR authorization details. However, between authorization and execution, one of the following changes: the vendor's compliance state changes from approved to suspended; a separate budget resource changes because another transaction consumes the remaining allocation; an approval prerequisite is revoked; or another independently maintained execution constraint becomes false. The purchase-order resource itself has not changed, so its If-Match precondition succeeds. This gives the case I am trying to distinguish: RAR authorization valid + target If-Match succeeds + external execution prerequisite changed = transition should still be rejected Of course, an application can explicitly re-query and enforce each of those conditions before executing. My question is whether OAuth/HTTP already defines an interoperable mechanism for binding such independently versioned execution-state assertions — including their freshness/version and required conjunction — to the authorized transaction. I have also been looking at the Transaction Tokens work, since rctx/transaction context appears relevant. My reading so far is that it preserves authorization/request context through a call chain, but I have not yet found a normative mechanism for saying, in effect: “execute only if state assertions S1..Sn, potentially originating from different resources or authorities, are still valid at the execution boundary.” If that already exists, a pointer would be very helpful. If not, that narrower case may better describe the gap I was trying to identify. Thanks, Valentyn On Sun, Sep 13, 2026, 15:43 Kieran Sweeney <[email protected]> wrote: > Hi Valentyn, > > I think what you're describing is largely covered today by composing RFC > 9110 conditional requests (ETag / If-Match, evaluated by the resource > server at execution time) with RFC 9396 RAR to bind the security-relevant > parameters of the action into the authorization itself, with a mismatch > triggering re-consent rather than a retry. I could be wrong depending on > your exact needs > > What would help me understand the gap is a concrete case your prototype > rejects that RAR plus a precondition check at the resource server would not. > Thanks, > > Kieran Sweeney > > > On Sun, Sep 13, 2026 at 6:32 PM Altru <[email protected]> wrote: > >> Hello OAuth WG, >> >> I have been exploring a potential authorization gap for automated agents >> and would appreciate feedback on whether this is already addressed by >> existing OAuth work or belongs within the current agent-authorization work. >> >> The problem is narrower than agent identity, delegation, scope, or >> obtaining an access token. >> >> An agent may possess valid authorization to perform an action, while the >> action itself becomes invalid before execution because the relevant >> resource state, prerequisites, constraints, or delegated context have >> changed. >> >> For example: >> A user authorizes an agent to perform action A against resource R. >> >> The authorization is valid and the agent obtains the necessary token or >> capability. >> Before execution, R changes state, a prerequisite becomes false, a >> conflicting operation occurs, or some execution constraint changes. >> >> The authorization may still permit A even though the transition is no >> longer valid in the current state. >> >> The property I am interested in is therefore approximately: >> authorization + expected pre-state + action + execution constraints → >> permitted state transition >> rather than authorization alone. >> >> One possible mechanism would bind an action to selected execution-time >> evidence such as: >> resource or pre-state identifier/hash; >> intended action and security-relevant parameters; >> freshness or validity bounds; >> prerequisites and constraints; >> authorization/delegation context; >> nonce or replay protection; >> resulting transition evidence, where applicable. >> >> The resource server, or a separate verifier, could then reject the >> operation when the observed execution state no longer satisfies the >> conditions under which the action was authorized. >> >> I have reviewed some of the current agent authorization and delegation >> work and do not want to duplicate existing efforts. My main question is: >> Is execution-time state-transition validity already covered by an >> existing OAuth specification or active Internet-Draft? >> If not, would the WG consider a focused problem statement or use-case >> draft in this area useful? >> >> I have implementation-oriented prototypes around this concept and can >> provide concrete threat cases, examples, and testable invariants if that >> would help the discussion. >> >> Regards, >> >> Valentyn Rukhaylo >> Altru.dev >> _______________________________________________ >> 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]
