Originally submitted by panva (Filip Skokan) on 2022-10-31
Currently, the language in https://openid.net/specs/fapi-2_0-baseline-01.html#name-network-layer-protections and https://openid.net/specs/openid-financial-api-part-2-1_0.html#tls-considerations does not mention the party responsible for the cipher enforcement.
The FAPI certification suite currently fails clients that make a connection using a cipher that falls outside of the 4 allowed. But in its TLS configuration it does not rank the four allowed as the most preferred.
This means that a client which cannot control its allowed ciphersuite fails certification because it chooses a cipher that isn’t amongst the 4 allowed but ranks higher in preferrence by the certification server.
I thinks it’s unreasonable to assume that every client software is capable of controlling the allowed TLS ciphers and that this should be made a server-side requirement to enforce.
This affects both FAPI1 and FAPI2
Bitbucket status: resolved
Bitbucket origin: issue 550
Currently, the language in https://openid.net/specs/fapi-2_0-baseline-01.html#name-network-layer-protections and https://openid.net/specs/openid-financial-api-part-2-1_0.html#tls-considerations does not mention the party responsible for the cipher enforcement.
The FAPI certification suite currently fails clients that make a connection using a cipher that falls outside of the 4 allowed. But in its TLS configuration it does not rank the four allowed as the most preferred.
This means that a client which cannot control its allowed ciphersuite fails certification because it chooses a cipher that isn’t amongst the 4 allowed but ranks higher in preferrence by the certification server.
I thinks it’s unreasonable to assume that every client software is capable of controlling the allowed TLS ciphers and that this should be made a server-side requirement to enforce.
This affects both FAPI1 and FAPI2
Bitbucket status: resolved
Bitbucket origin: issue 550