Security architecture basically follows the NextGenPSD2 API and addresses the specific requirements and needs of Switzerland.
The Swiss banks are responsible for issuing and accepting the certificates of TPPs. They can create the certificates themselves or delegate the allocation. Compared to the EU, there is currently no central contact body in Switzerland provided for by the legislator or regulator.
In the following, the four consent management procedures accepted by the Berlin Group will be explained and the advantages and disadvantages will be pointed out. Furthermore, the method based on the Six b.Link solution is presented.
The method Redirect was derived as a recommendation in the Swiss NextGen API. The very suitable, but not supported by the Berlin Group method "Open ID Connect" is taken on the roadmap.
Security architecture basically follows the NextGenPSD2 API and addresses the specific requirements and needs of Switzerland.
The Swiss banks are responsible for issuing and accepting the certificates of TPPs. They can create the certificates themselves or delegate the allocation. Compared to the EU, there is currently no central contact body in Switzerland provided for by the legislator or regulator.
In the following, the four consent management procedures accepted by the Berlin Group will be explained and the advantages and disadvantages will be pointed out. Furthermore, the method based on the Six b.Link solution is presented.
The method Redirect was derived as a recommendation in the Swiss NextGen API. The very suitable, but not supported by the Berlin Group method "Open ID Connect" is taken on the roadmap.
User is "transferred" from the TPP to the bank for SCA.
Technically implemented with HTTP Redirect (302)
+ Uncomplicated
+ Easy adaptation to specific use case
+ Also works with offline SCA mechanism
- Mechanism to pass information from bank to TPP requires mutual agreement
User is "transferred" from the TPP to the bank for SCA.
Technically implemented with HTTP Redirect (302)
+ Very similar to Redirect
+ Standardized procedure
- No possibility to send use case-specific information via OAuth2-client to OAuth2-AS
- Information transfer mechanism selected for NextGenPSD2 violates the standard and is not validated
The user is contacted by the bank through another channel to confirm the transaction.
Technically usually implemented by a push message to a Smartphone App
+ Only procedure that also works at POS (does not require a browser)
- Requires SCA procedure with push function (usually Smartphone App)
- Works only if data connection to the app is guaranteed (no offline possibility)
User enters bank credentials on the web page of the TPP, which uses them to authenticate to bank on behalf of the user. Requires huge efforts by TPPs to implement all the different SCA mechanisms.
+ Allows highly integrated user guidance
- TPP receives all bank credentials of the user
- TPP is man-in-the-middle and the customer cannot defend himself against it.
User must first select and activate the TPP in Web Banking before it can be accessed.
Technically solved as «bank-initiated» OAuth2 authorization code grant flow
+ No redirection of the user to the bank login page by TPP
+ Bank can outsource management & authentication of TPPs to Six (but loosing possibility to individually vet TPPs)
+ Makes use of a standard protocol
- Process has no similarities with PSD2 and is not available with NextGenPSD2
- «Bank initiation» of OAuth2 needs special code at TPP
- Not implemented by any foreign TPP
User is "transferred" from the TPP to the bank for SCA.
Technically implemented with HTTP Redirect (302)
+ Uncomplicated
+ Easy adaptation to specific use case
+ Also works with offline SCA mechanism
- Mechanism to pass information from bank to TPP requires mutual agreement
User is "transferred" from the TPP to the bank for SCA.
Technically implemented with HTTP Redirect (302)
+ Very similar to Redirect
+ Standardized procedure
- No possibility to send use case-specific information via OAuth2-client to OAuth2-AS
- Information transfer mechanism selected for NextGenPSD2 violates the standard and is not validated
The user is contacted by the bank through another channel to confirm the transaction.
Technically usually implemented by a push message to a Smartphone App
+ Only procedure that also works at POS (does not require a browser)
- Requires SCA procedure with push function (usually Smartphone App)
- Works only if data connection to the app is guaranteed (no offline possibility)
User enters bank credentials on the web page of the TPP, which uses them to authenticate to bank on behalf of the user. Requires huge efforts by TPPs to implement all the different SCA mechanisms.
+ Allows highly integrated user guidance
- TPP receives all bank credentials of the user
- TPP is man-in-the-middle and the customer cannot defend himself against it.
User must first select and activate the TPP in Web Banking before it can be accessed.
Technically solved as «bank-initiated» OAuth2 authorization code grant flow
+ No redirection of the user to the bank login page by TPP
+ Bank can outsource management & authentication of TPPs to Six (but loosing possibility to individually vet TPPs)
+ Makes use of a standard protocol
- Process has no similarities with PSD2 and is not available with NextGenPSD2
- «Bank initiation» of OAuth2 needs special code at TPP
- Not implemented by any foreign TPP