Hi Yaron,
Agreed on the payment example.
If a client already has a concrete intent — Merchant A, EUR 123.50, that
IBAN — puts those values into authorization_details, and the Resource
Server compares the actual POST /payments against the approved values, RFC
9396 is doing exactly what it was designed to do. I am not identifying a
gap in that pattern.
The distinction I am trying to understand is between *expressiveness of the
authority* and *how a dynamically generated invocation becomes authorized
and eventually effective*.
There seem to be three separate questions.
First, who establishes the authoritative values?
In an agent loop, the concrete {tool, arguments} may originate only after
the model executes:
standing/delegated authority
→ model emits {name, arguments}
→ host considers invoke(name, arguments)
RAR can represent those arguments precisely. But copying the same untrusted
model-generated arguments into a finer-grained authorization object does
not by itself establish an independent authorization decision. There still
needs to be some trusted basis — user intent, policy, prior validated
state, or another authority source — against which that concrete Candidate
Act is approved.
So the issue is not that model-generated values can never become
authorized. It is that the same untrusted output should not effectively
define both the act and its own authority without an independent validation
step.
Second, reusable authority and per-invocation authority are different
deployment shapes.
A host may already possess authority permitting use of a tool/API across
multiple calls. RAR can express a much narrower per-call grant, but
obtaining such a grant after each model emission is itself an additional
authorization lifecycle. RFC 9396 does not by itself require a host holding
reusable authority to stop before each invoke() and obtain or construct
act-specific authority.
Third, there is the effectuation boundary.
Even where exact arguments are authorized, the property I am exploring is:
- verify the finalized live arguments against the act that was actually
validated;
- verify current authority and the intended effectuation sink;
- handle concurrent/replayed use appropriately;
- and only then permit the external consequence.
This also matters for sinks that are not naturally OAuth Resource Servers,
such as local function dispatch, computer-use submission, local
persistent-state writes, or other host-controlled effects.
I have also been looking at Transaction Tokens and
draft-niyikiza-oauth-attenuating-agent-tokens. They clearly cover parts of
this space already — including transaction context, tool/argument
constraints, per-invocation PoP, audience binding, and replay controls — so
I would not claim OAuth work stops at coarse resource/action scope.
The residual invariant I am trying to identify is broader:
the concrete Candidate Act remains non-effective until independently
authorized act-bound state is verified at the boundary capable of creating
the external effect, and equivalent execution paths cannot bypass that
boundary.
If the OAuth view is that this last property belongs entirely to the
host/resource implementation, with OAuth providing the sufficiently
specific authority object, that is itself a useful answer. If it belongs
partly in OAuth, then I think the interesting question becomes where the
trustworthy act-specific authorization originates and how it is carried to
the final effectuation point.
Thanks — your example helped me separate these issues much more precisely.
Sangam
On Tue, 1 Sep 2026 at 3:35 PM, Yaron ZEHAVI <
[email protected]> wrote:
> Dear Sangdam,
>
> Thanks for sharing.
>
>
>
> I believe effective enforcement depends in a large part on how specific
> and fine-grained the approved authority is.
>
> For example in RFC 9396 is this RAR example:
>
> {
>
> "type": "payment_initiation",
>
> "actions": [
>
> "initiate",
>
> "status",
>
> "cancel"
>
> ],
>
> "locations": [
>
> "https://example.com/payments";
>
> ],
>
> "instructedAmount": {
>
> "currency": "EUR",
>
> "amount": "123.50"
>
> },
>
> "creditorName": "Merchant A",
>
> "creditorAccount": {
>
> "iban": "DE02100100109307118603"
>
> },
>
> "remittanceInformationUnstructured": "Ref Number Merchant"
>
> }
>
>
>
> Which defines an exact payment amount and beneficiary.
>
> A resource server can leverage these to deny a request with non-matching
> arguments.
>
>
>
> Could you please explain what gaps you identify, which cannot be mitigated
> with fine-grained authority properties?
>
>
>
> Regards,
>
> Yaron
>
>
>
>
>
> Classification: CONFIDENTIAL
>
> *From:* Sangam Das <[email protected]>
> *Sent:* Tuesday, September 1, 2026 9:52 AM
> *To:* [email protected]
> *Cc:* [email protected]
> *Subject:* [OAUTH-WG] Binding OAuth-authorized calls to specific
> tool-call arguments in agentic/MCP flows
>
>
>
> You don't often get email from [email protected]. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
>
> This message is from an external sender - be cautious, particularly with
> links and attachments.
>
>
>
> Hi all,
>
> A question prompted by watching how MCP/tool-use agents actually fail in
> practice:
>
> DPoP sender-constrains a token to a key. RAR and ID-JAG can scope a token
> to a resource and a set of permitted actions. But once an agent holds a
> valid token, none of these constrain the *specific call* it's about to
> make — the tool name and arguments the model just emitted. A
> prompt-injected or poisoned-context agent can hold a fully valid,
> correctly-scoped token and still invoke the right tool with
> attacker-controlled arguments, and OAuth has no visibility into that
> argument payload at all.
>
> Is there existing or in-flight work that binds authorization to the
> content of a specific call (e.g., a digest of the tool name + arguments)
> rather than just to the resource/scope class — something closer to a
> per-invocation proof tying a grant to *this exact call*, not *this class
> of calls*? Or is this considered out of scope for OAuth/WIMSE and better
> handled at the host-application layer?
>
> I*'ve written up one possible approach in more detail as *
> *draft-das-agentic-tool-binding-02** ("tool_use Is Not invoke(): Binding
> Execution-Finality to Agentic Tool-Call Interfaces and MCP"), if useful as
> a starting point rather than a
> proposal: https://datatracker.ietf.org/doc/draft-das-agentic-tool-binding/02/
> <https://datatracker.ietf.org/doc/draft-das-agentic-tool-binding/02/>*
>
> (Note: this builds on architecture covered by my pending patent
> applications, disclosed per RFC 8179 for transparency — flagging this now
> rather than later.)
>
> Mainly interested in whether this gap is already solved somewhere I'm
> missing.
>
> Thanks,
> Sangam
> This message and any attachment ("the Message") are confidential. If you
> have received the Message in error, please notify the sender immediately
> and delete the Message from your system, any use of the Message is
> forbidden. Correspondence via e-mail is primarily for information purposes.
> RBI neither makes nor accepts legally binding statements via e-mail unless
> explicitly agreed otherwise. Information pursuant to § 14 Austrian
> Companies Code: Raiffeisen Bank International AG; Registered Office: Am
> Stadtpark 9
> <https://www.google.com/maps/search/Am+Stadtpark+9?entry=gmail&source=g>,
> 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial
> Court of Vienna (Handelsgericht Wien).
>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
