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 | h...@udelt.no | +47 955 21 620 | www.udelt.no |
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
