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= 40auth0....@dmarc.ietf.org> 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 <stei...@udelt.no> 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 < >> dba...@leastprivilege.com>: >> >>> 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 (mat...@gmail.com) 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 <vitto...@auth0.com> 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 < >>> hans.zandb...@zmartzone.eu> 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 < >>>> dba...@leastprivilege.com> 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 ( >>>>> hans.zandb...@zmartzone.eu) 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 < >>>>> dba...@leastprivilege.com> 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 (mat...@gmail.com) 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=40auth0....@dmarc.ietf.org> 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 >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> >>>>> -- >>>>> hans.zandb...@zmartzone.eu >>>>> ZmartZone IAM - www.zmartzone.eu >>>>> >>>>> >>>> >>>> -- >>>> hans.zandb...@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> -- >> Vennlig hilsen >> >> Steinar Noem >> Partner Udelt AS >> Systemutvikler >> >> | stei...@udelt.no <stei...@udelt..no> | h...@udelt.no | +47 955 21 620 >> | www.udelt.no | >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
