From wparad@rhosys.ch Wed Feb 21 02:16:13 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 1FDB1C14F603 for ; Wed, 21 Feb 2024 02:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.086 X-Spam-Level: X-Spam-Status: No, score=-7.086 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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_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=rhosys.ch 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 hSSZ2_DnYd5a for ; Wed, 21 Feb 2024 02:16:08 -0800 (PST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 7670EC14F619 for ; Wed, 21 Feb 2024 02:16:08 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a28cfca3c45so227908966b.1 for ; Wed, 21 Feb 2024 02:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; t=1708510567; x=1709115367; 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=sywwkX72IctmyS2sDTblswIJ3d1lACTZrxGz+3MSIlM=; b=WPz8xSGfnfJO/VSlqx3C2FMTvSDr3c+/9dyKVyXFHPad7N7SosChi/4XiZ+UFHV8GZ xHsxTPCNKYRlY+vE+eiyCiF+6WrBRlRMdXG0a61k9nZznExssp3Mj7xuEHFGJMKmLX+X re00OhTl6muUxXh4OAo8sO8m4tcPnATHG5JHQ3T04235AYjGMqO+URzPBAPBZEXrGslh tFgSzlBIHlPOnAodOMEA7qDh4MHaOme4VtbuXBbnsN5Ka/2M9ltGPn8+n3+zD0l6RG00 i18hTwM1lKG8TYsrNOR5oEhyFJKsub2QdQDoz2lq0kCtGC5Jd5268zJNMnw1pEWr1+Ji h2Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708510567; x=1709115367; 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=sywwkX72IctmyS2sDTblswIJ3d1lACTZrxGz+3MSIlM=; b=C0E0vV1H5QxDGN6umjWDZjTg3LF7W7HQTKECI4bDr8PunSa2gOzL9dfDTWCh54t/J4 N2zg5cKEa15okJsb5vG7JYF4h9Sq568M46cYln5AFp4cHum3xCgWcb2EVUYbNi0HJFWV uUmwXMLXiGznCfXpCnVSibWjs8TD7WVPzCV5wsveKQlb4hXvsnB3lpMCX0eifESueZ8c ekdpsTWGqgQQ4NTQE9YFetqrbqHNMYIjzAPYau8BgTYH7A9ytW3wUIZJw6c28G9RWYz1 E2X3l+rLYR+7t2TmRL2LHb1smEBGFG37CS8B1Lc8HVJ9lp+0W3XA1k1pjUv0lbIoWCt7 N+MQ== X-Forwarded-Encrypted: i=1; AJvYcCVoQ7WNjQ9K7CttGyU7M+XLIR/O8DmGx/5G+gQpngk7S1PqfaqwwfBTNprG6VObAkELgTQV2D3AWx8UnUbwKQ== X-Gm-Message-State: AOJu0Yw23gEN1hruRmNWEO6oMk4rSB70Qg4kz3BIEv6swtx+XUcQlh7A yxL96rgx5dYG12gTGhdjh1yuZTz70y8EtN+M+tN0YNGG75fZaBqVrdrwjordsI1BD8njRuqcEEM GtyjWuCl/tCI3VlwrrNamGc7IU5IuaQaR1H3m X-Google-Smtp-Source: AGHT+IGufHFkqLKUB0UpJ72BQXbzdhqXCn7Gym/2B5XySI8hTf3NBjJVx7oEOZ4ca8Q7xLm71ef16I+uq9uCOmd78Uw= X-Received: by 2002:a17:906:3152:b0:a3e:7ae1:d0a7 with SMTP id e18-20020a170906315200b00a3e7ae1d0a7mr5725134eje.0.1708510566531; Wed, 21 Feb 2024 02:16:06 -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: From: Warren Parad Date: Wed, 21 Feb 2024 11:15:55 +0100 Message-ID: To: Sachin Mamoru Cc: Neil Madden , oauth , janak@wso2.com, thilinasenarath97@gmail.com, "piraveena@wso2.com" Content-Type: multipart/alternative; boundary="00000000000069d8e30611e19d9e" 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 10:16:13 -0000 --00000000000069d8e30611e19d9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sachin, Can I ask what your goal is here, as in what would you like out of this conversation, what concrete if anything would like this working group to action? It seems that you have had a question, which has been answered multiple times (in multiple different email threads, I might add). The language in the RFC is pretty clear, although, in practice I can see that the usage might be a bit complex. - Warren On Wed, Feb 21, 2024 at 10:37=E2=80=AFAM Sachin Mamoru wrote: > 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 th= e > 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 authorizatio= n > 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 th= e > 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 >>> suggested. >>> >>> When we request an access token using 3 scopes (scope1, scope2, scope3)= . >>> >>> Then will receive a refresh token (refresh_token1) with the access toke= n. >>> >>> 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 b= e >>> 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 >>> 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 >>> wrote: >>> >>>> It sounds like they are violating the spec then. On the other hand, th= e >>>> fact that the scope can be "increased back to the original scope" mayb= e >>>> suggests the effective scope of the refresh token is still the same? E= ither >>>> 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 >>>> to 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-ac= cess-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 o= r >>>>> 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. What= ever >>>>> scope you specify, any RT returned must always retain the original sc= ope. >>>>> >>>>> (There are other ways to downscope a RT, eg ForgeRock=E2=80=99s macar= oons >>>>> 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 an= d >>>>>>> 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 >>>>>>> cannot request scope3, instead, we can either request both scope1 a= nd >>>>>>> scope2 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 pr= ivilege, >>>>>>> where it updates the refresh token authorised scopes based on the r= equested >>>>>>> ones. >>>>>>> >>>>>>> What should be the correct behaviour? >>>>>>> narrow-down scope refresh token should also be able to request >>>>>>> access 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 >> >> >> >> >> > > -- > > Sachin Mamoru > Software Engineer, WSO2 > +94771292681 > | sachinmamoru.me > sachinmamoru@gmail.com > > > > --00000000000069d8e30611e19d9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sachin,

Can I ask what your goal is her= e, as in what would you like out of this conversation,=C2=A0what concrete= =C2=A0if anything would like this working group to action? It seems that yo= u have had a question, which has been answered multiple times (in multiple = different email threads, I might add). The language in the RFC is pretty cl= ear, although, in practice I can see that the=C2=A0usage might be a bit com= plex.

- Warren

On Wed, Feb 21, 2024 at 10:37= =E2=80=AFAM Sachin Mamoru <sac= hinmamoru@gmail.com> wrote:
Hi=C2=A0Neil,

Since = Access tokens are bound to scopes. These scopes define the permissions gran= ted for accessing resources. When an access token is requested, it's is= sued with specific scopes based on the authorization granted by the resourc= e owner.

On the other hand, Refresh tokens are used to obtain new ac= cess tokens when the current access token expires or becomes invalid. The c= ritical 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 na= rrower than the original scopes granted during the initial authorization pr= ocess.

When you use a refresh token to obtain a new access token, yo= u have the option to request a scope that is narrower than the original sco= pe.

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 refresh token included by the client in the request"= . -=C2=A0When a refresh token is used to obtain a new access token, and a n= ew 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 cl= ient 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 addi= tional access tokens with identical or narrower scope". -=C2=A0There&#= 39;s a flexibility in scope when using a refresh token to request new acces= s tokens, but this flexibility might seem counterintuitive at first. Specif= ically, the idea that the scope of the new access token can be adjusted (na= rrowed) without altering the permissions granted by the refresh token itsel= f.

Thanks & Regards,
Sachin

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

-- Neil

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

Hi Warren and Neil= ,

My basis for asking this is due to the follo= wing definition [1],

Refresh tokens are credentials use= d to obtain access tokens.=C2=A0 Refresh
=C2=A0 =C2=A0tokens are issued = to the client by the authorization server and are
=C2=A0 =C2=A0used to o= btain a new access token when the current access token
=C2=A0 =C2=A0beco= mes 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>

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

Then will receive a ref= resh 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).
<= font face=3D"arial, sans-serif">
S= imilarly, 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 in the spec where it d= oes explicitly say that the refresh token should not be narrowed down based= on the given scopes?

Thanks & Regards,
<= div>Sachin

On Wed, 21 Feb 2024 at 01:12, Neil Madden <neil.e.madden@gmail.com= > wrote:
It sounds like they are violating the spec then. On the other hand, t= he fact that the scope can be "increased back to the original scope&qu= ot; maybe suggests the effective scope of the refresh token is still the sa= me? Either way, the spec is pretty clear, regardless of what some vendor do= es.

-- Neil

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

Thanks for the clar= ification.
But Curity has a different approach and they implement= ed it according to the concept of narrowing down=C2=A0the refresh token sco= pes.

"The scope was orig= inally=C2=A0read openid profile= =C2=A0and after refresh the access was reduced to=C2=A0read= profile=C2=A0(i.e., the=C2=A0acc= ess_token=C2=A0now only has=C2=A0= read profile=C2=A0scope and any new tokens obta= ined using the refresh token=C2=A0daa38700-ba96-4ef1-8b30-5cb= 3527aae19=C2=A0will have the same, reduced scop= e). Note that=C2=A0increasi= ng=C2=A0the scope of access cannot be done in thi= s way unless first reduced and increased back to the original scope.= "


Thanks & Reg= ards,
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 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 ef= fectively you can never downscope a refresh token in this way. Whatever sco= pe you specify, any RT returned must always retain the original scope.=C2= =A0

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

=E2=80=94 Neil


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


On Tue, 20 Feb 2024 at 12:23, Neil Madden <neil.e.madden@gmail.c= om> wrote:

On 20 Feb 2024, at 06:44, Sachin Mamo= ru <sachinma= moru@gmail.com> wrote:

=EF=BB=BF
Hi All,

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

After that will request another access token with r= efresh_token1 and provide the scope list as scope1 and scope2 (Narrow down = scopes).
Similarly, get a= nother refresh token (refresh_token2) with the access token.<= /div>
Now if we request another access token with refresh_token2, we cannot = request scope3, instead, we can either request both scope1 and scope2 or on= e of them.

But in the specification, didn't able= to find anything related to narrow-down scopes with refresh token.<= /span>

From Spec

1.= 5.=C2=A0 Refresh Token -=C2=A0Refresh tokens are issued to the client by the authorization server = and are=C2=A0used to ob= tain a new access token when the current 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 fewe= r permissions than authorized by the resource=C2=A0owner).

6.=C2=A0 Refreshing = an Access Token
The scope= of the access request as described by=C2=A0Section 3.3.=C2=A0 The requested scope MUST NOT includ= e any scope=C2=A0not or= iginally granted by the resource owner, and if omitted is=C2=A0treated as equal to the scope origi= nally 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 token authorised scopes based on the request= ed ones.

What should be the correct behaviour?
narrow-down scope refresh= token should also be able to request access 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
<= /div>


--
=
=C2=A0
Sachin Mamoru
Software Engineer, WSO2
=
+94771292681=
<= td style=3D"padding:0px 4px"> | <= td style=3D"padding:0.01px;font-family:Arial;font-size:12px"> sachinmamoru.m= e=C2=A0
sachinmamoru@gmail.com=C2=A0

3D""

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

3D""

--
=C2=A0= <= /table>
Sachin Mamoru
Software En= gineer, WS= O2
+9477= 1292681
sachinmamoru.me=C2=A0
sachinmamoru@gmail.com=C2=A0
=
<= /tbody>

3D""


--
<= /tbody>
= =C2=A0
Sachin = Mamoru
Software Engineer, WSO2
+94771292681
| sachinmamoru.me=C2=A0
<= table cellpadding=3D"0" cellspacing=3D"0" style=3D"border-collapse:collapse= ">
sachinmamoru@gmail.com=C2= =A0

=3D""


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

3D""


--
=C2=A0<= /table>
Sachin Mamoru
Software Engineer, WSO2
+94771292681
<= /td>		=
| sachinmamoru.me=C2=A0
sachinmamoru@gma= il.com=C2=A0
=
<= td align=3D"left" style=3D"padding-right:6px;text-align:center;padding-top:= 0px">=

3D"" --00000000000069d8e30611e19d9e--