From sachinmamoru@gmail.com Wed Feb 21 01:37:42 2024 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8756C14F749 for ; Wed, 21 Feb 2024 01:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rASBqie7pXi for ; Wed, 21 Feb 2024 01:37:38 -0800 (PST) Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32D6C14F726 for ; Wed, 21 Feb 2024 01:37:37 -0800 (PST) Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-608342633b8so33898407b3.1 for ; Wed, 21 Feb 2024 01:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708508257; x=1709113057; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hosdO4vSuk3i4pb/iw1pKQVqbn80GGxyJ6j0uGMfJLc=; b=kUQfgXFLa3az/QTs1QfhuDuvt4LGh8Fy+lJrtCo6pyH7cwV9e15XwJxaC8J6UsjLpz sGAdzpSSpHA23tHOZN85HtX8CfKECs5U0bMrNOjVKwM+anbI33q72CzAgeEowd7ghHiL pcrePqW4SmeV1p9Q9VYqXqTPdK4OzCGF8T/Jv6s7COFk8iOOKS3xKAAlD6pKCniEbcJg aBvWBgTUT4nQPF6weadVbZrqSNpGi/lif+IlbYDURY6HDG3xTLcbZL0IrQMqcKFZ6Y1/ Ng4gLVI0+xucP3To1YxinnFXBaME6oT3LHzznlwnjkiqkmmK/VP0zehggTgWjbpwdkjx HC6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708508257; x=1709113057; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hosdO4vSuk3i4pb/iw1pKQVqbn80GGxyJ6j0uGMfJLc=; b=xJM8oP9VFgvnlxkJMPVWleryKQ4MCyic2jJllOhJydM7bJkP0NqTMV6tkZ2gBlWvIM yVzk7aM67Ow20hg45aWi6HCCu5Vwe8yBh2MXbxdi3pyR2jk3nbTqoIupL2r+q7y+AQH+ 5jSHoX04eaGbuq0SIo1SCmBtlv1HigfXrL57rFqe2RgXcLEnOZUJvlcvNhd/PSwy/vD1 FzVuoxg4/CF1zmYVfCYjUCLNQO9aEO6JG4Yw0ZmfkTBilC8RQ+PeJt6d1iBYJNW1wOZ1 HHpWabu5ftbT3d6P+WE9hYfxFR7YOaCwd7h1bXdPvN8KI7EZiBjx2li8WQ3HWbXrLwS9 ZiCQ== X-Forwarded-Encrypted: i=1; AJvYcCWay6QZfSH9eHq/XgIPABH7gDG9W7O1Zhd18jZMlp2ryaIr/rFySD9s/iSKgSV7C4QJFNOwIHik282dIMRThA== X-Gm-Message-State: AOJu0YxgN7KmTk/Lu7ApvW2qtfBjGZzrfdimY4VGZm7n8K4cOR4v6DFy YY+8U+9CUSjP1TWksZjfm8dGqOv58YNv/zH2SYxXgTmie7d+Z+l1Y5pZqNBa5uZqgG4ES6C3vRP Ig3XXp2TzjXX6ChCel+fUMgoAweQ= X-Google-Smtp-Source: AGHT+IH4cWzLMH94fbkn4tvetquBDILK/cThcYuDHi+NDEnnURv2vPbaZ5oMg39bj8jkI9T+EDsv/IplkF2fUW9nCxg= X-Received: by 2002:a81:9bd6:0:b0:604:9c75:626f with SMTP id s205-20020a819bd6000000b006049c75626fmr18082054ywg.46.1708508256831; Wed, 21 Feb 2024 01:37:36 -0800 (PST) MIME-Version: 1.0 References: <374ADB2C-2F74-4B95-8CDA-3266089CD00C@gmail.com> <13C59DD4-94E0-47AC-9A7E-D7B463BD1552@gmail.com> <11F9493F-CE30-450F-BDC9-3C8DCAC35B28@gmail.com> In-Reply-To: <11F9493F-CE30-450F-BDC9-3C8DCAC35B28@gmail.com> From: Sachin Mamoru Date: Wed, 21 Feb 2024 15:07:24 +0530 Message-ID: To: Neil Madden Cc: wparad@rhosys.ch, oauth , janak@wso2.com, thilinasenarath97@gmail.com, "piraveena@wso2.com" Content-Type: multipart/alternative; boundary="000000000000be8ccb0611e1138c" Archived-At: Subject: Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2024 09:37:42 -0000 --000000000000be8ccb0611e1138c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil, Since Access tokens are bound to scopes. These scopes define the permissions granted for accessing resources. When an access token is requested, it's issued with specific scopes based on the authorization granted by the resource owner. On the other hand, Refresh tokens are used to obtain new access tokens when the current access token expires or becomes invalid. The critical aspect here is that the refresh token itself is not bound by scopes in the same way access tokens are. Instead, the refresh token carries the potential to issue new access tokens with scopes that are the same as or narrower than the original scopes granted during the initial authorization process. When you use a refresh token to obtain a new access token, you have the option to request a scope that is narrower than the original scope. This is quite contradicting to me as the spec says that "refresh token scopes should be identical to that of the refresh token included by the client in the request". - When a refresh token is used to obtain a new access token, and a new refresh token is also issued in this process, the new refresh token must have the same scope as the refresh token that was used in the request. On the other hand, it says "Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope". - There's a flexibility in scope when using a refresh token to request new access tokens, but this flexibility might seem counterintuitive at first. Specifically, the idea that the scope of the new access token can be adjusted (narrowed) without altering the permissions granted by the refresh token itself. Thanks & Regards, Sachin On Wed, 21 Feb 2024 at 13:57, Neil Madden wrote: > That section quite clearly says "*access tokens* with identical or > narrower scope". Not refresh tokens. > > -- Neil > > On 21 Feb 2024, at 08:24, Sachin Mamoru wrote: > > Hi Warren and Neil, > > My basis for asking this is due to the following definition [1], > > Refresh tokens are credentials used to obtain access tokens. Refresh > tokens are issued to the client by the authorization server and are > used to obtain a new access token when the current access token > becomes invalid or expires, or to obtain additional access tokens > with identical or narrower scope (access tokens may have a shorter > lifetime and fewer permissions than authorized by the resource > owner). Issuing a refresh token is optional at the discretion of the > authorization server. If the authorization server issues a refresh > token, it is included when issuing an access token (i.e., step (D) in > Figure 1). > > [1] https://datatracker.ietf.org/doc/html/rfc6749#section-1.5 > > Thanks & Regards, > Sachin > > On Wed, 21 Feb 2024 at 13:36, Sachin Mamoru > wrote: > >> Hi Warren and Neil, >> >> Thanks for the valuable input and sorry for mentioning other products, I >> just wanted to provide an example. >> So Warren according to you following is the behaviour that spec suggeste= d. >> >> When we request an access token using 3 scopes (scope1, scope2, scope3). >> >> Then will receive a refresh token (refresh_token1) with the access token= . >> >> After that will request another access token with refresh_token1 and >> provide the scope list as scope1 and scope2 (Narrow down scopes). >> >> Similarly, get another refresh token (refresh_token2) with the access >> token. >> >> Now if we request another access token with refresh_token2, we should be >> able to request scope3 also. >> That means the refresh token will not be narrowed down instead only the >> access token will get narrowed down. >> >> So Warren and Neil, if possible can you pinpoint to me the exact place i= n >> the spec where it does explicitly say that the refresh token should not = be >> narrowed down based on the given scopes? >> >> Thanks & Regards, >> Sachin >> >> On Wed, 21 Feb 2024 at 01:12, Neil Madden >> wrote: >> >>> It sounds like they are violating the spec then. On the other hand, the >>> fact that the scope can be "increased back to the original scope" maybe >>> suggests the effective scope of the refresh token is still the same? Ei= ther >>> way, the spec is pretty clear, regardless of what some vendor does. >>> >>> -- Neil >>> >>> On 20 Feb 2024, at 19:26, Sachin Mamoru wrote: >>> >>> Hi Neil, >>> >>> Thanks for the clarification. >>> But Curity has a different approach and they implemented it according t= o >>> the concept of narrowing down the refresh token scopes. >>> >>> "The scope was originally read openid profile and after refresh the >>> access was reduced to read profile (i.e., the access_token now only has= read >>> profile scope and any new tokens obtained using the refresh token >>> daa38700-ba96-4ef1-8b30-5cb3527aae19 will have the same, reduced >>> scope). Note that *increasing* the scope of access cannot be done in >>> this way unless first reduced and increased back to the original scope.= " >>> >>> [1] >>> https://curity.io/resources/learn/refresh-tokens/#changing-scope-of-acc= ess-token-on-refresh >>> >>> Thanks & Regards, >>> Sachin >>> >>> On Tue, 20 Feb 2024 at 21:59, Neil Madden >>> wrote: >>> >>>> >>>> >>>> On 20 Feb 2024, at 11:02, Sachin Mamoru wrote= : >>>> >>>> =EF=BB=BF >>>> Hi Neil, >>>> >>>> Does that mean it should be identical to the narrowed scope request or >>>> the original request scope? >>>> >>>> >>>> It says it has to be identical to the scope of the existing refresh >>>> token in the request, not the scope specified in the request. So >>>> effectively you can never downscope a refresh token in this way. Whate= ver >>>> scope you specify, any RT returned must always retain the original sco= pe. >>>> >>>> (There are other ways to downscope a RT, eg ForgeRock=E2=80=99s macaro= ons allow >>>> you to attenuate the scope if you wish). >>>> >>>> =E2=80=94 Neil >>>> >>>> >>>> On Tue, 20 Feb 2024 at 16:31, Sachin Mamoru >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, 20 Feb 2024 at 12:23, Neil Madden >>>>> wrote: >>>>> >>>>>> >>>>>> On 20 Feb 2024, at 06:44, Sachin Mamoru >>>>>> wrote: >>>>>> >>>>>> =EF=BB=BF >>>>>> Hi All, >>>>>> >>>>>> When we request an access token using 3 scopes (scope1, scope2, >>>>>> scope3). >>>>>> Then will receive a refresh token (refresh_token1) with the access >>>>>> token. >>>>>> >>>>>> After that will request another access token with refresh_token1 and >>>>>> provide the scope list as scope1 and scope2 (Narrow down scopes). >>>>>> Similarly, get another refresh token (refresh_token2) with the acces= s >>>>>> token. >>>>>> >>>>>> Now if we request another access token with refresh_token2, we canno= t >>>>>> request scope3, instead, we can either request both scope1 and scope= 2 or >>>>>> one of them. >>>>>> >>>>>> But in the specification, didn't able to find anything related to >>>>>> narrow-down scopes with refresh token. >>>>>> >>>>>> From Spec >>>>>> >>>>>> 1.5. Refresh Token - Refresh tokens are issued to the client by the >>>>>> authorization server and are used to obtain a new access token when >>>>>> the current access token becomes invalid or expires or to obtain >>>>>> additional access tokens with identical or narrower scope (access >>>>>> tokens may have a shorter lifetime and fewer permissions than >>>>>> authorized by the resource owner). >>>>>> >>>>>> 6. Refreshing an Access Token >>>>>> The scope of the access request as described by Section 3.3. The >>>>>> requested scope MUST NOT include any scope not originally granted by >>>>>> the resource owner, and if omitted is treated as equal to the scope >>>>>> originally granted by the resource owner. >>>>>> >>>>>> https://datatracker.ietf.org/doc/html/rfc6749 >>>>>> >>>>>> IMO, from a security aspect, the current behaviour is much more >>>>>> secure because it is designed to maintain the principle of least pri= vilege, >>>>>> where it updates the refresh token authorised scopes based on the re= quested >>>>>> ones. >>>>>> >>>>>> What should be the correct behaviour? >>>>>> narrow-down scope refresh token should also be able to request acces= s >>>>>> token with original scope list? >>>>>> >>>>>> >>>>>> Also from section 6: >>>>>> >>>>>> If a >>>>>> new refresh token is issued, the refresh token scope MUST be >>>>>> identical to that of the refresh token included by the client in = the >>>>>> request. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =E2=80=94 Neil >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> Sachin Mamoru >>>>> Software Engineer, WSO2 >>>>> +94771292681 >>>>> | sachinmamoru.me >>>>> sachinmamoru@gmail.com >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> Sachin Mamoru >>>> Software Engineer, WSO2 >>>> +94771292681 >>>> | sachinmamoru.me >>>> sachinmamoru@gmail.com >>>> >>>> >>>> >>>> >>> >>> -- >>> >>> Sachin Mamoru >>> Software Engineer, WSO2 >>> +94771292681 >>> | sachinmamoru.me >>> sachinmamoru@gmail.com >>> >>> >>> >>> >>> >> >> -- >> >> Sachin Mamoru >> Software Engineer, WSO2 >> +94771292681 >> | sachinmamoru.me >> sachinmamoru@gmail.com >> >> >> >> > > -- > > Sachin Mamoru > Software Engineer, WSO2 > +94771292681 > | sachinmamoru.me > sachinmamoru@gmail.com > > > > > --=20 Sachin Mamoru Software Engineer, WSO2 +94771292681 | sachinmamoru.me sachinmamoru@gmail.com --000000000000be8ccb0611e1138c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Neil,

Since Access tokens are b= ound to scopes. These scopes define the permissions granted for accessing r= esources. When an access token is requested, it's issued with specific = scopes based on the authorization granted by the resource owner.

On = the other hand, Refresh tokens are used to obtain new access tokens when th= e current access token expires or becomes invalid. The critical aspect here= is that the refresh token itself is not bound by scopes in the same way ac= cess tokens are. Instead, the refresh token carries the potential to issue = new access tokens with scopes that are the same as or narrower than the ori= ginal scopes granted during the initial authorization process.

When = you use a refresh token to obtain a new access token, you have the option t= o request a scope that is narrower than the original scope.
=
This is quite contradicting=C2=A0to me as the spec says that= =C2=A0"refresh token scopes should be identical=C2=A0to that of the re= fresh token included by the client in the request". -=C2=A0When a refr= esh token is used to obtain a new access token, and a new refresh token is = also issued in this process, the new refresh token must have the same scope= as the refresh token that was used in the request.
On the other = hand, it says "Refresh tokens are issued to the client by the authoriz= ation server and are used to obtain a new access token when the current acc= ess token becomes invalid or expires, or to obtain additional access tokens= with identical or narrower scope". -=C2=A0There's a flexibility i= n scope when using a refresh token to request new access tokens, but this f= lexibility might seem counterintuitive at first. Specifically, the idea tha= t the scope of the new access token can be adjusted (narrowed) without alte= ring the permissions granted by the refresh token itself.

Thanks & Regards,
Sachin

On Wed, 21 Feb 2024 at = 13:57, Neil Madden <neil.e.ma= dden@gmail.com> wrote:
That section q= uite clearly says "*access tokens* with identical or narrower scope&qu= ot;. Not refresh tokens.

-- Neil

On 21 Feb 2024, at 08:24, Sachin Mamoru <sachinmamoru@gmail= .com> wrote:

Hi Warren and Neil,=

My basis for asking this is due to the follow= ing definition [1],

Refresh tokens are credentials used= to obtain access tokens.=C2=A0 Refresh
=C2=A0 =C2=A0tokens are issued t= o the client by the authorization server and are
=C2=A0 =C2=A0used to ob= tain a new access token when the current access token
=C2=A0 =C2=A0becom= es invalid or expires, or to obtain additional access tokens
=C2=A0 =C2= =A0with identical or narrower scope (access = tokens may have a shorter
=C2=A0 =C2=A0lifetime and fewer permissions th= an authorized by the resource
=C2=A0 =C2=A0owner).=C2=A0 Issuing a refre= sh token is optional at the discretion of the
=C2=A0 =C2=A0authorization= server.=C2=A0 If the authorization server issues a refresh
=C2=A0 =C2= =A0token, it is included when issuing an access token (i.e., step (D) in=C2=A0 =C2=A0Figure 1).


Thanks & Regards,
Sachin

On Wed, 21 Feb 2024 at 1= 3:36, Sachin Mamoru <sachinmamoru@gmail.com> wrote:
Hi=C2=A0Warren and Neil,<= div>
Thanks for the valuable input and sorry for mentioning= =C2=A0other products, I just wanted to provide an example.=C2=A0
= So Warren according to you following is the behaviour that spec suggested.<= /div>


So Warren and Neil, if possible can you pi= npoint to me the exact place in the spec where it does explicitly say that = the refresh token should not be narrowed down based on the given scopes?

Thanks & Regards,
Sachin
On Wed, = 21 Feb 2024 at 01:12, Neil Madden <neil.e.madden@gmail.com> wrote:
It sounds like the= y are violating the spec then. On the other hand, the fact that the scope c= an be "increased back to the original scope" maybe suggests the e= ffective scope of the refresh token is still the same? Either way, the spec= is pretty clear, regardless of what some vendor does.

=
-- Neil

On 20 Feb 2024, at = 19:26, Sachin Mamoru <sachinmamoru@gmail.com> wrote:

Hi Neil,

Thanks for the clarification.
B= ut Curity has a different approach and they implemented it according to the= concept of narrowing down=C2=A0the refresh token scopes.

"The scope was originally=C2=A0read openid profile=C2=A0and after refresh = the access was reduced to=C2=A0read profile=C2=A0(i.e., the=C2=A0access_token=C2=A0now only has=C2=A0read profile=C2=A0scope and any new tokens obtained using the refresh tok= en=C2=A0daa38700-ba96-4ef1-8b30-5cb3527aae19=C2=A0will have the same, reduced scope). Note that=C2=A0= increasinghttps://curit= y.io/resources/learn/refresh-tokens/#changing-scope-of-access-token-on-refr= esh

Thanks & Regards,
Sachin

On Tue, 20 Feb 2024 at 21:59, Neil Madden <neil.e.madden@gmail.com> wrote:
=


On 20 Feb 2024, at 11:02, Sachin Mamoru <sachinmamoru@gmail.com= > wrote:

=EF=BB=BF
Hi Neil,

Does that m= ean it should be identical to the narrowed scope request or the original re= quest scope?

It says it h= as to be identical to the scope of the existing refresh token in the reques= t, not the scope specified in the request. So effectively you can never dow= nscope a refresh token in this way. Whatever scope you specify, any RT retu= rned must always retain the original scope.=C2=A0

= (There are other ways to downscope a RT, eg ForgeRock=E2=80=99s macaroons a= llow you to attenuate the scope if you wish).=C2=A0

=E2=80=94 Neil


On Tue, 20 F= eb 2024 at 16:31, Sachin Mamoru <sachinmamoru@gmail.com> wrote:


<= div class=3D"gmail_quote">
On Tue, 20 = Feb 2024 at 12:23, Neil Madden <neil.e.madden@gmail.com> wrote:

On 20 Feb 2024, at 06:44, Sachin Mamoru <sachinmamoru@gmail.com> wrote:
=
=EF=BB=BF=
Hi All,

= When we request an access token using 3 scopes (scope1, scope2, scope3).
Then will receive a refresh= token (refresh_token1) with the access token.

After tha= t will request another access token with refresh_token1 and provide the sco= pe list as scope1 and scope2 (Narrow down scopes).
Similarly, get another refresh token (refresh_tok= en2) with the access token.

Now if we request another ac= cess token with refresh_token2, we cannot request scope3, instead, we can e= ither request both scope1 and scope2 or one of them.

But in the specification, didn't able to find anything related to narr= ow-down scopes with refresh token.

From Spec
1.5.=C2=A0 Refresh Token -=C2=A0Refresh tokens are issued t= o the client by the authorization server and are=C2=A0used to obtain a new access token when the c= urrent access token=C2=A0becomes invalid or expires or to obtain additional access tokens=C2=A0with identical or narrower= scope (access tokens may have a shorter=C2=A0lifetime and fewer permissions than authorized by th= e resource=C2=A0owner).=

6.=C2=A0 Refreshing an Access Token
The scope of the access request as descri= bed by=C2=A0Section 3.3= .=C2=A0 The requested scope MUST NOT include any scope=C2=A0not originally granted by the resource= owner, and if omitted is=C2=A0treated as equal to the scope originally granted by the=C2=A0resource owner.=


IMO, from a security = aspect, the current behaviour is much more secure because it is designed to= maintain the principle of least privilege, where it updates the refresh to= ken authorised scopes based on the requested ones.

What should be the co= rrect behaviour?
narrow-down scope refresh token should also be able to = request access token with original scope list?

Als= o from section 6:

If a
   new refresh token is issued, the refresh token scope MUST be
   identical to that of the refresh token included by the client in the
   request.
=




=E2=80=94 Neil
<= /div>


--
When we request an access token using 3 scopes (scope1, scope= 2, scope3).

=
Then will receive a refresh token (refresh_t= oken1) with the access token.

After that will request an= other access token with refresh_token1 and provide the scope list as scope1= and scope2 (Narrow down scopes).

Similarly, get another= refresh token (refresh_token2) with the access token.
<= font face=3D"arial, sans-serif">
N= ow if we request another access token with refresh_token2, we should be abl= e to request scope3 also.
That means the refresh token will not be narrowed down instead only the ac= cess token will get narrowed down.
=C2=A0
Sachin Mamoru
Software Engineer, WSO2
=
+94771292681
=
| sachinmamoru.me=C2=A0
sachinmamoru@gma= il.com=C2=A0
=
=

3D""


--
=C2=A0
Sachin= Mamoru
Software Engineer, WSO2
+94771292681
| sachinmamoru.me=C2=A0
=
sachinmamoru@gmail.com=C2= =A0

3D""


--
=C2=A0
Sachin Mamoru
Software Engineer, WSO2
=
+94771292681
=
| sachinmamoru.me=C2=A0<= /span>
<= /tr>
<= a href=3D"mailto:sachinmamoru@gmail.com" style=3D"text-decoration:unset;fon= t-size:12px;font-family:Arial" target=3D"_blank"> sachinmamoru@gmail.com=C2=A0
<= /table>
3D""



--
=C2=A0
Sachin Mamoru
Software Engineer, WSO2
<= tr>
+94771292681
=
| <= /td> sachinm= amoru.me=C2=A0
sachinmamoru@gmail.com=C2=A0
<= /table>

3D""

--
=C2=A0
Sachin= Mamoru
Software Engineer, WSO2
+94771292681
| sachinmamoru.me=C2=A0
=
sachinmamoru@gmail.com=C2= =A0

3D""



--
=C2=A0
Sachin Mamoru
Software Engi= neer, WSO2=
<= tr>
+9477= 1292681
sachinmamoru@gmail.com=C2=A0
=
=

3D"" --000000000000be8ccb0611e1138c--