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.
>