What's missing from RFC 9396, to support your use case? On Mon, Sep 21, 2026 at 5:46 PM Sangam Das <[email protected]> wrote:
> Dear OAuth Working Group, > > I would appreciate technical clarification concerning the boundary between > OAuth authorization and the final effectuation of an autonomous agent’s > action. > > RFC 9396 can express fine-grained authorization details. RFC 9449 provides > sender-constrained access tokens. The Transaction Tokens work propagates > identity, authorization, and request context through a call chain. These > mechanisms provide important inputs to secure agentic workflows. > > My question concerns the remaining transition from authorized context to > the exact externally effective consequence. > > Consider two examples: > > ● An AI agent is authorized to pay a specified beneficiary, but a > downstream transformation, compromised worker, retry process, or stale > queue entry changes the beneficiary, amount, or execution conditions after > an earlier authorization check. > > ● An AI agent is authorized to SEND a particular file to a specified > recipient, but the attachment, recipient, destination service, sharing > permissions, or link target changes before release. > > At the final resource server or irreversible boundary, does any current > OAuth specification establish the following complete invariant? > > 1. The resource server reconstructs the actual semantic act from the > parameters that the ledger, egress mechanism, storage system, or actuator > will use. > > 2. All consequence-relevant fields are compared with the granted > authorization or transaction context. > > 3. Current protected revocation, generation, expiry, quota, > resource-version, and replay state are revalidated. > > 4. Any single-use or replay-sensitive authority is consumed atomically > with the exact resulting state change. > > 5. Crash recovery can distinguish committed, denied, uncommitted, and > indeterminate outcomes without duplicating an irreversible consequence. > > 6. Every path capable of producing the protected consequence is > equivalently mediated. > > If a resource server performs all these functions at the last preventable > boundary, I regard it as functionally equivalent to the execution-finality > architecture described in my draft, regardless of whether the > implementation uses that terminology. > > The narrower question is therefore not whether OAuth can be deployed at > the final boundary. It clearly can. The question is whether token > validation at that location automatically provides these semantics, or > whether they remain application-specific properties outside the OAuth > framework. > > I would particularly welcome clarification on the following: > > 1. Is there an existing OAuth specification or profile that already > defines this complete check-consume-effect invariant? > > 2. Are Transaction Tokens intended only to preserve authorization and > request context across a trusted-domain call chain, or are they also > intended to guarantee reconstruction of the final semantic act and atomic > coupling to the resulting external consequence? > > 3. If the latter properties are not currently specified, would an > execution-bound profile or informational requirements document be useful to > distinguish what OAuth carries from what the final resource server must > enforce? > > The architectural analysis and a detailed FAQ addressing the “OAuth at the > last irreversible boundary” question are available here: > > https://datatracker.ietf.org/doc/draft-das-execution-finality-deployment/ > > Title: “Execution-Finality Architecture for AI and Autonomous Critical > Systems” > > I am not suggesting that OAuth, RAR, DPoP, or Transaction Tokens are > defective. I am trying to determine whether the end-to-end invariant is > already specified, remains entirely application-specific, or represents a > profile-level interoperability gap for autonomous-agent deployments. > > References to existing specifications or implementations providing > functional equivalence would be especially helpful. > > Regards, > > Sangam Kumar Das > Independent Researcher > _______________________________________________ > 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]
