[Openid-specs-ab] Issue #1362: alignment of certification tests with OAuth 2.1 (openid/connect)

[josephheenan]

New issue 1362: alignment of certification tests with OAuth 2.1
https://bitbucket.org/openid/connect/issues/1362/alignment-of-certification-tests-with

Joseph Heenan:

I think it would be good to have a discussion about how the certification tests for OpenID Connect Core might align with [https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04)

The main, and possibly only, issue to consider is how to deal with PKCE being mandatory \(except in the case where OIDCC is in use where it is ‘RECOMMENDED’\).

The obvious options I can think of here are:

1. Do nothing; current situation that servers are required to accept requests that **don’t** have PKCE continues
2. Align OP tests; all OP tests to send valid S256 PKCE, but it is permitted for the server to just ignore the PKCE parameters.
3. '2', but also align RP tests: to achieve interoperability \(certified OP will work with certified RP\), we would need to require clients to send valid PKCE in all requests
4. '3', but also add a test requiring the OP to reject invalid PKCE, i.e. ensuring that the OP actually does implement PKCE

\(Note that certification has a test module that already requires that servers do not reject valid PKCE, so going with option '2' will not cause any existing passing OPs to fail.\)

I am not in favour of option ‘1' as it results in server implementations that would otherwise mandate PKCE being required to implement an option where PKCE can be disabled, and I do not think it is good practice for certification to require servers to implement reduced-security options that they would not otherwise implement, as it has the potential to cause accidental reductions in security \(i.e. similar reasoning to why we now don’t require OPs to support alg: none\).

I’m in favour of going as close to option ‘4' as we feel we can - whilst the ‘nonce’ in OIDCC is a equivalent defence, it is reliant on the RP implementing the checks correctly, and if the RP does not implement correctly then the consequence is that the flow works but is insecure, and unfortunately our experience from the field is that a lot of RP implementations are low quality, and hence it is better for mitigations to be implemented on the authorization server. Using PKCE achieves this - for most cases, a poor implementation results in the flow not working as the server rejects requests with missing/incorrect PKCE \(though there are small cases the client could get wrong that the server may not pickup, like poor choice of `code_verifier` values\).