For info/feedback - new FAPI-RW ID2 certification tests

The OIDF certification team plan to add the below tests shortly - we’re sharing this to allow the FAPI working group to give feedback about the proposed tests first, and also so that testers have advanced warning.

(If there’s no negative feedback, this ticket can just be closed.)

Interoperability tests

767) Sending scope in wrong order

The tests will be modified so the different ordering of the scope parameter are used (i.e. both scope=openid accounts and scope=accounts openid); as per RFC6749 either order must be accepted.

https://gitlab.com/openid/conformance-suite/-/issues/767

761) IPv6 addresses in x-fapi-customer-ip-address header

The tests will send a x-fapi-customer-ip-address that contains an IPv6 address. This must not be rejected, as rejecting it would prevent TPPs that support IPv6 from performing ‘customer present’ operations.

https://gitlab.com/openid/conformance-suite/-/issues/761

778) Requests that use valid PKCE must succeed

This test will pass valid code_challenge and code_challenge_method to the Authorization Endpoint, and valid code_verifier to the token endpoint call. These calls must succeed, either because the AS ignores unknown parameters as per RFC6749, or because the AS supports PKCE. (FAPI neither requires nor precludes authorisations servers from supporting PKCE, and many clients optimistically use PKCE and must not be rejected.)

https://gitlab.com/openid/conformance-suite/-/issues/778

We believe the majority of ASPSPs that would fail these tests will already have been made aware of these problems by tickets TPPs have raised with their support desks. As these tests

a) relate to requirements that are clear in the underlying specifications that ASPSPs already state they conform with

and

b) have been reported by TPPs as interoperability problems that have unnecessarily delayed their integrations

we do not currently propose to allow any grace period where systems failing these this tests would be permitted to be certified.

Security tests

785) When private_key_jwt is supported, a request object must not be usable as client authentication

A client_assertion that is missing the ’sub’ claim must be rejected. This is required by https://tools.ietf.org/html/rfc7523#section-3

Given that verifying sub is a vital step in authenticating the client, we are not expecting any existing ASPSP deployments will fail this test.

https://gitlab.com/openid/conformance-suite/-/issues/785

The above gitlab links may be used to provide feedback on any of the above intended tests. Other queries can be sent to certification@oidf.org.

Other notes

OIDF will shortly be added support for testing Pushed Authorization Requests, in version 4.1.0 of the suite. This is a new spec and UK ASPSPs are not required to implement it - however when this version is deployed, any ongoing test plans for UK banks will need to be edited to select a value for the 'Request Object Method’ setting (otherwise an error will occur when trying to run a new test) - to maintain the current behaviour, select ‘by value’. Deployment of the new release will be announced via https://gitlab.com/openid/conformance-suite/-/releases

Comments (8)