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]
