Dear Takahiko, Thank you so much for your kind and prompt response, and for having deleted the tweets. We all care a lot about doing the right thing, and I fully understand how passion can sometimes carry us away. For me this resolves the matter 100%. Thanks again, V.
From: Takahiko Kawasaki <t...@authlete.com> Date: Friday, April 24, 2020 at 15:49 To: Vittorio Bertocci <vittorio.berto...@auth0.com> Cc: oauth <oauth@ietf.org>, Vittorio Bertocci <vittorio.bertocci=40auth0....@dmarc.ietf.org> Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Dear Vittorio, I apologize. To me, the requirements on "aud" and "sub" sounded too strange and the logic to deny counter proposals sounded unnaturally unconvincing, too. They made me suspicious, and unfortunately and accidentally, my subsequent observation matched my doubt, and it made me feel I should bring it here with a kind of sense of justice, but I was a way too stupid. I wanted to discuss the requirements purely technically by removing politics, which I thought existed but did not exist actually. The ironic result was that my previous post itself was politics. I stop making comments to the spec. I'm sorry for my tweets. Because they have been copied to here in an unremovable way, allow me to remove them from Twitter to reflect my conduct. I'm sorry for having cast doubt although I've actually respected you since long before without your knowing. Hopefully, I want mercy from you and the community in spite of my conduct. Takahiko On Sat, Apr 25, 2020 at 5:24 AM Vittorio Bertocci <vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>> wrote: Takahiro, Before I acknowledge your comments, I would like to clarify some important points. Your first email, and various tweets you published contextually (https://twitter.com/darutk/status/1253375039681884160), suggest that with my work on the spec I am driving some hidden agenda for my company, and you are exposing this thanks to some findings you uncovered- and that the WG somehow missed. This is of course nonsense, insulting to my own professional integrity and to the intelligence of the chairs, working group and everyone who participated in the discussion. I include the tweets in the discussion because you included in them a link to the mailing list archives, hence involving the WG in the process. Some basic facts: * The profile as it exists today does NOT work out of the box with Auth0, there are several things that would need to change in the product for that to happen- including adding support for resource indicators which is currently missing * The layout of the Auth0 token is certainly not a secret, given that it was presented alongside all the other tokens obtained from other vendors at the OSW2019 in March, in the initial draft pitch at IETF104 as recorded in https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-jwt-profile-for-access-token-00, in the first discussion at IETF105 as shown in https://datatracker.ietf.org/meeting/105/materials/slides-105-oauth-sessa-json-web-token-jwt-profile-for-oauth-20-access-tokens-02-00. The use of resource indicators for client cred flows is certainly not a dark ploy to smuggle the Auth0 way, in fact it’s informed more by my work on Azure AD- where I found the transition from pseudo resource indicators to scopes to be riddled by challenges. Once again, all discussions were made in full transparency. * The concerns about symmetric algorithms being allowed, which you are oddly bringing up in a tweet rather than on the list, are disconnected from the discussion: people in the working group explicitly asked for symmetric to be an option and even to relax the current language to be more permissive, which I gently pushed back against. Again, not an obscure ploy. I am saddened that you chose to make those statements on twitter. There was nothing for you to discover, everything was already out in the open. You might want to consider retracting your accusations. I am not worried about myself, my conscience is perfectly clean and the IETF process records back me up, but by suggesting lack of transparency you are unfairly portraying the IETF, standardization process and the people who do their best to check at the door their affiliations and contribute their time and expertise for the benefit of the industry as a whole. I am adding the tweets here for reference, together with the translation Twitter provided. Taka@Authlete, BaaS for OAuth 2.0 & OpenID Connect @darutk もしやと思って調べてみたら、Auth0（スペックリードの所属企業）の client_credentials フローの実装は audience（RFC 8707 の resource 相当）が必須で、生成する JWT アクセストークンの sub にクライアント ID を埋め込む。JWT アクセストークン仕様ドラフトが歪んでいるのはこれが理由だろう。 Suddenly, I searched and thought, implementation of client_credentials flow of Auth0 (company of Spec Lead) requires audience (equivalent to resource of RFC 8707), and embed client ID in sub of generated JWT access token. This is probably the reason why the JWT access token specification draft is distorted. 元々 Auth0 の現実装を業界に認めさせるために JWT アクセストークン標準仕様策定作業が開始されたと噂では聞いていたが、実際にそうだったか。技術的に不自然な点が多いし裏事情がはっきりした今となっては黙っている訳にもいかないので、メーリングリストで意見を述べた。 https://mailarchive.ietf.org/arch/msg/oauth/Jy1fpar6LKnNX_zpoT7_fpCzBSg/ I've heard rumors that the JWT Access Token standard specification work was started to get the industry to accept the current implementation of Auth0, but was that really the case? Since there are many technical unnatural points and it is impossible to keep silent now that the circumstances are clear, I made an opinion on the mailing list. ついでに言っておくと、Auth0 が生成する JWT アクセストークンの署名アルゴリズムとして選択できるのは、HS256 と RS256 のみのようだ。HS256 は対称鍵系アルゴリズム。一方の RS256 は非対称鍵系アルゴリズムだが、セキュリティー上の理由で Financial-grade API Part 2 では使用禁止とされている。 Incidentally, it seems that only HS256 and RS256 can be selected as the signature algorithm for the JWT access token generated by Auth0. HS256 is a symmetric key algorithm. On the other hand, RS256 is an asymmetric key algorithm, but for security reasons, it is prohibited in Financial-grade API Part 2. From: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> on behalf of Takahiko Kawasaki <t...@authlete.com<mailto:t...@authlete.com>> Date: Thursday, April 23, 2020 at 18:01 To: oauth <oauth@ietf.org<mailto:oauth@ietf.org>> Cc: Vittorio Bertocci <vittorio.bertocci=40auth0....@dmarc.ietf.org<mailto:40auth0....@dmarc.ietf.org>> Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" I apologize if my previous post has made you all here feel unpleasant, especially I'm sorry for the author, the chairs, and people who directly joined the discussion about the spec. I could have expressed my disagreement on the requirements for "aud" and "sub" in another different way. For software specifications and architectures, I'm liable to get excited and aggressive. Please forgive me. Regarding the relationship between "aud" and "scope", the assumption in the draft is not necessarily applicable to all possible use cases. For example, multiple resources may share the same scopes. What if both "/resource1" and "/resource2" recognize "get" scope and "update" scope? In this case, it is not appropriate to determine the default resource indicator for "aud" from the scopes. It is also impossible to map scopes to resources and vice versa. The assumption in the current draft is too narrow to be included in a standard.. If the current description continues to exist, it will impose big restrictions on the design of scopes and resources. If you still think the "aud" claim should always exist, then the authorization endpoint and/or the token endpoint (and/or the backchannel authentication endpoint and/or the device authorization endpoint) of your system can require the "resource" request parameter as mandatory. We don't have to put rules to determine the default "aud" value into the spec about JWT access tokens. The "resource" parameter defined in RFC 8707 can work regardless of whether the format of access tokens is JWT or not. Therefore, it is not appropriate to discuss the necessity of the "aud" claim only in the context of "JWT" access tokens. Regarding the "sub" claim, setting the client ID there, rather, will confuse resource servers. If the "sub" claim is set even in the case of the client credentials flow, resource servers cannot judge whether the "sub" claim represents either the subject of the resource owner or the client ID. On the other hand, if the "sub" claim is null or absent in the case of the client credentials flow, resource servers can always handle the value of the "sub" claim as the subject of the resource owner. For resource servers, this logic is easier. Setting the "sub" claim in every case to make resource server implementations simpler is not convincing. Best Regards, Taka On Fri, Apr 24, 2020 at 2:15 AM Takahiko Kawasaki <t...@authlete.com<mailto:t...@authlete.com>> wrote: First, to make the discussion fair, I think I should share what I observed today. Auth0's client_credentials flow requires an "audience" parameter, which is equivalent to the "resource" parameter defined in RFC 8707, and embeds the client ID in the generated JWT access token as the value of the "sub" claim. My opinion as a software engineer is as follows. [aud] The "aud" claim should be null or absent when the "resource" parameters are not given in an authorization request. It is not good to introduce inflexible rules to determine the default value for the "aud" claim based on the "scope" parameter. [sub] The "sub" claim should be null or absent when a resource owner is not involved in an authorization request. To be concrete, the "sub" claim should be null or absent in the client credentials flow. The spec draft says in "5. Security Considerations" as follows. - - - - - - - - - - Authorization servers should prevent scenarios where clients can affect the value of the sub claim in ways that could confuse resource servers. For example: if the authorization server elects to use the client_id as the sub value for access tokens issued client credentials grant, the authorization server should prevent clients to register an arbitrary client_id value, as this would allow malicious clients to select the sub of a high privilege resource owner and confuse any authorization logic on the resource server relying on the sub value. For more details please refer to section 4.13 of [OAuth2.Security.BestPractices]. To preventing cross-JWT confusion, authorization servers MUST use a distinct identifier as "aud" claim value to uniquely identify access tokens issued by the same issuer for distinct resources. - - - - - - - - - - However, the attack vector is brought about merely by introducing the following rule defined in "2.2. Data Structure". - - - - - - - - - - In case of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of sub SHOULD correspond to an identifier the authorization server uses to indicate the client application. - - - - - - - - - - If the rule is not introduced, the attack vector disappears and the "aud" claim doesn't have to be mandatory. Finally, to make the discussion fair, I should also mention that I myself is a co-founder of Authlete, Inc. that provides an implementation of OAuth and OpenID Connect. My thoughts about implementations of access tokens are publicly described here: OAuth Access Token Implementation https://medium.com/@darutk/oauth-access-token-implementation-30c2e8b90ff0 Best Regards, Takahiko Kawasaki Authlete, Inc. On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci <vittorio.bertocci=40auth0....@dmarc.ietf.org<mailto:40auth0....@dmarc.ietf.org>> wrote: Ouch! Sorry 😊 fixed From: Dominick Baier <dba...@leastprivilege.com<mailto:dba...@leastprivilege.com>> Date: Tuesday, April 21, 2020 at 10:23 To: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>, Rifaat Shekh-Yusef <rifaat.i...@gmail.com<mailto:rifaat.i...@gmail.com>>, Vittorio Bertocci <vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>> Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Oh and while we are at it - could you also fix the typo in my name? Thanks ;) ——— Dominick Baier On 21. April 2020 at 09:43:49, Vittorio Bertocci (vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>) wrote: This is a great point. In my head I just considered the OIDC semantic and thought only of highlighting the app identity case, but you are absolutely right that not mentioning the user case at all is confusing. I added the language you suggested at the beginning of the sub definition. Thanks! From: Dominick Baier <dba...@leastprivilege.com<mailto:dba...@leastprivilege.com>> Date: Monday, April 20, 2020 at 22:54 To: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>, Rifaat Shekh-Yusef <rifaat.i...@gmail.com<mailto:rifaat.i...@gmail.com>>, "vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>" <vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>> Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" In case of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of sub SHOULD correspond to an identifier the authorization server uses to indicate the client application. Maybe I am missing something, but does it say anywhere what to explicitly do in the case of an access token where a resource owner is involved? There’s some language that seems to imply that, e.g.: as this would allow malicious clients to select the sub of a high privilege resource owner I would have expected to see something stronger like above just - In case of access tokens obtained through grants where a resource owner is involved, such as the authorisation code grant, the value of sub SHOULD correspond to the subject identifier of the resource owner. If this spec is about interop, I think this should be at least a recommendation... ——— Dominick Baier On 20. April 2020 at 09:48:51, vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0..com> (vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>) wrote: Thanks Dominick for your comments! Inline > All other OAuth specs make a very clear distinction between users and client. There’s a nuance worth highlighting here: sub != user. In previous discussions on this topic it has been brought up that the JWT spec defines sub as identifying the principal that is the subject of the JWT, and that’s not necessarily limited to users. However I get the potential confusion, and I am happy to add clarifying language if you have specific passages in the space you are particularly worried about: however I feel the matter is addressed upfront by the language in Section 2.2. in the sub entry, “In case of access tokens obtained through grants where no resource owner is involved, such as the client credentials grant, the value of sub SHOULD correspond to an identifier the authorization server uses to indicate the client application.“ and Section 5 has an entire paragraph discussing things to watch out in assigning sub values in the app identity case. Feel free to suggest additional language if you want to clarify further. > sub has a different semantic here as in OIDC The spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC, to preempt that concern and keep the original sub semantic available. > I am not fully clear why aud is required. Aud is there mostly because of three reasons: • Many existing specs postulate its existence in the token. No one declares it as a proper MUST (apart from the BCP, but that’s partial) however I think its importance comes across.. -Bearer token usage RFC6750 calls it out (in threat mitigation) as the mechanism to prevent token redirect (and adds scope restriction as also important, however here we make it optional to acocut for non-delegations scenario). -Resource indicators RFC8707 refers to the same section of RFC7519 as one of the assumptions that must hold to prevent bearer tokens misuse -BCP225 makes aud mandatory for AS which can issue JWTs for more than one app • Apart from Ping, for which some of its examples are without aud (but also without identifying scopes, given that the one I retrieved had only “openid”), all of the sample JWT ATs I received from vendors all featured an aud. I know one shoulnd’t overindex on those examples, but together with the above it seemed to point to something universally useful. One possible reason is that use of a format for the AT is correlated with topologies where AS and RS are separated by some boundary (network, logical, business, code factoring, etc) hence identifying the resource seems like a natural need. Again, not an iron clad law, but an indication. • A lot of people repurpose existing libraries for the JWT AT case, and some people even sends id_tokens in lieu of ATs. That doesn’t mean that we should condone any bad practices, but in tis particular case it suggests that lots of developers already expect/can handle an audience in the JWT used to call their API None of those are a slam dunk argument for mandatory, but I find them compelling enough to simplify validation and just require an aud to be there, as opposed to introduce complications that make it conditional to the presence of scopes or other disambiguation.. One reason I feel pretty good about that is that adding a default audience isn’t very hard if any of the above assumptions end up not being true for a particular case > What’s the rationale for using iat instead of nbf. That’s just straight from OIDC ID_tokens, and the considerations about repurposing existing logic. I see there’s a thread on this specifically, let me answer further on that branch. > This spec feels somehow in between a profile and a BCP You are right that this spec attempts to go beyond just declaring a layout, and I agree this means that this profile will not apply to absolutely everyone. The reason I tried that route (at the cost of working way harder in the last year for reaching consensus than if we would have just listed the possible content), is that I often observe implementers make questionable choices because of the large leeway specifications allow. My hope was that the scope of this profile was small enough to make that extra level of guidance achievable, whereas trying to do the same with a larger spec would have been prohibitively expensive. I believe things worked out well so far: we had lots of constructive discussions, and I ended up relaxing A LOT of the constraints I was originally envisioning. Nonetheless, my hope is that we identified the right set of guidelines that will help people actually interoperate out of the box for the most basic/common scenarios, as opposed to complying with the letter of the spec but still having a lot to figure out out of band. From: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On Behalf Of Dominick Baier Sent: Thursday, April 16, 2020 12:10 AM To: Rifaat Shekh-Yusef <rifaat.i...@gmail.com<mailto:rifaat.i...@gmail.com>>; oauth <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Since this is the last call, I thought I bring up some of thoughts / concerns. Some of them have been discussed before. client_id vs sub I am still not entirely happy with the “re-purposing” of the claim types based on flow. If the intention is, that sub expresses the entity against which the resource will do authorisation (and that might be a client or a user) - I get it (and maybe it should be stated like that) - but this thinking reminds me of the old AD days where there was no distinction between user and service accounts (something that has been fixed IIRC in Windows Server 2012 R2). All other OAuth specs make a very clear distinction between users and client. Furthermore it says "Authorization servers should prevent scenarios where clients can affect the value of the sub claim in ways that could confuse resource servers.” If we keep that dual semantics of the sub claim - it must be clearly stated, that subject ID and client ID are now in the same collision domain. So when an AS / OP creates them, they need to be unique across user ids and client ids. Maybe it should be also explicitly mentioned that sub has a different semantic here as in OIDC - even though a majority of the software built today will use them together. audience claim I am not fully clear why aud is required. OAuth itself does not have a notion of an audience (in the JWT sense) - they have scopes (which is very similar). But in simple scenarios where resources don’t exist, you'd need to make up an audience just to fulfil this requirement. And in many case this will be either static or just repeat the scope values. What’s the value of that? If the concept of resources are used, I absolutely agree that aud should be used too. But I wouldn’t make it required. iat vs nbf What’s the rationale for using iat instead of nbf. Aren’t most JWT libraries (including e.g. the .NET one) looking for nbf by default? General This spec feels somehow in between a profile and a BCP. On one hand you define some claims and their semantics (good) - on the other hand there is some prescriptive guidance and maybe over-specification. My concern is, that in the end no-one will fully comply with it, because it doesn’t work one way or the other for them. I know we just went though the discussion to make certain claims required as opposed to optional - but maybe less is more. Tbh - the most valuable part of the doc to me is the definition of the “at+jwt” typ. For the rest I’d rather like to see just some standard claims and IF they are used, which semantics they have. cheers ——— Dominick Baier On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (rifaat.i...@gmail.com<mailto:rifaat.i...@gmail.com>) wrote: Hi all, This is a second working group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens". Here is the document: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06 Please send your comments to the OAuth mailing list by April 29, 2020. Regards, Rifaat & Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
