I should add that even some OpenID Connect profiles require PKCE, such as FAPI:
https://openid.net/specs/openid-financial-api-part-1.html#authorization-server So the precedent for requiring PKCE already exists within some OpenID Connect profiles. On Wed, May 6, 2020 at 12:23 PM Aaron Parecki <aa...@parecki.com> wrote: > Yes, and also, many of those providers very likely already support PKCE > already. Skimming through that list of certified OPs, I recognize many > names there from providers that I know support PKCE. > > On Wed, May 6, 2020 at 12:18 PM Steinar Noem <stei...@udelt.no> wrote: > >> So, wouldn't a MUST just mean that we would have some OPs that are 2.1 >> compliant and some that aren't? >> >> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt < >> phil.h...@independentid.com>: >> >>> Mike, >>> >>> The point of 2.1 is to raise the security bar. >>> >>> Yes it adds new MUST requirements. >>> >>> But what about OIDC would break other than required implementation of >>> PKCE to support 2.1? >>> >>> Eg Would additional signaling be required to facilitate interoperability >>> and migration between versions? Would that be an oauth issue or an OIDC one? >>> >>> Phil >>> >>> On May 6, 2020, at 11:56 AM, Aaron Parecki <aa...@parecki.com> wrote: >>> >>> >>> > In particular, authorization servers shouldn’t be required to support >>> PKCE when they already support the OpenID Connect nonce. >>> >>> The Security BCP already requires that ASs support PKCE: >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 >>> Are >>> you suggesting that the Security BCP change that requirement as well? If >>> so, that's a discussion that needs to be had ASAP. If not, then that's an >>> implicit statement that it's okay for OpenID Connect implementations to not >>> be best-practice OAuth implementations. And if that's the case, then I also >>> think it's acceptable that they are not complete OAuth 2.1 implementations >>> either. >>> >>> >>> >>> >>> >>> >>> On Wed, May 6, 2020 at 11:21 AM Mike Jones <Michael.Jones= >>> 40microsoft....@dmarc.ietf.org> wrote: >>> >>>> The disadvantage of requiring PKCE for OpenID Connect implementations >>>> is that you’re trying to add a normative requirement that’s not required of >>>> OpenID Connect deployments today, which would bifurcate the ecosystem. >>>> There are hundreds of implementations (including the 141 certified ones at >>>> https://openid.net/certification/), none of which have ever been >>>> required to support PKCE. Therefore, most don’t. >>>> >>>> >>>> >>>> Per feedback already provided, I believe that OAuth 2.1 should align >>>> with the guidance already in the draft Security BCP, requiring EITHER the >>>> use of PKCE or the OpenID Connect nonce. Trying to retroactively impose >>>> unnecessary requirements on existing deployments is unlikely to succeed and >>>> will significantly reduce the relevance of the OAuth 2.1 effort. >>>> >>>> >>>> >>>> In particular, authorization servers shouldn’t be required to support >>>> PKCE when they already support the OpenID Connect nonce. And clients >>>> shouldn’t reject responses from servers that don’t support PKCE when they >>>> do contain the OpenID Connect nonce. Doing so would unnecessarily break >>>> things and create confusion in the marketplace. >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Dick Hardt >>>> *Sent:* Wednesday, May 6, 2020 10:48 AM >>>> *To:* oauth@ietf.org >>>> *Subject:* [OAUTH-WG] OAuth 2.1 - require PKCE? >>>> >>>> >>>> >>>> Hello! >>>> >>>> >>>> >>>> We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is >>>> best practice for OAuth 2.0. It is not common in OpenID Connect servers as >>>> the nonce solves some of the issues that PKCE protects against. We think >>>> that most OpenID Connect implementations also support OAuth 2.0, and >>>> hence have support for PKCE if following best practices. >>>> >>>> >>>> >>>> The advantages or requiring PKCE are: >>>> >>>> >>>> >>>> - a simpler programming model across all OAuth applications and >>>> profiles as they all use PKCE >>>> >>>> >>>> >>>> - reduced attack surface when using S256 as a fingerprint of the >>>> verifier is sent through the browser instead of the clear text value >>>> >>>> >>>> >>>> - enforcement by AS not client - makes it easier to handle for client >>>> developers and AS can ensure the check is conducted >>>> >>>> >>>> >>>> What are disadvantages besides the potential impact to OpenID Connect >>>> deployments? How significant is that impact? >>>> >>>> >>>> >>>> Dick, Aaron, and Torsten >>>> >>>> >>>> >>>> ᐧ >>>> _______________________________________________ >>>> 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 >>> >> >> >> -- >> 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
