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

Benjamin Kaduk <> Sat, 30 May 2020 20:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E53F83A09C8 for <>; Sat, 30 May 2020 13:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VB0UhBnnR7uA for <>; Sat, 30 May 2020 13:55:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 839083A09C0 for <>; Sat, 30 May 2020 13:55:29 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 04UKtMJ8023463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 May 2020 16:55:24 -0400
Date: Sat, 30 May 2020 13:55:22 -0700
From: Benjamin Kaduk <>
To: Denis <>
Cc:, Vittorio Bertocci <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [OAUTH-WG] 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: Sat, 30 May 2020 20:55:31 -0000

On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
> Hi Benjamin,
> > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
> >> Since then, I questioned myself how a client would be able to request an
> >> access token that would be
> >> *strictly compliant with this Profile*.
> > I don't understand why this is an interesting question to ask.  The access
> > token and interpretation thereof is (AIUI) generally seen as an internal
> > matter between AS and RS, with the client having no need to care about the
> > specifics.
> This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not 
> _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.

Sure.  But (in my understanding), in common usage, the contents and
interpretation of the access token is set by common agreement between AS
and RS, with the client serving only as a "dumb" channel for transporting
the token.  That is, we're providing a token format that an RS and AS can
agree to use, most likely for all tokens issued by the AS for that RS.  I
don't know of any existing mechanisms, or desire for such mechanisms by
deployments, for using a different token format for different tokens issued
by a given AS for a given RS.  Attempting to have the client provide input
that would affect such a mechanism seems like complexity with no market
demand; a "solution in search of a problem" as it were.  Is there some
pent-up demand among OAuth deployments that I'm not aware of?  I freely
admit to not being very on top of the broad spectrum of what's deployed...

> 1) A client may wish to obtain an Access Token that corresponds to this 
> Profile because, for example,
> this document mandates the "sub" claim to be present". Hence, the 
> content of the Access Token is not
> totally "/an internal matter between AS and RS/".
> However, I have not understood how a client could request an Access 
> Token that corresponds to *_this_***Profile,
> since there is no mandatory parameter in the request (both the "scope" 
> parameter and the "resource" parameter are optional).
> In the future, we could define _*another*_**Profile. Hence, there is the 
> same question:  How could a client request an Access Token
> that corresponds to *_that other_***Profile ?
> 2) When getting a JWT,  how can the client make sure that the access 
> token it got is compliant with this Profile ?
> RFC 8725 states in section 3.11 :
>     3.11. Use Explicit Typing
>     Sometimes, one kind of JWT can be confused for another. If a
>     particular kind of JWT is subject to such confusion,
>     that JWT can include an explicit JWT type value, and the validation
>     rules can specify checking the type (...).
>     Explicit JWT typing is accomplished by using the "typ" Header
>     Parameter.
> Wouldn't be wise to include an explicit JWT type value for JWTs 
> conformant to this Profile ?

In the model where the client is a "dumb" communications channel, this
question does not seem interesting.  But the related question of "how can
the RS make sure that the access token it got was generated according to
this profile?" does seem interesting, and seems like it would benefit from
the same proposed solution.

> This relates to an email posted by Dominick Baier under the topic "JAR: 
> JWT typ" on May 19 :
>     This has been brought up before - but no response.
>     Either I can’t find it - or it is missing. But is the setting the
>     JWT typ explicitly mentioned somewhere?

It is fairly likely that I will remember to ask about explicit "typ" usage
if I'm still on the IESG when this document gets there: I think I've been
making a habit of doing so.