Hi Iman, I ran the concrete race case and then checked the closest existing mechanisms I could find, including RFC 9110 conditional requests, RFC 9396 RAR, Transaction Tokens, WebDAV RFC 4918 If, and the current AEB draft.
The results split cleanly: a competing change to the target resource is correctly stopped by If-Match; a verifier-to-commit race on the target is also stopped when the mutation boundary re-evaluates If-Match; but if an independently versioned prerequisite changes while the target representation remains unchanged, target If-Match still succeeds. Minimal trace: authorize(target=v7, compliance=v4) verify(target=v7, compliance=v4) -> PASS compliance -> v5 target remains v7 execute If-Match(target=v7) -> succeeds An application-specific re-check of compliance=v4 at the effect boundary closes the case, so I am not claiming this is unimplementable today. I also checked RFC 4918, since its If header supports tagged resources and state-token/ETag conditions. It provides useful precedent for richer conditional state semantics, but it appears DAV-specific and does not seem to establish a generic atomic precondition set across unrelated providers. So the remaining question I would frame is narrower: Is there already an interoperable mechanism for conveying a conjunction of independently versioned execution preconditions to the actual effecting component and requiring that conjunction to remain valid at commit time, especially across provider boundaries? AEB appears to handle the local effect boundary well, while explicitly not claiming atomicity with an unrelated remote provider. If there is an existing mechanism for that exact case, I would be very interested in testing the same trace against it. Thanks, Valentyn On Sun, Sep 13, 2026, 17:53 Iman Schrock <[email protected]> wrote: > 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]
