Return-Path: X-Original-To: oauth@mail2.ietf.org Delivered-To: oauth@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A95DC132F82B8 for ; Tue, 1 Sep 2026 03:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1788258739; bh=/BUfrEZtBxbqRRBxfHWbz2mVl4MxfnQM4L4vqeaHrW8=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=y348PzDH3ptW9PLanpi5M5GTUrPe8LcbYfjk5QmuyhWC0EvDPCEgVx2X4KFm8cK0I EFc9+aQLfwlikYg/BBqaMAYjN/1Z/NW3jGMSyEJR8d7Uci+YrMn2rgLPPuR3VmI61g CxcZV1MgJO4jiL93p3hnpniAw5ROBdRkdA9kYTSY= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=sangamdas-com.20251104.gappssmtp.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdD03TPqYf5W for ; Tue, 1 Sep 2026 03:32:18 -0700 (PDT) Received: from mail-yx1-xb12d.google.com (mail-yx1-xb12d.google.com [IPv6:2607:f8b0:4864:20::b12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 73A86132F825D for ; Tue, 1 Sep 2026 03:32:18 -0700 (PDT) Received: by mail-yx1-xb12d.google.com with SMTP id 956f58d0204a3-66bd7857841so969858d50.3 for ; Tue, 01 Sep 2026 03:32:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1788258732; cv=none; d=google.com; s=arc-20260327; b=XxVsDKrcThOfmSAgIoLs1L/YWFFvhE8kuu2BYRbBfdcPNoyyyRE3u0Fc4L38JpJRKj TuMiRZ5CDtbWEk4QIQFNt3wSYNMIfWBpY9AaLccDOr/PHy1uAI78TDZOfEOZRk4EmNfd O4LLn7Qle5SDipe+1I2d72y8OLxyzO/suGZxs+dgAFgpXVKyIrYftlnkxCRwSeCMEWll JuPeNzbOZa28UYwg4QxirkafiIbrgfhPowrZsPoLiaLyRKibWwhVXgqPQNyySUKNWuZM xj2i/FA9iuRPtI7F9rLmcyVwYsio3tHAKgllKHr/P7qHzP1bayLa/ijalssWPAYfjmYG WTJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=CZOviko0W3pON+lHJAg0MUddQYAFkC/N/0a5auE7fGA=; fh=USDI95/S6vjYIsSeR03SP0x5uiZfXVCKj6cMxo1x9nU=; b=JbRa13ef0b+xPRJxtK8wKqXmT+R8wTwwCTcXGpwqzUgutAZJDbyObiTkBXtRW/qYo6 2sP4nH6Qvt/ZhbLqtGPcUAu+NemhHL5a8AjupYqvFbNVJGrLS+rtbA2ob4GVyXt03sGH 8d9OqmnLm4aPoKcq8kq6Q45Q5MODflSz8A8xMpN2YBdO/v/jNXsKGCs9uUdsoiPdaDUk lGt2ZXHI+PWNKN7RQsvN602CDcZGPfeFziEyIIlA54QZb3WDJBnAH+iZiBCN/8b5sQnd UP00AwIcTBmQ8h+58H2J+6UKBKJwvK8WMfkVo/Mr9y+qzFyhOM9qk/O5mmOo7ANOwk+H bzGQ==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sangamdas-com.20251104.gappssmtp.com; s=20251104; t=1788258732; x=1788863532; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=CZOviko0W3pON+lHJAg0MUddQYAFkC/N/0a5auE7fGA=; b=aZ/ZUBYXtdVoDJZIuDkHqZNyIKbSdOXFhaKuFjl6olyLgfQnVEgwLHprVtZJk1vul4 vBhTqY55Iqn4HGG1B6STAPiXYGoPNv9gkvTfsB6X+pOSla4Zy7DT+AuHr/P2m8Zm/w9P lPi5wyHOGegfgB5nuUytQMyG1xno9QQ76epdJCvNiLsfJHoGYOn4936OGgO23Ukx1m2s sQ2hMET+Bh0fOuRxM6I5E/DV3DJXNkeYlPGcs2gT2ZUg8VPcm7st+L8P/TwV9okwVe6O I7U9Bryplo+Fn9+++PdH++cJWGW6El7cZIFxklIYttNMwp3h9mOsIrWrE7p18QiTatI1 o1/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788258732; x=1788863532; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=CZOviko0W3pON+lHJAg0MUddQYAFkC/N/0a5auE7fGA=; b=P2L/G6RnQFrGQueWF28Px/zFQFpS35pSXcyXBk2fjUAoT5YRgmB90rNqMaHHDqNUOD PhE1zmTN9fFqI8Ps38/ekQVuYw929KBjVf/RrN6XjasOZVBpisO3wxGkPAy0VEn3EQ6u S/MUOcjzg5YwYP2IW4LXXUCP/jVWhrx4QeCQPTscRhKdhP/GBU4hyKCpY8Vw6Hb/b9RP rV4+shNEEGKkc0ouE/WGUZFWbuHwTB9klWKkOcCXpK9L4KsqqO3OiriLu0+gQEdK7iBy iCzIkztdexZJUDKADfP9p4g4B6vh1ysEocO7FKRCPLJxnnXaQpl5dqVBsx1cJbpgTJcd U+vQ== X-Gm-Message-State: AFuF++kEb07c3ziqjxPUdaLms63k/GnkEuyMXEIpP2Ufyxp6XOmAzh+S cKUV0YU2uQu7Fw2HS8ScBWTri+rqFf6Inr4y0GNGyg1X/qNKSrg7th1KtzjxVF2yAMl36gLhTSY NVJXRM7Xw3jJswMOhRsfOHNazQxosc2EoptUZc2zNLkk+J+IpluAJGGp4 X-Gm-Gg: AYBFou0xj6IivtvMwzFg4gDscopjPijF2EtbFKAQUD5WEHjoahr4EACyedFe2VN2OmR 8AIQTUchHenF35kjKtIFmJxrSFycpm7R9YUGVKUevgz4a10mDyxyW5MtwQw/3IXmq4kU1yaotTf AxT3HJWfn2f4+AGoElgbqROfyeH6IytNUM7LupaTbD+plSm0I/RYXdN1mJBbYt2Cpux+Or1gi0i X4+4/5JQS/O+TZSybUWtKrJ4V9nViPQg3tsO7+4P8cYw3EC0kUIKdRxzSt3q6lRvv7VrUa1nhAQ SisfL3aLwNNNTEtRzM5v4Cu4ZJ9T9jez0738uwFDaOl0D+Ey6Eg+yyaXAF778FAyd2hqTBsmx34 yUA== X-Received: by 2002:a05:690e:1720:b0:668:180c:bf6a with SMTP id 956f58d0204a3-66e4c776c07mr6997625d50.37.1788258731854; Tue, 01 Sep 2026 03:32:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sangam Das Date: Tue, 1 Sep 2026 16:02:00 +0530 X-Gm-Features: AcwNN1VAwafq7GSMOedwa6HGB0Y3BDdx0Fdzh-8W3wtl39S4wA97SKC3aCXov2U Message-ID: To: Yaron ZEHAVI Content-Type: multipart/alternative; boundary="0000000000007aa5a2065a696e7f" Message-ID-Hash: EWW34ARPKHYDIJPLSJGY277YJL4H4C4T X-Message-ID-Hash: EWW34ARPKHYDIJPLSJGY277YJL4H4C4T X-MailFrom: info@sangamdas.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "oauth@ietf.org" , "wimse@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_Binding_OAuth-authorized_calls_to_specific_to?= =?utf-8?q?ol-call_arguments_in_agentic/MCP_flows?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000007aa5a2065a696e7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, Agreed on the payment example. If a client already has a concrete intent =E2=80=94 Merchant A, EUR 123.50,= that IBAN =E2=80=94 puts those values into authorization_details, and the Resour= ce 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 =E2=86=92 model emits {name, arguments} =E2=86=92 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 =E2=80=94 user intent, policy, prior validat= ed state, or another authority source =E2=80=94 against which that concrete Ca= ndidate 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 =E2=80=94 including transaction context, tool/argument constraints, per-invocation PoP, audience binding, and replay controls =E2= =80=94 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 =E2=80=94 your example helped me separate these issues much more pre= cisely. Sangam On Tue, 1 Sep 2026 at 3:35=E2=80=AFPM, Yaron ZEHAVI < yaron.zehavi@rbinternational.com> 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 mitigate= d > with fine-grained authority properties? > > > > Regards, > > Yaron > > > > > > Classification: CONFIDENTIAL > > *From:* Sangam Das > *Sent:* Tuesday, September 1, 2026 9:52 AM > *To:* oauth@ietf.org > *Cc:* wimse@ietf.org > *Subject:* [OAUTH-WG] Binding OAuth-authorized calls to specific > tool-call arguments in agentic/MCP flows > > > > You don't often get email from info@sangamdas.com. Learn why this is > important > > 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 =E2=80=94 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 =E2=80=94 something closer t= o 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 a= s > a starting point rather than a > proposal: 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 =E2=80=94 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 purpose= s. > RBI neither makes nor accepts legally binding statements via e-mail unles= s > explicitly agreed otherwise. Information pursuant to =C2=A7 14 Austrian > Companies Code: Raiffeisen Bank International AG; Registered Office: Am > Stadtpark 9 > , > 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commerci= al > Court of Vienna (Handelsgericht Wien). > --0000000000007aa5a2065a696e7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Yaron,

Agreed on the payment example.

If a client already has a concrete intent =E2=80=94 Merchant A, EUR 123.= 50, that IBAN =E2=80=94 puts those values into authorization_details<= /code>, and the Resource Server compares the actual POST /payments against the approved values, RFC 9396 is doing exactly what it was des= igned to do. I am not identifying a gap in that pattern.

The distinction I am trying to understand is between expressiveness o= f the authority and how a dynamically generated invocation becomes a= uthorized 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 origin= ate only after the model executes:

standing/delegated authority
=E2=86=92 model emits {name, arguments}
=E2=86=92 host considers invoke(name, arguments)

RAR can represent those arguments precisely. But copying the same untrus= ted model-generated arguments into a finer-grained authorization object doe= s not by itself establish an independent authorization decision. There stil= l needs to be some trusted basis =E2=80=94 user intent, policy, prior valid= ated state, or another authority source =E2=80=94 against which that concre= te Candidate Act is approved.

So the issue is not that model-generated values can never become authori= zed. It is that the same untrusted output should not effectively define bot= h the act and its own authority without an independent validation step.

Second, reusable authority and per-invocation authority are different de= ployment 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 obtain= ing such a grant after each model emission is itself an additional authoriz= ation lifecycle. RFC 9396 does not by itself require a host holding reusabl= e authority to stop before each invoke() and obtain or constru= ct act-specific authority.

Third, there is the effectuation boundary.

Even where exact arguments are authorized, the property I am exploring i= s:

  • verify the finalized live arguments against the act that was actual= ly validated;
  • verify current authority and the intended effectuatio= n sink;
  • handle concurrent/replayed use appropriately;
  • and o= nly then permit the external consequence.

This also matters for sinks that are not naturally OAuth Resource Server= s, such as local function dispatch, computer-use submission, local persiste= nt-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 spa= ce already =E2=80=94 including transaction context, tool/argument constrain= ts, per-invocation PoP, audience binding, and replay controls =E2=80=94 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 aut= horized act-bound state is verified at the boundary capable of creating the= external effect, and equivalent execution paths cannot bypass that boundar= y.

If the OAuth view is that this last property belongs entirely to the hos= t/resource implementation, with OAuth providing the sufficiently specific a= uthority object, that is itself a useful answer. If it belongs partly in OA= uth, then I think the interesting question becomes where the trustworthy ac= t-specific authorization originates and how it is carried to the final effe= ctuation point.

Thanks =E2=80=94 your example helped me separate these issues much more = precisely.

Sangam



On Tue, 1 Sep 2026 at 3:35=E2=80= =AFPM, Yaron ZEHAVI <yaron.zehavi@rbinternational.com> wrote:

Dear Sangdam,

Thanks for sharing.

=C2=A0

I believe effective enforcement depends in a large pa= rt on how specific and fine-grained the approved authority is.

For example in RFC 9396 is this RAR example:

{

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "type": &quo= t;payment_initiation",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "actions": [=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &quo= t;initiate",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &quo= t;status",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &quo= t;cancel"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ],

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "locations":= [

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &quo= t;https://exampl= e.com/payments"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ],

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "instructedAmount= ": {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &quo= t;currency": "EUR",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &quo= t;amount": "123.50"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "creditorName&quo= t;: "Merchant A",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "creditorAccount&= quot;: {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &quo= t;iban": "DE02100100109307118603"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "remittanceInform= ationUnstructured": "Ref Number Merchant"

=C2=A0=C2=A0 }

=C2=A0

Which defines an exact payment amount and beneficiary= .

A resource server can leverage these to deny a reques= t with non-matching arguments.

=C2=A0

Could you please explain what gaps you identify, whic= h cannot be mitigated with fine-grained authority properties?=

=C2=A0

Regards,

Yaron

=C2=A0

=C2=A0


Classification: CONFIDENTIAL

From: Sangam Das <info@sangamdas.com>
Sent: Tuesday, September 1, 2026 9:52 AM
To: oauth@ietf.o= rg
Cc: wimse@ietf.o= rg
Subject: [OAUTH-WG] Binding OAuth-authorized calls to specific tool-= call arguments in agentic/MCP flows

=C2=A0

This message is from an external sender - be cautious, particularly wit= h links and attachments.

=C2=A0

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 toke= n to a resource and a set of permitted actions. But once an agent holds a v= alid token, none of these constrain the specific call<= /span> it's about to make =E2=80=94 the tool name and arguments th= e 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 cont= ent of a specific call (e.g., a digest of the tool name + arguments) rather= than just to the resource/scope class =E2=80=94 something closer to a per-= invocation proof tying a grant to this exact cal= l, not this class of = calls? Or is this considered out of scope for OAuth/WIMSE and b= etter 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-Finalit= y to Agentic Tool-Call Interfaces and MCP"), if useful as a starting point rather than a proposal:=C2=A0https://datatracker.ietf.org/doc/draf= t-das-agentic-tool-binding/02/

(Note: this builds on architecture covered by my pending patent applicat= ions, disclosed per RFC 8179 for transparency =E2=80=94 flagging this now r= ather 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 immedi= ately and delete the Message from your system, any use of the Message is fo= rbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding st= atements via e-mail unless explicitly agreed otherwise. Information pursuan= t to =C2=A7 14 Austrian Companies Code: Raiffeisen Bank International AG; R= egistered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Cou= rt of Vienna (Handelsgericht Wien).
--0000000000007aa5a2065a696e7f--