The application / client is responsible for interpreting the information in the authorization token. How you choose to do that is up to you. The concerns you are focusing on, are real problems that require the context of the actual problem, the business needs, and users expectations to make the decision for how the resource server / application / client should handle unexpected states.
On Mon, Sep 21, 2026 at 5:53 PM Sangam Das <[email protected]> wrote: > Thank you. The short answer is: possibly nothing is missing from RFC 9396 > as an authorization-details data model. > > RFC 9396 appears sufficiently extensible for an application-defined > authorization_details type to carry all consequence-relevant fields—for > example, beneficiary, account, amount, currency, destination, content > digest, permitted operation and expiry. > > The distinction I am examining is not primarily whether RAR can express > the authorized act. It is whether the final resource server is required to > establish that the act actually becoming effective is the same act and > remains permitted at commit time. > > For example, assume that a RAR object accurately authorizes: > > ● payment of amount X to beneficiary Y; or > > ● SEND of content digest D to recipient R. > > The remaining questions at the final effectuation boundary are whether the > resource server: > > 1. reconstructs the actual semantic act from the parameters the ledger, > egress mechanism or downstream system will really use; > > 2. deterministically compares every consequence-relevant field with the > authorization details, including aliases, transformations and destination > resolution; > > 3. revalidates current revocation, authorization generation, expiry, > quota, resource version and replay state; > > 4. atomically consumes any single-use authority with the exact payment, > SEND, write or other resulting state transition; > > 5. handles crashes so that committed, denied, uncommitted and > indeterminate outcomes cannot cause an unauthorized retry or duplicate > effect; and > > 6. ensures that no alternate execution path bypasses the same check. > > My understanding is that RFC 9396 deliberately defines how fine-grained > authorization requirements are conveyed, while leaving the > application-specific semantics and enforcement of an authorization_details > type to the relevant API and resource server. > > If that understanding is correct, then I should not describe the issue as > a missing feature of RFC 9396 itself. > > Rather, the possible gap is the absence of an interoperable > execution-bound profile establishing how an authorized RAR object is bound > to: > > ● the final semantic act; > > ● current protected state; > > ● replay-sensitive consumption; and > > ● the atomic or crash-consistent external consequence. > > If a resource server already performs all of those functions at the last > preventable boundary, I regard it as functionally equivalent to the > execution-finality architecture. In that deployment, RAR can be the > authorization representation and no additional generic authorization > protocol may be necessary. > > So my more precise questions are: > > ● Is this final check-consume-effect invariant already specified by an > existing OAuth or RAR profile? > > ● Or is it intentionally an application-specific resource-server and > transaction-design responsibility? > > ● If it is application-specific, would documenting the boundary between > what RFC 9396 conveys and what an execution-bound application profile must > enforce be useful—or is that clearly outside OAuth WG scope? > > I would appreciate references to any existing specification that already > defines these final enforcement and atomicity properties. > > Regards, > > Sangam Kumar Das > > > On Mon, 21 Sep 2026 at 9:18 PM, Warren Parad <[email protected]> wrote: > >> 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]
