Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

Denis <denis.ietf@free.fr> Wed, 14 April 2021 15:39 UTC

Return-Path: <denis.ietf@free.fr>
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 ED58B3A13D2 for <oauth@ietfa.amsl.com>; Wed, 14 Apr 2021 08:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHxHB9tOHTOH for <oauth@ietfa.amsl.com>; Wed, 14 Apr 2021 08:39:22 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr [80.12.242.123]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141533A13DE for <oauth@ietf.org>; Wed, 14 Apr 2021 08:39:21 -0700 (PDT)
Received: from [192.168.1.11] ([90.26.9.133]) by mwinf5d77 with ME id sffH2400v2sDAeJ03ffJLw; Wed, 14 Apr 2021 17:39:20 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 14 Apr 2021 17:39:20 +0200
X-ME-IP: 90.26.9.133
To: vittorio.bertocci@auth0.com, 'Vittorio Bertocci' <vittorio.bertocci=40auth0.com@dmarc.ietf.org>, 'Murray Kucherawy' <superuser@gmail.com>, 'The IESG' <iesg@ietf.org>
Cc: draft-ietf-oauth-access-token-jwt@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org
References: <161786294101.28888.16150454715315694485@ietfa.amsl.com> <CO6PR18MB4052516F8420BBF956A5992FAE4E9@CO6PR18MB4052.namprd18.prod.outlook.com> <b837264b-6fba-f77c-c288-5b3e3c1a2214@free.fr> <00b301d73142$128aae40$37a00ac0$@auth0.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <ac0c4fb6-a0c8-70bb-3047-553fd6648aba@free.fr>
Date: Wed, 14 Apr 2021 17:39:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <00b301d73142$128aae40$37a00ac0$@auth0.com>
Content-Type: multipart/alternative; boundary="------------D139FA4AE264743A00A11C6C"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/8uZIgut6eSgqWibXb5Jfy4G_Re0>
Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Apr 2021 15:39:27 -0000

Hi Vittorio,

Since Murray raised the concern, I have responded. A *guidance *section 
should not contain any *MUST*, *SHALL*, *MUST *or *SHALL NOT.*
I believe that my proposal is a fair compromise on this topic by keeping 
all the sentences, except the first half of the second paragraph
of Section 6, as noticed by Murray.

Denis

> Hi Denis, this aspect was debated at length (one example in 
> https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/ 
> <https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/>, 
> there are many others) and the consensus reflected in the current text 
> was clear.
>
> *From:* Denis <denis.ietf@free.fr>
> *Sent:* Wednesday, April 14, 2021 1:19 AM
> *To:* Vittorio Bertocci 
> <vittorio.bertocci=40auth0.com@dmarc.ietf.org>; Murray Kucherawy 
> <superuser@gmail.com>; The IESG <iesg@ietf.org>
> *Cc:* draft-ietf-oauth-access-token-jwt@ietf.org; 
> oauth-chairs@ietf.org; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Murray Kucherawy's No Objection on 
> draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
>
> Hi Murray,
>
> Thank you for your comments. I come back on one of your comments 
> (while other comments and Vittorio's responses are deleted):
>
>        The first half of the second paragraph of Section 6 seems much
>     more like an
>
>        interoperability issue than a privacy issue to me.
>
> I agree that, taken in isolation, the connection to privacy of that 
> aspect is not immediately self-evident.
> I would argue it is not about interop either, given that noncompliance 
> with *the guidance given there* doesn’t
> impact what's transmitted. Nonetheless, I believe the privacy section 
> is the closest match we have *for that *
> *guidance*, given its many touch points to privacy matters (the ability of a 
> client to inspect ATs is a privacy
> concern; the decision to use a JWT ATs, which ultimately makes 
> spelling out *the guidance* necessary, is influenced
> by privacy considerations; and so on and so forth). In sum, although I 
> agree it's not a perfect fit, I think
> that's the best fit we have; and given that consolidating consensus 
> for that part has been particularly painful,
> I am inclined to leave that part as is.
>
> The second paragraph of Section 6 (Privacy Considerations) is as follows:
>
> The client *MUST NOT* inspect the content of the access token: the
>    authorization server and the resource server might decide to change
>    token format at any time (for example by switching from this profile
>    to opaque tokens) hence any logic in the client relying on the
>    ability to read the access token content would break without
>    recourse. /The OAuth 2.0 framework assumes that access tokens are
>    treated as opaque by clients./  Administrators of authorization
>    servers should also take into account that the content of an access
>    token is visible to the client.  Whenever client access to the access
>    token content presents privacy issues for a given scenario, the
>    authorization server should take explicit steps to prevent it.
>
> As soon as there is a *MUST NOT*, this is not a *guidance *any more.
>
> Some words of this paragraph, i.e. "/any logic in the client relying 
> on the *ability *to read the access token content/" simply recognize that
> the client *is able to inspect the content of the access token*, but 
> if it does it this is at its own risk since "/the resource server 
> might decide
> to change token format at any time (for example by switching from this 
> profile to opaque tokens)/".
>
> The second paragraph may be rewritten by placing in front of it an 
> important sentence that comes later on in this paragraph:
>
>     The OAuth 2.0 framework assumes that access tokens are treated as
>     opaque by clients.
>
> Then after, the first sentence that includes the *MUST NOT* can be 
> removed and the current text can be re-used after it, by shuffling the 
> order
> of the remaining sentences.
>
> The end result would be the following:
>
>   The OAuth 2.0 framework assumes that access tokens are treated as 
> opaque by clients.
>   Administrators of authorization servers should take into account 
> that the content
>   of an access token is visible to the client. The authorization 
> server and the resource
>   server might decide to change token format at any time (for example 
> by switching from
>   this profile to opaque tokens) hence any logic in the client relying 
> on the ability to read
>   the access token content would break without recourse. Whenever 
> client access to the access
>   token content presents privacy issues for a given scenario, the 
> authorization server should
>   take explicit steps to prevent it.
>
> The key benefits are the following: the *guidance *is still there, but 
> the sentence with the "*MUST NOT*" has been removed.
>
> Denis
>