From neil.e.madden@gmail.com Wed Feb 21 00:22:20 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 87AC8C151093 for ; Wed, 21 Feb 2024 00:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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_DNSWL_NONE=-0.0001, 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_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 PUJAQ1Hg_Z4u for ; Wed, 21 Feb 2024 00:22:16 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 B9F6AC151091 for ; Wed, 21 Feb 2024 00:22:16 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2d2579378c4so128181fa.1 for ; Wed, 21 Feb 2024 00:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708503735; x=1709108535; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=ugC1XPkl1w3Egkv3OSNAZ5Rx8Rd7LwI7dVrcjlLb5sk=; b=ddcA9728VbXOTnlZek6vuze0wWwJkLzy2PDXzEp2XnsoKDvYUaRweAR0BdSbxWW6gU xqpncY+xhf9i2oDPDspjezzdcRtZ42e6338qb/vXdS7KVJzIigi+iMYU7ZeYYS2tN3e4 ypoA1q5YwyHIwI2hP+/QP93+ojJs1SorHTE3eZNp2RnPgBwrGx4WXjznVjvQdcEbQ/Ug sK4z6M3/657AE19hmQBe4+++ggvhlPSDKgdr9rs2Ws9+JDPQnuAULq2Dz1OgfS6L5WwQ 1xD6CjB70+2EEt2zABBdhZ9X71c6vD3ozOcRWanF0CbO9cmlzMrnrCwpAHjW1NLlQ+tL FyeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708503735; x=1709108535; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ugC1XPkl1w3Egkv3OSNAZ5Rx8Rd7LwI7dVrcjlLb5sk=; b=cNVQnMqSg0m0IoZV2mDYT04HkSQQnJ31XJrX3IxBn7GObZlchKmPzZxUgpYeLduJPn dEd9dj+pML5rTwcbQtJFsqsrh8mmq0QPOSNawG8jt7jwyF9EOb5f+z3qPRChwNcl4v6K 6KP4G2Yw3j80YGPGNyoQLiLHAmUOEq4n/zwsq1ZyFbmPLaAtnpVXHokUe0UUqlgP7W5d wiJ2tuOIvTpd2wbkxBhu4BCEcQi+N/+5gQaSIY4enY6cf7mF0rkSp3MDmMrwpHUdqRRy bxYzonZXICl4wdsjdyMbh7lSpuNqXWqJkA7Pij98yeYGYUMvteDLTf1ThjvTqekmPVai x1Hg== X-Forwarded-Encrypted: i=1; AJvYcCWnuiRE36MLGIEai8MTW3dvWO8G+Xv1GJ+b4J5zT43V+sYHNvs0rDW84XsKuA86NOJJwfo9yG7hYM35gES91A== X-Gm-Message-State: AOJu0YwVbfE7TxBMLLU8vPNQJqR9MKu1vwqygRW7NSphTeE4rwQ05zDQ 6yqhmatBGRw3XvLZA+wvuAXENItWvC+a//sgnrgu0lwSeZISOTGULkk7WYGXhgU= X-Google-Smtp-Source: AGHT+IEcGxOOHgUeewgJUa56PHNwwY77zzfyDQCMzsHTvVSXnA64qwALObTnOLuVDK4Peu+rXyCQ4Q== X-Received: by 2002:a2e:96c2:0:b0:2d2:5097:f643 with SMTP id d2-20020a2e96c2000000b002d25097f643mr1470497ljj.4.1708503734469; Wed, 21 Feb 2024 00:22:14 -0800 (PST) Received: from smtpclient.apple ([213.31.127.136]) by smtp.gmail.com with ESMTPSA id bv9-20020a0560001f0900b0033b1277e95dsm16635683wrb.77.2024.02.21.00.22.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2024 00:22:14 -0800 (PST) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_03425108-E1D1-4646-B6AE-EFC9C847529D" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Date: Wed, 21 Feb 2024 08:22:13 +0000 In-Reply-To: Cc: wparad@rhosys.ch, oauth , janak@wso2.com, thilinasenarath97@gmail.com, "piraveena@wso2.com" To: Sachin Mamoru References: <374ADB2C-2F74-4B95-8CDA-3266089CD00C@gmail.com> <13C59DD4-94E0-47AC-9A7E-D7B463BD1552@gmail.com> X-Mailer: Apple Mail (2.3696.120.41.1.4) 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 08:22:20 -0000 --Apple-Mail=_03425108-E1D1-4646-B6AE-EFC9C847529D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 Feb 2024, at 08:06, Sachin Mamoru wrote: >=20 > Hi Warren and Neil, >=20 > Thanks for the valuable input and sorry for mentioning other products, = I just wanted to provide an example.=20 > So Warren according to you following is the behaviour that spec = suggested. >=20 > When we request an access token using 3 scopes (scope1, scope2, = scope3). >=20 > Then will receive a refresh token (refresh_token1) with the access = token. >=20 > After that will request another access token with refresh_token1 and = provide the scope list as scope1 and scope2 (Narrow down scopes). >=20 > Similarly, get another refresh token (refresh_token2) with the access = token. >=20 > 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. >=20 > 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 = 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= --Apple-Mail=_03425108-E1D1-4646-B6AE-EFC9C847529D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 21 Feb 2024, at 08:06, Sachin Mamoru <sachinmamoru@gmail.com> 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

   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
= --Apple-Mail=_03425108-E1D1-4646-B6AE-EFC9C847529D--