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

[Denis <[e-mail]>]

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