Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Denis <> Tue, 12 May 2020 09:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54D183A0D49 for <>; Tue, 12 May 2020 02:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.496
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tDT-G8wo8fxL for <>; Tue, 12 May 2020 02:54:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92CF83A0D44 for <>; Tue, 12 May 2020 02:54:58 -0700 (PDT)
Received: from [] ([]) by mwinf5d87 with ME id dlut2200e4FMSmm03luugn; Tue, 12 May 2020 11:54:56 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 12 May 2020 11:54:56 +0200
To: Vittorio Bertocci <>
Cc: Jared Jennings <>, Benjamin Kaduk <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Denis <>
Message-ID: <>
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: <>
Content-Type: multipart/alternative; boundary="------------BF59C457E797090FEDF33352"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


> 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 <>
> *Date: *Monday, May 11, 2020 at 20:14
> *To: *Vittorio Bertocci <>
> *Cc: *Denis <>fr>, Benjamin Kaduk <>du>, 
> "" <>
> *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
>     < <>>
>     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.