Why couldn’t OIDC evolve as a spec to conform and match FAPI and 2.1? Phil
> On May 6, 2020, at 12:34 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > > > Yes, FAPI requires PKCE, which is great. Many of its requirements come from > OpenID Connect but some of them are intentionally incompatible – such as > requiring that Basic authentication not be supported, whereas Connect > requires that it be supported. It’s a different ecosystem with different > requirements. > > Don’t get me wrong, I support PKCE where it makes sense, such as when you’re > doing bare OAuth without OpenID Connect. But trying to impose an unnecessary > requirement on a working and secure ecosystem will just create grief for us > and our customers and lessen our credibility as stewards of the OAuth > ecosystem. > > -- Mike > > From: Aaron Parecki <aa...@parecki.com> > Sent: Wednesday, May 6, 2020 12:29 PM > To: Steinar Noem <stei...@udelt.no> > Cc: Phillip Hunt <phil.h...@independentid.com>; Mike Jones > <michael.jo...@microsoft.com>; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > > 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
