Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

[Neil Madden <[e-mail]>]

On 21 Feb 2024, at 08:06, Sachin Mamoru <[e-mail]> 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 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 in the spec where it does explicitly say that the refresh token should not be narrowed down based on the given scopes?

I have already pointed out the exact place in the spec that says this: https://www.rfc-editor.org/rfc/rfc6749#section-6 <https://www.rfc-editor.org/rfc/rfc6749#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.

In your example, refresh_token1 has scope1, scope2, scope3 so therefore refresh_token2 must also have those scopes.

-- Neil