From neil.e.madden@gmail.com Mon Feb 19 22:53:47 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 B1B60C14F6F0 for ; Mon, 19 Feb 2024 22:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.093 X-Spam-Level: X-Spam-Status: No, score=-7.093 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, MIME_QP_LONG_LINE=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_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 JiSUZOVFp0C3 for ; Mon, 19 Feb 2024 22:53:43 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 BFD1CC151064 for ; Mon, 19 Feb 2024 22:53:43 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4126e9d587dso822665e9.0 for ; Mon, 19 Feb 2024 22:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708412022; x=1709016822; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=ZKX7/+aZup9D028gnNekALQNpwOIT+ifWbgtp3rnNgY=; b=gDw4OIDfB0jGgr2H7r+60czj3sZhiaZIBCr9m/0qMkzxozAUS+h30bEqT1r59QTLYr IsF0BgN0lou0NDb03insAnr3FsfagbbMVxgB1KFsqFeADuVDVq7ZEZhPLFFIY2xCb8gE cxwZAgu6Yj4Fbwyyq+2CbYx5f6bJ9pZpunfi9KjRSBPymebbVd0GVJEbcW9NHZ9Ury45 VWTQChwi+din6SW5ntp+f/VFvH4ieX2Bl1vfd6PBnsqa0Zo4Q5xuSALmqQGrXlU8P321 mU0aJYdy84XrEXUP/Nsf7cFAykqzXifSiTkheojw+048cr/XF2qQ6xJKKx/TDCtaqVgU xGKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708412022; x=1709016822; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZKX7/+aZup9D028gnNekALQNpwOIT+ifWbgtp3rnNgY=; b=TyG9cpgiG2vmHe4TIREgSHuZO3ng1uZsuvoUr9qhsHsO6v0dd0fsUnaRTQRAELWUJh jXcSxiRL7qwPcLK/KiRWDI5FXAbhbSTgVOpmPR5tGFIbONqurrA90Xl1vFTRac/pq14z d1ODEk9X8YkWOcy5lHtP3D/VrVQ2bCZkiHJq584uG4A7MMDLXVFe9hWbBG8eGWSEDiCE rtFNPgQfGdd+1/3g5MI/BjnHP9lai/8QmY/SzJSlaxGykCb/GY8+QKXjpRqRFGb7qrhy LrnNminsXNQxryda2uLafMnH2eHqnrcj36YHnulW82Nl6+FmMsoAjCvfa8DNk+F6sFao CEjA== X-Gm-Message-State: AOJu0Yz5N4ds0UeF+ZbLmAewyyAtTaA5RI4U+6aDRLEDIbYLNLp1XXwY g9oashfEzFz/6KCosfL7hMnk3uyiZ7fnSgn0WlHNUiiREXuPp8qy X-Google-Smtp-Source: AGHT+IEoOMPA2bAVBub52zep6Gz0gJDu/LLOsymNksIGKwyCNuBUqkLG0Cjg5jHsw12JDR2V02hIaA== X-Received: by 2002:a05:600c:198e:b0:412:6df1:e496 with SMTP id t14-20020a05600c198e00b004126df1e496mr989526wmq.3.1708412021399; Mon, 19 Feb 2024 22:53:41 -0800 (PST) Received: from smtpclient.apple ([213.31.127.136]) by smtp.gmail.com with ESMTPSA id o20-20020a05600c4fd400b00412590eee7csm10417287wmq.10.2024.02.19.22.53.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Feb 2024 22:53:41 -0800 (PST) From: Neil Madden X-Google-Original-From: Neil Madden Content-Type: multipart/alternative; boundary=Apple-Mail-4510206D-DEA6-4DF2-B8E5-7E86DB46753B Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Tue, 20 Feb 2024 06:53:30 +0000 Message-Id: <9D9E6142-0C87-4140-BB9F-AE3B89A44BCB@gmail.com> References: Cc: oauth@ietf.org In-Reply-To: To: Sachin Mamoru X-Mailer: iPhone Mail (21C66) 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: Tue, 20 Feb 2024 06:53:47 -0000 --Apple-Mail-4510206D-DEA6-4DF2-B8E5-7E86DB46753B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 20 Feb 2024, at 06:44, Sachin Mamoru wrote: >=20 > =EF=BB=BF > Hi All, >=20 > When we request an access token using 3 scopes (scope1, scope2, scope3). > Then will receive a refresh token (refresh_token1) with the access token. >=20 > After that will request another access token with refresh_token1 and provi= de the scope list as scope1 and scope2 (Narrow down scopes). > Similarly, get another refresh token (refresh_token2) with the access toke= n. >=20 > Now if we request another access token with refresh_token2, we cannot requ= est scope3, instead, we can either request both scope1 and scope2 or one of t= hem. >=20 > But in the specification, didn't able to find anything related to narrow-d= own scopes with refresh token. >=20 > =46rom Spec >=20 > 1.5. Refresh Token - Refresh tokens are issued to the client by the autho= rization server and are used to obtain a new access token when the current a= ccess 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). >=20 > 6. Refreshing an Access Token > The scope of the access request as described by Section 3.3. The requeste= d scope MUST NOT include any scope not originally granted by the resource ow= ner, and if omitted is treated as equal to the scope originally granted by t= he resource owner. >=20 > https://datatracker.ietf.org/doc/html/rfc6749 >=20 > IMO, from a security aspect, the current behaviour is much more secure bec= ause it is designed to maintain the principle of least privilege, where it u= pdates the refresh token authorised scopes based on the requested ones. >=20 > What should be the correct behaviour? > narrow-down scope refresh token should also be able to request access toke= n 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= --Apple-Mail-4510206D-DEA6-4DF2-B8E5-7E86DB46753B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 20 Feb 2024, at 06:44, S= achin Mamoru <sachinmamoru@gmail.com> wrote:

=EF=BB=BF
Hi All= ,

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

Then wi= ll receive a refresh token (refresh_token1) with the access token.


After that will request another access token w= ith refresh_token1 and provide the scope list as scope1 and scope2 (Narrow d= own scopes).

Similarly, get another refresh token (refresh_token2) with the acce= ss token.


Now if we request another a= ccess 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 r= elated to narrow-down scopes with refresh token.


=46rom Spec


1.5.  Refresh Token - Refresh tokens are issued to th= e 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 additio= nal access tokens with identical or narrower scope (access tokens may have a s= horter lifetime and fewer permissions than authorized by the resource owner).


6.  Refreshing an Access Token

The sc= ope of the access request as described by Section 3.3.  The requested sco= pe MUST NOT include any scope not originally granted by the resource owner, an= d if omitted is treated as equal to the scope originally granted by the <= /span>resource= owner.


https://datatracker.ietf.org/doc/html/rfc6749


IMO, from a security aspect, the current behaviour is much more s= ecure because it is designed to maintain the principle of least privilege, w= here it updates the refresh token authorised scopes based on the requested o= nes.


What should be the correct behaviour?
narrow-down scop= e refresh token should also be able to request access token with original sc= ope list?

<= /blockquote>

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 Nei=
l
= --Apple-Mail-4510206D-DEA6-4DF2-B8E5-7E86DB46753B--