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
