Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 8 Apr 2019 17:07:17 +0000

Hi all,

this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'  document following the positive feedback at the last IETF meeting in Prague.

Here is the document:
https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00

Please let us know by April 22nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Rifaat

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.

---

From: Filip Skokan <[email-masked]>
Date: Mon, 8 Apr 2019 19:24:28 +0200

I support the draft's adoption.

Best,
*Filip Skokan*

On Mon, 8 Apr 2019 at 19:07, Hannes Tschofenig <[email-masked]>
wrote:

> Hi all,
>
> this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'
> document following the positive feedback at the last IETF meeting in Prague.
>
> Here is the document:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Apr 2019 19:34:18 +0200

I agree this should be adopted as a working group document.

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 8 Apr 2019 19:38:22 +0200

+1

Hans.

On Mon, Apr 8, 2019, 19:34 John Bradley <[email-masked]> wrote:

> > this is the call for adoption of the 'JWT Usage in OAuth2 Access
> Tokens'  document following the positive feedback at the last IETF meeting
> in Prague.
> >
> > Here is the document:

---

From: George Fletcher <[email-masked]>
Date: Mon, 8 Apr 2019 14:11:26 -0400

+1 for me as well :)

On 4/8/19 1:38 PM, Hans Zandbelt wrote:
> +1
>
> Hans.
>
> On Mon, Apr 8, 2019, 19:34 John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Tokens'?? document following the positive feedback at the last IETF
>     meeting in Prague.
>     >
>     > Here is the document:
>     > 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.
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: William Denniss <[email-masked]>
Date: Mon, 8 Apr 2019 11:20:54 -0700

I support adoption of this draft as a working group document.

On Mon, Apr 8, 2019 at 11:11 AM George Fletcher <gffletch=
[email-masked]> wrote:

>> Tokens'?? document following the positive feedback at the last IETF meeting
>> in Prague.
>> >
>> > Here is the document:
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Dominick Baier <[email-masked]>
Date: Mon, 8 Apr 2019 21:44:51 -0700

+1

———
Dominick

On 8. April 2019 at 20:21:21, William Denniss (
wdenniss=[email-masked]) wrote:

On Mon, Apr 8, 2019 at 11:11 AM George Fletcher <gffletch=
[email-masked]> wrote:

> OAuth mailing [email-masked]://www.ietf..org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>

---

From: Scott Brady <[email-masked]>
Date: Tue, 9 Apr 2019 08:40:36 +0100

+1

On Tue, Apr 9, 2019 at 5:45 AM Dominick Baier <[email-masked]>
wrote:

>> OAuth mailing [email-masked]://www.ietf...org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>

-- 
Thanks,

Scott Brady
scottbrady91.com <https://www.scottbrady91.com>

---

From: Neil Madden <[email-masked]>
Date: Tue, 9 Apr 2019 09:43:07 +0100

I support adoption of this draft.

— Neil

> On 8 Apr 2019, at 18:07, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Lars Wilhelmsen <[email-masked]>
Date: Wed, 10 Apr 2019 06:48:16 +0000

+1

Lars Wilhelmsen
Thales

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Neil Madden
Sent: tirsdag 9. april 2019 10:43
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

— Neil

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 10 Apr 2019 11:12:21 +0000

I support adoption of this draft as a working group document with the following caveats:

1. These are not to be used as ID Tokens/authentication tokens 
2. The privacy issues must be addressed 
3. Needs to be extensible, much like ID-Token, can't be 100% fixed 

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Monday, April 8, 2019 10:07 AM
To: [email-masked]
Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

Hi all,

Here is the document:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&amp;sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&amp;reserved=0

Please let us know by April 22nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group.

Ciao
Hannes & Rifaat

_______________________________________________
OAuth mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&amp;sdata=zcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&amp;reserved=0

---

From: n-sakimura <[email-masked]>
Date: Wed, 10 Apr 2019 13:41:19 +0000

+1 

For that matter, explicit typing is good and I am a bit ambivalent on the use of `sub`. 

Also, I need to add the 4th consideration: Although the current privacy consideration is stating about the encryption, it is in relation to the end user exposure. In fact, the by-value access token when involving some PII is by definition leaking information and violating the data minimization principle. This should be clearly delineated. My gut feeling is that it should be encrypted unless it is certain that it does not include sensitive PII as judging whether a claim may form a PII is too hard for an average developer. 

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Anthony Nadalin
Sent: Wednesday, April 10, 2019 8:12 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

1. These are not to be used as ID Tokens/authentication tokens 2. The privacy issues must be addressed 3. Needs to be extensible, much like ID-Token, can't be 100% fixed 

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Monday, April 8, 2019 10:07 AM
To: [email-masked]
Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

Hi all,

Here is the document:

Ciao
Hannes & Rifaat

---

From: Dick Hardt <[email-masked]>
Date: Wed, 10 Apr 2019 12:41:55 -0700

+1

---

From: Pedro Igor Silva <[email-masked]>
Date: Wed, 10 Apr 2019 17:38:51 -0300

+1 plus Anthony's caveats.

The draft seems to provide a good reference for implementors by providing
how different ASes are using JWT as the access token format. As well as
providing valuable information about validation and security considerations.

Regards.
Pedro Igor

On Wed, Apr 10, 2019 at 8:12 AM Anthony Nadalin <tonynad=
[email-masked]> wrote:

> adoption of this document as a starting point for work in the OAuth working
> group.
>
> Ciao
> Hannes & Rifaat
>

---

From: Sascha Preibisch <[email-masked]>
Date: Wed, 10 Apr 2019 10:39:25 -0700

I am late in the game, but not too late I hope.

I would like to see 'aud' be the requesting client_id. For identifying the
the target resource, a 'resource' claim should be introduced. I am also
suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and the
validation process will show if it is an access_token or not.

Last but not least, 'aud' (as resource identifier) should not be required.
Requiring that, and the requested resource in the the token request, will
require existing clients to be updated. Introducing jwt access_token should
be transparent to clients.

Thanks,
Sascha

On Wed., Apr. 10, 2019, 06:41 n-sakimura, <[email-masked]> wrote:

> Also, I need to add the 4th consideration: Although the current privacy
> consideration is stating about the encryption, it is in relation to the end
> user exposure. In fact, the by-value access token when involving some PII
> is by definition leaking information and violating the data minimization
> principle. This should be clearly delineated. My gut feeling is that it
> should be encrypted unless it is certain that it does not include sensitive
> PII as judging whether a claim may form a PII is too hard for an average
> developer.
>
> 1. These are not to be used as ID Tokens/authentication tokens 2. The
> privacy issues must be addressed 3. Needs to be extensible, much like
> ID-Token, can't be 100% fixed
>
>

---

From: Dag Helge Østerhagen <[email-masked]>
Date: Fri, 12 Apr 2019 13:34:12 +0200

I agree on "I am also suggesting to not introduce 'typ: at+jwt'".

Both regarding practical considerations and RFC7519 (5.1):

"This is intended for use by the JWT application
when values that are not JWTs could also be present in an application
data structure that can contain a JWT object; the application can use
this value to disambiguate among the different kinds of objects that
might be present.  It will typically not be used by applications when

it is already known that the object is a JWT"

Introducing the "+"-pattern for typ will probably lead to unintended usage
in the future.

/dag

tor. 11. apr. 2019 kl. 19:56 skrev Sascha Preibisch <
[email-masked]>:

> On Wed., Apr. 10, 2019, 06:41 n-sakimura, <[email-masked]
> <n-sakimura@nri..co.jp>> wrote:
>
>> +1
>>
>> developer..

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Sat, 13 Apr 2019 16:29:27 +0000

> On 10. Apr 2019, at 19:39, Sascha Preibisch <[email-masked]> wrote:
> 
> I would like to see 'aud' be the requesting client_id. For identifying the the target resource, a 'resource' claim should be introduced. I am also suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and the validation process will show if it is an access_token or not.

"aud = client_id" would mean that, by definition, the JWT must not be presented to any other entity than the client. This makes only sense for the ID Token in OIDC I think.  OTOH, defining a JWT which can be presented by the client to the RS is the whole point of this draft.
Also, the reason why it makes sense to introduce a new type is that an OIDC ID Token _could_ be mistaken for an AT (which it isn't).
IMO it might even make sense to encourage the OIDC spec to change to jwt+id or something by extending the JWT spec.

I also support the adoption.

> 
> Last but not least, 'aud' (as resource identifier) should not be required. Requiring that, and the requested resource in the the token request, will require existing clients to be updated. Introducing jwt access_token should be transparent to clients.
> 
> Thanks,
> Sascha
> 
> 
> Also, I need to add the 4th consideration: Although the current privacy consideration is stating about the encryption, it is in relation to the end user exposure. In fact, the by-value access token when involving some PII is by definition leaking information and violating the data minimization principle. This should be clearly delineated. My gut feeling is that it should be encrypted unless it is certain that it does not include sensitive PII as judging whether a claim may form a PII is too hard for an average developer..
> 

Martin Schanzenbach
Fraunhofer AISEC
Department Service & Application Security
Parkring 4, 85748 Garching near Munich (Germany)
Tel: +49 89 3229986-193
[email-masked]
GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0

---

From: Sascha Preibisch <[email-masked]>
Date: Mon, 15 Apr 2019 09:20:20 -0700

Thanks, Martin!

I understand. I just think it is difficult to get this adopted if
clients now have to include the target resource in their request in
order to place that into the 'aud' field. Unless the client has
somehow registered its intended protected resources beforehand the
authorization server cannot set an appropriate value if it was not
passed in as a request parameter.

Thanks,
Sascha

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Tue, 16 Apr 2019 08:13:26 +0000

> On 15. Apr 2019, at 18:20, Sascha Preibisch <[email-masked]> wrote:
> 
> Thanks, Martin!
> 

Yes, I think this is how it was supposed to work anyway even without JWTs. The client uses the "scope" parameter to indicate what it needs access to.
The AS needs to make a decision in accordance with the RO what access token to issue (i.e. which RS to grant access to).
The scope does not need to be the full RS URI. It is domain-specific what RSes a scope parameter maps to. Nothing the spec can do here, really.

BR
Martin

Martin Schanzenbach
Fraunhofer AISEC

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 22 Apr 2019 12:19:49 -0400

Thanks you all for your comments.

Based on this feedback, we think that there is good support for this to
become a WG document.

*Vittorio*,

Please, go ahead and submit a new WG draft.

Regards,
 Rifaat & Hannes

On Tue, Apr 16, 2019 at 4:13 AM Schanzenbach, Martin <
[email-masked]> wrote:

> Yes, I think this is how it was supposed to work anyway even without JWTs.
> The client uses the "scope" parameter to indicate what it needs access to.
> The AS needs to make a decision in accordance with the RO what access
> token to issue (i.e. which RS to grant access to).
> The scope does not need to be the full RS URI. It is domain-specific what
> RSes a scope parameter maps to. Nothing the spec can do here, really.
>
> BR
> Martin
>
> >
> > Thanks,
> > Sascha
> >
> >>> I would like to see 'aud' be the requesting client_id. For identifying
> the the target resource, a 'resource' claim should be introduced. I am also
> >> "aud = client_id" would mean that, by definition, the JWT must not be
> presented to any other entity than the client. This makes only sense for
> the ID Token in OIDC I think.  OTOH, defining a JWT which can be presented
> by the client to the RS is the whole point of this draft.
> >> Also, the reason why it makes sense to introduce a new type is that an
> OIDC ID Token _could_ be mistaken for an AT (which it isn't).
> >> IMO it might even make sense to encourage the OIDC spec to change to
> jwt+id or something by extending the JWT spec.
> >>
> >>> Last but not least, 'aud' (as resource identifier) should not be
> required. Requiring that, and the requested resource in the the token
> request, will require existing clients to be updated. Introducing jwt
> access_token should be transparent to clients.
> >>>
> >>> Thanks,
> >>> Sascha
> >>>
> >>>
> >>> Also, I need to add the 4th consideration: Although the current
> privacy consideration is stating about the encryption, it is in relation to
> the end user exposure. In fact, the by-value access token when involving
> some PII is by definition leaking information and violating the data
> minimization principle. This should be clearly delineated. My gut feeling
> is that it should be encrypted unless it is certain that it does not
> include sensitive PII as judging whether a claim may form a PII is too hard
> for an average developer..
> >>>