I notice that a few of my emails to the OAuth WG list have come through with the From field from “oauth-bounces”:
From: OAuth <oauth-boun...@ietf.org> On Behalf Of Neil Madden Is this normal? I checked my subscription status on mailman and I’m posting from the same email address that I subscribed from. Cheers, Neil > On 7 May 2019, at 10:25, Hannes Tschofenig <hannes.tschofe...@arm.com> wrote: > > No, it is definitely not too late for your comment > > From: OAuth <oauth-boun...@ietf.org> On Behalf Of Neil Madden > Sent: Dienstag, 7. Mai 2019 11:18 > To: IETF oauth WG <oauth@ietf.org> > Subject: [OAUTH-WG] OAuth security topics > > Is it too late to add the observation below to the OAuth security topics BCP > draft? > > > > Begin forwarded message: > > From: Neil Madden <neil.mad...@forgerock.com > <mailto:neil.mad...@forgerock.com>> > Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > Date: 7 May 2019 at 09:37:29 BST > To: Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org > <mailto:Vittorio=40auth0....@dmarc.ietf.org>> > Cc: Hans Zandbelt <hans.zandb...@zmartzone.eu > <mailto:hans.zandb...@zmartzone.eu>>, Karl McGuinness <kmcguinn...@okta.com > <mailto:kmcguinn...@okta.com>>, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>>, IETF oauth WG <oauth@ietf.org > <mailto:oauth@ietf.org>> > > I wasn’t at IIW so I may be missing some context. > > There is a potential security issue if the client_id is used as the “sub” for > an AT obtained via client_credentials. If the client can register itself with > a self-chosen client_id then it may deliberately chose a client_id that > matches the user name of a privileged user. An RS that just blindly looks at > the “sub” claim may then erroneously let the client perform privileged > actions. > > Is this the context of the discussion? > > Given that there are a lot of RSes in existence, many of which are probably > just looking at the “sub” claim to identify the resource owner, I think the > onus is on the AS to ensure that no such ambiguity can arise in the first > place by ensuring that the space of “sub” values for client credentials is > disjoint with the space for genuine users or by disallowing the > client_credentials grant altogether. > > This issue already arises in token introspection though, so maybe ought to be > mentioned in the OAuth security topics draft rather than specific to the JWT > AT draft? > > — Neil > > > On 6 May 2019, at 18:32, Vittorio Bertocci > <Vittorio=40auth0....@dmarc.ietf.org > <mailto:Vittorio=40auth0....@dmarc.ietf.org>> wrote: > > Hi all, > thanks for your patience during this month long hiatus, and thanks for the > comments. > Last week at IIW I had the opportunity to discuss this with many of the > people on the list. Here's a summary of where the discussion landaed on the > subject of the sub (pun intended). > > - It seems that RFC 7519 has pretty clear language on the use of sub- I > didn't check it back when we started the discussion. I do agree with the > people saying that we shouldn't violate existing specifications, hence it > looks like we do need to have sub also in the case in which we have app-only > tokens carrying claims about the app itself. I understand this will cause > some implementation to break, but unfortunately that's intrinsic in the > process of coming up with a common approach and standards compliance is > probably one of the strongest reasons to tolerate that. > - That said, I am strongly committed to preserve existing functionality. One > of the main reasons that was brought up for including sub only for user based > ATs was to use it as heuristic for telling those tokens apart from app-only > ones. To that end, Karl MCGuinness suggested that we include grant_type as a > return claim, which the RS could use to the same effect. I find the proposal > very clever, and the people at IIW thought so as well. What you think? > Note, John Bradley observed that in some cases this might lead to ambiguous > results if an extension grant is used (say an assertion profile) but that > seems like a relatively fringe occurrence. > > On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <hans.zandb...@zmartzone.eu > <mailto:hans.zandb...@zmartzone.eu>> wrote: > I also meant to say that (of course) the JWT standard doesn't say that the > JWT is supposed to be about the client or about the resource owner, hence > both are valid > > Hans. > > On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <michael.jo...@microsoft.com > <mailto:michael.jo...@microsoft.com>> wrote: > I get that existing practice is likely to be all over the map, but if we’re > to create a JWT access token standard, it’s reasonable to require that the > claims usage comply with the JWT standards. > > -- Mike > > From: Hans Zandbelt <hans.zandb...@zmartzone.eu > <mailto:hans.zandb...@zmartzone.eu>> > Sent: Thursday, April 4, 2019 12:59 PM > To: Mike Jones <michael.jo...@microsoft.com > <mailto:michael.jo...@microsoft.com>> > Cc: George Fletcher <gffletch=40aol....@dmarc.ietf.org > <mailto:40aol....@dmarc...ietf.org>>; Vittorio Bertocci > <Vittorio=40auth0....@dmarc.ietf.org <mailto:40auth0....@dmarc.ietf.org>>; > IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>> > Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > > the definition of RFC 7519 is actually "petitio principii" and a lot of > deployments put claims about the Resource Owner in the access token (as a > Resource Server implementer I've suffered a lot from this) > > Hans. > > On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <michael.jo...@microsoft.com > <mailto:michael.jo...@microsoft.com>> wrote: > I agree with George that the subject of a token must be the principal of that > token. That what the JWT “sub” claim is for. Indeed, the first sentence of > the “sub” definition at https://tools.ietf.org/html/rfc7519#section-4.1.2 > <https://tools.ietf.org/html/rfc7519#section-4.1.2> is: > The "sub" (subject) claim identifies the principal that is the subject of the > JWT. > > If an access token uses “sub”, its usage must comply with the definition from > RFC 7519. > > -- Mike > > From: OAuth <oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>> On > Behalf Of George Fletcher > Sent: Thursday, April 4, 2019 8:51 AM > To: Hans Zandbelt <hans.zandb...@zmartzone.eu > <mailto:hans.zandb...@zmartzone.eu>> > Cc: Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org > <mailto:40auth0....@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org > <mailto:oauth@ietf.org>> > Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > > 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 <gffle...@aol.com > <mailto:gffle...@aol.com>> 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=40auth0....@dmarc.ietf.org <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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 inhttps://tools.ietf.org/html/rfc7519#section-4.1.2 > <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 > <mailto: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 > <mailto: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 > <mailto: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/ > <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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > -- > hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> > ZmartZone IAM -www.zmartzone.eu <http://www.zmartzone.eu/> > > > -- > hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> > ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > -- > Vennlig hilsen > > Steinar Noem > Partner Udelt AS > Systemutvikler > > | stei...@udelt.no <mailto:stei...@udelt..no> | h...@udelt.no > <mailto:h...@udelt.no> | +47 955 21 620 | www.udelt.no > <http://www.udelt.no/> | > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > -- > hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> > ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > -- > hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> > ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> > > > > -- > hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> > ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> > > > -- > hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> > ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
