[Openid-specs-fapi] Issue #429: FAPI Certification with Lodged Intent or RAR - User Consent vs Technical Process Certification. (openid/fapi)
issues-reply at bitbucket.org
Mon Jul 12 16:05:47 UTC 2021
New issue 429: FAPI Certification with Lodged Intent or RAR - User Consent vs Technical Process Certification.
Please note that i’ve raised this ticket against the FAPI 2 Baseline however this same issue applies to any of the standards.
The OpenID Foundation Certification Suite and Programme for implementations has a challenge that will either require scope clarification in terms of the service on offer or a process change to include UI/UX validation of the consent and Authorization processes.
Several Banks in Brazil have been listed as certified by the OpenID Foundation as meeting the requirements of the Open Banking Brazil Security Profile. Over the last few weeks it has emerged that there is a difference between the Swagger Specifications and Security Model published by the central programme and the User Experience Guidelines published by the central programme. In short, it should not be possible for customers to consent to release just the data “Accounts Read” that the Conformance and Certification tooling is requesting Banks to release. Instead it should only be possible at present to release ‘Groups of Permissions’ at a time.
This as highlighted a gap in the certification process of implementations, one that is arguably most important to the safe sharing of customers data. **What exactly were the customers informed about the data that they are sharing and was this accurate to the Authorization request?**
For the Banks that self certified using the Accounts Read permission they were ‘Spec Compliant’ however the users MUST have been displayed consent and Authorization screens that were not consistent with the data that was actually being shared.
The conformance and certification suite explicitly includes tests to ensure that error messages for bad requests, when displayed to users, indicate that the error came from a TPP Bad Request. i.e the Certification team will fail certification tests if there is language such as ‘Your Request Caused an Error” when actually “The TPP Sent a Request that was Invalid” was more accurate. This situation currently being faced is potentially no different, the customer is being presented with information, this time regarding consent and authorization to share information that does not accurately reflect what was being requested.
For Generic FAPI certification processes where vendors are proving that they have capabilities that can meet the specifications this isn’t an issue, every one can put a scope description string on an out of the box UI, however for Ecosystem Specific Certification programmes like the UK, Australia or Brazil or when we incorporate RAR as part of FAPI 2.0 this won’t be the case.
In this situation, because the FAPI Certification of **Implementations** doesn’t incorporate any checks to validate the if the implementation is accurately informing the user of what is being **Authorized** too and the access that they are actually granting to the TPP, the needs of the Customer are not fulfilled.
This issue exists with any usage of OpenID Connect not just FAPI.
The certification programme has a couple of options here to address:
1. Formally put out of scope any element or process used to check what a customers experience is like and whether or not it is ‘appropriate’. Leave the certification entirely to ‘protocol’ aspects only.
2. Request that all Implementers take screen shots of their consent and Authorization screens so that they can demonstrate that they have actually displayed to the customer the information that was being technically Authorized. All vendors have the capability for doing this with Scopes. With RAR or Lodging intent this will require an implementation specific set of tests that should be done in conjunction with the ecosystem that the certification programme is being created and run for.
More information about the Openid-specs-fapi