I suggest putting error numbers/codes into a separate document because the error scenarios/cases are already specified in the OIDF/IETF standards. We can then mark that new document as "informational".
In case we would make an error in the copying process or context for an error is lost, it is then clear that the document is no spec.
I do not want to accidentally change the standard or even go near to the case where somebody thinks we did change the standard(s).

If we clarify the standard, then that clarification should go into the profile. But changing the standard(s) should be avoided.

Also, we should encourage developers to use (certified) libraries/SDKs.
https://openid.net/developers/certified-openid-connect-implementations/

Telcos should not try to implement their own OpenId Providers.
API consumers, who, I think, this issue addresses, should use SDKs, which usually have built-in error handling.
SDKs often automatically use all the security the OpenId provider support. E.g. if the OP supports PKCE then that is automatically used. Implementing security measures correctly can be tricky and should therefore be done by the SDK.
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics

We have real world examples with existing information that shows we have an issue with different interpretation. Any improvement we make MUST be MANDATORY. The end goal is interoperability. We can NOT have the situation where different operators have different interpretations and as a developer I need to have multiple SDKs and versions of software depending on which operator or aggregator I use. Developers will use different providers in different markets

Please provide those real world examples. Links to issues where the "interpretation" is discussed would be very welcome.

We MUST not create new standards. https://m.xkcd.com/927/ comes to mind.

You could add "SDK" to the list "A/C chargers, character encodings, instant messaging, etc).

Yes, "improvements" must be mandatory. We are talking about "error scenarios" here but that sentence is true for all "improvements". That is what the Security and Interoperability document is for. IF we find something that needs clarification then we write it down and make it mandatory.
That is no argument for repeating the standards.

We had this discussion before when we created the Security and Interoperability document. We created a concise document that clarifies in a mandatory way just the bits that needed clarification. The alternative was to repeat the standards and put everything into one huge document, where it is hard to find things that differ from the standards and things that follows the standards.

If an operator has an interpretation that differs from all other interpretation, then we can probably explain why that interpretation is wrong. If this WG agrees, that there really is a need for a clarification, then we will certainly clarify in a mandatory way without changing the standard.

Yes, we can NOT have the situation where different operators have different interpretations.
All operators MUST follow the standards. The standards are over 10 years old and errata exist. That is a signs of the maturity of the standard. If an operator has an interpretation of the standard that is different to everybody else's interpretation, then that interpretation is probably wrong. Which is another reason why operators should use certified implementations or get themselves certified by OIDF.

Yes, developers will use different providers in different markets. Luckily we have standards. And all the different providers adhere to the standard and there is no problem. That is the beauty of standards.

+1 to create a separate doc.

@AxelNennker,

What is the expected error in a CIBA flow if an authorization server does not support signed requests?

If we look at the CIBA specification, there is no mention of an error for this case, and only OAuth2.0 errors are referenced in the bc-authorize endpoint. However, if we look at the analogous error in the OIDC Authorization Code flow (or in RFC9101), the expected error is request_not_supported.

Strictly speaking, the error for CIBA would be invalid_request. Nevertheless, it doesn't seem very logical to get a different error than the one returned in the Authorization Code flow due to this oversight in the CIBA specification.