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 >
- [OAUTH-WG] Murray Kucherawy's No Objection on dra… Murray Kucherawy via Datatracker
- Re: [OAUTH-WG] Murray Kucherawy's No Objection on… Vittorio Bertocci
- Re: [OAUTH-WG] Murray Kucherawy's No Objection on… Denis
- Re: [OAUTH-WG] Murray Kucherawy's No Objection on… vittorio.bertocci
- Re: [OAUTH-WG] Murray Kucherawy's No Objection on… Denis