Yes, IdenTrust can see benefit in the requirements for strong customer authentication. However, the provisions proposed in Chapter 1 appear to have a solution in mind, and digital signatures seem to be excluded from the solution outcome. It is not clear why eIDAS is considered at the website certificates level, but not at the natural person level. Equally it is not clear how interoperability will be achieved. Digital signatures can meet the knowledge and possession requirements; proves and establishes identity; delivers non-repudiation; combats frauds; provides audit and compliance tracking; guarantees privacy; ensures data integrity; eliminates man-in-the-middle attacks; provides legally binding user-level signatures and can be used in multiple applications. The signatures can be validated in real time by the relying party. With the number of parties involved at any one time, the relying party will change through the transaction flow and identification, and authentication, between account servicing payment service providers, payment initiation service providers, account information service providers, payers, payees and other payment service providers then real time validation at the point of reliance is critical. The inter-party liability provisions do not seem to have been addressed. An end-to-end secure payment system underpinned by using digital signatures with a risk management and liability framework could help provide this.
Yes, IdenTrust believes that the dynamic linking should be a feature of the application rules and channel. However, as a practical matter, we believe that a customer will initiate the payment within the application on the same device, and if this segregation/independence test is taken forward, then customer experience will be poor and could be a barrier to adoption.
It is not clear that brute force attack has been considered.
No, IdenTrust do not agree. It seems to be a blunt instrument and crude mitigation to the lack of a liability model and agreed dispute resolution regime, and does not allow the parties to take risk-managed decisions on the transactions involved. If caps are introduced, what is the mechanism for managing change of those caps going forward?
See Q4 response
Yes, IdenTrust agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, but we do not agree with the resultant provisions provided in Chapter 3. If the authentication procedure will remain fully in the sphere of competence of the ASPSP, then they need to be in control of the provision of the PSUs credentials, which will be an existing BAU process. This Chapter and Articles seem imbalanced and rather than outcome based are too prescriptive.
Yes, IdenTrust agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information. However, we do believe that for interoperability then Chapter 4 should define the detail of communication interface/or provide for its definition
The use of ISO20022 elements is a worthy intent, but specificity is required. Whilst this is an industry standard, if the message types do not exist today they need to be defined and agreed. If they do agree today, then the message identifiers and elements to be used needs to be documented in this RTS standard.
As eIDAS seeks to enhance trust in electronic transactions in the EU's internal market by providing a common foundation for secure electronic interaction between citizens, businesses and public authorities cross-borders, in order to increase the effectiveness of public and private online services, electronic business and electronic commerce in the Union, then it is understandable that this has been considered to provide the mutual trust between PSPs. The challenge will be that supervisory bodies and accreditation regimes need to be implemented in order for Trust Service Providers to register and be accredited. The timelines will be tight, and IdenTrust believe that Option 4.2.2 (Allow identification via certificates issued by a General Certificate Authority) should be explored in parallel.
Unless the customer has given their explicit consent" to that access, then IdenTrust believes that there should be zero frequency permitted."
[Other "]"
IdenTrust provide a global borderless trust network that is
– based on pki technology standards
– places risk control at its source
– allocates liability by contractual framework
– provides system-wide risk management
– and a platform for finanical institutions and other providers to develop replicable solutions from bank-to-business, business-to-business and consumer-to-consumer
[Other"]"
PKI Infrastructure and OTP Authentication Hosted Managed Services provided as Software as a Service
