Ah, that makes sense. Well, we already add a grant_type claim to our JWT-based 
access tokens, so I’m in favour of that solution :-)


> On 7 May 2019, at 09:48, Vittorio Bertocci <vitto...@auth0.com> wrote:
> 
> Thanks Neil, one more reason to avoid that.
> TL;DR, 
> The context is the discussion we had pre-IIW about whether sub should be 
> included always or only for tokens issued to ROs. Some exiting 
> implementations rely on that heuristic.
> Turns out that 7519 has language suggesting sub should be there for both 
> tokens issued for the RO and for apps (via client creds, etc).
> We don't want to contradict 7519 but we also want to preserve the ability for 
> a RS to tell whether an AT was issued via RO auth or app auth, hence the 
> discussion. Suggestions ranged from adding a grant_type claim (Vlad made a 
> convincing argument against it), to relying to the client_id==sub heuristic 
> (which i pushed back on) to the introduction of a new claim (name TBD given 
> that sub_type is taken already) that can explicitly declare whether the token 
> has been issued authenticating th RO or via app credentials.
> 
> On Tue, May 7, 2019 at 1:37 AM Neil Madden <neil.mad...@forgerock.com 
> <mailto:neil.mad...@forgerock.com>> wrote:
> 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 in https://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>
> 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to