Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
- mobile phone, tablet, computer…
- dynamic token devices (i.e. RSA key, Vasco token, etc.) and static token devices (e.g. a certificate), both issued by a Certification Authority, which is part of a Public Key Infrastructure.
Data (for example: a SMS) linked to a device (for example: a mobile) can be considered as answering the possession obligation imposed by the strong authentification if the following conditions are fulfilled:
- The enrolment procedure is secured;
- The data cannot be copied on another device without the agreement of the user.
The client can have different secured devices.
The customer experience has to remain simple.
If this notion includes behaviour characteristics (behaviour biometry such as keystroke, mouse usage…), it could be accepted to strengthen the “inherence” element.
Today, behaviour-based characteristics cannot be recognized as an authentification factor on their own. From a technical perspective, the password authentication works well. It is not the case of behaviour-based authentification. However, in the future, the behaviour-based characteristics techniques will improve and the question will have to be considered again.
It is also important to note that applicable privacy legislation have to be taken in account when using behaviour-based elements.
The sole scoring related to connection or purchase habits is clearly not sufficient in the context of “inherence” elements to process a SCA.
The SMS is compliant with the eIDAS regulation as it is only valid for one operation. It allows dynamic authentification with a substantial level of guaranty.
The enrolment procedure of the SMS is important as the SMS proves that the client uses a device registered by the bank.
Concerning the corporate bodies, it seems possible to start a secure operation on one device and to end it on another device. This solution cannot be used for retail clients as it is far too complex.
For users, we consider the 3DS process existing in payment cards provides this dynamic linking: today a dynamic code issued by the ASPSP (Account Servicing Payment Service Providers) is sent to the PSU (Payment Service Users), who enters it to finalize his/her payment knowing the amount and beneficiary, and hence validates the true amount and beneficiary. This code could be supplied to PSU with key payment data (beneficiary and total amount) to ensure compliance with what-you-see-is-what-you-sign (WYSIWYS) principles.
A similar process is currently used to finalize SCT payments: if the payment is considered sensitive, a dynamic code issued by the ASPSP is sent to the PSU, who enters it to finalize his/her payment, and then validates the true amount and beneficiary.
In both cases, this could be considered as the relevant information of the payer on the specific transaction. If it was not the case, some ASPSP’s payment infrastructures would have to be upgraded to further dynamically link the code to the beneficiary and amount of the transaction, sealing the payment signature. This could require more than 18 months to develop and to implement for some actors.
For corporate bodies and governmental agencies, the strong customer authentication is performed in a specific way: for instance, corporate bodies do no validate each transaction but a whole file with the summary of all their transactions. The dynamic linking shall only be done with the file.
It results that during the processing of a transaction (account information or payment initiation) through a payment service provider, the ASPSP (Account Servicing Payment Service Providers) must keep a direct access to the customer’s device to process its strong customer authentification, even if the payment service provider relies on the authentication procedures provided by the ASPSP. For safety purpose, the ASPSP must be in charge of defining and managing the strong authentification system.
The dynamic linking will participate to the traceability of the operation.
SG is in favor of the EBA exemptions to the strong authentification (SCA).
The EBA clarifications are useful and SG agrees with them. These exemptions to the strong authentification have to remain optional (i.e. not mandatory). For security purposes, the banks have to remain free, on the basis of objective criteria, to close for a short period the exemptions to the strong authentification (example of objective criteria: unusual operation of a client, high amount of the operation…).
The client experience has to remain easy to use and seamless. For retail clients, SG supports the exemption to the strong authentification for the purely consultative services with no display of sensitive payment data, as suggested by the EBA. SG considers as more acceptable to hide data than to ask for a strong authentification for the consultation services.
Concerning corporate bodies, it does not seem appropriate to hide sensitive data as they are necessary for this type of clients. One corporate body subscription allows an access to various bank accounts. Corporate bodies will therefore use strong authentification.
The EBA exemption list could be completed with installment payments, where only the first transaction should be based on the SCA.
When a strong authentification had been made, it could be appropriate not to ask for it again during a certain time (for example, during 15 minutes without any move) if the following conditions are met:
- the operations are realized on the device on which the strong authentication process has already been performed and if
- a strong authentification is necessary for sensitive operations.
The EBA could then take into account a new factor which would be the period of validity of the strong authentification.
The existing interbank protocols (SWIFT, EBICS…) have to be considered out of scope of the PSD2 as this directive only applies to payment services providers.
For security purposes, the banks have to remain free, on the basis of objective criteria, to close for a short period the exemptions to the strong authentification (example of objective criteria: unusual operation of a client, high value operation…)
SG considers necessary the introduction of criteria to go back to a strong authentification in case of emergency situation (fraud suspicion, transfer to a new IT system which meets technical difficulties…).
SG also recommends considering corrupted devices (for instance a device under jailbreak or root access) as a complement to the risks set forth in paragraph 45.
Risks are higher for instant credit transfer than for differed credit transfer.
SG considers necessary the introduction of criteria to go back to a strong authentification in case of emergency situation (fraud suspicion, transfer to a new IT system which meet technical difficulties…).
SG also recommends adding corrupted devices (for instance a device under jailbreak or root access) as a complement to the risk list set forth in paragraph 45.
Today when using the PSU’s personalised security credentials (PSC), a TPP accesses to the whole online banking of the PSU, including sensitive information as well as information not needed by the TPP to address its client’s needs. For both reasons, it is necessary to strongly protect the PSU's PSC.
The suggested clarification regarding the protection of users personalised security credentials seems to be appropriate but is not enough.
Critical risks currently exist relating to the confidentiality and the integrity of users’ personalised security credentials when a TPP is involved in a transaction and as a consequence in the trust chain.
RTS should be more specific on the protection of PSU’s personalised security credentials. The RTS should clearly state that the PSU has to authenticate himself with the authentication method of his ASPSP inside the ASPSP's environment during the enrolment phase. That will prevent any disclosure of the PSC to third parties, in accordance with the current best practices. It is worth reminding that in case the PSC is compromised while being used for another purpose than the one for which it was established (access to online banking), the PSU will have to change its PSC for every purpose (online banking, aggregation services, payment initiation ...).
SG strongly recommends that TPP do not access to the personalised security credentials at any time during the payment process. They do not need this information to request the ASPSP to initiate a payment.
Moreover, the user has to be able to identify that the TPP is the correct one. TPPs will have to be registered in the EBA register. As the market develops, phishing attacks may increase and TPPs may be hacked. PSUs may then lose confidence when accessing a TPP’s interface as they are not able to make the difference between a genuine TPP’s interface and a fake one.
There should also be an evaluation to ensure a good level of confidence in the overall system. This evaluation should be performed by an independent accredited body (In France, the Banque de France) and state of the art standards should be referred to. All the requirements currently existing on ASPSPs have to apply equally to TPPs (risk assessment, incident monitoring, safeguard processes, etc. – cf. EBA guidelines on the security of internet payments, etc.).
All the requirements currently existing on ASPSPs have to apply equally to TPPs (risk assessment, incident monitoring, safeguard processes, etc. – cf. EBA guidelines on the security of internet payments, etc.).
In terms of security, the enrolment process is the key.
Frameworks such as OAuth 2.0 precisely aim at securing the transmission of the client's consent to access its resource without compromising its online banking credentials. To do that, OAuth introduces an authorisation layer in which a third-party app is issued by the server which hosts, in the client's resource (e.g. the bank), a dedicated set of credentials. Other common and innovative protocols will probably emerge in the coming years to address the future challenges. That reinforces the need for the EBA to remain technology neutral in order to be compatible with the forthcoming new open and common standards.
As mentioned in the answer to question 10, SG strongly recommends that TPP do not access to the personalised security credentials at any time during the payment process. They do not need this information to request the ASPSP to initiate a payment.
SG would recommend solutions where the PSU is redirected by the TPP to the ASPSP's authentication module and authenticates himself/herself in the bank's secure environment. The benefit for the TPP lies in the fact that it will not have to develop and maintain secure processes to access, transmit and store sensitive data.
In the early 2010s, the client had to share his/her credentials with the TPP to access his/her resources, which created numerous problems and limitations. As the number of web services and mobile apps requiring the creation of a user account by the clients have grown, new protocols and frameworks have been designed by the IT international community to address the issue of third parties applications accessing restricted resources. OAuth 2.0 is an example of such frameworks.
As stated in the RFC6749, the following practices are deemed to be unsecure:
- Third party applications are required to store the resource owner's (PSUs) credentials for future use, typically a password in clear-text;
- Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources;
- Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party's password.
Consequently the state-of-the-art practices do not rely on credentials sharing. If sharing credentials was quite common when the draft PSD2 has been written, that is no longer the case. The EBA should take this fact into account.
Moreover, as explained before, state-of-the-art practices evolve quite quickly in the market. This fact strengthens the necessity for the EBA's rules to be technologically neutral to adapt to the future standards and best practices of the market.
However, SG considers as necessary to distinguish the rules applicable to the clients and the ones applicable to the providers.
A centralized body at EU level would be useful. It would be a way to:
- ensure a PKI (public key infrastructure) for a proper and mutual authentication between TPP and ASPSP;
- define common standard and ensure the shared evolution of the common rules;
- define the minimum level of security;
- harmonized implementation and evolution.
An open standard means accessibility, on the contrary to a proprietary standard. Everybody can use it freely.
SG globally supports open and common standards widely shared and used by a majority of entities such as W3C.
They also consider the registration of the TPP by an authorization server before accessing the resources of the client. Different methods can be used to perform this step, but in any case the TPP has to provide information to the authorization server (such as application name, description, acceptance of legal terms...).
In our view, other existing standards seem as of today appropriate and relevant, such as for instance TLSv1.2 or EBICS TS.
Such requirements should also be compatible with existing solutions that are already secured (e.g. EBICS TS for instance).
Open standards could be the appropriate answer as open standards allow any type of interfacing, with existing or new frameworks. Once again, in our view, other existing standards seem as of today appropriate and relevant, such as TLSv1.2 or EBICS TS.
It has to be mentioned that a solution implying the issuance by the PIS (Payment Initiation Service) or the AIS (Account Initiation Service) of their own credentials to authenticate strongly the user cannot be used by the ASPSP to collect the user consent to give access to its account to the TPP. Without any contractual relationship between ASPSPs and TPPs, the only way to collect the consent of the user is based on its strong customer authentication by the ASPSP.
A) Trust services
This may be the following:
- Signature of his orders by the payer using an electronic signature trust service;
- Authentication of websites AIS / PIS through a certificate issuance service to authenticate websites;
- Time stamp of certain ‘sensitive time’ operations using an electronic time stamping service.
For the identification of AIP/PIS, it is possible to apply the authentication service of trust websites of e-IDAS regulation. The regulation does describe the qualified level, but it can be used for non-certified levels.
The authentication certificate of the website is defined as a certificate that authenticates a website and links it to the person or entity to which the certificate is issued.
B) Authentication Levels
The use of identification schemes is possible, even if they were initially intended for the public sphere, and conditional on the notification made by the Member States.
Some concepts of the PSD are also present in the e-IDAS regulation. In particular, the high level of authentication PSD matches the substantial level of e-IDAS regulation.
Dynamic authentication is also defined by the Act of 2015/1502 execution of e-IDAS regulation.
The act of implementation 2015/1502 of e-IDAS Regulation of the Commission on 8 September 2015 defines levels of electronic identification means. There are three levels Low / Substantial / High according to several categories of criteria (including evidence and verification of identity, how the signer is authenticated, the strength of the authentication mechanism in relation to potential attacks of varying levels high).
However, it is not because a service is not qualified that it is unreliable. For example it can comply with all the standards corresponding to the qualified level, but not having undergone the certification stage. It can also be in accordance with certain standard levels set by the e-IDAS regulation, ensuring a substantial level of reliability, but without being able to claim the qualified level."
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
The examples provided for in Article 97(1)(c) appear to be complete. The wording of the Directive is also opened enough to take into account all the situations. There seems to be no additional examples of transactions or actions implying a risk of payment fraud or other abuses to be considered in the forthcoming RTS.2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
Some devices can be considered as possession elements:- mobile phone, tablet, computer…
- dynamic token devices (i.e. RSA key, Vasco token, etc.) and static token devices (e.g. a certificate), both issued by a Certification Authority, which is part of a Public Key Infrastructure.
Data (for example: a SMS) linked to a device (for example: a mobile) can be considered as answering the possession obligation imposed by the strong authentification if the following conditions are fulfilled:
- The enrolment procedure is secured;
- The data cannot be copied on another device without the agreement of the user.
The client can have different secured devices.
The customer experience has to remain simple.
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
The « behaviour-based characteristics » expression should be defined by the EBA.If this notion includes behaviour characteristics (behaviour biometry such as keystroke, mouse usage…), it could be accepted to strengthen the “inherence” element.
Today, behaviour-based characteristics cannot be recognized as an authentification factor on their own. From a technical perspective, the password authentication works well. It is not the case of behaviour-based authentification. However, in the future, the behaviour-based characteristics techniques will improve and the question will have to be considered again.
It is also important to note that applicable privacy legislation have to be taken in account when using behaviour-based elements.
The sole scoring related to connection or purchase habits is clearly not sufficient in the context of “inherence” elements to process a SCA.
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
The SMS is not kept on the device (mobile phone), and the compromising of this element (the SMS) does not imply the compromising of the other element (the mobile phone). The SMS need therefore to be considered as being able to participate to a strong authentification.The SMS is compliant with the eIDAS regulation as it is only valid for one operation. It allows dynamic authentification with a substantial level of guaranty.
The enrolment procedure of the SMS is important as the SMS proves that the client uses a device registered by the bank.
Concerning the corporate bodies, it seems possible to start a secure operation on one device and to end it on another device. This solution cannot be used for retail clients as it is far too complex.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
‘Dynamic linking’ could be considered as information given to the client, such as a reference of the operations.For users, we consider the 3DS process existing in payment cards provides this dynamic linking: today a dynamic code issued by the ASPSP (Account Servicing Payment Service Providers) is sent to the PSU (Payment Service Users), who enters it to finalize his/her payment knowing the amount and beneficiary, and hence validates the true amount and beneficiary. This code could be supplied to PSU with key payment data (beneficiary and total amount) to ensure compliance with what-you-see-is-what-you-sign (WYSIWYS) principles.
A similar process is currently used to finalize SCT payments: if the payment is considered sensitive, a dynamic code issued by the ASPSP is sent to the PSU, who enters it to finalize his/her payment, and then validates the true amount and beneficiary.
In both cases, this could be considered as the relevant information of the payer on the specific transaction. If it was not the case, some ASPSP’s payment infrastructures would have to be upgraded to further dynamically link the code to the beneficiary and amount of the transaction, sealing the payment signature. This could require more than 18 months to develop and to implement for some actors.
For corporate bodies and governmental agencies, the strong customer authentication is performed in a specific way: for instance, corporate bodies do no validate each transaction but a whole file with the summary of all their transactions. The dynamic linking shall only be done with the file.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
There are existing solutions such as OTP (one time password delivered by a token independent from the mobile phone, such as RSA key, Vasco token, etc., or by SMS) or OOB (out of band) which fulfill both objectives of independence and dynamic linking. If the independence of the authentication elements on a mobile device is combined with adequate fraud management, this fraud management would require detailed information on the associated payment information, used device and context usage.It results that during the processing of a transaction (account information or payment initiation) through a payment service provider, the ASPSP (Account Servicing Payment Service Providers) must keep a direct access to the customer’s device to process its strong customer authentification, even if the payment service provider relies on the authentication procedures provided by the ASPSP. For safety purpose, the ASPSP must be in charge of defining and managing the strong authentification system.
The dynamic linking will participate to the traceability of the operation.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
SG would much appreciate a definition of the notion of ‘sensitive data’ and ‘purely consultative services’.SG is in favor of the EBA exemptions to the strong authentification (SCA).
The EBA clarifications are useful and SG agrees with them. These exemptions to the strong authentification have to remain optional (i.e. not mandatory). For security purposes, the banks have to remain free, on the basis of objective criteria, to close for a short period the exemptions to the strong authentification (example of objective criteria: unusual operation of a client, high amount of the operation…).
The client experience has to remain easy to use and seamless. For retail clients, SG supports the exemption to the strong authentification for the purely consultative services with no display of sensitive payment data, as suggested by the EBA. SG considers as more acceptable to hide data than to ask for a strong authentification for the consultation services.
Concerning corporate bodies, it does not seem appropriate to hide sensitive data as they are necessary for this type of clients. One corporate body subscription allows an access to various bank accounts. Corporate bodies will therefore use strong authentification.
The EBA exemption list could be completed with installment payments, where only the first transaction should be based on the SCA.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
The EBA could take into account the number of transactions, the number of connections, the maximum amount of payment…When a strong authentification had been made, it could be appropriate not to ask for it again during a certain time (for example, during 15 minutes without any move) if the following conditions are met:
- the operations are realized on the device on which the strong authentication process has already been performed and if
- a strong authentification is necessary for sensitive operations.
The EBA could then take into account a new factor which would be the period of validity of the strong authentification.
The existing interbank protocols (SWIFT, EBICS…) have to be considered out of scope of the PSD2 as this directive only applies to payment services providers.
For security purposes, the banks have to remain free, on the basis of objective criteria, to close for a short period the exemptions to the strong authentification (example of objective criteria: unusual operation of a client, high value operation…)
SG considers necessary the introduction of criteria to go back to a strong authentification in case of emergency situation (fraud suspicion, transfer to a new IT system which meets technical difficulties…).
SG also recommends considering corrupted devices (for instance a device under jailbreak or root access) as a complement to the risks set forth in paragraph 45.
9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
The EBA could take into account the number of transactions, the number of connections, the maximum amount of payment…Risks are higher for instant credit transfer than for differed credit transfer.
SG considers necessary the introduction of criteria to go back to a strong authentification in case of emergency situation (fraud suspicion, transfer to a new IT system which meet technical difficulties…).
SG also recommends adding corrupted devices (for instance a device under jailbreak or root access) as a complement to the risk list set forth in paragraph 45.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Safety of personalised credentials is central for payments service providers.Today when using the PSU’s personalised security credentials (PSC), a TPP accesses to the whole online banking of the PSU, including sensitive information as well as information not needed by the TPP to address its client’s needs. For both reasons, it is necessary to strongly protect the PSU's PSC.
The suggested clarification regarding the protection of users personalised security credentials seems to be appropriate but is not enough.
Critical risks currently exist relating to the confidentiality and the integrity of users’ personalised security credentials when a TPP is involved in a transaction and as a consequence in the trust chain.
RTS should be more specific on the protection of PSU’s personalised security credentials. The RTS should clearly state that the PSU has to authenticate himself with the authentication method of his ASPSP inside the ASPSP's environment during the enrolment phase. That will prevent any disclosure of the PSC to third parties, in accordance with the current best practices. It is worth reminding that in case the PSC is compromised while being used for another purpose than the one for which it was established (access to online banking), the PSU will have to change its PSC for every purpose (online banking, aggregation services, payment initiation ...).
SG strongly recommends that TPP do not access to the personalised security credentials at any time during the payment process. They do not need this information to request the ASPSP to initiate a payment.
Moreover, the user has to be able to identify that the TPP is the correct one. TPPs will have to be registered in the EBA register. As the market develops, phishing attacks may increase and TPPs may be hacked. PSUs may then lose confidence when accessing a TPP’s interface as they are not able to make the difference between a genuine TPP’s interface and a fake one.
There should also be an evaluation to ensure a good level of confidence in the overall system. This evaluation should be performed by an independent accredited body (In France, the Banque de France) and state of the art standards should be referred to. All the requirements currently existing on ASPSPs have to apply equally to TPPs (risk assessment, incident monitoring, safeguard processes, etc. – cf. EBA guidelines on the security of internet payments, etc.).
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Major risks are detailed by the EBA. Critical risks currently exist relating to the confidentiality and the integrity of users’ personalised security credentials in the context of disruption of the trust chain when a TPP is involved in a transaction. It can be difficult for the PSU to identify that the TPP is the correct one.All the requirements currently existing on ASPSPs have to apply equally to TPPs (risk assessment, incident monitoring, safeguard processes, etc. – cf. EBA guidelines on the security of internet payments, etc.).
12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
Open standards currently available on the market, such as https, could be used.In terms of security, the enrolment process is the key.
Frameworks such as OAuth 2.0 precisely aim at securing the transmission of the client's consent to access its resource without compromising its online banking credentials. To do that, OAuth introduces an authorisation layer in which a third-party app is issued by the server which hosts, in the client's resource (e.g. the bank), a dedicated set of credentials. Other common and innovative protocols will probably emerge in the coming years to address the future challenges. That reinforces the need for the EBA to remain technology neutral in order to be compatible with the forthcoming new open and common standards.
As mentioned in the answer to question 10, SG strongly recommends that TPP do not access to the personalised security credentials at any time during the payment process. They do not need this information to request the ASPSP to initiate a payment.
SG would recommend solutions where the PSU is redirected by the TPP to the ASPSP's authentication module and authenticates himself/herself in the bank's secure environment. The benefit for the TPP lies in the fact that it will not have to develop and maintain secure processes to access, transmit and store sensitive data.
13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
SG does not identify alternatives to certification or evaluation by third parties of component payments solutions or mobile devices.In the early 2010s, the client had to share his/her credentials with the TPP to access his/her resources, which created numerous problems and limitations. As the number of web services and mobile apps requiring the creation of a user account by the clients have grown, new protocols and frameworks have been designed by the IT international community to address the issue of third parties applications accessing restricted resources. OAuth 2.0 is an example of such frameworks.
As stated in the RFC6749, the following practices are deemed to be unsecure:
- Third party applications are required to store the resource owner's (PSUs) credentials for future use, typically a password in clear-text;
- Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources;
- Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party's password.
Consequently the state-of-the-art practices do not rely on credentials sharing. If sharing credentials was quite common when the draft PSD2 has been written, that is no longer the case. The EBA should take this fact into account.
Moreover, as explained before, state-of-the-art practices evolve quite quickly in the market. This fact strengthens the necessity for the EBA's rules to be technologically neutral to adapt to the future standards and best practices of the market.
14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
The segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur focuses on the entrance of the service providers in the payment chain. It is difficult for a bank to be sure that the provider which tries to connect itself, is the one agreed by the client.15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
The clarifications of the EBA are comprehensive and suitable.However, SG considers as necessary to distinguish the rules applicable to the clients and the ones applicable to the providers.
A centralized body at EU level would be useful. It would be a way to:
- ensure a PKI (public key infrastructure) for a proper and mutual authentication between TPP and ASPSP;
- define common standard and ensure the shared evolution of the common rules;
- define the minimum level of security;
- harmonized implementation and evolution.
An open standard means accessibility, on the contrary to a proprietary standard. Everybody can use it freely.
SG globally supports open and common standards widely shared and used by a majority of entities such as W3C.
16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
Governance is expected by ASPSPs to ensure a space for the actors to exchange and implement the PSD2 in a harmonized way.17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
New protocols such as OAuth 2.0 do take into account the privacy dimension to the extent that the client defines the set of resources that the third party app can access to deliver its own service. On the contrary to the current practice of aggregators, where they can access to the whole online banking, these new frameworks respect the principle of privacy by design.They also consider the registration of the TPP by an authorization server before accessing the resources of the client. Different methods can be used to perform this step, but in any case the TPP has to provide information to the authorization server (such as application name, description, acceptance of legal terms...).
In our view, other existing standards seem as of today appropriate and relevant, such as for instance TLSv1.2 or EBICS TS.
18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
Future requirements that will be defined by EBA need to be as open as possible to encompass further innovation.Such requirements should also be compatible with existing solutions that are already secured (e.g. EBICS TS for instance).
Open standards could be the appropriate answer as open standards allow any type of interfacing, with existing or new frameworks. Once again, in our view, other existing standards seem as of today appropriate and relevant, such as TLSv1.2 or EBICS TS.
It has to be mentioned that a solution implying the issuance by the PIS (Payment Initiation Service) or the AIS (Account Initiation Service) of their own credentials to authenticate strongly the user cannot be used by the ASPSP to collect the user consent to give access to its account to the TPP. Without any contractual relationship between ASPSPs and TPPs, the only way to collect the consent of the user is based on its strong customer authentication by the ASPSP.
19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
Both means of electronic identification, and the trust services of e-services IDAS regulation, can be applied.A) Trust services
This may be the following:
- Signature of his orders by the payer using an electronic signature trust service;
- Authentication of websites AIS / PIS through a certificate issuance service to authenticate websites;
- Time stamp of certain ‘sensitive time’ operations using an electronic time stamping service.
For the identification of AIP/PIS, it is possible to apply the authentication service of trust websites of e-IDAS regulation. The regulation does describe the qualified level, but it can be used for non-certified levels.
The authentication certificate of the website is defined as a certificate that authenticates a website and links it to the person or entity to which the certificate is issued.
B) Authentication Levels
The use of identification schemes is possible, even if they were initially intended for the public sphere, and conditional on the notification made by the Member States.
Some concepts of the PSD are also present in the e-IDAS regulation. In particular, the high level of authentication PSD matches the substantial level of e-IDAS regulation.
Dynamic authentication is also defined by the Act of 2015/1502 execution of e-IDAS regulation.
The act of implementation 2015/1502 of e-IDAS Regulation of the Commission on 8 September 2015 defines levels of electronic identification means. There are three levels Low / Substantial / High according to several categories of criteria (including evidence and verification of identity, how the signer is authenticated, the strength of the authentication mechanism in relation to potential attacks of varying levels high).
20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.
The use of trusted services of e-IDAS regulation at a qualified level does not seem absolutely necessary. Achieving a confidence level of service Qualified" leads his presumption of reliability.However, it is not because a service is not qualified that it is unreliable. For example it can comply with all the standards corresponding to the qualified level, but not having undergone the certification stage. It can also be in accordance with certain standard levels set by the e-IDAS regulation, ensuring a substantial level of reliability, but without being able to claim the qualified level."