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 <[email protected]> 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 <[email protected]> > *Date: *Tuesday, September 1, 2026 at 3:32 AM > *To: *Yaron ZEHAVI <[email protected]> > *Cc: *[email protected] <[email protected]>; [email protected] <[email protected]> > *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 < > [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]
