[OAUTH-WG] Re: [WIMSE] Re: Binding OAuth-authorized calls to specific tool-call arguments in agentic/MCP flows

[Sangam Das <[e-mail]>]

Dear Ashley,

Thank you — that is the distinction I was after.
I agree with your proposed host rule as the right shape:

A conforming host MUST NOT invoke a tool sink unless the finalized
parameter digest matches an authorized policy assertion.
Two qualifications I would keep explicit, so the assertion cannot be the
model block in another envelope:

1. The policy assertion MUST be established by a source other than the live
tool payload (user/policy/prior validated state). Matching a digest of
values that were copied from the same untrusted emission is not an
independent decision.

2. “Tool sink” includes the first local dispatch — function table, MCP
client tools/call, computer-use submit — not only a downstream RS.
Equivalent paths that can produce the same effect MUST see the same check.

Your point on tctx plus agentic_ctx is the complementary half: once the
host has allowed a call, propagating those claims lets later services
authorize the same act rather than a mutated one. That is defense in depth
on the chain. It does not replace the host MUST at the first sink.

If it is useful, I can try a one-paragraph “host conformance” note that
sits next to the txn-token-for-agents text rather than as a separate model.
Happy to stay in your vocabulary (tctx, digest, policy assertion, sink)
instead of mine.
Thanks again for the precise read.
Sangam





On Wed, 2 Sep 2026 at 12:35 AM, Raut, Ashay <[e-mail]> wrote:

>
>    -
>
>    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.
>
> Agree with this statement here.
>
>
>
>    -
>
>    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.
>
> Fair call out. It’s almost like we need spec to say, “A conforming host
> implementation MUST NOT invoke a tool sink unless the finalized parameter
> digest matches an authorized policy assertion”.
>
> On side note, you can pass Txn token’s ​ tctx​ claims along with
> agentic_context​ so that deep down call chains can do fine grained
> authorization to enable defense in depth and additional checks for agent
> initiated actions. Refer to
> https://www.ietf.org/archive/id/draft-araut-oauth-transaction-tokens-for-agents-02.html
>
>
> Ashay
>
> Get Outlook for Mac <https://aka.ms/GetOutlookForMac>
> *From: *Sangam Das <[e-mail]>
> *Date: *Tuesday, September 1, 2026 at 3:32 AM
> *To: *Yaron ZEHAVI <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> *Subject: *[EXTERNAL] [WIMSE] Re: [OAUTH-WG] Binding OAuth-authorized
> calls to specific tool-call arguments in agentic/MCP flows
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
> 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 <
> [e-mail]> 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 <[e-mail]>
> *Sent:* Tuesday, September 1, 2026 9:52 AM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *Subject:* [OAUTH-WG] Binding OAuth-authorized calls to specific
> tool-call arguments in agentic/MCP flows
>
>
>
> You don't often get email from [e-mail]. 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).
>
>