[Openid-specs-fapi] Issue #618: Certification/conformance: Strictness of checking error responses (openid/fapi)

[josephheenan]

New issue 618: Certification/conformance: Strictness of checking error responses
https://bitbucket.org/openid/fapi/issues/618/certification-conformance-strictness-of

Joseph Heenan:

An ecosystem has queried the certification team as to whether particular conformance tests are overly strict and perhaps not adding significant value.

The particular issue in this case is when the FAPI2 tests attempt to do an authorization using `response_type=code id_token` \(which is not permitted in FAPI2\). One of the accepted outcomes here is an error from the PAR endpoint, where [https://www.rfc-editor.org/rfc/rfc9126.html#section-2.3](https://www.rfc-editor.org/rfc/rfc9126.html#section-2.3) seems to be the relevant place to start and says:

> The authorization server returns an error response with the same format as is specified for error responses from the token endpoint in Section 5.2 of \[RFC6749\] using the appropriate error code from therein or from Section 4.1.2.1 of \[RFC6749\].

and [https://www.rfc-editor.org/rfc/rfc6749#section-5.2](https://www.rfc-editor.org/rfc/rfc6749#section-5.2) seems clear to me than an 'unauthorized\_client' error \(i.e. “The client is not authorized to request an authorization code using this method”.\) is sent with a 400 http status code. The system in question is returning a 401 response instead, which causes a failure in the test and prevents certification.

As in this case, I don’t think we would ever expect the client to have logic like “if try response\_type code id\_token and I get a http 400 with JSON that has an unauthorized\_client error then try response code instead”, so potentially allowing any 4xx error is sufficient to achieve the underlying goal that the client is not permitted to use that response type \(or all least downgrading the failure to a warning\).

In this working group agreed this might be a suitable approach to be used across all FAPI conformance tests, we’d probably need a bit more guidance as to what kind of errors fail into this category and which ones we do have an expectation that at least some clients might react to and recover from automatically.

\(I thought we’d discussed this topic before, but I can’t find a prior issue. [#434](/openid/fapi/issues/434/certification-team-query-error-messages) is vaguely related, but about user visible error messages.\)