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]> 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]> > *Date: *Friday, 27. March 2026 at 00:52 > *To: *Deb Cooley <[email protected]>, Filip Skokan <[email protected]> > *Cc: *[email protected] < > [email protected]>, Web Authorization Protocol > Working Group <[email protected]>, oauth <[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]> > Sent: Thursday, March 26, 2026 3:36 PM > To: Deb Cooley <[email protected]>; Filip Skokan <[email protected]> > Cc: Brian Campbell <[email protected]>; > [email protected]; Web Authorization Protocol > Working Group <[email protected]>; oauth <[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]> > Sent: Thursday, March 26, 2026 3:27 PM > To: Filip Skokan <[email protected]> > Cc: Brian Campbell <[email protected]>; > [email protected]; Web Authorization Protocol > Working Group <[email protected]>; oauth <[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]> 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%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]> > > 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]> 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]> > >>> 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 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] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
