I agree. Maybe RFC 7519 is actually as good as it gets wrt claim specifications? At least for OAuth. Use case specific profiles can/must then use their own definitions (see OIDC) for (JWT) ATs. I mean, at least for OIDC, an AT which is the result of a client credential grant isn't even a thing which really simplifies the specification of a JWT AT in OIDC.
So maybe just reference / rely on RFC 7519 for the basic claims and clarify usage of this JWT using the typ? > On 4. Apr 2019, at 18:29, Hans Zandbelt <hans.zandb...@zmartzone.eu> wrote: > > I believe the root problem is that we're trying to unify across tokens that > are issued for different use cases (auth vs. authz), different subjects and > different audiences. The JWT spec allows us to cover those use cases nicely > within its own semantics but the profile specific use case semantics are > really different at heart. This problem becomes even more apparent in SPAs > that share both the id_token and the access_token across frontend and > backend: the RS then needs to flip back and forth between the use cases and > their specific semantics. > > It seems were stuck between a rock and a hard place: I don't think there's a > way to make things explicit and clear across use cases whilst sticking with > JWT semantics only (as clear as the semantics may be in their own RFC7519 > context). I also don't think there's a way to make things explicit and clear > without breaking existing deployments and existing spec text which is as > awkward. > > Hans. > > On Thu, Apr 4, 2019 at 5:58 PM Schanzenbach, Martin > <martin.schanzenb...@aisec.fraunhofer.de> wrote: > I think what needs to be clarified is whether the "sub" claim should denote > the caller (=client) or the RO in the case of an JWT AT. > RFC 7519 only defines "sub" to be the principal which is the subject of all > claims in the JWT. > This means that the AT can contain either claims regarding the client OR the > RO, but not both. (I prefer to use RO instead of user as I think this a term > better used in OIDC). > > Now, the question is what does an RS need to make an authorisation decision? > Claims about the client or claims about the RO? > Since OIDC already has ID Tokens as JWT which have the RO as "sub", maybe it > makes sense to have the client as sub for the AT? > If the RS needs claims about the RO in order to do authorization decisions, > maybe it needs to be presented with an ID Token (which would imply that it is > issued with the RS in its aud claim). > > > On 4. Apr 2019, at 17:50, George Fletcher > > <gffletch=40aol....@dmarc.ietf.org> wrote: > > > > 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> 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> 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 > >>>>>>>> ) - 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 > >>> > >>> > >>> -- > >>> hans.zandb...@zmartzone.eu > >>> ZmartZone IAM - www.zmartzone.eu > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > Martin Schanzenbach > Fraunhofer AISEC > Department Service & Application Security > Parkring 4, 85748 Garching near Munich (Germany) > Tel: +49 89 3229986-193 > martin.schanzenb...@aisec.fraunhofer.de > GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0 > > > > -- > hans.zandb...@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu Martin Schanzenbach Fraunhofer AISEC Department Service & Application Security Parkring 4, 85748 Garching near Munich (Germany) Tel: +49 89 3229986-193 martin.schanzenb...@aisec.fraunhofer.de GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
