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

[Steinar Noem]

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 <
rifaat.s.i...@gmail.com>:

> 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
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no |
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Denis]

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


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


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vittorio Bertocci]

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  wrote:

> 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
>
> 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
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Denis]

Hi Vittorio,

I raised the following question:

   In the future, if additional parameters are included in the request,
   will the "sub" claim necessarily be present in the access token ?

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

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 > wrote:


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


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


___
OAuth mailing list
OAuth@ietf.org  
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Benjamin Kaduk]

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Denis]

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



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Benjamin Kaduk]

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.

Thanks,

Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Janak Amarasena]

Hi all,

My apologies, if this was already discussed.

In section *4*. Validating JWT Access Tokens
 it
is stated;

The resource server MUST handle errors as described in section 3.1 of
   [RFC6750] .  In
particular, in case of any failure in the validation
   checks listed above the *authorization server* response MUST include
   the error code "invalid_token".




Should this be;

 above the *resource server* response MUST include the error code
"invalid_token".


If that is not the case, which kind of scenarios would occur for an AS to
respond with the error code "invalid_token"?

Best Regards,
Janak Amarasena

On Sun, May 31, 2020 at 2:25 AM Benjamin Kaduk  wrote:

> 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.
>
> Thanks,
>
> Ben
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Denis]

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.


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.

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.


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.


Denis


Thanks, Ben



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Benjamin Kaduk]

On Mon, Jun 01, 2020 at 10:06:22PM +0530, Janak Amarasena wrote:
> Hi all,
> 
> My apologies, if this was already discussed.
> 
> In section *4*. Validating JWT Access Tokens
>  
> it
> is stated;
> 
> The resource server MUST handle errors as described in section 3.1 of
>[RFC6750] .  In
> particular, in case of any failure in the validation
>checks listed above the *authorization server* response MUST include
>the error code "invalid_token".
> 
> 
> 
> 
> Should this be;
> 
> ... above the *resource server* response MUST include the error code
> "invalid_token".

It does look like it should be the resource server there, yes.
Good catch, and thanks for mentioning it!

-Ben

> 
> If that is not the case, which kind of scenarios would occur for an AS to
> respond with the error code "invalid_token"?
> 
> Best Regards,
> Janak Amarasena
> 
> On Sun, May 31, 2020 at 2:25 AM Benjamin Kaduk  wrote:
> 
> > 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.
> 

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

[Benjamin Kaduk]

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 " instead of having to specify a lot of
details individually.  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.

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.

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

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

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

[Denis]

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



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

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




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" p

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

[Vittorio Bertocci]

Hi Hannes,
Thank you! 
I am not aware of any IPR related to 
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/.

On 9/17/20, 05:48, "Hannes Tschofenig"  wrote:

Hi Vittorio,

I am working on the shepherd writeup for the "JSON Web Token (JWT) Profile 
for OAuth 2.0 Access Tokens" specification:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-08

One item in the template requires me to indicate whether each document 
author has confirmed that any and all appropriate IPR disclosures required for 
full conformance with the provisions of BCP 78 and BCP 79 have already been 
filed.

Could you please confirm?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth