Hi Valentyn, > [VR] The resource server, or a separate verifier, could then reject the > operation
[IS] That distinction is worth testing. A separate verifier can see the right state and still lose a race before the resource server performs the action. A fresh, signed state hash doesn't reserve that state. There are existing pieces to build on. OAuth Rich Authorization Requests can carry detailed action requirements, with resource-server processing defined for the relevant authorization_details type: https://www.rfc-editor.org/rfc/rfc9396.html#section-11.1 For a conditional resource update, HTTP If-Match already requires the server not to perform the method when the selected representation's strong ETag no longer matches. That isn't a general check of all the prerequisites in your example: https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.1 Related work in our EMILIA AEB draft separates local admission from provider commitment. Section 5.8 explicitly does not claim atomicity with an unrelated remote provider: https://www.ietf.org/archive/id/draft-schrock-action-evidence-boundary-05.html#section-5.8 A concrete test would be: authorize a write against version 7, let the verifier pass, commit a competing version 8, then attempt the original write. The stale attempt should produce no additional effect. Run the same case without the competing write and it should succeed. If version 7 was part of the approval, silently replacing it with version 8 isn't a valid retry under that approval. That would help distinguish two questions: how the approved precondition reaches the executor unchanged, and how the component performing the mutation enforces it. I'd start the problem statement with that trace and identify what needs interoperable wire semantics beyond the existing mechanisms. Best, Iman _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
