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

[George Fletcher <[e-mail]>]

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 
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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=[e-mail]
>>     <mailto:[e-mail]>> 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
>>         <[e-mail] <mailto:[e-mail]>> 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
>>             <[e-mail]
>>             <mailto:[e-mail]>>:
>>
>>                 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
>>                 ([e-mail] <mailto:[e-mail]>) 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
>>>                 <[e-mail] <mailto:[e-mail]>> 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
>>>>                 <[e-mail]
>>>>                 <mailto:[e-mail]>> 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
>>>>                     <[e-mail]
>>>>                     <mailto:[e-mail]>> 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 ([e-mail]
>>>>                         <mailto:[e-mail]>) 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 <[e-mail]
>>>>>                         <mailto:[e-mail]>> 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 ([e-mail]
>>>>>                             <mailto:[e-mail]>) 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=[e-mail]
>>>>>>>                             <mailto:vittorio.bertocci=[e-mail]>>
>>>>>>>                             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
>>>>>>>                             [e-mail] <mailto:[e-mail]>
>>>>>>>                             https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>                             _______________________________________________
>>>>>>                             OAuth mailing list
>>>>>>                             [e-mail] <mailto:[e-mail]>
>>>>>>                             https://www.ietf.org/mailman/listinfo/oauth
>>>>>                             _______________________________________________
>>>>>                             OAuth mailing list
>>>>>                             [e-mail] <mailto:[e-mail]>
>>>>>                             https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>                         --
>>>>>                         [e-mail]
>>>>>                         <mailto:[e-mail]>
>>>>>                         ZmartZone IAM - www.zmartzone.eu
>>>>>                         <http://www.zmartzone.eu>
>>>>
>>>>
>>>>
>>>>                     --
>>>>                     [e-mail]
>>>>                     <mailto:[e-mail]>
>>>>                     ZmartZone IAM - www.zmartzone.eu
>>>>                     <http://www.zmartzone.eu>
>>>>
>>                 _______________________________________________
>>                 OAuth mailing list
>>                 [e-mail] <mailto:[e-mail]>
>>                 https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>             -- 
>>             Vennlig hilsen
>>
>>             Steinar Noem
>>             Partner Udelt AS
>>             Systemutvikler
>>             | [e-mail] <mailto:steinar@udelt..no> |
>>             [e-mail] <mailto:[e-mail]>  | [phone] |
>>             www.udelt.no <http://www.udelt.no/> |
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>     -- 
>>     [e-mail] <mailto:[e-mail]>
>>     ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> -- 
> [e-mail] <mailto:[e-mail]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>