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

Denis <denis.ietf@free.fr> Wed, 03 June 2020 16:13 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 428B53A0797 for <oauth@ietfa.amsl.com>; Wed, 3 Jun 2020 09:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level:
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, 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 YVLG6IN-OMo4 for <oauth@ietfa.amsl.com>; Wed, 3 Jun 2020 09:13:05 -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 8FF193A0788 for <oauth@ietf.org>; Wed, 3 Jun 2020 09:13:04 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d86 with ME id mgD12200A4FMSmm03gD12t; Wed, 03 Jun 2020 18:13:02 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 03 Jun 2020 18:13:02 +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> <e835def4-9688-112f-eadc-f645a303fa40@free.fr> <20200530205522.GV58497@kduck.mit.edu> <0c2a52b0-f05b-38c6-6e37-7aacd6c98a24@free.fr> <20200603042324.GS58497@mit.edu>
From: Denis <denis.ietf@free.fr>
Message-ID: <01860781-023a-9bba-64e5-774468586edd@free.fr>
Date: Wed, 3 Jun 2020 18:13:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <20200603042324.GS58497@mit.edu>
Content-Type: multipart/alternative; boundary="------------56F302F7D8D8ADB0237B18A7"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZDIokfqm-f1fMqLpUcZPZkaSbOQ>
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: Wed, 03 Jun 2020 16:13:07 -0000

Hi Benjamin,

My responses are between the lines.

> Hi Denis,
>
> On Tue, Jun 02, 2020 at 10:20:36AM +0200, Denis wrote:
>> Hi Benjamin,
>>
>> Responses are between the lines.
>>
>>> 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.
>> Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it
>> means that potentially other Profiles could be defined in the future.
>> In the request, there is no parameter for a client to indicate that it
>> wants a JWT conformant to _this_ profile and no parameter either
>> in the response to indicate to the client that it got a JWT that is
>> conformant to _this_ profile.
> I don't think my point came through clearly.  Right now, the AS and RS have
> to negotiate by some out-of-band means what token format and details to use
> for tokens issued by AS with RS in audience, and there is not a
> "well-known" description of how to use JWT to do so. The goal of this
> document is to simplify the out-of-band negotiation between AS and RS, so
> they can just say "use RFC NNNN" instead of having to specify a lot of
> details individually.

At this time, it is still unknown how a client can request a JWT 
conformant to /this/ profile,
i.e. I have not identified in the protocol a request parameter saying 
"use RFC NNNN".

> Nowhere does the client come into the current negotiation of what token format to use,
> and the act of specifying a profile of JWT for this usage does not create a requirement
> for the client to be included in the negotiation.

It is not a "negotiation" where one party proposes a set of choices and 
the other party selects one of these choices,
it is supposed to be a protocol where the client is saying "please 
provide me a token compliant with RFC NNNN".
Unfortunately, the current protocol description does not allow to do so.

> Now, whether or not to include the client in this negotiation (and whether
> or not to make the choice of token format finer-grained) may be a topic
> worth discussion in its own right, but that discussion is untethered from
> specifying a profile of JWT to simplify AS/RS negotiations.

Agreed. It is not a matter for this working draft which may be discussed 
using a separate thread.

>
>> The processing mandated in the document of a request made by a client to
>> an AS only applies for a request conformant to this profile
>> which may or may not include a scope parameter and which may or may not
>> include a "resource" parameter (and, if it does not, shall
>> include an "aud" claim). Currently, it is not possible to make a
>> difference between a JWT request or response conformant to this profile
>> and other JWT requests or responses.
> I don't see where this document places constraints on a "conformant
> request" made by a client; could you point that out to me?
>
> (FWIW, the section heading for section 3 seems needlessly confusing, as the
> contents of the section do not seem to say anything about specifically
> requesting a JWT token.  I can see how this heading might cause some
> confusion.)

This is the core of the discussion: the current protocol description 
does not
allow a client to say: "Please provide me a token compliant with RFC NNNN".

>
>>> 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.
>> An explicit JWT type value added both in the JWT request and in the JWT
>> response would solve this problem.
> An explicit JWT type is a solution to the problme I'm interested in, yes.
> Though I don't know if that's what you mean by "this problem".

  The problem that still needs to be solved is a way for a client to be 
able to state:
"Please provide me a token compliant with RFC NNNN".

>
>>>> 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.
>> Once again, an explicit "typ" sould be considered for both the JWT
>> request and the JWT response. This implies that the client "MUST" be
>> able to inspect the content of the access token.
> As above, I do not see how the client currently has input into the token
> type/format agreed upon by the AS/RS out-of-band, so I dispute both the
> premise and the supposed conclusion.

Since the token format negotiation is out-of-band (i.e. it is not 
specified in the current RFCs
or in drafts in preparation) all assumptions can be made of the way(s) a 
RS makes available
the token formats it supports. Without knowing anything about which 
token formats are
being supported, the client may attempt to ask: "Please provide me a 
token compliant with
RFC NNNN". This will fail or succeed. So the client does not need to 
have any knowledge
about the token type/format agreed upon by the AS/RS out-of-band.

Denis

> -Ben