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

[George Fletcher <[e-mail]>]

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]
> https://www.ietf.org/mailman/listinfo/oauth