[Openid-specs-fapi] Issue #308: For info/feedback - new FAPI-RW ID2 certification tests (openid/fapi)
issues-reply at bitbucket.org
Wed Aug 26 14:27:02 UTC 2020
New issue 308: 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.\)
**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.
**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.
**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.\)
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
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.
**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](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.
The above gitlab links may be used to provide feedback on any of the above intended tests. Other queries can be sent to [certification at oidf.org](mailto:certification at oidf.org).
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](https://gitlab.com/openid/conformance-suite/-/releases)
More information about the Openid-specs-fapi