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

Denis <denis.ietf@free.fr> Fri, 22 May 2020 09:37 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 312643A0B37 for <oauth@ietfa.amsl.com>; Fri, 22 May 2020 02:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level:
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 VbnveuoplrxO for <oauth@ietfa.amsl.com>; Fri, 22 May 2020 02:37:32 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8101F3A0ABD for <oauth@ietf.org>; Fri, 22 May 2020 02:37:30 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d74 with ME id hldT220074FMSmm03ldTn7; Fri, 22 May 2020 11:37:28 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 22 May 2020 11:37:28 +0200
X-ME-IP: 86.238.65.197
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: oauth@ietf.org, Vittorio Bertocci <vittorio.bertocci@auth0.com>
References: <CADNypP8t4oVUpoqOFhb-Aft-5C4Z2F9O2vBxh6QxmkHrWkN_gw@mail.gmail.com> <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> <20200521200735.GL58497@kduck.mit.edu>
From: Denis <denis.ietf@free.fr>
Message-ID: <e835def4-9688-112f-eadc-f645a303fa40@free.fr>
Date: Fri, 22 May 2020 11:37:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200521200735.GL58497@kduck.mit.edu>
Content-Type: multipart/alternative; boundary="------------2DAAA3147719CAD194796CD5"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/u_clLBNxNuICD6XNvQ4ZvNQfo98>
Subject: Re: [OAUTH-WG] 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: Fri, 22 May 2020 09:37:42 -0000

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.

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 ?

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?

Denis

> To my knowledge, this WG has not previously given guidance
> indicating that the client should be involved or specifics for how to do
> so, and I do not remember seeing WG agreement that this should change.
>
> -Ben