...
In the context of Open Finance(OF) the Central Authentication and Authorization Provider(CAAP) acts as a the an IdP for the LFIs which are the RPs that participate in the federation.
...
The User is verified and onboarded with the CAAP and can then use the authentication with the CAAP to securely authorise their LFIs for account access through multiple TPPs.
This takes away removes the need for the User having to authenticate with their LFI for every new Data Sharing Request(DSR)/Service Initiation Request(SIR) interaction through the TPPs.
...
For Authenticating and Authorizing OF requests using the CAAP for LFIs that support the federated model the following one-time setup steps are needed
...
We have used one example of a User-facing TPP and DSR journey to demonstrate how a User can be onboarded with the CAAP as part of a an OF journey. (The same applies to SIR and service requests)
These flows apply to other variations based on Use Cases covered in detail under the sections: Use Cases
2.1 User Journey
...
2.2 Wireframes
...
consuming the TPP service on a mobile app, mobile browser or a desktop browser
has selected a an LFI that uses the federated authentication model using the CAAP
does not have a CAAP app
Click here for a prototype depicting this journey.
| Rules & Guidelines |
---|---|
1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs authentication, data grouping and/or service initiation capabilities. |
2 | User-facing TPPs MUST make the User aware on the inbound redirection screen(User-facing TPP to CAAP) that the authorisation for the request needs to be done through the CAAP app and provide additional information related to CAAP app. |
3 | Since the User does not have the CAAP app the redirection MUST take the User to a web page hosted by the CAAP. |
4 | The CAAP webpage MUST provide the following
|
5 | On redirection to the CAAP webpage in Step 4 the consent details will be persisted for the User which will be retrieved and presented after the User installs the app (using the mechanism of deferred deep linking). |
6 | After installing the CAAP app the User MUST be presented with a one time consent to be given to the CAAP app to
|
7 | The CAAP app MUST perform a ID verification of the User which will involve
Each step MUST be presented with clear instructions |
8 | On successful verification of the User’s identity, the CAAP app MUST link the LFI which was selected as part of the consent. For this
|
9 | On successfully linking the LFI, the User MUST be presented the OF consent given to the TPP. If the Consent Authorisation Window as expected by the TPP has expired then the User MUST be informed that they need to initiate the request again from the TPP. |
10 | As an additional step for authorization of the consent the CAAP COULD conditionally request another biometric authentication only for the following scenarios
|
11 | On successful authorization MUST have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
12 | CAAP MUST inform the User on the outbound redirection screen that their session with the CAAP was closed. |
13 | User-facing TPPs MUST confirm the successful completion of the OF Request (DSR, SIR). |
2. Linking subsequent LFIs with CAAP
...
We have used one example of a User-facing TPP and DSR journey to demonstrate how a User can authorize a an OF consent for a new LFI using the CAAP app. (The same applies to SIR and service requests)These flows apply to other variations based on Use Cases covered in detail under the sections: Use Cases
2.1 User Journey
...
2.2 Wireframes
...
Click here for a prototype depicting this journey.
| Rules & Guidelines |
---|---|
1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs authentication, data grouping and/or service initiation capabilities. |
2 | User-facing TPPs MUST make the User aware on the inbound redirection screen( User-facing TPP to CAAP) that the authorisation for the request needs to be done through the CAAP app and provide additional information related to CAAP app. |
3 | If the user is consuming the TPP service(mobile app/mobile web page) on the same mobile device which has the CAAP app the redirection MUST take the User to the CAAP app. |
4 | If the user is consuming the TPP service on the device which does not have the CAAP app then the redirection MUST take the User to a CAAP hosted webpage which MUST provide the following
|
5 | On redirection from Step 3 or 4 the CAAP app will request for the biometric/Device PIN authentication. |
6 | On successful User authentication, the CAAP app MUST link the LFI which was selected as part of the consent. For this
|
7 | On successfully linking the LFI, the User MUST be presented the OF consent given to the TPP. If the Consent Authorisation Window as expected by the TPP has expired then the User MUST be informed that they need to initiate the request again from the TPP. |
8 | As an additional step for authorization of the consent the CAAP COULD conditionally request another biometric authentication only for the following scenarios
|
9 | On successful authorization of the consent the CAAP MUST have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
10 | CAAP MUST inform the User on the outbound redirection screen that their session with the CAAP was closed. |
11 | User-facing TPPs MUST confirm the successful completion of the OF Request (DSR, SIR). |
3. OF journey for a Linked LFI
...
We have used one example of a User-facing TPP and DSR journey to demonstrate how a User can authorize a an OF consent for a linked LFI using the CAAP app. (The same applies to SIR and service requests)
These flows apply to other variations based on Use Cases covered in detail under the sections: Use Cases
2.1 User Journey
...
2.2 Wireframes
...
consuming the TPP service on a mobile app, mobile browser or a desktop browser
is onboarded with the CAAP app
has selected a an LFI that uses the federated authentication model and is already linked with the CAAP app
...
Click here for a prototype depicting this journey
| Rules & Guidelines |
---|
Rules & Guidelines
1 | User-facing TPPs MUST initially ask the User to identify the LFI so that the consent request can be constructed in line with the LFIs authentication, data grouping and/or service initiation capabilities. |
2 | User-facing TPPs MUST make the User aware on the inbound redirection screen( User-facing TPP to CAAP) that the authorisation for the request needs to be done through the CAAP app and provide additional information related to CAAP app. |
3 | If the user is consuming the TPP service(mobile app/mobile web page) on the same mobile device which has the CAAP app the redirection MUST take the User directly to the CAAP app. |
4 | If the user is consuming the TPP service on the device which does not have the CAAP app then the redirection MUST take the User to a CAAP hosted webpage which MUST provide the following
|
5 | On redirection from Step 3 or 4 the CAAP app will request for the biometric authentication. |
6 | After successful User authentication the CAAP app MUST present the OF consent given to the TPP. |
8 | As an additional step for authorization of the consent the CAAP COULD conditionally request another biometric authentication only for the following scenarios
|
9 | On successful authorization of the consent the CAAP MUST have an outbound redirection screen which indicates the status of the request and informs the User that they will be automatically taken back to the User-facing TPP. |
10 | CAAP MUST inform the User on the outbound redirection screen that their session with the CAAP was closed. |
11 | User-facing TPPs MUST confirm the successful completion of the Open Banking Service Request (DSR, SIR). |