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
