Hi Vladimir. Client registration parameter sounds like a good idea to me.
In terms of which document this goes to.... I wonder if PKCE RFC7636 could be updated to add this. This way ecosystems using PKCE in OAuth 2.0 could benefit from this too. Thanks Dima On Sat, Oct 8, 2022 at 9:27 PM Vladimir Dzhuvinov <vladi...@connect2id.com> wrote: > Thanks for chiming in Dima. > > Do you reckon it's a good idea to define a code_challenge_method client > reg parameter in the OAuth 2.1 spec? > > To enable 2.0 -> 2.1 transitions and also give people a concrete and > standard compliant way to implement the "REQUIRED or RECOMMENDED" in the > OAuth 2.1 spec for code_challenge. > > Another spec that deals with PKCE is the OAuth BCP, but to me that's not a > optimal place to define a new parameter. > > > Vladimir Dzhuvinov > > > On 08/10/2022 04:31, Dima Postnikov wrote: > > Hi Vladimir, > > Similar issue exists in CDR (Australian Open Banking). PAR and PKCE was > added as mandatory to FAPI 1 Advanced profile. > > There was a transition period when AS had to support both (potentially). > > Also if the same AS is used outside of CDR, this dual support would > continue for some implementations. > > I don't think this was solved, so your client registration parameter > makes sense. > > > > On Wed, Oct 5, 2022 at 5:43 PM Vladimir Dzhuvinov <vladi...@connect2id.com> > wrote: > >> Has anyone faced the issue how an AS can handle a mix of OAuth 2.0 and >> 2.1 clients regarding PKCE enforcement? >> >> The new OAuth 2.1 spec makes PKCE required, which is a good security >> measure and fine for an AS where all clients are ready to comply with >> the upgrade. In practice however, it's common for AS deployments to have >> a mix of legacy 2.0 and 2.1 clients, and at present OAuth doesn't have a >> standard client registration parameter, e.g. code_challenge_method, to >> lock a client into using PKCE. >> >> >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-02#section-4.1.1 >> >> RFC 8414 defined the code_challenge_methods_supported metadata for >> servers. It would be useful if deployments had a corresponding parameter >> for the clients. >> >> https://www.rfc-editor.org/rfc/rfc8414 >> >> ~ Vladimir >> >> -- >> Vladimir Dzhuvinov >> >> _______________________________________________ >> 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
