Mike, I understand choices must be made but rfc7523bis does not even mention that with requiring that the audience has only one value introduces the thread that now that assertion can be used at several endpoints. RFC7523bis mentions explicit typing but the type proposed does not protect against misusing on assertion at different endpoints. Sure, rfc7523bis'es place is not to secure OIDF specifications but, I think, that rfc7523bis should mention that e.g. the private_key_jwt for CIBA and the private_key_jwt for OpenId Auth Code Flow SHOULD have different types. And any other assertion used at that issuer should have a different type.
" An explicit type for each affected kind of token, as defined in [RFC8725], is also defined to facilitate distinguishing between tokens produced in accordance with specifications published prior to these updates and those incorporating them. " The explicit type for private_key_jwt is good for distinguishing e.g. private_key_jwt assertions from JWT Bearer flow assertions, but it does not help to distinguish two private_key_jwt assertions at the same AZ for different endpoints. I do not propose having an array as the audience value as a second choice but as the only choice. Requiring the issuer identifier AND the endpoint-URL to be mandatory in the audience array stops the attacks, is practical, simple, easy to implement, and backward compatible. Without the drawback that the assertion can be used at multiple endpoints. Best wishes Axel From: Michael Jones <[email protected]> Date: Friday, 10. April 2026 at 17:08 To: Nennker, Axel <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: RE: AD comments on draft-ietf-oauth-rfc7523bis Axel, yes, there were multiple possibilities for fixing the audience vulnerability identified in the Stuttgart security analysis. Fixing the vulnerability required picking ONE. That’s what the specification does and it has working group and IETF consensus. Having a second possibility, which you’re advocating, is exactly the behavior that enabled the attack. Therefore, we MUST NOT do that. The way to prevent one kind of token from being able to be used in the wrong place is to explicitly type the token – as described in Section 3.11 of RFC 8725<https://www.rfc-editor.org/rfc/rfc8725#name-use-explicit-typing>. The specification employs this best practice for this reason. See Section 4<https://www.ietf.org/archive/id/draft-ietf-oauth-rfc7523bis-07.html#name-updates-to-rfc-7523> and Section 5<https://www.ietf.org/archive/id/draft-ietf-oauth-rfc7523bis-07.html#name-updates-to-rfc-9126>. I hope this helps explain and motivate the choices made, and how they prevent the attacks found during the Stuttgart security analysis. Best wishes, -- Mike P.S. I once did a whole talk on the topic “Standards are About Making Choices”. See https://self-issued.info/?p=2535. From: [email protected] <[email protected]> Sent: Friday, April 10, 2026 2:26 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: AD comments on draft-ietf-oauth-rfc7523bis Hi Filip, 1. Assertion usage at several endpoints attack Regarding "and their formal security analysis concluded by the researchers of University of Stuttgart confirms using the issuer identifier satisfies their respective attacker models." I agree that using the issuer identifier as audience fixes those attacks. It does stop those attacks, but now the new assertion that was created for one endpoint e.g. CIBA can be used at a second endpoint e.g. the ACF token endpoint. In that sense, I think, the "solution" to use the issuer identifier as audience reduces the security of the system. If the above is true, then I would like to have that mentioned in rfc7523bis. 1. Issuer identifier de facto must be a URL because of rfc8414 The systems, Linus Foundation's CAMARA<https://camaraproject.org/> project and GSMA OpenGateway<https://open-gateway.gsma.com/> initiative, I am "using", do not use rcf8414 to discover endpoints. "Rfc7523bis" is forcing everybody to use an URL as an issuer identifier. Even when OpenId Federation and rcf8414 are not used by them. Usually, the language in RFCs is more cautious when forcing something on somebody, like: IF you use RFC8414 then you cannot trust the endpoints discovered, so then you MUST not use them as audience values but then use the issuer identifier. With the new risk that the assertion can be used at several endpoints. We also use URLs as issuer identifiers, but that is not the point. The point is requiring a format through the backdoor and without stating that format requirement. Even for systems that do not use RFC8414 1. Audience array with exactly one element "simple solution" I think having the issuer identifier AND the endpoint-URL both in the audience array is the better security advise. The receiver would then reject the request if one or more elements in the array are not associated with the receiver. In the Stuttgart attack the client sends an assertion to the attacker in which the audience is honest-endpoint-URL. If the client would add the issuer identifier into the audience from which the client got the honest-endpoint-URL then that assertion would be rejected by honest-AZ because it contains attacker-issuer-identifer. 1. Client request AZ metadata form attacker-AZ and that contains honest-endpoint-URL but the issuer in that metadata must be attacker-identifer because otherwise the client would reject the metadata. 2. Client creates assertion with audience=[attacker-identifier, honest-endpoint-URL] to attacker 3. Attacker uses assertion an honest-endpoint-URL but request is rejected because the audience array contains attacker-identifier I think the "simple and practical solution" of demanding that the sole value of audience is too simple and less secure. The clients who follow rfc7523bis must change their implementation anyway to comply with the RFC. So, using the array as proposed above is not really work for the client. The work the AZ server implementations need to do is changing the audience validation logic from "one-element-must-be-me" to "all-elements-must-be-me". And that is actually backward compatible, because no AZ will break if they do not implement this new logic. The reasoning about the audience-array does the same effort and reasoning as with the "typed" jwt-assertion. The AZ implementation continues to work but professional AZ implementations will implement the change and later demand the better security. S pozdravem, Axel From: Filip Skokan <[email protected]<mailto:[email protected]>> Date: Friday, 10. April 2026 at 09:43 To: Nennker, Axel <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: AD comments on draft-ietf-oauth-rfc7523bis Hello Alex, 1. Yes. Using the issuer identifier as the client assertion audience is already a SHOULD in CIBA, the other values being accepted by an AS is for interop due to ambiguity in the assertion's definition, and it is in fact the reason why this needs fixing. In effect we're promoting that SHOULD to a MUST, this has already been done in OpenID Federation as well as FAPI 2.0, planned for FAPI 1.0 and OIDC 1.0 as soon as we publish this. CIBA or at least FAPI-CIBA will follow suit too. 2. Yes. 3. No. -03 relaxed this so that, as per JWT aud definition, it may be an array. But with a sole value being the issuer identifier. If 1) is true, I think, that -07 reduces the security of systems that use both CIBA and OpenId Connect. Both FAPI 2.0 and OpenID Federation utilize more than one endpoint with client authentication using private_key_jwt and their formal security analysis concluded by the researchers of University of Stuttgart confirms using the issuer identifier satisfies their respective attacker models. S pozdravem, Filip Skokan On Thu, 9 Apr 2026 at 12:38, <[email protected]<mailto:[email protected]>> wrote: Hi, Regarding the change to RFC7523: " For client authentication, the aud (audience) claim value MUST use the issuer identifier [RFC8414] of the authorization server as its sole value. The authorization server MUST have an issuer identifier to be used with this specification. Unlike the aud value specified in [RFC7523], there MUST be no value other than the issuer identifier of the intended authorization server used as the audience of the JWT; this includes that the token endpoint URL of the authorization server MUST NOT be used as an audience value. The authorization server MUST reject any JWT that does not contain its issuer identifier as its sole audience value. " 1. Is it true that a private_key_jwt for client authentication created to be used at the CIBA endpoint can now be used at the authorization code flow token endpoint? 2. Is it true that because the above references rfc8414 the issuer identifier from now on MUST be an URL while before it could be e.g. an UUIDv4 for systems that to not use rfc8414? 3. Is it true that the audience value cannot be an array anymore? If 1) is true, I think, that -07 reduces the security of systems that use both CIBA and OpenId Connect. //Axel https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7 https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication From: Michael Jones <[email protected]<mailto:[email protected]>> Date: Friday, 27. March 2026 at 00:52 To: Deb Cooley <[email protected]<mailto:[email protected]>>, Filip Skokan <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Web Authorization Protocol Working Group <[email protected]<mailto:[email protected]>>, oauth <[email protected]<mailto:[email protected]>> Subject: [OAUTH-WG] Re: AD comments on draft-ietf-oauth-rfc7523bis https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-rfc7523bis-07.html&data=05%7C02%7CAxel.Nennker%40telekom.de%7Cf11b207f204d4f290d0508de8b92c561%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639101659652934396%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rz%2BwjkH9y8lge49QpQJMjvfmJ9yCb78HSNnXy9mUwbU%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf-oauth-rfc7523bis-07.html> has been published to address your comments, Deb. Thanks, -- Mike -----Original Message----- From: Michael Jones <[email protected]<mailto:[email protected]>> Sent: Thursday, March 26, 2026 3:36 PM To: Deb Cooley <[email protected]<mailto:[email protected]>>; Filip Skokan <[email protected]<mailto:[email protected]>> Cc: Brian Campbell <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Web Authorization Protocol Working Group <[email protected]<mailto:[email protected]>>; oauth <[email protected]<mailto:[email protected]>> Subject: RE: AD comments on draft-ietf-oauth-rfc7523bis I approved the PR https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foauth-wg%2Fdraft-ietf-oauth-rfc7523bis%2Fpull%2F27&data=05%7C02%7CAxel.Nennker%40telekom.de%7Cf11b207f204d4f290d0508de8b92c561%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639101659652962470%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WRWPsWx%2FjtNN%2FewUaWsWjRch1%2BhKOjjTiIlvyXmTQXs%3D&reserved=0<https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/27>. Thanks for doing that, guys. -- Mike -----Original Message----- From: Deb Cooley <[email protected]<mailto:[email protected]>> Sent: Thursday, March 26, 2026 3:27 PM To: Filip Skokan <[email protected]<mailto:[email protected]>> Cc: Brian Campbell <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Web Authorization Protocol Working Group <[email protected]<mailto:[email protected]>>; oauth <[email protected]<mailto:[email protected]>> Subject: Re: AD comments on draft-ietf-oauth-rfc7523bis Filip (and Brian), You are right, I have also come to the conclusion that idnits is wrong here. apologies for that. I will look at the PR soonest (prolly tomorrow). Although waiting until after spring breaks are over (I forgot about those, again apologies), that is fine as well. Deb On Thu, Mar 26, 2026 at 4:09 PM Filip Skokan <[email protected]<mailto:[email protected]>> wrote: > Hello Deb, > > I picked up a WIP PR from Brian to (hopefully) resolve your comments > here > <https://gith/ > %2F&data=05%7C02%7C%7C83e6fef89cb448fd867e08de8b880ab1%7C84df9e7fe9f64 > 0afb435aaaaaaaaaaaa%7C1%7C0%7C639101613575943450%7CUnknown%7CTWFpbGZsb > 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mh1gEWVXYZfEIPMMaHvRgVe0Y > nZGCEZBbcZCqdojSTw%3D&reserved=0 > ub.com<http://ub.com/>%2Foauth-wg%2Fdraft-ietf-oauth-rfc7523bis%2Fpull%2F27&data=05%7C > 02%7C%7Caeb3cee0ed444f527dc108de8b86dc41%7C84df9e7fe9f640afb435aaaaaaa > aaaaa%7C1%7C0%7C639101608487502793%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1 > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=52LLsQQE6Bzv44HFNxNvkCK0%2BaWjdKcWFFXyUBGia%2BY%3D&reserved=0>. > I reverted brian's attempt to fix BCP 14 references as I think idnits v3 is > in error after comparing how BCP14 is referenced here vs other recently > published documents. But I'll happily take you up on your offer to align it > with a different example, that being said, as many iterations of this I've > tried they all came back as issues from idnits anyway. > > S pozdravem, > *Filip Skokan* > > > On Thu, 26 Mar 2026 at 20:07, Brian Campbell > <[email protected]<mailto:[email protected]>> > wrote: > >> Apologies, the meeting and travel and inability to access some >> systems on-site definitely did disrupt the getting things done list >> for me. Further disruption is coming for me with the kids' spring >> break starting soon (in a few hours for all intents and purposes with >> respect to work). So I can only apologize again as realistically an >> ETA for me responding in a useful way isn't until the week after next. >> >> On Thu, Mar 26, 2026, 11:13 AM Deb Cooley >> <[email protected]<mailto:[email protected]>> wrote: >> >>> Hi, >>> >>> Can I get an eta for responses to my comments? I had assumed there >>> was some urgency, but I recognize the meeting tends to disrupt >>> things for a minute or two. The good news is that we are probably >>> only looking at a 2 week IETF Last Call. >>> >>> Deb >>> >>> On Wed, Mar 11, 2026 at 11:28 AM Deb Cooley >>> <[email protected]<mailto:[email protected]>> >>> wrote: >>> >>>> Hi, >>>> >>>> Below is a complete set of my comments on this draft (I've pestered >>>> the authors about a couple of early comments raised by idnits already). >>>> >>>> idnits v3 (experimental) raised three issues, one of them is legit, >>>> one is borderline, and the last is clearly in error: >>>> - idnits points out that it is preferred if BCP 14 is referenced. >>>> If you need me to find you an example of how to do this, I can. >>>> >>>> - RFCs to be updated are not in the Abstract. >>>> >>>> - the third entry here is clearly in error. Mea Culpa. (about >>>> open.org<http://open.org/> in the references) >>>> >>>> Section 1: (improve clarity) The token identifies the recipient? via >>>> an audience value(s)? If that is correct, then maybe the second sentence >>>> could be something like 'These tokens, which identify the >>>> recipient, contain an audience value(s). s/aud/'aud' (or something >>>> to make it obvious that this is a field name). >>>> >>>> Section 3, replacing text: I'm not sure the parenthetical for >>>> Section >>>> 2.2 (The authors re not actually aware....)adds much. I would remove it. >>>> >>>> Section 4 a. and b.: Just to be sure I understand... for an >>>> authorization grant the audience can be the token endpoint URL (and >>>> nothing else), but for client authentication, the 'aud' claim value >>>> must not be the token endpoint URL (it has to be the issuer >>>> identifier). Assuming that audience = aud (audience) claim value. >>>> [I have no judgement on this, just being sure this is what you >>>> intended to say.] >>>> >>>> Section 7.1.1, contact information: I believe we can use oauth for >>>> this contact (vice a person). This is the authors' preference. >>>> >>>> >>>> The publication window opens on Monday, hopefully it is fine to >>>> wait until then. Once these are addressed, I will put the draft >>>> into IETF Last Call (3 weeks because of IETF 125). >>>> >>>> Thanks for your patience, >>>> Deb >>>> >>>> >>>> >>>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). >> Any review, use, distribution or disclosure by others is strictly >> prohibited _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
