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 09:55 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 54D183A0D49 for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 02:55:01 -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 tDT-G8wo8fxL for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 02:54:59 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CF83A0D44 for <oauth@ietf.org>; Tue, 12 May 2020 02:54:58 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d87 with ME id dlut2200e4FMSmm03luugn; Tue, 12 May 2020 11:54:56 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 12 May 2020 11:54:56 +0200
X-ME-IP: 86.238.65.197
To: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Cc: Jared Jennings <jaredljennings@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, "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>
From: Denis <denis.ietf@free.fr>
Message-ID: <0c7942f8-f94b-f0a9-cec1-cfa9803d4db6@free.fr>
Date: Tue, 12 May 2020 11:54:52 +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: <MWHPR19MB15018666981170A2DAA7B0D7AEBE0@MWHPR19MB1501.namprd19.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------BF59C457E797090FEDF33352"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/eXpZlsMG2a4PmUEp6yLmdCnCD18>
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 09:55:01 -0000
Hi Vittorio, draft-ietf-oauth-access-token-jwt states in section 2.2.2: This profile does not introduce any mechanism for a client to directly request the presence of specific claims in JWT access tokens, as the authorization server can determine what additional claims are required by a particular resource server by taking in consideration the client_id of the client, the scope and the resource parameters included in the request. RFC 6750 states in section 3 : (...) Use of the "scope" attribute is OPTIONAL. The "scope" value is intended for programmatic use and is not meant to be displayed to end-users. This has the following consequence: the end-user is usually not able to know which attributes correspond to a scope (or to a missing scope). The only way to know is to look at the content of the token and the reason for doing this may be related a privacy consideration. RFC 6749 states in section 1.4: "The string [access token] *is usually opaque* to the client". However, this sentence does not mean : "The client *MUST NOT* inspect the content of the access token". RFC 6749 does not contain a MUST, SHALL or SHOULD in the above quoted sentence. In such a situation, we should not be "more royalist than the King" Benjamin Kaduk wrote: "*I do in fact agree that token inspection by a client can be useful in at least some situations*". 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 > It’s not really an interop issue either, given that following or not > following this requirement doesn’t alter the shape of messages or > tokens. It’s more of an architectural requirement, which preserves the > relationships between the OAuth2 roles involved and prevents the > confusion that might arise by the availability of data that > characterizes this particular scenario, but that doesn’t change the > more general premises of the protocol. In terms of finding common > ground, I am not sure if visions as diametrically opposed as pitting a > MUST against a MUST NOT have much of an achievable common ground, > especially given that the MUST NOT stance already passed consensus in > the past year, and in more than one month of very public debate during > last calls, the MUST side had mostly one backer and more than one > opposed. > > *From: *Jared Jennings <jaredljennings@gmail.com> > *Date: *Monday, May 11, 2020 at 20:14 > *To: *Vittorio Bertocci <vittorio.bertocci@auth0.com> > *Cc: *Denis <denis.ietf@free.fr>, Benjamin Kaduk <kaduk@mit.edu>, > "oauth@ietf.org" <oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile > for OAuth 2.0 Access Tokens" > > Hi Vittorio, > > Yeah, this does make a bit of sense. So, the goal is to guide > implementors from making bad choices, not from a security perspective. > Meaning, it's not a security risk that a client does inspect or > analyze the token. Instead, it's is an interop issue and thus we are > guiding implementors to never assume or expect the token format to be > consistent or of a expected format, for various reasons. I kinda know > the answer to this question, but I am kinda asking this way to help > restate the intent of the "topic" and maybe help guide to a wording > that works for everyone. > > For example, as a consultant, it can be very helpful to know how to > decompile or inspect an "Object", but at the same time knowing that > such a method or practice should never be used in production. > > Jared > > > > On May 11, 2020, at 19:24, Vittorio Bertocci > <vittorio.bertocci@auth0.com <mailto:vittorio.bertocci@auth0.com>> > wrote: > > Real world scenarios are full of situations where additional > assumptions can lower dangers that must be taken in consideration > in the general case, which might make less of a risk going against > the spec/in those particular circumstances/, but their existence > doesn’t warrant relaxing guidance for the general case. A concrete > example: I worked on scenarios where resource servers wanted to > guarantee some degree of business continuity in case of AS outage, > which boiled down to RS’ willingness to accept ATs past their > declared expiration time, on the condition that the AS outage > condition was detectable and the staleness of the AT didn’t cross > a tolerance threshold. The business scenario made sense, and the > implementer was within their right in deciding that disregarding > exp in those circumstances was acceptable. Nonetheless, I would > not argue that given the existence of that scenario, rfc7519 > should turn its MUST NOT into a SHOULD NOT. >
- [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