FAPI Certification with Lodged Intent or RAR - User Consent vs Technical Process Certification.

[Ralph Bragg]

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 has 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.

‌

[Tom Jones]

I have tried to push consent UI in OIDF for some time but received major push back from the guys on the board. I would support the idea of a full consent process. If not in OIDF we need to find a place to do that.

[Ralph Bragg]

Raidiam, as part of the functional certification process for Brazil (which is using a fork of the OIDF suite) suite will add in consent screen shot captures into the Authorization process but it is such a fundamental part of an ‘ecosystem certification programme’ i felt it should be raised

[Lukasz Jaromin]

Undoubtedly, informed consent is a must. On the other hand, the certification package should consist of objective checks. Such objective certification of it may a challenge. Before we jump into area of subjective verifications we should consider what objective checks can be included in the suite.

Regardless, we might consider reiterate in the FAPI specification that the consent screen must reflect what the user is actually consenting to.

[Chris Michael]

I agree that UI/UX validation is a vital component which should be checked by someone, but IMO this is not something which should be in scope for the OIDF. This is a complex issue which requires understanding of regulatory, product and/or customer experience concerns. Often the UI/UX will vary significantly depending on the context (e.g. the amount and payee for payments). Asking implementers to upload simple screen grabs is an over simplification and won’t prove anything. Asking technical experts to review this is also going to be a challenge. I suggest regulators who have such concerns take note of the work the UK OBIE has been doing - there are many lessons to be learnt here.

[Dave Tonge]

I agree with Chris. I think this sort of verification should be explicitly outside the scope of a technical conformance test.

[Dave Tonge]

@Ralph Bragg are you ok for this to be closed?

[Ralph Bragg]

We’re picking it up as part of the consent and certification process. It raises questions for the OIDF’s role in certification of specific profiles for ecosystems as users have a major role to play in this flow but technically if the group feels that there’s nothing that they feel should be done then i’m happy to close it.

I would have preferred adoption of something in language to require OPs to display the consent screen in a way that make sense to the Resource Owner and matches what the RP is actually requesting.

[Chris Michael]

I hear you Ralph, but having seen this play out in UK and across EU, there is so much subjectivity and contention here around what it means to have any screen which ‘makes sense’ - or for that matter whether you should have any screens at all versus several screens. OIDF would be better off sticking to the tech aspects and leaving such political hot potatoes to the regulators and/or their nominated bodies (e.g. OBIE) to make such assessments.

[Ralph Bragg]

Sure - so if we can’t technically test it, doesn’t mean for the protection of customers we shouldn’t state it.

[Dave Tonge]

I propose that a section on this is added to the implementation and deployment advice document