Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Denis <denis.ietf@free.fr> Tue, 12 May 2020 12:40 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 6B8573A0885 for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 05:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.496
X-Spam-Level:
X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 Upcv_gb8vYTb for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 05:40:33 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C313A0864 for <oauth@ietf.org>; Tue, 12 May 2020 05:40:32 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d69 with ME id dogS2200G4FMSmm03ogTVR; Tue, 12 May 2020 14:40:31 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 12 May 2020 14:40:31 +0200
X-ME-IP: 86.238.65.197
To: "Manger, James" <James.H.Manger@team.telstra.com>, Vittorio Bertocci <vittorio.bertocci@auth0.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
References: <CAGL6epKuHTqLrZEjm0goKV+3jaPfTkN_JSLc0jfQyPqNzeP3aA@mail.gmail.com> <125f32d3-dd3b-3add-1172-391acd831cde@free.fr> <MWHPR19MB150159025ECBAD75B6DDE1DFAEAD0@MWHPR19MB1501.namprd19.prod.outlook.com> <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr> <CAMVRk+Ln4xo_3pC6ALf0rp3+7gHyvO1zV=+NsA2pW4AZJ=1JAw@mail.gmail.com> <MWHPR19MB1501B1F305C170BCA0FD01F6AEBE0@MWHPR19MB1501.namprd19.prod.outlook.com> <CA4B872F-C0A1-4011-9221-B27CB45C41AB@gmail.com> <MWHPR19MB15018666981170A2DAA7B0D7AEBE0@MWHPR19MB1501.namprd19.prod.outlook.com> <0c7942f8-f94b-f0a9-cec1-cfa9803d4db6@free.fr> <MEXPR01MB1702E09FD7E18BF36B05A05DE5BE0@MEXPR01MB1702.ausprd01.prod.outlook.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <c8f80b73-3713-afd6-f5ec-5b604c3c72cf@free.fr>
Date: Tue, 12 May 2020 14:40:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <MEXPR01MB1702E09FD7E18BF36B05A05DE5BE0@MEXPR01MB1702.ausprd01.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------95A2BBF890C1FC5129153040"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1InFhgTzyK9b2Y93zCaO8yHUI98>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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: Tue, 12 May 2020 12:40:35 -0000
Hi James, You wrote: "Because your client has violated a MUST in the best practices". It seems that you are already taking your wish as granted. However, this is exactly the point we are discussing. You wrote: "The end-user has to trust the Authorization Server (they sign-in there)". The end-user does not trust the AS for everything, but only with respect to some activities. Please remember a definition of trust present in ISO/IEC 13888-1. 3.59. trust : relationship between two elements, a set of activities and a security policy in which element x trusts element y if and only if x has confidence that y will behave in a well defined way (with respect to the activities) that does not violate the given security policy. You wrote: "The access-token might be a JWT with minimal claims". Yes indeed, however the end-user may not know it. You wrote "a client to do that inspection as standard behaviour". No, token inspection is not a standard behaviour. It happens if, and only if, the end-user has some privacy concerns. Please reconsider the text proposal which does make that point: There are however cases, where the access token content presents privacy issues for a given scenario. In such cases, the end-user would like to know which attributes have been placed in a token before forwarding it to a resource server. If these attributes do not correspond to the expectations of the end-user or if the format of the access token is not understandable by the client, then the client SHOULD NOT forward the access token to the resource server. Denis > That text is an poor suggestion, Denis. > > > end-user will usually have no knowledge of the attributes which > correspond to the scope > > The OAuth model is that the Authorization Server is responsible for > informing the end-user about what is going on. That’s why they display > consent pages showing what will be disclosed, often giving the > end-user control over this. > > > the *end-user* would like to know which attributes have been placed in a > token … > > > … if the format of the access token is not understandable by the *client*, then the client SHOULD NOT forward > > A major point of OAuth is to protect end-users from clients. The > end-user has to trust the Authorization Server (they sign-in there), > but that can lessen the trust required in clients. > > A client that inspects an access-token in the hope of preventing an > Authorization Server from disclosing too much to a Resource Server is > kidding itself (and kidding the end-user). The access-token might be a > JWT with minimal claims, then the RS calls the AS’s token-inspection > API and gets back squillions of claims. > > So, by all means, do some auditing of Authorization Servers, Resource > Servers, and the tokens they exchange to improve your confidence that > they are behaving as they say. But if you write a client to do that > inspection as standard behaviour then don’t call it OAuth-compliant. > It will break when the Authorization Server choses to change its token > format. Because your client has violated a MUST in the best practices > it will be clear where the responsibility for broken interop lies. And > the rest of the ecosystem can hope that such clients are not prevalent > enough to harm ongoing evolution of the rest of the system. > > -- > > James Manger > > *From:*OAuth <oauth-bounces@ietf.org> *On Behalf Of *Denis > *Sent:* Tuesday, 12 May 2020 7:55 PM > *To:* Vittorio Bertocci <vittorio.bertocci@auth0.com> > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile > for OAuth 2.0 Access Tokens" > > … > > This being stated, hereafter is a full text proposal replacement for > the first paragraph (12 lines) > of the Privacy Considerations section (section 6): > > As indicated in RFC 6750, the "scope" value is intended for > programmatic use and is not meant to be displayed to end-users. > This means that, even when the client uses the scope parameter, the > end-user will usually have no knowledge of the attributes > which correspond to the scope (or to a missing scope parameter). > > RFC 6749 mentions that the string [access token] is usually opaque > to the client. Hence, the client will not necessarily be able > to inspect the content of the access token. As an example, an > authorization server and a resource server might decide to change > the access token format at any time. > > There are however cases, where the access token content presents > privacy issues for a given scenario. In such cases, > the end-user would like to know which attributes have been placed > in a token before forwarding it to a resource server. > If these attributes do not correspond to the expectations of the > end-user or if the format of the access token is not understandable > by the client, then the client SHOULD NOT forward the access token > to the resource server. > > Denis >
- [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) P… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Dominick Baier
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Aaron Parecki
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Brian Campbell
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Aaron Parecki
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Brian Campbell
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… David Waite
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Dominick Baier
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Philippe De Ryck
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Dominick Baier
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… vittorio.bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… vittorio.bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… vittorio.bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Dominick Baier
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Dominick Baier
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Mike Jones
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Takahiko Kawasaki
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Takahiko Kawasaki
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Takahiko Kawasaki
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Benjamin Kaduk
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Brian Campbell
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Benjamin Kaduk
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Benjamin Kaduk
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Jared Jennings
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Jared Jennings
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Vittorio Bertocci
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Manger, James
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Manger, James
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Hannes Tschofenig
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Hannes Tschofenig
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Phillip Hunt
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis
- Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JW… Denis