Subject: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

From: Vittorio Bertocci <[email-masked]>
Date: Sun, 24 Mar 2019 16:29:05 -0700

Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access
tokens. You can find it in
https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc
came to be. The trajectory it followed is somewhat unusual.

   - Despite OAuth2 not requiring any specific format for ATs, through the
   years I have come across multiple proprietary solution using JWT for their
   access token. The intent and scenarios addressed by those solutions are
   mostly the same across vendors, but the syntax and interpretations in the
   implementations are different enough to prevent developers from reusing
   code and skills when moving from product to product.
   - I asked several individuals from key products and services to share
   with me concrete examples of their JWT access tokens (THANK YOU Dominick
   Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
   (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
   I studied and compared all those instances, identifying commonalities
   and differences.
   - I put together a presentation summarizing my findings and suggesting a
   rough interoperable profile (slides:
   https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
   ) - got early feedback from Filip Skokan on it. Thx Filip!
   - The presentation was followed up by 1.5 hours of unconference
   discussion, which was incredibly valuable to get tight-loop feedback and
   incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
   Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and
   contributed generously to the discussion. Thank you!!!
   Note: if you were at OSW2019, participated in the discussion and didn't
   get credited in the draft, my apologies: please send me a note and I'll
   make things right at the next update.
   - On my flight back I did my best to incorporate all the ideas and
   feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
   Hannes and above all Brian were all super helpful in negotiating the
   mysterious syntax of the RFC format and submission process.

I was blown away by the availability, involvement and willingness to invest
time to get things right that everyone demonstrated in the process. This is
an amazing community.
V.

---

From: Nov Matake <[email-masked]>
Date: Mon, 25 Mar 2019 13:12:45 +0900

Hi Vittorio,

Thanks for the good starting point of standardizing JWT-ized AT.

One feedback.
The “sub” claim can include 2 types of identifier, end-user and client, in this spec.
It requires those 2 types of identifiers to be unique each other in the IdP context.

I prefer omitting “sub” claim in 2-legged context, so that no such constraint needed.

thanks

nov

> On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=[email-masked]> wrote:
> 
> Dear all,
> I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/ <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/>.
> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!
> 
> Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
> Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
> I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!). 
> I studied and compared all those instances, identifying commonalities and differences. 
> I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx> ) - got early feedback from Filip Skokan on it. Thx Filip!
> The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
> Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
> On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
> I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community. 
> V.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dominick Baier <[email-masked]>
Date: Mon, 25 Mar 2019 06:41:17 -0700

IMHO the sub claim should always refer to the user - and nothing else.

OIDC says:

"Subject - Identifier for the End-User at the Issuer."

client_id should be used to identify clients.

cheers
Dominick

On 25. March 2019 at 05:13:03, Nov Matake ([email-masked]) wrote:

Hi Vittorio,

One feedback.
The “sub” claim can include 2 types of identifier, end-user and client, in
this spec.
It requires those 2 types of identifiers to be unique each other in the IdP
context.

I prefer omitting “sub” claim in 2-legged context, so that no such
constraint needed.

thanks

nov

On Mar 25, 2019, at 8:29, Vittorio Bertocci <
vittorio.bertocci=[email-masked]> wrote:

Dear all,

   <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 25 Mar 2019 14:58:44 +0100

Without agreeing or disagreeing: OIDC does not apply here since it is not
OAuth and an access token is not an id_token.
The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:

"The "sub" (subject) claim identifies the principal that is the
   subject of the JWT.  The claims in a JWT are normally statements
   about the subject.  The subject value MUST either be scoped to be
   locally unique in the context of the issuer or be globally unique.
   The processing of this claim is generally application specific"

which kind of spells "client" in case of the client credentials grant but I
also do worry about Resource Servers thinking/acting only in terms of users

Hans.

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <[email-masked]>
wrote:

> On 25.. March 2019 at 05:13:03, Nov Matake ([email-masked]) wrote:
>
> Hi Vittorio,
>
>    - Despite OAuth2 not requiring any specific format for ATs, through
>    the years I have come across multiple proprietary solution using JWT for
>    their access token. The intent and scenarios addressed by those solutions
>    are mostly the same across vendors, but the syntax and interpretations in
>    the implementations are different enough to prevent developers from reusing
>    - I put together a presentation summarizing my findings and suggesting
>    a rough interoperable profile (slides:
>    Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>    and contributed generously to the discussion. Thank you!!!
>    Note: if you were at OSW2019, participated in the discussion and
>    didn't get credited in the draft, my apologies: please send me a note and
>    I'll make things right at the next update.
> I was blown away by the availability, involvement and willingness to
> invest time to get things right that everyone demonstrated in the process.
> This is an amazing community.
> V.

-- 
[email-masked]
ZmartZone IAM - www.zmartzone.eu

---

From: Pedro Igor Silva <[email-masked]>
Date: Mon, 25 Mar 2019 15:14:29 +0100

Nice work Vittorio.

I think the "sub" claim can also be used to reference the client (depending
on the implementation may not necessarily map to the client_id). It might
eventually reference the same entity as the client_id.

In addition to the "sub" claim, does it make sense to explicitly have
the "preferred_username"
claim (section 5.1 of OpenID.Core) as OPTIONAL in Section 2.2 Data Structure
? Isn't this claim a quite common piece of information processed by
resource servers?

Regards.
Pedro Igor

On Mon, Mar 25, 2019 at 2:59 PM Hans Zandbelt <[email-masked]>
wrote:

> which kind of spells "client" in case of the client credentials grant but
> I also do worry about Resource Servers thinking/acting only in terms of
> users
>
> Hans.
>
>> Here's just a bit of backstory, in case you are interested in how this
>> doc came to be. The trajectory it followed is somewhat unusual.
>>
>>    Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel
>>    Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!
>>    ).
>>    - I put together a presentation summarizing my findings and
>>    suggesting a rough interoperable profile (slides:

---

From: Dominick Baier <[email-masked]>
Date: Mon, 25 Mar 2019 07:39:27 -0700

Yes I know - and I think in hindsight it was a mistake to use the same
claim type for multiple semantics.

All the “this is OIDC not OAuth” arguments are making things more
complicated than they need to be - in my experience almost no-one (that I
know) does OIDC only - nor OAuth only. They always combine it.

In reality this leads to potential security problems - this spec has the
potential to rectify the situation.

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt ([email-masked])
wrote:

Hans.

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 25 Mar 2019 15:44:06 +0100

I believe there are plenty of OAuth 2.0 only use cases out there... but
nevertheless I agree with the potential confusion and thus security
problems arising from that (though one may argue the semantics are the
same).

Hans.

---

From: CARLIER Bertrand <[email-masked]>
Date: Mon, 25 Mar 2019 14:55:39 +0000

Hi Vittorio,

Very nice work !

Here are a few ideas:
- In addition to the "sub" claim (I agree it should only relate to the end user, not the client_id), I think the scope claim should be mentioned as OPTIONAL in §2.2 (it's already mentioned in other parts of the draft)
- Should we mention security recommendation on the JWT (like DO NOT USE alg="none") and maybe refer to https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html ?
- Should we mention the "act" claim defined by Token Exchange as a possible claim for JWT access tokens?
- any reason to rely on RFC 7662 (Introspection) for the token format? I see that the "nbf" (not before) claim is defined there

Regards,
--
Bertrand CARLIER

From: OAuth <[email-masked]> On Behalf Of Vittorio Bertocci
Sent: lundi 25 mars 2019 00:29
To: IETF oauth WG <[email-masked]>
Subject: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access tokens. You can find it in https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are interested in how this doc came to be. The trajectory it followed is somewhat unusual.
•       Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
•       I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
I studied and compared all those instances, identifying commonalities and differences.
•       I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx<https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx> ) - got early feedback from Filip Skokan on it. Thx Filip!
•       The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
•       On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.
I was blown away by the availability, involvement and willingness to invest time to get things right that everyone demonstrated in the process. This is an amazing community.
V.

The information transmitted in the present email including the attachment is intended only for the person to whom or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete all copies of the material.

Ce message et toutes les pièces qui y sont éventuellement jointes sont confidentiels et transmis à l'intention exclusive de son destinataire. Toute modification, édition, utilisation ou diffusion par toute personne ou entité autre que le destinataire est interdite. Si vous avez reçu ce message par erreur, nous vous remercions de nous en informer immédiatement et de le supprimer ainsi que les pièces qui y sont éventuellement jointes.

---

From: <[email-masked]>
Date: Mon, 25 Mar 2019 12:51:02 -0400

Dominick,

While you assumption of how OIDC and OAuth are used may apply to Federated solutions, the North American Energy Standards Board (NAESB) Energy Service Provider Interface (ESPI) REQ.21, which defines the data transmission standard for Energy utilities (electricity, gas, and water) to use in providing consumer’s and Third Party applications information about their customer’s energy consumption only allows OAuth 2.0 opaque ATs.

The Green Button Alliance, is reviewing how to update the standard to utilize the various IETF standards associated with OIDC this coming year, but currently the standard does NOT support a mixture of OIDC and OAuth.  I am very happy to see the IETF attempting to standardize the content and usage of JWT based OAuth ATs.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

Phone:      (949) 636-8571

Email:       [email-masked] <mailto:[email-masked]> 

From: Dominick Baier <[email-masked]> 
Sent: March 25, 2019 10:39 AM
To: Hans Zandbelt <[email-masked]>
Cc: IETF oauth WG <[email-masked]>; Nov Matake <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

All the “this is OIDC not OAuth” arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it..

In reality this leads to potential security problems - this spec has the potential to rectify the situation.

Dominick

On 25. March 2019 at 14:58:56, Hans Zandbelt ([email-masked] <mailto:[email-masked]> ) wrote:

Without agreeing or disagreeing: OIDC does not apply here since it is not OAuth and an access token is not an id_token.

which kind of spells "client" in case of the client credentials grant but I also do worry about Resource Servers thinking/acting only in terms of users

Hans.

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <[email-masked] <mailto:[email-masked]> > wrote:

OIDC says:

cheers

Dominick

On 25.. March 2019 at 05:13:03, Nov Matake ([email-masked] <mailto:[email-masked]> ) wrote:

Hi Vittorio, 

One feedback.

thanks

nov

On Mar 25, 2019, at 8:29, Vittorio Bertocci <vittorio.bertocci=[email-masked] <mailto:vittorio.bertocci=[email-masked]> > wrote:

Dear all, 

*	Despite OAuth2 not requiring any specific format for ATs, through the years I have come across multiple proprietary solution using JWT for their access token. The intent and scenarios addressed by those solutions are mostly the same across vendors, but the syntax and interpretations in the implementations are different enough to prevent developers from reusing code and skills when moving from product to product.
*	I asked several individuals from key products and services to share with me concrete examples of their JWT access tokens (THANK YOU Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
I studied and compared all those instances, identifying commonalities and differences. 
*	I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>  ) - got early feedback from Filip Skokan on it. Thx Filip!
*	The presentation was followed up by 1.5 hours of unconference discussion, which was incredibly valuable to get tight-loop feedback and incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and contributed generously to the discussion. Thank you!!!
Note: if you were at OSW2019, participated in the discussion and didn't get credited in the draft, my apologies: please send me a note and I'll make things right at the next update.
*	On my flight back I did my best to incorporate all the ideas and feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat, Hannes and above all Brian were all super helpful in negotiating the mysterious syntax of the RFC format and submission process.

V.

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

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

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

--

[email-masked] <mailto:[email-masked]> 

ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 25 Mar 2019 16:51:31 -0700

Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was expecting to cause more
discussion, and I am glad we are having this opportunity to clarify.
The current language in the draft traces the etymology of sub to OpenID
Connect core, hence Dominick observation is on point. However in the
description I express something in line with 7519, which was in fact my
intent.

The idea was to provide an identifier of the calling subject that is
guaranteed to be present in all cases- this would allow an SDK developer to
use the same code for things like lookups and membership checks regardless
of the nature of the caller (user in a delegated case, app in app-only
grants). The information to discriminate between user and app callers is
always available in the token (say, the caller is a user if sub!=client_id,
where client_id is always guaranteed to be present as well) hence there's
no loss in expressive power, should that difference be relevant for the
resource server.

Dominick, Hans- I probably missed the security issue you guys are thinking
of in this case. Of course, if this would introduce a risk I completely
agree it should be changed- I'd just like to understand better the problem.
Could you expand it in a scenario/use case to clarify the risk?
Nov- playing this back: is the concern that a user and a client might have
the same identifier within an IDP? When using collision resistant IDs, as
it is usually the case, that seems to be a remote possibility- did you
stumble in such scenario in production?

Thanks
V.

On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <[email-masked]>
wrote:

>>>    - I asked several individuals from key products and services to
>>>    share with me concrete examples of their JWT access tokens (THANK YOU
>>>    Dominick Baier (IdentityServer), Brian Campbell (PingIdentity),
>>>    Daniel Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and
>>>    explanations!).

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 25 Mar 2019 17:11:31 -0700

Thank you Bertrand for your comments and kind words!
Inline

>  In addition to the "sub" claim (I agree it should only relate to the end
> user, not the client_id),

See the reply to Dominick & Hans on this. Do you have specific case/attack
in mind?

I think the scope claim should be mentioned as OPTIONAL in §2.2 (it's
> already mentioned in other parts of the draft)

Mmh, let me clarify... the fact that the scope soemtrimes doesn;t show up
doesn;t automatically mean it's optional. Per the current formulation, I am
suggesting that when *scope *is present in the request, a *scope*
claim is *required
(*hence not optional*) *in the resulting token. When scope isn't present in
the incoming request, I didn't go all the way to explicitly disallow it but
it doesn't seem to be necessary in the resulting token. What do you think?

- Should we mention security recommendation on the JWT (like DO NOT USE
> alg="none") and maybe refer to
> *https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html*
> <https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html> ?

That is an excellent idea. Thank you!

- Should we mention the "act" claim defined by Token Exchange as a possible
> claim for JWT access tokens?

My bias would be to keep the set of things we mention in the profile to the
essential of what has been observed in concrete use, to keep the cognitive
burden of consuming the spec to the bare minimum. Currently there's no
language reminding the reader that they can add any extra claims they like,
but that should be true by default for all those specs. How strongly do you
feel about the value of explicitly mentioning "act" already in v1 of the
profile?

- any reason to rely on RFC 7662 (Introspection) for the token format? I
> see that the "nbf" (not before) claim is defined there

Do you mean "not rely" by any chance?
The current set of claims in the layout derives from observing what's most
commonly used, combined with the fact that many JWT validators used in the
wild are geared to work with id_tokens (hence more likely to work as is
with the new profile, always remembering the at+typ measure).
In particular, nbf was brought up during OSW2019 and, given its relatively
rare occurrence (only AAD and IS had it), I was advised to improve the
signal/noise ratio and cut it.

On Mon, Mar 25, 2019 at 7:55 AM CARLIER Bertrand <
[email-masked]> wrote:

> Hi Vittorio,
>
> Very nice work !
>
> Here are a few ideas:
> - In addition to the "sub" claim (I agree it should only relate to the end
> user, not the client_id), I think the scope claim should be mentioned as
> OPTIONAL in §2.2 (it's already mentioned in other parts of the draft)
> - Should we mention security recommendation on the JWT (like DO NOT USE
> alg="none") and maybe refer to
> *https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html*
> <https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-02.html> ?
> - any reason to rely on RFC 7662 (Introspection) for the token format? I
> see that the "nbf" (not before) claim is defined there
>
> Regards,
> --
>
> *Bertrand CARLIER *
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Vittorio Bertocci
> *Sent:* lundi 25 mars 2019 00:29
> *To:* IETF oauth WG <[email-masked]>
> *Subject:* [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
> Dear all,
> *https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/*
> <https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/>.
>    *https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx*
> The information transmitted in the present email including the attachment
> is intended only for the person to whom or entity to which it is addressed
> and may contain confidential and/or privileged material. Any review,
> retransmission, dissemination or other use of, or taking of any action in
> reliance upon this information by persons or entities other than the
> intended recipient is prohibited. If you received this in error, please
> contact the sender and delete all copies of the material.
>
> Ce message et toutes les pièces qui y sont éventuellement jointes sont
> confidentiels et transmis à l'intention exclusive de son destinataire.
> Toute modification, édition, utilisation ou diffusion par toute personne ou
> entité autre que le destinataire est interdite. Si vous avez reçu ce
> message par erreur, nous vous remercions de nous en informer immédiatement
> et de le supprimer ainsi que les pièces qui y sont éventuellement jointes.
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Mon, 25 Mar 2019 17:13:02 -0700

Thanks Don for your perspective on this!

On Mon, Mar 25, 2019 at 10:13 AM <[email-masked]> wrote:

> Dominick,
>
>
>
> While you assumption of how OIDC and OAuth are used may apply to Federated
> solutions, the North American Energy Standards Board (NAESB) Energy Service
> Provider Interface (ESPI) REQ.21, which defines the data transmission
> standard for Energy utilities (electricity, gas, and water) to use in
> providing consumer’s and Third Party applications information about their
> customer’s energy consumption only allows OAuth 2.0 opaque ATs.
>
> The Green Button Alliance, is reviewing how to update the standard to
> utilize the various IETF standards associated with OIDC this coming year,
> but currently the standard does NOT support a mixture of OIDC and OAuth.  I
> am very happy to see the IETF attempting to standardize the content and
> usage of JWT based OAuth ATs.
>
>
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
>
>
> REMI Networks
>
> 2335 Dunwoody Xing #E
>
> Dunwoody, GA 30338-8221
>
>
>
> Phone:      (949) 636-8571
>
> Email:       [email-masked]
>
>
>
> *From:* Dominick Baier <[email-masked]>
> *Sent:* March 25, 2019 10:39 AM
> *To:* Hans Zandbelt <[email-masked]>
> *Cc:* IETF oauth WG <[email-masked]>; Nov Matake <[email-masked]>;
> [email-masked]
> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
>
>
> know) does OIDC only - nor OAuth only. They always combine it..
>
>
>

---

From: Nov Matake <[email-masked]>
Date: Tue, 26 Mar 2019 09:34:49 +0900

Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.

If you can enforce collision resistant IDs between user & client instances, it’ll works fine. I feel its overkill though.

Sent from my iPhone

> On Mar 26, 2019, at 8:51, Vittorio Bertocci <[email-masked]> wrote:
> 
> Hey Nov, Dominick, Hans-
> thanks for the comments. That was an area I was expecting to cause more discussion, and I am glad we are having this opportunity to clarify.
> The current language in the draft traces the etymology of sub to OpenID Connect core, hence Dominick observation is on point. However in the description I express something in line with 7519, which was in fact my intent.
> 
> The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=client_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server.
> 
> Dominick, Hans- I probably missed the security issue you guys are thinking of in this case. Of course, if this would introduce a risk I completely agree it should be changed- I'd just like to understand better the problem. Could you expand it in a scenario/use case to clarify the risk?
> Nov- playing this back: is the concern that a user and a client might have the same identifier within an IDP? When using collision resistant IDs, as it is usually the case, that seems to be a remote possibility- did you stumble in such scenario in production?
> 
> Thanks
> V. 
> 
> 
>> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <[email-masked]> wrote:
>> I believe there are plenty of OAuth 2.0 only use cases out there... but nevertheless I agree with the potential confusion and thus security problems arising from that (though one may argue the semantics are the same).
>> 
>> Hans.
>> 
>>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <[email-masked]> wrote:
>>> All the “this is OIDC not OAuth” arguments are making things more complicated than they need to be - in my experience almost no-one (that I know) does OIDC only - nor OAuth only. They always combine it.
>>> 
>>>> On 25. March 2019 at 14:58:56, Hans Zandbelt ([email-masked]) wrote:
>>>> 
>>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <[email-masked]> wrote:
>>>>>>> I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!

---

From: Dominick Baier <[email-masked]>
Date: Mon, 25 Mar 2019 23:23:54 -0700

>From an access token consumer (aka API) developer point of view, I prefer
this logic

"If sub is present - client acts on behalf of a user, if not - not."

Anything more complicated has a potential of going wrong.

On 26. March 2019 at 01:34:53, Nov Matake ([email-masked]) wrote:

Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select username as sub, or
incremental integer as sub & client_id will be easily collide.

If you can enforce collision resistant IDs between user & client instances,
it’ll works fine. I feel its overkill though.

Sent from my iPhone

Hey Nov, Dominick, Hans-

Thanks
V.

---

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

Hi,

first time posting here but I have a comment on the "sub" claim:

We use RFC7523 for client authentication in a machine to machine scenario (i.e. client credentials grant).
In this RFC, the JWT used as client assertion is defined that it "MUST contain a "sub" (subject) claim identifying the principal that is the subject of the JWT" (Section 3).

Now, we also issue JWT access tokens which look already very similar to what is proposed in this draft.
As an implementer of an AS, I would find it a bit odd that I need to add the "sub" client with client_id for the self-signed assertion JWT on token request, but it is then not included in the JWT issued by the AS.
Regarding our application-specific claims in the JWT access token issued by the AS, the interpretation of the "sub" claim should not change imho.

BR
Martin

> On 26. Mar 2019, at 00:51, Vittorio Bertocci <Vittorio=[email-masked]> wrote:
> 
> Hey Nov, Dominick, Hans-
> The idea was to provide an identifier of the calling subject that is guaranteed to be present in all cases- this would allow an SDK developer to use the same code for things like lookups and membership checks regardless of the nature of the caller (user in a delegated case, app in app-only grants). The information to discriminate between user and app callers is always available in the token (say, the caller is a user if sub!=client_id, where client_id is always guaranteed to be present as well) hence there's no loss in expressive power, should that difference be relevant for the resource server..
> 
>>>> 	• I put together a presentation summarizing my findings and suggesting a rough interoperable profile (slides: https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx ) - got early feedback from Filip Skokan on it. Thx Filip!

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: Dave Tonge <[email-masked]>
Date: Tue, 26 Mar 2019 09:26:44 +0100

Thanks Vittorio for your presentation and putting this draft together.

I agree with Dominck that there is a potential of things going wrong when
`sub` has multiple meanings.
However I can see that using `sub` for a client_id semantically makes sense
in some situations and I agree that it makes it simpler from an SDK point
of view for there to always be a `sub`.

My suggestion would be that either there is an explicit type to
differentiate between "user access tokens" and "application access tokens",
or failing that the `sub` is used to indicate the difference.

Furthermore an agreement on the naming and description of these two types
of access tokens would be helpful more generally.

Dave

On Tue, 26 Mar 2019 at 07:25, Dominick Baier <[email-masked]>
wrote:

> If you can enforce collision resistant IDs between user & client
> instances, it’ll works fine. I feel its overkill though.
>
> Sent from my iPhone
>
>>> Without agreeing or disagreeing: OIDC does not apply here since it is
>>> not OAuth and an access token is not an id_token.
>>> which kind of spells "client" in case of the client credentials grant
>>> but I also do worry about Resource Servers thinking/acting only in terms of
>>> users
>>>
>>> Hans.
>>>

--

---

From: Rob Otto <[email-masked]>
Date: Tue, 26 Mar 2019 08:39:39 +0000

I’d like to add my support for not proposing any change to how sub is
typically interpreted for client credentials tokens.  In my experience the
usage of the client_id as the subject in this flow is well established and
it would cause disruption to many current implementations should that be
changed

Best regards
Rob

On Tue, 26 Mar 2019 at 08:27, Dave Tonge <[email-masked]>
wrote:

> However I can see that using `sub` for a client_id semantically makes
> sense in some situations and I agree that it makes it simpler from an SDK
> point of view for there to always be a `sub`.
>
>> Dominick, Hans- I probably missed the security issue you guys are
>> thinking of in this case. Of course, if this would introduce a risk I
>> completely agree it should be changed- I'd just like to understand better
>> the problem. Could you expand it in a scenario/use case to clarify the risk?
>> Nov- playing this back: is the concern that a user and a client might
>> have the same identifier within an IDP? When using collision resistant IDs,
>> as it is usually the case, that seems to be a remote possibility- did you
>>>>>    - Despite OAuth2 not requiring any specific format for ATs,
>>>>>    through the years I have come across multiple proprietary solution using
>>>>>    JWT for their access token. The intent and scenarios addressed by those
>>>>>    solutions are mostly the same across vendors, but the syntax and
>>>>>    interpretations in the implementations are different enough to prevent
>>>>>    developers from reusing code and skills when moving from product to product.
>>>>>    Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all
>>>>>    there and contributed generously to the discussion. Thank you!!!
-- 
Rob Otto
EMEA Field CTO - Ping Identity
+44 777 135 6092

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Steinar Noem <[email-masked]>
Date: Tue, 26 Mar 2019 09:40:04 +0100

Hi Vittorio, we  (the national federation-gateway for the health services
in norway - "HelseID")  think his is a really valuable initiative!
We also agree with Dominick concerning definition of the "sub" claim.

<mvh>Steinar</mvh>

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <[email-masked]
>:

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

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

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 26 Mar 2019 09:48:08 -0700

thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob, David, Nov,
Bertrand recommend using sub only for users. Martin would like to have the
sub for app only flows as well. Hans is neutral.
That does sound like the sub as user has more consensus, tho before
changing it I'd wait for the people currently at IETF104 to have more time
to comment as well.
Clarification. If the goal is to be able to apply the logic "if there's a
sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use
of sub when that's not the case. Are all OK with it?

Dave, the suggestion of having explicit typing for app only vs user only is
interesting! For the purpose of putting together an interoperable profile,
tho, I would suggest we table it for v1 in the interest of getting to
something easy to adopt (hence with small delta vs existing
implementations) faster.

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <[email-masked]> wrote:

> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <
> [email-masked]>:
>

---

From: Hans Zandbelt <[email-masked]>
Date: Tue, 26 Mar 2019 17:56:27 +0100

great summary! this will hurt quite a few existing m2m deployments but I do
like the rigidness of it all: it is very explicit, cannot misinterpreted
and thus prevents failure (which is really what Dominick is after); I'm on
board

Hans.

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci <Vittorio=
[email-masked]> wrote:

> Dave, the suggestion of having explicit typing for app only vs user only
> is interesting! For the purpose of putting together an interoperable
> profile, tho, I would suggest we table it for v1 in the interest of getting
> to something easy to adopt (hence with small delta vs existing
> implementations) faster.
>
>>> From an access token consumer (aka API) developer point of view, I
>>> prefer this logic
>>>
>>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0
>>>>>> access tokens. You can find it in
>>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be
>>>>>> presenting remotely). I look forward for your comments!
>>>>>>
>>>>>> Here's just a bit of backstory, in case you are interested in how
>>>>>> this doc came to be. The trajectory it followed is somewhat unusual.
>>>>>>
>>>>>>    - On my flight back I did my best to incorporate all the ideas
>>>>>>    and feedback in a draft, which will be discussed at IETF104 tomorrow.
>>>>>>    Rifaat, Hannes and above all Brian were all super helpful in negotiating
>>>>>>    the mysterious syntax of the RFC format and submission process.
>>>>>>
>> | [email-masked] <steinar@udelt..no> | [email-masked]  | +47 955 21 620
>>  | www.udelt.no |
>>

---

From: Dave Tonge <[email-masked]>
Date: Tue, 26 Mar 2019 17:57:18 +0100

Hi Vittorio

My understanding from Rob and others is that `sub` is already used for
tokens issued via the client credentials grant (in fact looking at the
tables from your presentation, most examples used `sub` for both user
identity and client identity). Given the desire for a spec that doesn't
break existing implementations, perhaps a new claim indicating the type of
access token would allow for better interoperability.

Dave

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Tue, 26 Mar 2019 17:00:24 +0000

> On 26. Mar 2019, at 17:48, Vittorio Bertocci <Vittorio=[email-masked]> wrote:
> 
> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, Bertrand recommend using sub only for users. Martin would like to have the sub for app only flows as well. Hans is neutral.

I am also neutral to this change in general. I was just noting that in RFC7523 in combination with client credentials + JWT bearer token grant, the JWT MUST contain a "sub" claim with the client_id.

So, imo it is a little inconsistent if the JWT access token does not contain a "sub" claim with client ID when it contains claims for the client (as there is no user context).
Hans also pointed out the JWT spec which supports this logic.

In other words, if you think that the use of "sub" is consistent across RFC7523 and your draft, it is fine with me and we will adopt our use accordingly eventually.

> That does sound like the sub as user has more consensus, tho before changing it I'd wait for the people currently at IETF104 to have more time to comment as well.
> Clarification. If the goal is to be able to apply the logic "if there's a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use of sub when that's not the case. Are all OK with it?
> 
> Dave, the suggestion of having explicit typing for app only vs user only is interesting! For the purpose of putting together an interoperable profile, tho, I would suggest we table it for v1 in the interest of getting to something easy to adopt (hence with small delta vs existing implementations) faster.
> 
> Hi Vittorio, we  (the national federation-gateway for the health services in norway - "HelseID")  think his is a really valuable initiative!
> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier <[email-masked]>:
> From an access token consumer (aka API) developer point of view, I prefer this logic
> 

Martin Schanzenbach
Fraunhofer AISEC

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 26 Mar 2019 11:23:08 -0700

Hi Dave,
either a type check or a lookup for client_id together with absence of sub
are going to be new logic- the latter seems to be more economical in term
of moving parts, without loss of expressive power.
I am not really committed to one model or the other, I just want to capture
the approach that gets the most consensus. Let's see if more
people/products chime in with perspectives on this

On Tue, Mar 26, 2019 at 9:57 AM Dave Tonge <[email-masked]>
wrote:

>>> Hi Vittorio, we  (the national federation-gateway for the health
>>> services in norway - "HelseID")  think his is a really valuable initiative!
>>>> I haven’t seen such implementations, but user-select username as sub,
>>>> or incremental integer as sub & client_id will be easily collide.
>>>>
>>>>> I believe there are plenty of OAuth 2.0 only use cases out there...
>>>>> but nevertheless I agree with the potential confusion and thus security
>>>>>> The JWT spec says in
>>>>>> https://tools.ietf.org/html/rfc7519#section-4.1.2:
>>>>>>
> Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 26 Mar 2019 11:33:24 -0700

Thank you, Martin! RFC7523 was the reason for which i had the sub in the
first JWT AT profile draft the way I did. The proposal of requiring it only
for user flows and disallowing it otherwise is not in alignment with
RFC7523, which does not sound like a good thing, but ultimately the
function of JWT as assertion isn't the same as the function of an AT, and
might even prevent an AT to be used for that purpose (tho I know that's
what some ASes do today.
Ultimately I'd like this profile to reflect the desires of as many ASes as
possible, and if in-market usage differs, as long as there's no direct
violation of existing specs (doesn't seem to be the case here given tha
assertion!=AT) and there are no security/privacy issues coming with that, I
won't push back

On Tue, Mar 26, 2019 at 10:00 AM Schanzenbach, Martin <
[email-masked]> wrote:

> I am also neutral to this change in general. I was just noting that in
> RFC7523 in combination with client credentials + JWT bearer token grant,
> the JWT MUST contain a "sub" claim with the client_id.
>
> So, imo it is a little inconsistent if the JWT access token does not
> contain a "sub" claim with client ID when it contains claims for the client
> (as there is no user context).
> In other words, if you think that the use of "sub" is consistent across
> RFC7523 and your draft, it is fine with me and we will adopt our use
> accordingly eventually.
>
> > Clarification. If the goal is to be able to apply the logic "if there's
> a sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use
> >>> thanks for the comments. That was an area I was expecting to cause
> more discussion, and I am glad we are having this opportunity to clarify.
> >>> The current language in the draft traces the etymology of sub to
> OpenID Connect core, hence Dominick observation is on point. However in the
> >>>>>>  • Despite OAuth2 not requiring any specific format for ATs,
> >>>>>>  • I asked several individuals from key products and services to
> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel
> Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and
> explanations!).
> >>>>>>  • I put together a presentation summarizing my findings and
> >>>>>>  • The presentation was followed up by 1.5 hours of unconference
> >>>>>>  • On my flight back I did my best to incorporate all the ideas and
> >>>>>> I was blown away by the availability, involvement and willingness
> to invest time to get things right that everyone demonstrated in the
> process. This is an amazing community.
> >>>>>> V.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 30 Mar 2019 04:15:27 -0500

Hi Vittorio,

> changing it I'd wait for the people currently at IETF104 to have more time

I'm not the responsible AD for OAuth, but as irresponsible AD let me point
out that the WG chairs need to look at the "why" and not just the headcount
of support, when they determine what has consensus (or lack of consensus).
But I think we have seen some good arguments presented in this thread, so
hopefully the chairs' job will not be very difficult.

-Ben

---

From: Vittorio Bertocci <[email-masked]>
Date: Sat, 30 Mar 2019 10:34:52 -0700

Hey Benjamin,
Of course I agree that sheer headcount isn’t the main factor :).
The main point here is that this is a profile meant to promote and
facilitate interoperability, so _as long as a proposal is is sound &
secure_, the number of products and services favoring it does have direct
impact on adoption & expectations of successful interop. I agree that the
“why” remains the highest order bit, and as you mentioned we have seen good
arguments.