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

From: George Fletcher <[email-masked]>
Date: Mon, 1 Apr 2019 11:12:00 -0400

Thanks for writing this up. One comment on auth_time...

    auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core  <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
       Important: as this claim represents the time at which the end user
       authenticated, its value will remain the same for all the JWT
       access tokens issued within that session.  For example: all the
       JWT access tokens obtained with a given refresh token will all
       have the same value of auth_time, corresponding to the instant in
       which the user first authenticated to obtain the refresh token.

During a current session a user can be challenged for additional 
credentials or required to re-authenticate due to a number of different 
reasons. For example, OIDC prompt=login or max_age=NNN. In this context, 
I'd assume that the auth_time value should be updated to the latest time 
at which the user authenticated.

If we need a timestamp for when the "session" started, then there could 
be a session_start_time claim.

Thanks,
George

On 3/24/19 7:29 PM, Vittorio Bertocci 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/.
> 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: David Waite <[email-masked]>
Date: Mon, 1 Apr 2019 13:02:20 -0600

Do we know if there is a justifying use case for auth_time, acr, and amr to be available in OAuth JWT access tokens? These are meant to be messages about the client, either directly (in the case of client credentials) or about its delegated authorization of the user.

Embedding attributes about the user (such as group membership and roles) can be used for the resource to make finer-grained decisions than scopes, but normally I would expect say acr limitations enforced by a resource to instead be controlled by the AS requiring a higher quality authentication to release certain scopes.

Thats of course not to say extensions to OAuth such as OIDC can’t provide these values, just that they might better be defined by those extensions.

-DW

> On Apr 1, 2019, at 9:12 AM, George Fletcher <gffletch=[email-masked]> wrote:
> 
> During a current session a user can be challenged for additional credentials or required to re-authenticate due to a number of different reasons. For example, OIDC prompt=login or max_age=NNN. In this context, I'd assume that the auth_time value should be updated to the latest time at which the user authenticated. 
> 
> If we need a timestamp for when the "session" started, then there could be a session_start_time claim.
> 
> Thanks,
> George
> 
>> 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.
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 3 Apr 2019 11:23:52 -0600

+1 to David's question here. I'd like to see justifying use cases (beyond
just the fact that some people are already doing it) for auth_time, acr,
and amr to be available in OAuth JWT access tokens. Those claims are
defined for, and in the context of, an ID Token and I fear that codifying
their use in an access token will lead to misuse and/or confusion.

On Mon, Apr 1, 2019 at 1:03 PM David Waite <[email-masked]>
wrote:

> Do we know if there is a justifying use case for auth_time, acr, and amr
> to be available in OAuth JWT access tokens? These are meant to be messages
> about the client, either directly (in the case of client credentials) or
> about its delegated authorization of the user.
>
> Embedding attributes about the user (such as group membership and roles)
> can be used for the resource to make finer-grained decisions than scopes,
> but normally I would expect say acr limitations enforced by a resource to
> instead be controlled by the AS requiring a higher quality authentication
> to release certain scopes.
>
> Thats of course not to say extensions to OAuth such as OIDC can’t provide
> these values, just that they might better be defined by those extensions.
>
> -DW
>
> On Apr 1, 2019, at 9:12 AM, George Fletcher <
> gffletch=[email-masked]> wrote:
>
> I'd assume that the auth_time value should be updated to the latest time at
> which the user authenticated.
>
> 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 put together a presentation summarizing my findings and suggesting
>    a rough interoperable profile (slides:
>    - 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!!!
>    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.
>
> invest time to get things right that everyone demonstrated in the process.
> This is an amazing community.
> V.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
_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: Vittorio Bertocci <[email-masked]>
Date: Wed, 3 Apr 2019 12:38:30 -0700

Thanks guys for the comment, sorry for the delay in addressing them.
I am not married to the claim types used in here, so if you think that
reusing the ones in the id_token can cause confusion we should expand on
the specific ways in which you think might go south.
However I think it's important that the information on say, whether the
current token was obtained using MFA or a specific authentication factor is
something that API developers can legitimately latch to when doing
authorization decisions. From the perspective of a developer modeling a
solution, whether functionality is delivered as a route in a postback based
web app (hence receiving an id_token or derived) or as an API consumed by a
native app, the business requirement gating access to that functionality
doesn't change. If the admin managing that resource establishes that access
should be performed only via MFA, the developer should be equipped to
enforce that regardless of the stack used to expose functionality (web app,
API).
Although it is true that triggering the desired behavior might be achieved
by the resource setting and contract with the AS, along the lines of what
David said, it's actually not uncommon for those policies to be assigned on
the resource AFTER the current session was established and/or the
corresponding AT was obtained and cached. Furthermore, the requirement
might be more granular than an AS policy can tolerate (an API might
requires MFA only for certain routes, hence hard to express in a static
policy) and triggered in form of challenges. So the situation in which you
have an AT with the right issuer, audience, etc but was obtained with a
policy now obsolete/unacceptable to the RP is strong. Requesting to support
revocation just for this seems overkill, especially given that the scenario
in which the same logical app is exposed as both web app and native
client+API, the code consuming those claims is already in place. It just
makes intuitive sense for developers.
In summary, one can take steps to push as much of the MFA requirements to
the AS settings for a particular request, but ultimately the desire of the
API developer to enforce that it actually happened is a requirement I
encountered often in practice. Anything providing extra context to refine
decisions about it (like auth_time, which might inform decisions about
whether to accept an MFA check occurred N minutes ago or refuse access).

I thought that reusing the existing names for the same concepts just made
sense (dev existing skills, existing codebases, etc etc) and especially in
the case in which the values are exactly the same, and the idea seemed to
receive good support during OSW. But I am completely open to change it of
course, especially for cases like the one identified by George.
WDYT?

On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

>>    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
> *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.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: George Fletcher <[email-masked]>
Date: Wed, 3 Apr 2019 16:48:41 -0400

I agree that this will break a lot of existing flows... especially those 
using any form of the client_credentials flow. In that sense I'm not 
completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:
> 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] 
> <mailto:[email-masked]>> wrote:
>
>     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]
>     <mailto:[email-masked]>> wrote:
>
>         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] <mailto:[email-masked]>>:
>
>             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] <mailto:[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
>>
>>             On Mar 26, 2019, at 8:51, Vittorio Bertocci
>>             <[email-masked] <mailto:[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]
>>>             <mailto:[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]
>>>                 <mailto:[email-masked]>> wrote:
>>>
>>>                     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.
>>>>                     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]
>>>>                     <mailto:[email-masked]>> wrote:
>>>>
>>>>                         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]
>>>>                         <mailto:[email-masked]>) wrote:
>>>>
>>>>>                         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]
>>>>>>                         <mailto: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
>>>>>>                         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
>>>>>>                           * I asked several individuals from key
>>>>>>                             products and services to share with
>>>>>>                             me concrete examples of their JWT
>>>>>>                             access tokens (THANK YOU Dominick
>>>>>>                             Dobalian (Microsoft), Karl Guinness
>>>>>>                             (Okta) for the tokens and explanations!).
>>>>>>                             I studied and compared all those
>>>>>>                             instances, identifying commonalities
>>>>>>                             and differences.
>>>>>>                           * 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
>>>>>>                             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.
>>>>                     [email-masked]
>>>>                     <mailto:[email-masked]>
>>>>                     ZmartZone IAM - www.zmartzone.eu
>>>>                     <http://www.zmartzone.eu>
>>>
>>>
>>>
>>>                 --
>>>                 [email-masked]
>>>                 <mailto:[email-masked]>
>>>                 ZmartZone IAM - www.zmartzone.eu
>>>                 <http://www.zmartzone.eu>
>>>
>         Vennlig hilsen
>         Steinar Noem
>         Partner Udelt AS
>         Systemutvikler
>         | [email-masked] <mailto:steinar@udelt..no> | [email-masked]
>         <mailto:[email-masked]>  | +47 955 21 620 | www.udelt.no
>         <http://www.udelt.no/> |
>
> [email-masked] <mailto:[email-masked]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>
>

---

From: Hans Zandbelt <[email-masked]>
Date: Wed, 3 Apr 2019 22:56:49 +0200

I will argue that in a way such deployments are already broken e.g. in the
typical use case of onboarding client accounts in the same
directory/OU/namespace as user accounts and we don't need to cater for that.

Hans.

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <[email-masked]> wrote:

> 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:
>
>> 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:
>>
>>> 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]>:
>>>
>>>> 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."
>>>>
>>>> On 26. March 2019 at 01:34:53, Nov Matake ([email-masked]) wrote:
>>>>
>>>> Hi Vittorio,
>>>>
>>>> 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
>>>> 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:
>>>>>
>>>>>> 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:
>>>>>>
>>>>>> 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
>>>>>> "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:
>>>>>>
>>>>>>> IMHO the sub claim should always refer to the user - and nothing
>>>>>>> else.
>>>>>>>
>>>>>>> OIDC says:
>>>>>>>
>>>>>>> "Subject - Identifier for the End-User at the Issuer."
>>>>>>>
>>>>>>> On 25.. March 2019 at 05:13:03, Nov Matake ([email-masked]) wrote:
>>>>>>>
>>>>>>> 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
>>>>>>> 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!).
>>>>>>>    Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all
>>>>>>>    there and contributed generously to the discussion. Thank you!!!
>>>>>>>    - 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: Dominick Baier <[email-masked]>
Date: Wed, 3 Apr 2019 23:12:21 -0700

My experience:

When building modern applications, we use OIDC and OAuth together for
authentication, session management and API access. Only the combination
makes sense (to me) here. Hence it also makes sense (for me) to share
claims types going forward.

IdentityServer is a framework that is typically used when building new
applications (or modernising them) so we have the luxury of a lot of
“Greenfield-ish” scenarios - I acknowledge that this might not apply to
everyone on this list.

Maybe we need a “base profile” + “end-user identity” extensions...

———
Dominick

On 3. April 2019 at 21:38:55, Vittorio Bertocci (
vittorio=[email-masked]) wrote:

On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

> * CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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: George Fletcher <[email-masked]>
Date: Thu, 4 Apr 2019 10:06:57 -0400

Another comment...

    aud  REQUIRED - as defined in section 2 of [OpenID.Core  <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].  See
       Section 3  <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#section-3>  for indications on how an authorization server should
       determine the value of aud depending on the request.  [Note: some
       vendors seem to rely on resource aliases.  If we believe this to
       be a valuable feature, here's some proposed language: The aud
       claim MAY include a list of individual resource indicators if they
       are all aliases referring to the same requested resource known by
       the authorization server. ]

I don't think OpenID.Core Section 3 is the correct reference for 
determining the 'aud' value. The issue here is that the 'aud' of the 
id_token is the recipient of the id_token (i.e. the client). However, 
for access_tokens the 'aud' value should be the resource service that 
will receive the access_token. There is no existing guidance for this 
and we should provide such guidance as this is "kind of new" for OAuth2 
(from an explicit specification perspective).

Also, there is the concept of 'azp' from the id_token which amounts to 
"who's allowed to present this token" which might be interesting from 
the case where one entity obtains the token, and gives it to another 
entity to present. Not sure if we want to include this concept or not.

Finally, I think we may need some best practice around how the concept 
of audience and resource should be managed. For instance...

    If the request does not include a resource parameter, the
    authorization server MUST use in the aud claim a default resource
    indicator.  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.

I think for most implementations this would amount to... define an 
audience that covers all the resource services where the access token 
can be returned and set that as the audience (e.g. urn:x-mydomain:apis). 
Which is perfectly legal but maybe not in the spirit of the spec:) I am 
receiving feedback from developers that binding access tokens narrowly 
to the resource where they will be presented is concerning from a 
chattiness perspective (latency issues) and general load on the deployed 
AS infrastructure.

---

From: George Fletcher <[email-masked]>
Date: Thu, 4 Apr 2019 10:14:00 -0400

Comments inline...

On 4/3/19 3:38 PM, Vittorio Bertocci wrote:
> reusing the ones in the id_token can cause confusion we should expand 
> on the specific ways in which you think might go south.
I'm fine with re-using claims... we just need to make sure if we reuse a 
claim it keeps the same semantic.
> However I think it's important that the information on say, whether 
> the current token was obtained using MFA or a specific authentication 
> factor is something that API developers can legitimately latch to when 
> doing authorization decisions. From the perspective of a developer 
> modeling a solution, whether functionality is delivered as a route in 
> a postback based web app (hence receiving an id_token or derived) or 
> as an API consumed by a native app, the business requirement gating 
> access to that functionality doesn't change. If the admin managing 
> that resource establishes that access should be performed only via 
> MFA, the developer should be equipped to enforce that regardless of 
> the stack used to expose functionality (web app, API).
> Although it is true that triggering the desired behavior might be 
> achieved by the resource setting and contract with the AS, along the 
> lines of what David said, it's actually not uncommon for those 
> policies to be assigned on the resource AFTER the current session was 
> established and/or the corresponding AT was obtained and cached. 
> Furthermore, the requirement might be more granular than an AS policy 
> can tolerate (an API might requires MFA only for certain routes, hence 
> hard to express in a static policy) and triggered in form of 
> challenges. So the situation in which you have an AT with the right 
> issuer, audience, etc but was obtained with a policy now 
> obsolete/unacceptable to the RP is strong. Requesting to support 
> revocation just for this seems overkill, especially given that the 
> scenario in which the same logical app is exposed as both web app and 
> native client+API, the code consuming those claims is already in 
> place. It just makes intuitive sense for developers.
> In summary, one can take steps to push as much of the MFA requirements 
> to the AS settings for a particular request, but ultimately the desire 
> of the API developer to enforce that it actually happened is a 
> requirement I encountered often in practice. Anything providing extra 
> context to refine decisions about it (like auth_time, which might 
> inform decisions about whether to accept an MFA check occurred N 
> minutes ago or refuse access).
As an aside, I worry about trying to put all information needed to make 
a dynamic policy decision into an access token. For cases where the 
policy can change over time including the lifetime of the access_token 
then I prefer the User Managed Access (UMA) approach as it inherently 
allows for dynamic policy change.
>
> I thought that reusing the existing names for the same concepts just 
> made sense (dev existing skills, existing codebases, etc etc) and 
> especially in the case in which the values are exactly the same, and 
> the idea seemed to receive good support during OSW. But I am 
> completely open to change it of course, especially for cases like the 
> one identified by George.
> WDYT?
>
> On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell 
> <bcampbell=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     +1 to David's question here. I'd like to see justifying use cases
>     (beyond just the fact that some people are already doing it) for
>     auth_time, acr, and amr to be available in OAuth JWT access
>     tokens. Those claims are defined for, and in the context of, an ID
>     Token and I fear that codifying their use in an access token will
>     lead to misuse and/or confusion.
>
>     On Mon, Apr 1, 2019 at 1:03 PM David Waite
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Do we know if there is a justifying use case for auth_time,
>         acr, and amr to be available in OAuth JWT access tokens? These
>         are meant to be messages about the client, either directly (in
>         the case of client credentials) or about its delegated
>         authorization of the user.
>
>         Embedding attributes about the user (such as group membership
>         and roles) can be used for the resource to make finer-grained
>         decisions than scopes, but normally I would expect say acr
>         limitations enforced by a resource to instead be controlled by
>         the AS requiring a higher quality authentication to release
>         certain scopes.
>
>         Thats of course not to say extensions to OAuth such as OIDC
>         can’t provide these values, just that they might better be
>         defined by those extensions.
>
>         -DW
>
>>         On Apr 1, 2019, at 9:12 AM, George Fletcher
>>         <gffletch=[email-masked]
>>         <mailto:gffletch=[email-masked]>> wrote:
>>
>>         During a current session a user can be challenged for
>>         additional credentials or required to re-authenticate due to
>>         a number of different reasons. For example, OIDC prompt=login
>>         or max_age=NNN. In this context, I'd assume that the
>>         auth_time value should be updated to the latest time at which
>>         the user authenticated.
>>
>>         If we need a timestamp for when the "session" started, then
>>         there could be a session_start_time claim.
>>
>>         Thanks,
>>         George
>>
>>>         I just submitted a draft describing a JWT profile for OAuth
>>>         2.0 access tokens. You can find it in
>>>         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
>>>           * I put together a presentation summarizing my findings
>>>             and suggesting a rough interoperable profile (slides:
>>>           * 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
>>>             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.
>>>
>     /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./_______________________________________________
>     OAuth mailing list

---

From: Brian Campbell <[email-masked]>
Date: Thu, 4 Apr 2019 09:21:33 -0600

Yeah, OpenID.Core isn't the right reference for `aud`.
https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of
`aud` which should be the reference and this document can provide
additional specifics for the given application.

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

> id_token is the recipient of the id_token (i.e. the client). However, for
> access_tokens the 'aud' value should be the resource service that will
> receive the access_token. There is no existing guidance for this and we
> should provide such guidance as this is "kind of new" for OAuth2 (from an
> explicit specification perspective).
>
> "who's allowed to present this token" which might be interesting from the
> case where one entity obtains the token, and gives it to another entity to
> present. Not sure if we want to include this concept or not.
>
> Finally, I think we may need some best practice around how the concept of
> audience and resource should be managed. For instance...
>
> audience that covers all the resource services where the access token can
> be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which
> is perfectly legal but maybe not in the spirit of the spec:) I am receiving
> feedback from developers that binding access tokens narrowly to the
> resource where they will be presented is concerning from a chattiness
> perspective (latency issues) and general load on the deployed AS
> infrastructure.
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 4 Apr 2019 09:26:11 -0600

The same is true for most of the other main claims too - iss, exp, aud,
sub, iat, etc.. They are defined in RFC 7519 not OIDC.

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 4 Apr 2019 17:38:54 +0200

agreed but it (i.e. "sub") also brings us back to where we started

Hans.

---

From: George Fletcher <[email-masked]>
Date: Thu, 4 Apr 2019 11:46:29 -0400

:)

The more I think about 'sub' the more I don't think is should mean 
"user". What about an IoT device? To me it feels like 'sub' should be 
what 7519 states, the subject or principal of the token. In some cases, 
that is quite legitimately the "client" or "machine". Changing that 
semantic seems bad. If a developer needs to know whether this JWT is 
about a "human" or not, that's something else entirely and could have 
it's own claim.

On 4/4/19 11:38 AM, Hans Zandbelt wrote:
> On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell 
>     The same is true for most of the other main claims too - iss, exp,
>     aud, sub, iat, etc.. They are defined in RFC 7519 not OIDC.
>
>     On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         https://tools.ietf.org/html/rfc7519#section-4.1.3 is the
>         definition of `aud` which should be the reference and this
>         document can provide additional specifics for the given
>         application.
>
>         On Thu, Apr 4, 2019 at 8:07 AM George Fletcher
>         <mailto:[email-masked]>> wrote:
>
>             Another comment...
>
>             I don't think OpenID.Core Section 3 is the correct
>             reference for determining the 'aud' value. The issue here
>             is that the 'aud' of the id_token is the recipient of the
>             id_token (i.e. the client). However, for access_tokens the
>             'aud' value should be the resource service that will
>             receive the access_token. There is no existing guidance
>             for this and we should provide such guidance as this is
>             "kind of new" for OAuth2 (from an explicit specification
>             perspective).
>
>             Also, there is the concept of 'azp' from the id_token
>             which amounts to "who's allowed to present this token"
>             which might be interesting from the case where one entity
>             obtains the token, and gives it to another entity to
>             Finally, I think we may need some best practice around how
>             the concept of audience and resource should be managed.
>             For instance...
>
>             I think for most implementations this would amount to...
>             define an audience that covers all the resource services
>             where the access token can be returned and set that as the
>             audience (e.g. urn:x-mydomain:apis). Which is perfectly
>             legal but maybe not in the spirit of the spec:) I am
>             receiving feedback from developers that binding access
>             tokens narrowly to the resource where they will be
>             presented is concerning from a chattiness perspective
>             (latency issues) and general load on the deployed AS
>             infrastructure.
>
>>             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.
>>
>>                 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
>>                 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.
>>                 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!!!
>>               * 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
>>             willingness to invest time to get things right that
>>             everyone demonstrated in the process. This is an amazing
>>             community.
>>             V.
>>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 4 Apr 2019 09:46:54 -0600

I'm not sure I understand what you mean but this document would reference
the RFC 7519 claims and, if needed, futher profile their usage for access
tokens.

---

From: George Fletcher <[email-masked]>
Date: Thu, 4 Apr 2019 11:50:49 -0400

The more I think about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It 
shouldn't matter whether that is a machine, a user, or a device. Trying 
to separate out "humans" as a special class will just make things more 
complicated. If we need a claim to identify the subject is a "human" 
then why not just add that. This doesn't break anything and makes it 
easy for people to detect this case in those use cases where it's required.

Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:
> I will argue that in a way such deployments are already broken e.g. in 
> the typical use case of onboarding client accounts in the same 
> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I agree that this will break a lot of existing flows... especially
>     those using any form of the client_credentials flow. In that sense
>     I'm not completely on board yet :)
>
>>     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.
>>
>>         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.
>>         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] <mailto:[email-masked]>> wrote:
>>
>>             health services in norway - "HelseID")  think his is a
>>             really valuable initiative!
>>             <mailto:[email-masked]>>:
>>
>>                 From an access token consumer (aka API) developer
>>                 point of view, I prefer this logic
>>
>>>                 If you can enforce collision resistant IDs between
>>>                 user & client instances, it’ll works fine. I feel
>>>                 its overkill though.
>>>
>>>                 Sent from my iPhone
>>>
>>>>                 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
>>>>                 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.
>>>>
>>>>
>>>>                     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.
>>>>
>>>>                         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.
>>>>
>>>>                         On 25. March 2019 at 14:58:56, Hans
>>>>                         Zandbelt ([email-masked]
>>>>>                         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
>>>>>                         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]
>>>>>                             IMHO the sub claim should always refer
>>>>>                             to the user - and nothing else.
>>>>>
>>>>>                             OIDC says:
>>>>>
>>>>>                             On 25.. March 2019 at 05:13:03, Nov
>>>>>                             Matake ([email-masked]
>>>>>>                             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.
>>>>>>
>>>>>>>                                 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.
>>>>>>>                                 share with me concrete examples
>>>>>>>                                 of their JWT access tokens
>>>>>>>                                 (THANK YOU Dominick Baier
>>>>>>>                                 (IdentityServer), Brian Campbell
>>>>>>>                                 (PingIdentity), Daniel Dobalian
>>>>>>>                                 (Microsoft), Karl Guinness
>>>>>>>                                 instances, identifying
>>>>>>>                                 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
>>>>>>>                                 feedback in a draft, which will
>>>>>>>                                 be discussed at IETF104
>>>>>>>                                 tomorrow. Rifaat, Hannes and
>>>>>>>                                 above all Brian were all super
>>>>>>>                                 helpful in negotiating the
>>             | [email-masked] <mailto:steinar@udelt..no> |
>>             [email-masked] <mailto:[email-masked]>  | +47 955 21 620 |
>>             www.udelt.no <http://www.udelt.no/> |
>>

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Thu, 4 Apr 2019 15:58:29 +0000

I think what needs to be clarified is whether the "sub" claim should denote the caller (=client) or the RO in the case of an JWT AT.
RFC 7519 only defines "sub" to be the principal which is the subject of all claims in the JWT.
This means that the AT can contain either claims regarding the client OR the RO, but not both. (I prefer to use RO instead of user as I think this a term better used in OIDC).

Now, the question is what does an RS need to make an authorisation decision? Claims about the client or claims about the RO?
Since OIDC already has ID Tokens as JWT which have the RO as "sub", maybe it makes sense to have the client as sub for the AT?
If the RS needs claims about the RO in order to do authorization decisions, maybe it needs to be presented with an ID Token (which would imply that it is issued with the RS in its aud claim).

> On 4. Apr 2019, at 17:50, George Fletcher <gffletch=[email-masked]> wrote:
> 
> The subject of a token should be the principal of that token. It shouldn't matter whether that is a machine, a user, or a device. Trying to separate out "humans" as a special class will just make things more complicated. If we need a claim to identify the subject is a "human" then why not just add that. This doesn't break anything and makes it easy for people to detect this case in those use cases where it's required.
> 
> Thanks,
> George
> 
>> I will argue that in a way such deployments are already broken e.g. in the typical use case of onboarding client accounts in the same directory/OU/namespace as user accounts and we don't need to cater for that.
>> 
>> Hans.
>> 
>> I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :)
>> 
>>> 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:
>>> 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.
>>> 
>>> 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
>>> 
>>>> 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
>>>> 
>>>>> 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:
>>>>> 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:
>>>>> 
>>>>>> 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:
>>>>>> 
>>>>>> 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:
>>>>>> IMHO the sub claim should always refer to the user - and nothing else.
>>>>>> 
>>>>>> OIDC says:
>>>>>> 
>>>>>>> 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/.
>>>>>>>> 	• 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 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!!!
>>>>>>>> 	• 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] | [email-masked]  | +47 955 21 620 | www.udelt.no |

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: Hans Zandbelt <[email-masked]>
Date: Thu, 4 Apr 2019 18:29:43 +0200

I believe the root problem is that we're trying to unify across tokens that
are issued for different use cases (auth vs. authz), different subjects and
different audiences. The JWT spec allows us to cover those use cases nicely
within its own semantics but the profile specific use case semantics are
really different at heart. This problem becomes even more apparent in SPAs
that share both the id_token and the access_token across frontend and
backend: the RS then needs to flip back and forth between the use cases and
their specific semantics.

It seems were stuck between a rock and a hard place: I don't think there's
a way to make things explicit and clear across use cases whilst sticking
with JWT semantics only (as clear as the semantics may be in their own
RFC7519 context). I also don't think there's a way to make things explicit
and clear without breaking existing deployments and existing spec text
which is as awkward.

Hans.

On Thu, Apr 4, 2019 at 5:58 PM Schanzenbach, Martin <
[email-masked]> wrote:

> I think what needs to be clarified is whether the "sub" claim should
> denote the caller (=client) or the RO in the case of an JWT AT.
> This means that the AT can contain either claims regarding the client OR
> the RO, but not both. (I prefer to use RO instead of user as I think this a
> term better used in OIDC).
>
> Now, the question is what does an RS need to make an authorisation
> decision? Claims about the client or claims about the RO?
> Since OIDC already has ID Tokens as JWT which have the RO as "sub", maybe
> it makes sense to have the client as sub for the AT?
> If the RS needs claims about the RO in order to do authorization
> decisions, maybe it needs to be presented with an ID Token (which would
> imply that it is issued with the RS in its aud claim).
>
> shouldn't matter whether that is a machine, a user, or a device. Trying to
> separate out "humans" as a special class will just make things more
> complicated. If we need a claim to identify the subject is a "human" then
> why not just add that. This doesn't break anything and makes it easy for
> people to detect this case in those use cases where it's required.
> >
> > Thanks,
> > George
> >
> those using any form of the client_credentials flow. In that sense I'm not
> misinterpreted and thus prevents failure (which is really what Dominick is
> after); I'm on board
> >>>
> >>> Hans.
> >>>
> 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
> >>>>> 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
> >>>>> 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.
> >>>>>
> >>>>>
> >>>>>> 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
> >>>>>> 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.
> >>>>>>
> >>>>>>>>        • 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
> >>>>>>>>        • 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),
> >>>>>>>>        • I put together a presentation summarizing my findings
> >>>>>>>>        • 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
> >>>>>>>>        • 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.
> >>>>>>>> I was blown away by the availability, involvement and willingness
> to invest time to get things right that everyone demonstrated in the

---

From: Brian Campbell <[email-masked]>
Date: Thu, 4 Apr 2019 10:32:13 -0600

A few remarks/responses inline below this time...

> the specific ways in which you think might go south.

My concern isn't with reusing the names/types of the claims per se.  But
more generally that codifying the use of certain authentication-centric
claims in the context of an access token furthers the potential confusion
around authentication vs. authorization that has been a nagging problem for
OAuth (i.e. the https://oauth.net/articles/authentication/ article).

> whether to accept an MFA check occurred N minutes ago or refuse access).

I understand what you are saying but but personally do not find it
sufficiently compelling.  But that's just my opinion and not a hill I want
to die on (at the present time anyway).

> receive good support during OSW.
>

Our recollection of OSW differs somewhat. As I recall there was support for
pointing to identity claims from OIDC for additional end-user info. But
there was some grumbling (from John and myself at least) at first mention
of acr/amr and auth_time. By the time it came up again near the end of the
last unconference session, I wasn't wanting to prolong things because I was
kinda worn out for the day and wanting to get to Frankfurt that evening
before sunset ('cause I like to do stuff like this:
https://flic.kr/p/2fiAaPe :) ).

> But I am completely open to change it of course, especially for cases like
> the one identified by George.
>

FWIW, to me, George's suggestion "assume[ing] that the auth_time value
should be updated to the latest time at which the user authenticated"
though some unspecified and in many cases non-existent link between the AT
and a current user session at the AS is an example of how
authentication-centric claims in an access token can be confusing.

>>> Thats of course not to say extensions to OAuth such as OIDC can’t
>>> provide these values, just that they might better be defined by those
>>> extensions.
>>>
>>> -DW
>>>

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Thu, 4 Apr 2019 17:04:04 +0000

I agree. Maybe RFC 7519 is actually as good as it gets wrt claim specifications?
At least for OAuth. Use case specific profiles can/must then use their own definitions (see OIDC) for (JWT) ATs.
I mean, at least for OIDC, an AT which is the result of a client credential grant isn't even a thing which really simplifies the specification of a JWT AT in OIDC.

So maybe just reference / rely on RFC 7519 for the basic claims and clarify usage of this JWT using the typ?

> On 4. Apr 2019, at 18:29, Hans Zandbelt <[email-masked]> wrote:
> 
> I believe the root problem is that we're trying to unify across tokens that are issued for different use cases (auth vs. authz), different subjects and different audiences. The JWT spec allows us to cover those use cases nicely within its own semantics but the profile specific use case semantics are really different at heart. This problem becomes even more apparent in SPAs that share both the id_token and the access_token across frontend and backend: the RS then needs to flip back and forth between the use cases and their specific semantics.
> 
> It seems were stuck between a rock and a hard place: I don't think there's a way to make things explicit and clear across use cases whilst sticking with JWT semantics only (as clear as the semantics may be in their own RFC7519 context). I also don't think there's a way to make things explicit and clear without breaking existing deployments and existing spec text which is as awkward.
> 
> Hans.
> 
> On Thu, Apr 4, 2019 at 5:58 PM Schanzenbach, Martin <[email-masked]> wrote:

Martin Schanzenbach
Fraunhofer AISEC

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 4 Apr 2019 10:19:51 -0700

But before I get in the details, let me make an uber-point.
I am acutely aware of the potential for confusion and abuse in the context
of OAuth and sign in, the article you pointed to quotes my own articles on
the matter extensively. But there are concrete aspects that need to be
considered about what developers are trying to achieve in practice.
OAuth2 is the de facto mechanism to secure API calls nowadays. That
includes scenarios not directly addressed by the spec, such as first party
APIs. People do that for 1st party APIs as well because they can leverage a
well supported mechanism for driving authentication experiences and
outsource authentication to products and services.
Forgetting for a second about the fact that 3rd party APIs can use identity
and authentication levels info as well, let me focus for a second on 1st
party APIs. From the functionality perspective, delivering an app as a web
site or as a native client+API combination doesn't change the business
requirements and the information a backend needs to do its job.
Given that we tell people NOT to use ID tokens for calling APIs: if a
developer chooses to deliver their app as a native client+API instead of a
web site, the only artifact they have available is the access token. So
either we embed the info in the access token, and we do what we can to
prevent abuse and the most likely pitfalls/privacy challenges/etc in the
guidance, or we find a way for 1st party APIs to consume ID tokens (which
is problematic- I discussed this with John and Nat at OSW and the place we
got stuck on was that we can; safely use sender constrain in that
scenario). And to pre-empt comments on userinfo, that's asking for a lot of
extra moving parts- the only outcome will be that people will keep
embedding the info they need in the AT, but will do so in non-interoperable
way, and without the guidance and warnings that would at least contain some
of the damage.

That said, inline.

> OAuth (i.e. the https://oauth.net/articles/authentication/ article).

see preamble.

> to die on (at the present time anyway)..

Noted :) does the fact that in some scenarios the AT might be the *only*
artifact a backend will receive change the stance?

 By the time it came up again near the end of the last unconference
> session, I wasn't wanting to prolong things because I was kinda worn out
> for the day and wanting to get to Frankfurt that evening before sunset
> ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ).

Sorry for having tired you out :) at the time I echoed back what was
suggested (to reflect the original values in the session) precisely to make
sure everyone had a chance to push back, and I got lots of nods (including
from John who was in the first row). I misinterpreted your silence as
assent, given that during that session you did chime in on other matters..
but I was expecting the discussion to keep going on the ML anyway, so it's
all according to plan :)

> authentication-centric claims in an access token can be confusing.

 I agree it can be confusing, but to me that makes the need to provide
guidance on it more compelling, not less. There are important scenarios
where access decisions are made on the basis of that information, and
implementations WILL find a way to get the info they are interested into.
To me that's all the more reasons to provide guidance on how to do so being
aware of pitfalls and with whatever protections we can put in place, as
opposed to leave developers to their own device.

On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> achieved by the resource setting and contract with the AS, along the lines
>> of what David said, it's actually not uncommon for those policies to be
>> assigned on the resource AFTER the current session was established and/or
>> the corresponding AT was obtained and cached. Furthermore, the requirement
> to die on (at the present time anyway)..
>
>
>
> Our recollection of OSW differs somewhat. As I recall there was support
> for pointing to identity claims from OIDC for additional end-user info. But
>> But I am completely open to change it of course, especially for cases
>> like the one identified by George.
>>
>
>>> (beyond just the fact that some people are already doing it) for auth_time,
>>> acr, and amr to be available in OAuth JWT access tokens.. Those claims are
>>>> Do we know if there is a justifying use case for auth_time, acr, and
>>>> amr to be available in OAuth JWT access tokens? These are meant to be
>>>> messages about the client, either directly (in the case of client
>>>> credentials) or about its delegated authorization of the user.
>>>>
>>>> Embedding attributes about the user (such as group membership and
>>>> roles) can be used for the resource to make finer-grained decisions than
>>>> scopes, but normally I would expect say acr limitations enforced by a
>>>> resource to instead be controlled by the AS requiring a higher quality
>>>> authentication to release certain scopes.
>>>>
> your computer. Thank you.*

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 4 Apr 2019 10:34:54 -0700

Hey George! Thanks for the comments. nline

The issue here is that the 'aud' of the id_token is the recipient of the
> id_token (i.e. the client). However, for access_tokens the 'aud' value
> should be the resource service that will receive the access_token. There is
> no existing guidance for this and we should provide such guidance as this
> is "kind of new" for OAuth2 (from an explicit specification perspective).

Fair enough. We do provide more specific guidance on the use of audience
for API, the language you quote later on being an example of that.

> present. Not sure if we want to include this concept or not.

We embedded that in the client_id claim. I originally had azp but got
strong pushback, given the debacle it caused in the past (see
https://bitbucket.org/openid/connect/issues/1009/contradictory-statements-about-id-token?fbclid=IwAR2iPZcEStXGXB-9SW0889Ky1cpKbK8h1WdjyQX2PKMly4nN6050Na4KfYw
,
https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-underspecified-and?fbclid=IwAR0IN6JT_jPqukOzsbegJLY2MXl1xnplURjXoxSyhd3kvgfw6Nj6LsPLU5M
).

I think for most implementations this would amount to... define an audience
> that covers all the resource services where the access token can be
> returned and set that as the audience (e.g. urn:x-mydomain:apis). Which is
> perfectly legal but maybe not in the spirit of the spec:) I am receiving

This is an interesting point. In my experience, the main boundary used to
define a resource is either reflecting an underlying, *actual* resource
that exists independently of the API facade slapped on top of it (say a VM)
or it is the context within a certains et of scopes makes sense (say an API
facading access to a bunch of documents).
Some of that criterion is reflected in the rationale for sigle value
audiences. Do you think it should be made more explicit? Perhaps in a
dedicated section?

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Thu, 4 Apr 2019 17:39:56 +0000

Hi Vittorio,

> On 4. Apr 2019, at 19:19, Vittorio Bertocci <Vittorio=[email-masked]> wrote:
> 
> But before I get in the details, let me make an uber-point..
> I am acutely aware of the potential for confusion and abuse in the context of OAuth and sign in, the article you pointed to quotes my own articles on the matter extensively. But there are concrete aspects that need to be considered about what developers are trying to achieve in practice.
> OAuth2 is the de facto mechanism to secure API calls nowadays. That includes scenarios not directly addressed by the spec, such as first party APIs. People do that for 1st party APIs as well because they can leverage a well supported mechanism for driving authentication experiences and outsource authentication to products and services.
> Forgetting for a second about the fact that 3rd party APIs can use identity and authentication levels info as well, let me focus for a second on 1st party APIs. From the functionality perspective, delivering an app as a web site or as a native client+API combination doesn't change the business requirements and the information a backend needs to do its job.
> Given that we tell people NOT to use ID tokens for calling APIs: if a developer chooses to deliver their app as a native client+API instead of a web site, the only artifact they have available is the access token. So either we embed the info in the access token, and we do what we can to prevent abuse and the most likely pitfalls/privacy challenges/etc in the guidance, or we find a way for 1st party APIs to consume ID tokens (which is problematic- I discussed this with John and Nat at OSW and the place we got stuck on was that we can; safely use sender constrain in that scenario).
> And to pre-empt comments on userinfo, that's asking for a lot of extra moving parts- the only outcome will be that people will keep embedding the info they need in the AT, but will do so in non-interoperable way, and without the guidance and warnings that would at least contain some of the damage.

Userinfo is OIDC. Do you mean rfc7662?
So you say that the use of a token introspection endpoint like rfc7662 is not always viable, right?
I kind of agree that you might want to have this information in the token, if possible. You can save a lot of round trips over time (at the expense of revocation).
But then, we should simply take that (rfc7662) as a boilerplate for the JWT, not OIDC.
An introspection response also contains scopes, username and optional additional claims (e.g. OIDC / authN specific claims).
I think an access token JWT should not convey more / other information than a token introspection endpoint.

BR

> 
> That said, inline.
> 
> My concern isn't with reusing the names/types of the claims per se.  But more generally that codifying the use of certain authentication-centric claims in the context of an access token furthers the potential confusion around authentication vs. authorization that has been a nagging problem for OAuth (i.e. the https://oauth.net/articles/authentication/ article).
> see preamble.
> 
> I  understand what you are saying but but personally do not find it sufficiently compelling.  But that's just my opinion and not a hill I want to die on (at the present time anyway)..
> Noted :) does the fact that in some scenarios the AT might be the *only* artifact a backend will receive change the stance?
> 
>  By the time it came up again near the end of the last unconference session, I wasn't wanting to prolong things because I was kinda worn out for the day and wanting to get to Frankfurt that evening before sunset ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ).
> Sorry for having tired you out :) at the time I echoed back what was suggested (to reflect the original values in the session) precisely to make sure everyone had a chance to push back, and I got lots of nods (including from John who was in the first row). I misinterpreted your silence as assent, given that during that session you did chime in on other matters.. but I was expecting the discussion to keep going on the ML anyway, so it's all according to plan :)
> 
>  FWIW, to me, George's suggestion "assume[ing] that the auth_time value should be updated to the latest time at which the user authenticated" though some unspecified and in many cases non-existent link between the AT and a current user session at the AS is an example of how authentication-centric claims in an access token can be confusing.
>  I agree it can be confusing, but to me that makes the need to provide guidance on it more compelling, not less. There are important scenarios where access decisions are made on the basis of that information, and implementations WILL find a way to get the info they are interested into. To me that's all the more reasons to provide guidance on how to do so being aware of pitfalls and with whatever protections we can put in place, as opposed to leave developers to their own device.
> 
> On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell <bcampbell=[email-masked]> wrote:
> On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci <Vittorio=[email-masked]> wrote:
> I am not married to the claim types used in here, so if you think that reusing the ones in the id_token can cause confusion we should expand on the specific ways in which you think might go south.
> 
> My concern isn't with reusing the names/types of the claims per se.  But more generally that codifying the use of certain authentication-centric claims in the context of an access token furthers the potential confusion around authentication vs. authorization that has been a nagging problem for OAuth (i.e. the https://oauth.net/articles/authentication/ article).
> 
> 
> However I think it's important that the information on say, whether the current token was obtained using MFA or a specific authentication factor is something that API developers can legitimately latch to when doing authorization decisions. From the perspective of a developer modeling a solution, whether functionality is delivered as a route in a postback based web app (hence receiving an id_token or derived) or as an API consumed by a native app, the business requirement gating access to that functionality doesn't change. If the admin managing that resource establishes that access should be performed only via MFA, the developer should be equipped to enforce that regardless of the stack used to expose functionality (web app, API).
> Although it is true that triggering the desired behavior might be achieved by the resource setting and contract with the AS, along the lines of what David said, it's actually not uncommon for those policies to be assigned on the resource AFTER the current session was established and/or the corresponding AT was obtained and cached. Furthermore, the requirement might be more granular than an AS policy can tolerate (an API might requires MFA only for certain routes, hence hard to express in a static policy) and triggered in form of challenges. So the situation in which you have an AT with the right issuer, audience, etc but was obtained with a policy now obsolete/unacceptable to the RP is strong. Requesting to support revocation just for this seems overkill, especially given that the scenario in which the same logical app is exposed as both web app and native client+API, the code consuming those claims is already in place. It just makes intuitive sense for developers.
> In summary, one can take steps to push as much of the MFA requirements to the AS settings for a particular request, but ultimately the desire of the API developer to enforce that it actually happened is a requirement I encountered often in practice. Anything providing extra context to refine decisions about it (like auth_time, which might inform decisions about whether to accept an MFA check occurred N minutes ago or refuse access).
> 
> I understand what you are saying but but personally do not find it sufficiently compelling.  But that's just my opinion and not a hill I want to die on (at the present time anyway)..
> 
> 
> 
> I thought that reusing the existing names for the same concepts just made sense (dev existing skills, existing codebases, etc etc) and especially in the case in which the values are exactly the same, and the idea seemed to receive good support during OSW.
> 
> Our recollection of OSW differs somewhat. As I recall there was support for pointing to identity claims from OIDC for additional end-user info. But there was some grumbling (from John and myself at least) at first mention of acr/amr and auth_time. By the time it came up again near the end of the last unconference session, I wasn't wanting to prolong things because I was kinda worn out for the day and wanting to get to Frankfurt that evening before sunset ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ).
> 
> 
> But I am completely open to change it of course, especially for cases like the one identified by George.
> 
> FWIW, to me, George's suggestion "assume[ing] that the auth_time value should be updated to the latest time at which the user authenticated" though some unspecified and in many cases non-existent link between the AT and a current user session at the AS is an example of how authentication-centric claims in an access token can be confusing.
> 
> 
> 
> WDYT?
> 
> On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=[email-masked]> wrote:
> +1 to David's question here. I'd like to see justifying use cases (beyond just the fact that some people are already doing it) for auth_time, acr, and amr to be available in OAuth JWT access tokens.. Those claims are defined for, and in the context of, an ID Token and I fear that codifying their use in an access token will lead to misuse and/or confusion.
> 
> On Mon, Apr 1, 2019 at 1:03 PM David Waite <[email-masked]> wrote:
>>    auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core
>> ].
> 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._______________________________________________
> OAuth mailing list
> [email-masked]
> 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.

Martin Schanzenbach
Fraunhofer AISEC

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 4 Apr 2019 10:40:43 -0700

>
> As an aside, I worry about trying to put all information needed to make a
> dynamic policy decision into an access token.

I am not suggesting any of this would be exhaustive. The intent is to give
guidance on the most commonly used elements, stuff we already know is being
considered. Besides achieving some level of interop, this can help educate
readers on what are the things one typically watch out for- and could lead
to better decisions even for other attributes they choose to add outside of
the scope of this profile.

> For cases where the policy can change over time including the lifetime of
> the access_token then I prefer the User Managed Access (UMA) approach as it
> inherently allows for dynamic policy change

I think simplicity is key here. Having the info available allows developers
to be confident they can enforce their requirements transparently, using
off the shelf software components.

On Thu, Apr 4, 2019 at 7:14 AM George Fletcher <gffletch=
[email-masked]> wrote:

> As an aside, I worry about trying to put all information needed to make a
> dynamic policy decision into an access token. For cases where the policy
> can change over time including the lifetime of the access_token then I
> prefer the User Managed Access (UMA) approach as it inherently allows for
> dynamic policy change.
>
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 4 Apr 2019 10:51:14 -0700

Thanks Martin. Inline

I kind of agree that you might want to have this information in the token,
> if possible. You can save a lot of round trips over time (at the expense of
> revocation).

Yep, this entire profile idea emerged as acknowledgement that a large
number of services and products choose to use format driven validation.

 But then, we should simply take that (rfc7662) as a boilerplate for the
> JWT, not OIDC.
> An introspection response also contains scopes, username and optional
> additional claims (e.g. OIDC / authN specific claims)
>
Ultimately all I care about is that we give guidance to developers on on
how to transport in JWT encoded ATs the info their API need. In the initial
formulation I referred to OIDC because in my experience most of the
existing software being used to consume JWT ATs is largely "jury-rigged"
middleware either meant to be used for id_tokens or reusing infrastructure
meant for OIDC (discovery, etc).
As long as the expressive power is the same, I am happy to switch all the
references from OIDC to rfc7662. Developers won't care either ways as long
as they can get the job done.

> than a token introspection endpoint.

Could you expand on this? Could you make a concrete example of a claim you
can get through OIDC that you would not want included in an AT, and why? I
am especially interested in this from the PoV of the 1st party API scenario
I described earlier: if an AT is all you are getting , it seems you should
be able to get any info you could have gotten otherwise.

On Thu, Apr 4, 2019 at 10:40 AM Schanzenbach, Martin <
[email-masked]> wrote:

> > I am acutely aware of the potential for confusion and abuse in the
> context of OAuth and sign in, the article you pointed to quotes my own
> articles on the matter extensively. But there are concrete aspects that
> need to be considered about what developers are trying to achieve in
> practice.
> > Forgetting for a second about the fact that 3rd party APIs can use
> identity and authentication levels info as well, let me focus for a second
> on 1st party APIs. From the functionality perspective, delivering an app as
> a web site or as a native client+API combination doesn't change the
> business requirements and the information a backend needs to do its job.
> got stuck on was that we can; safely use sender constrain in that scenario).
> > And to pre-empt comments on userinfo, that's asking for a lot of extra
> moving parts- the only outcome will be that people will keep embedding the
> info they need in the AT, but will do so in non-interoperable way, and
> without the guidance and warnings that would at least contain some of the
> damage.
>
> I kind of agree that you might want to have this information in the token,
> if possible. You can save a lot of round trips over time (at the expense of
> revocation).
> An introspection response also contains scopes, username and optional
> additional claims (e.g. OIDC / authN specific claims).
> to the AS settings for a particular request, but ultimately the desire of
> the API developer to enforce that it actually happened is a requirement I
> especially in the case in which the values are exactly the same, and the
> idea seemed to receive good support during OSW.
> >
> >>>     • 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
> >>>     • I put together a presentation summarizing my findings and
> >>>     • The presentation was followed up by 1.5 hours of unconference
> Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there and
> contributed generously to the discussion. Thank you!!!
> >>>     • On my flight back I did my best to incorporate all the ideas and
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> attachments from your computer. Thank
> you._______________________________________________
> > OAuth mailing list
> > [email-masked]
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> attachments from your computer. Thank you.

---

From: George Fletcher <[email-masked]>
Date: Thu, 4 Apr 2019 15:17:26 -0400

I get your 1st party use case and if you think about a company that 
might have multiple endpoints on different domains that provide API 
services all invoked by a mobile app... requiring the mobile app to 
effectively downscope (or resource indicator bind) tokens means a lot of 
chatter between the mobile app to the AS to obtain appropriate tokens. 
And all this over a connection that does have latency issues.

That said, having a single token that is authorized to access all those 
services has it's own risks.

I'm not sure about a structure like...
    https://user.example.com
       scope: profile
    https://mail.example.com
       scope: mail-write
    https://cal.example.com
       scope: calendar-write

User Managed Access (UMA) [1] explicitly defines this structure but it's 
not embedded in the UMA access token.

[1] 
https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html#permission-endpoint

I suppose a need to support multiple audiences within a given access 
token kind of necessitates the need to bind the scopes with the 
audience/resource.

On 4/4/19 1:34 PM, Vittorio Bertocci wrote:
>     audience that covers all the resource services where the access
>     token can be returned and set that as the audience (e.g.
>     urn:x-mydomain:apis). Which is perfectly legal but maybe not in
>     the spirit of the spec:) I am receiving feedback from developers
>     that binding access tokens narrowly to the resource where they
>     will be presented is concerning from a chattiness perspective
>     (latency issues) and general load on the deployed AS infrastructure.
>
> This is an interesting point. In my experience, the main boundary used 
> to define a resource is either reflecting an underlying, *actual* 
> resource that exists independently of the API facade slapped on top of 
> it (say a VM) or it is the context within a certains et of scopes 
> makes sense (say an API facading access to a bunch of documents).
[rest of thread snipped]

---

From: Mike Jones <[email-masked]>
Date: Thu, 4 Apr 2019 19:48:33 +0000

I agree with George that the subject of a token must be the principal of that token.  That what the JWT “sub” claim is for.  Indeed, the first sentence of the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
The "sub" (subject) claim identifies the principal that is the subject of the JWT.

If an access token uses “sub”, its usage must comply with the definition from RFC 7519.

                                                                -- Mike

From: OAuth <[email-masked]> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <[email-masked]>
Cc: Vittorio Bertocci <Vittorio=[email-masked]>; IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Thanks,
George

Hans.

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <[email-masked]<mailto:[email-masked]>> wrote:
I agree that this will break a lot of existing flows... especially those using any form of the client_credentials flow. In that sense I'm not completely on board yet :)
On 3/26/19 12:56 PM, Hans Zandbelt wrote:
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]<mailto:[email-masked]>> wrote:

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>>:
From an access token consumer (aka API) developer point of view, I prefer this logic

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

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci <[email-masked]<mailto:[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.

Thanks
V.

On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <[email-masked]<mailto:[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]<mailto:[email-masked]>> wrote:
Yes I know - and I think in hindsight it was a mistake to use the same claim type for multiple semantics.

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.
The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:

Hans.

On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier <[email-masked]<mailto:[email-masked]>> wrote:
IMHO the sub claim should always refer to the user - and nothing else.

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

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

--
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked]<mailto:steinar@udelt..no> | [email-masked]<mailto:[email-masked]>  | +47 955 21 620 | www.udelt.no<http://www.udelt.no/> |
_______________________________________________
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>

OAuth mailing list

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

--
[email-masked]<mailto:[email-masked]>
ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu>

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 4 Apr 2019 21:58:51 +0200

the definition of RFC 7519 is actually "petitio principii" and a lot of
deployments put claims about the Resource Owner in the access token (as a
Resource Server implementer I've suffered a lot from this)

Hans.

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <[email-masked]>
wrote:

> I agree with George that the subject of a token must be the principal of
> that token.  That what the JWT “sub” claim is for.  Indeed, the first
> sentence of the “sub” definition at
> https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
>
> *From:* OAuth <[email-masked]> *On Behalf Of *George Fletcher
> *Sent:* Thursday, April 4, 2019 8:51 AM
> *To:* Hans Zandbelt <[email-masked]>
> *Cc:* Vittorio Bertocci <Vittorio=[email-masked]>; IETF oauth
> WG <[email-masked]>
> *Subject:* Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
>
>
>
> The subject of a token should be the principal of that token. It shouldn't
> matter whether that is a machine, a user, or a device. Trying to separate
> out "humans" as a special class will just make things more complicated. If
> we need a claim to identify the subject is a "human" then why not just add
> that. This doesn't break anything and makes it easy for people to detect
> this case in those use cases where it's required.
>
> Thanks,
> George
>
> 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.
>
>
>
> 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
> 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
> 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.
>
>
>
> | [email-masked] <steinar@udelt..no> | [email-masked]  | +47 955 21 620 |
> www.udelt.no |
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 4 Apr 2019 20:09:44 +0000

I get that existing practice is likely to be all over the map, but if we’re to create a JWT access token standard, it’s reasonable to require that the claims usage comply with the JWT standards.

                                                                -- Mike

From: Hans Zandbelt <[email-masked]>
Sent: Thursday, April 4, 2019 12:59 PM
To: Mike Jones <[email-masked]>
Cc: George Fletcher <gffletch=[email-masked]>; Vittorio Bertocci <Vittorio=[email-masked]>; IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

the definition of RFC 7519 is actually "petitio principii" and a lot of deployments put claims about the Resource Owner in the access token (as a Resource Server implementer I've suffered a lot from this)

Hans.

On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I agree with George that the subject of a token must be the principal of that token.  That what the JWT “sub” claim is for.  Indeed, the first sentence of the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 is:
The "sub" (subject) claim identifies the principal that is the subject of the JWT.

                                                                -- Mike

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of George Fletcher
Sent: Thursday, April 4, 2019 8:51 AM
To: Hans Zandbelt <[email-masked]<mailto:[email-masked]>>
Cc: Vittorio Bertocci <Vittorio=[email-masked]<mailto:[email-masked]>>; IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

Thanks,
George

Hans.

Hans.

<mvh>Steinar</mvh>

Sent from my iPhone

Thanks
V.

Hans.

Dominick

Hans.

OIDC says:

cheers
Dominick

One feedback.

thanks

nov

Dear all,

--
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

OAuth mailing list

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 4 Apr 2019 22:11:15 +0200

I also meant to say that (of course) the JWT standard doesn't say that the
JWT is supposed to be about the client or about the resource owner, hence
both are valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <[email-masked]>
wrote:

> I get that existing practice is likely to be all over the map, but if
> we’re to create a JWT access token standard, it’s reasonable to require
> that the claims usage comply with the JWT standards.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Hans Zandbelt <[email-masked]>
> *Sent:* Thursday, April 4, 2019 12:59 PM
> *To:* Mike Jones <[email-masked]>
> *Cc:* George Fletcher <gffletch=[email-masked]>; Vittorio
> Bertocci <Vittorio=[email-masked]>; IETF oauth WG <
> [email-masked]>

---

From: Binningsbø, Jørgen <[email-masked]>
Date: Tue, 26 Mar 2019 16:35:01 +0000

Hi,

We have a machine-to-machine scenario where clients, RSes and our AS all belong to different legal entities.

Some RSes require their clients to limit the access token to a specific Resource Owner, while other RSes don't. In the former case, we use 'sub' to identify that Resource Owner.  In such a mixed deployment scenario, allowing using 'sub' for different meanings can lead to confusion, so I think the actual meaning should be explicitly signalled like Dave suggests below.

Having said that, I do prefer to limit the usage of 'sub' in access tokens for the End User only.

As a side note, in our case we need a more formal client identification than the client_id alone (as they are randomly generated by DCR),  and have thus opted for a custom claim `client_owner` containing the registered company identifier.  We pull this out from certificate used to sign the JWT-grant (RFC7523) from the token request.   We could of course have used ‘sub’ for client_owner, but that would require us to invent another custom claim for those RSes that requires RO-limited tokens.    To make matters even more complicated, there might be business delegation happening,  where company A running the client is acting on behalf of different other companies B,C,D… and the instantaneous A+B or A+C relation also have to be communicated in the token  (According to EU privacy laws, I belive A is the Data Processor and their customer B,C,D… are Data Controller).   So again this leads me to think that client identification should be kept in separate claims.

Anyway, for us as user of the oauth2 protocols, this draft is welcome !

Kind regards,
--
Jørgen Binningsbø
Product Owner, Norwegian National eID Infrastructure (ID-porten)

Fra: OAuth <[email-masked]> På vegne av Dave Tonge
Sendt: tirsdag 26. mars 2019 09.27
Til: Dominick Baier <[email-masked]>
Kopi: IETF oauth WG <[email-masked]>
Emne: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

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]<mailto:[email-masked]>> wrote:
From an access token consumer (aka API) developer point of view, I prefer this logic

Sent from my iPhone

Thanks
V.

Hans.

Dominick

Hans.

OIDC says:

cheers
Dominick

One feedback.

thanks

nov

Dear all,

--

---

From: Brian Campbell <[email-masked]>
Date: Mon, 8 Apr 2019 12:33:17 -0600

"quotes my own articles on the matter extensively" - I know and almost
mentioned that but didn't want to further embolden your ego :)

Silence is rarely assent. Especially near the end of the last session of
the last day of a workshop. And when I've got a train to catch.

I am somewhat sympathetic to the "... more reasons to provide guidance on
how to do so being aware of pitfalls ... " line of reasoning. But I'd
already indicated my intent to not fight you on this one anymore so that
doesn't change much. Carry on then.

On Thu, Apr 4, 2019 at 11:20 AM Vittorio Bertocci <Vittorio=
[email-masked]> wrote:

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