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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 13 May 2020 10:06:52 -0400

All,

Based on the 3rd WGLC, we believe that we have consensus to move this
document forward.
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/

We will be working on the shepherd write-up and then submit the document to
the IESG soon.

Regards,
 Rifaat & Hannes

---

From: Steinar Noem <[email-masked]>
Date: Wed, 13 May 2020 17:15:16 +0200

Sorry for coming late in the game, but I really think that the "sub" claim
should be OPTIONAL instead of REQUIRED.

We are implementing OAuth 2.0 for the Norwegian health sector, where we
have several resources in production already.
I don't think the "sub" claim should have different meaning depending on
the flow - we would prefer to omit the sub claim in cases where the
resource owner isn't present.
This is not possible with the current language. We would like to be able to
choose if and how we use the "sub" - the "client_id" claim will always be
present.

Regards
Steinar

ons. 13. mai 2020 kl. 16:07 skrev Rifaat Shekh-Yusef <
[email-masked]>:

> We will be working on the shepherd write-up and then submit the document
> to the IESG soon.
>
> Regards,
>  Rifaat & Hannes
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked] | [email-masked]  | +47 955 21 620 | www.udelt.no |

---

From: Denis <[email-masked]>
Date: Thu, 14 May 2020 16:29:43 +0200

The current version of this draft is 
"draft-ietf-oauth-access-token-jwt-07" issued on April the 27 th.

This means that comments sent later on on the list have not been 
incorporated in this draft.
In particular, this one sent on April the 28 th:

*1) *The title of this spec. is:

    JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

So, this spec. is supposed to be targeted to OAuth *2.0. *

However, the header at the top of the page omits to mention it.

Currently, it is :

    Internet-Draft       OAuth Access Token JWT Profile           April 2020

It should rather be:

    Internet-Draft       OAuth *2.0* Access Token JWT Profile April 2020

It has been acknowledged by Vittorio on April, the 29 th:

/> The title of this spec./

Fixed, thanks!

This means that the draft document currently available on the IETF 
server is not reflecting the agreed comments.

Since then, I questioned myself how a client would be able to request an 
access token that would be
*strictly compliant with this Profile*.

For doing this exercise, I took a look at section 3 on pages 6 to 8. To 
summarize my findings:

  * the request MAY include a "resource" parameter. If the request does
    not include a "resource" parameter,
    the authorization server MUST use in the "aud" claim a default
    resource indicator.
  * the request MAY include "scope" parameter. If a "scope" parameter is
    present in the request,
    the authorization server SHOULD use it to infer the value of the
    default resource indicator to be used in the "aud" claim.

It seems to mean that if the request includes no "resource" parameter 
and no "scope" parameter, the access token will necessarily
include the "sub" claim.

If in the request, there would be present a parameter meaning "I want a 
token compliant with *this OAuth 2.0 profile*",
then there would be no problem, but this is not the case.

In the future, if additional parameters are included in the request, 
will the "sub" claim necessarily be present in the access token ?
If yes, this may be a privacy concern.

On the list there have been requirements for not making the "sub" 
parameter mandatory.

This point needs to be addressed and solved one way or another.

Denis

> We will be working on the shepherd write-up and then submit the 
> document to the IESG soon.
>
> Regards,
>  Rifaat & Hannes
>
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 14 May 2020 07:54:57 -0700

Denis, the change you mentioned is basically a typo, which I did fix but
did not publish a new draft for- that doesn’t change the substance of the
consensus (and is something that will be fixed in the subsequent phases of
the process).
Whether the sub should be mandatory has been discussed for two reasons:

- as a way of distinguishing whether the token was obtained on behalf of a
user or an application identity, by omitting it in the latter case. We had
extensive discussions following IETF105 and concluded that not enough
people were interested in that scenario. I kept that discussion open for a
long time.
- for privacy concerns. Those has been debated and your position failed to
gather momentum.

Some of the recent discussions on sub didn’t pick up on the discussions
above and didn’t bring new arguments that weren’t already debated.
Nonetheless I did my best to provide context and pointer to the past
discussions when answering the concerns. In other words, those discussions
didn’t appear to change the consensus achieved on the matter. We have 3
last calls, I don’t think the chairs changed the status of the document
lightly.

On Thu, May 14, 2020 at 07:29 Denis <[email-masked]> wrote:

> *> The title of this spec.*
>
> Fixed, thanks!
>
> This means that the draft document currently available on the IETF server
> is not reflecting the agreed comments.
>
>    - the request MAY include a "resource" parameter. If the request does
>    - the request MAY include "scope" parameter. If a "scope" parameter is
>    present in the request,
> It seems to mean that if the request includes no "resource" parameter and
> no "scope" parameter, the access token will necessarily
> include the "sub" claim.
>
> In the future, if additional parameters are included in the request, will
> the "sub" claim necessarily be present in the access token ?
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Denis <[email-masked]>
Date: Thu, 14 May 2020 17:29:06 +0200

Hi Vittorio,

I raised the following question:

The answer to this question does not seem to be present in the draft. 
Would you be able to provide an answer ?

Denis

> Denis, the change you mentioned is basically a typo, which I did fix 
> but did not publish a new draft for- that doesn’t change the substance 
> of the consensus (and is something that will be fixed in the 
> subsequent phases of the process).
> - as a way of distinguishing whether the token was obtained on behalf 
> of a user or an application identity, by omitting it in the latter 
> case. We had extensive discussions following IETF105 and concluded 
> that not enough people were interested in that scenario. I kept that 
> discussion open for a long time.
> - for privacy concerns. Those has been debated and your position 
> failed to gather momentum.
>
> Some of the recent discussions on sub didn’t pick up on the 
> discussions above and didn’t bring new arguments that weren’t already 
> debated. Nonetheless I did my best to provide context and pointer to 
> the past discussions when answering the concerns. In other words, 
> those discussions didn’t appear to change the consensus achieved on 
> the matter. We have 3 last calls, I don’t think the chairs changed the 
> status of the document lightly.
>
>
>
> On Thu, May 14, 2020 at 07:29 Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Since then, I questioned myself how a client would be able to
>     request an access token that would be
>     For doing this exercise, I took a look at section 3 on pages 6 to
>     8. To summarize my findings:
>
>       * the request MAY include a "resource" parameter. If the request
>         does not include a "resource" parameter,
>       * the request MAY include "scope" parameter. If a "scope"
>         parameter is present in the request,
>         the authorization server SHOULD use it to infer the value of
>         the default resource indicator to be used in the "aud" claim.
>
>     It seems to mean that if the request includes no "resource"
>     parameter and no "scope" parameter, the access token will necessarily
>     include the "sub" claim.
>
>     If in the request, there would be present a parameter meaning "I
>     want a token compliant with *this OAuth 2.0 profile*",
>     In the future, if additional parameters are included in the
>     request, will the "sub" claim necessarily be present in the access
>     token ?
>>     Based on the 3rd WGLC, we believe that we have consensus to move
>>     this document forward.
>>     [email-masked]  <mailto:[email-masked]>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 May 2020 13:07:35 -0700

> *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.  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

---

From: Denis <[email-masked]>
Date: Fri, 22 May 2020 11:37:28 +0200

Hi Benjamin,
> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 30 May 2020 13:55:22 -0700

> _*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...

> 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.

>     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.

Thanks,

Ben