This article is our quick tour to PSD2 regulations and how they affect to eIDAS business opportunities. We will improve the article when we learn more about PSD2. We believe PSD2 model is broken for authentication. This article is not exhaustive and it is not a strict fact analysis (because the PSD2 is still quite new and vague). The article contains our opinions based how we read those standards. Please, do not take this article too seriously.
1. Introduction to eIDAS
eIDAS: electronic IDentification, Authentication and trust Services, commonly known as eIDAS, which was introduced by European Commission as a part of efforts to standardize rules for digital/electronic transactions across the continent. eIDAS regulation known as 910/2014, created rules for trust services and defined framework for: electronic signatures (QES), electronic seals(QES), electronic time stamps, electronic documents, and last but the least, certificate services for website authentication (QWAC).
Privacy and security are the most important attributes of the eIDAS. Where non-repudiation was made a priority. With 8 years of feedback around eIDAs we see a shift today. With advent of eIDAS2 and introduction of European Digital Identity, we see more care is being given to protect the identity of persons and their personal data. Motivation behind this shift is that currently you share all your identity attributes with every entity and this can be considered as user’s privacy problem.
2. Introduction to PSD2
Payment Services Directive 2 aka PSD2 (EU 2015/2366) has been applied since 13 January 2018. PSD2 tries to define and handle a payment transactions. The main objective of PSD2 is to ensure the security of electronic payments and to reduce the risk of fraud.
In practice less than 30%1 of PSD2 definitions restricts the transactions to payments only. Therefore, PSD2 transactions can be utilized in very many business contexts. One example which can be seen are signing services.
Moreover, PSD2 encourages PSPs to this kind of innovations. Additionally, PSD2 tries formalize payment security requirements to the national legislation2. Once the legally binding of PSD2 transactions have been agreed, there are no restrictions to use the PSD2 transactions also in other business contexts, which inherently provides a loophole to bypass eIDAS-regulations .
2.1 PSD2 is interpreted friendly
EBA as the banking authority has been very lenient when reading PDS2. We would have been much more strict. It definitely opens lots of ways to implement the directive, and none seem to be following a standardized path. Maybe EBA should change their name to European Bank Association.
2.2 PSD2 avoids product certification burden
PSD2 defines the technical standard as RTS (Regulatory Technical Standards). The RTS standard is something which is probably the most “recent” or “in force” version, no standard version numbers are needed, no expiration or anything that is used in a normal technical standard. In contrast, eIDAS uses well defined technical standards. Additionally, eIDAS defined (at least roughly) how products need to be certified.
The result is that SCA products can be anything under the sky and in the worst case the eIDAS specification requires costly and long security evaluation processes of different products.
3. Transactional requirements of eIDAS and PSD2
Both eIDAS and PSD2 transactions require some identity and security assertions to work together. Main difference between the two remains, eIDAS talks more with existing standards terms from MSS, DSS, Oasis and ETSI standards. However, EBA published its ‘final-draft of Regulatory Technical Standards on Strong Customer Authentication’ and secure communication under PSD2 very carefully using payment oriented terms, which are more or less very board and opaque.
It definitely opens lots of innovative ways to implement the directive. RTS clarifies several ambiguities in their explanations, but like a good thriller it has still kept all of us hanging with unanswered questions at the end.
Though eIDAS is well defined, same remains true for eIDAS 2.0 and European Digital Identity where technical details remain to be seen, and impacts of it will also reach financial sector.
3.1 eIDAS transactions
Under the eIDAS-regulations, transactions can contain a data container holding a group of file objects, digital signatures and/or time assertions that are associated to those objects. All this information in one container was accepted by European Commission, as they laid down specifications relating to formats of Qualified/Advanced electronic signatures and Qualified/Advanced seals to be recognized legally.
eIDAS specifies for example ASiC – an associated signature container, can contain XML, CMS or PDF electronic signature which complies with XAdES, CAdES, and PAdES standards is termed Advanced Electronic Signature (AdES). When the ASiC container contains a Qualified Digital certificate, it is called Qualified Electronic Signature (QES).
3.2 PSD2 transactions
Though PSD2 came for financial sector, but it does not restrict the data specifically to payments. PSD2 Payment data is actually any sensitive data carried in the transaction.
PSD2 transactions have three elements1:
- Strong Customer Authentication (SCA)
- Common and Secure Communication (CSC)
- Payment data
Others can argue dynamic linking with authentication code can be considered as fourth element, however it remains covered in CSC.
EBA clarifies the SCA as an authentication based on the use of two or more elements categorized as knowledge (something only the user knows such as password or a PIN or “personal identification number”), possession (something only the user possesses, such as device) and inherence (something the user is such as biometrics). Once authentication is completed, it has to be linked to the transaction details using a Dynamic Linking process. These categories are independent and the breach of one category does not compromise the reliability of the others.
There are lots of weird claims around the SCA technology. One of the best is this one: “One difference between the SCA requirements and most other regulations is that SCA requirements are based on computer security theory”. This is one problem of all SCA papers that when they use references they refer to something, which is at least as big as the computer security theory.
One very strange issue in PSD2 is the implementation requirements for a CSC. PSD2 requires that eIDAS qualified certificates (QWAC) are used for website authentication and electronic seals are used for communication between financial services players. We do not understand this. Where’s the beef?
Using eIDAS certificates to identify with banks became law for TPPs on 14th September 2019, along with PSD2 technical standards (SCA-RTS). RTS set out that banks must have an interface that enables a third-party provider (TPP) to identify itself and communicate securely to request and receive information or to initiate a payment order. For the identification part, TPPs and banks must rely on certificates issued by regulated bodies called Qualified Trust Service Provider (QTSPs).
4. Security requirements of eIDAS and PSD2
The implementation of eIDAS transactions (issuing QES, QWAC, etc) requires the implementation to be undisputed, non-repudiation and tamper-proof. This is ensured by making sure signature/transaction is uniquely identified to the signer, signature creation data (especially the private key) must be under the sole control of signer only, there must be tamper-proof protection in place and the user must have a qualified certificate (which are issued after identity proofing). All these four requirements are extremely important, and standardized and tested.
PSD2 earlier draft specified the use of multi-purpose devices (mobile phones and the like) used a Trusted Execution Environment (TEE) for security. TEE is a well-defined, tried, and tested standard, but it seems it won’t be enforced. Seems like, EBA has caved in to pressure from organizations lobbying for non-standard based solution (proprietary and in some cases, less secure) solutions. The RTS now mandates a ‘Secure Execution Environment,’ which has no current industry definition, so mobile security effectively becomes a free for all again. This is where ETSI, CEN, EBA, European Commission, standardization committees of eIADS and PSD2 come together and work for a standardized solution.
5. Conclusion
5.1 Redefining eIDAS with PSD2: Re-Inventing the wheel?
European Bank Authority (EBA) has identified several improvements for the PSD2 directive. In relation to the clarifications on the application of SCA, the EBA proposes:
- clarify aspects on the application of SCA related to reliance on third party technology, delegation of SCA to Third Party Provider (TPP) and delegation to technical service providers, including digital wallet providers;
- clarify different aspects in relation to the use of the SCA elements ‘knowledge’, ‘inherence’ and ‘possession’,
- clarify the nature of the exemptions from SCA and whether these should be optional or mandatory; and
- clarify explicitly that the application of SCA should be considered as a corrective and preventive measure, thus being free of charge.
All these aspects are key points also in eIDAS. More or less, eIDAS and PSD2 talk about same concerns. While there are standards for one, second remains at the wimp of financial sector to decide for themselves.
5.2 Implement PSD2 with eIDAS support
eIDAS qualified certificates are used only for website authentication. This approach provides almost null compliance with eIDAS and it does not have nothing to do with eIDAS transactions. However, this requirement makes PSD2 to be officially eIDAS compliant and obfuscates a lot public discussion.1 This is clearly only a very narrow perspective from the EBA, because the supplementing Directive (EU) 2015/2366 talks about authentication codes and low value transactions. Once PSD2 high level SCA requirements have been accepted as legally binding transactions, then PSD2 provides a way to use lower authentication mechanisms as well.
Chain of trust under PSD2 scheme and under eIDAS/eIDAS2.0 scheme converges at some point, but there needs to be more interoperability.
Additionally, PSD2 defines the use of a separated secure execution environments through the software installed inside the multi-purpose device. Really? Nowadays Tursted Execution Environment (TEE) development is under GlobalPlatform2. Additionally, the TEE defines an execution platform for applications and not a key storage or any similar plain-old smart card stuff. By using unidentified secure execution environment term in PSD2 looks like someone wants to mess up a lot.
5.3 Our brutal assessment
Based on our quick analysis here is our brutal assessment:
- PSD2 transactions will be legally binding similarly as eIDAS transaction.
- PSD2 regulation claims to utilize eIDAS and claims to be compliant.
- PSD2 does not need open standard protocols
- PSD2 does not need certifications similarly as eIDAS.
- PSD2 is easier and more cost efficient to implement.
- PSD2 can provide payments and all that eIDAS provides.
- Banking authority interpret PSD2 RTS more lenient that anyone else interprets eIDAS regulation.
If we cannot standardize SCA and Customer Authentication according to eIDAS, PSD2 will inherently keep providing a loophole to bypass eIDAS-regulations to offer business critical applications where trust is needed. Dream of digital Europe with means to facilitate secure and seamless electronic transactions within the Union, remains a dream. As a final conclusion, why do we need eIDAS. PSD2 is much better?
6. How to Fix
The easiest way to fix this weird situation between PSD2 and eIDAS, would be to explicitly restrict PSD2 to payment transactions only. That would mean that payment or receipt of payment wouldn’t be proof of identity in any case. It wouldn’t harm anyone.
We support digital identity over a wide variety of authentication mechanisms and security assertions. As a global leader of open standard Mobile ID and Signature services, Methics solutions and products are delivering tech for strong authentication and signatures. Methics will offer a bridge between traditional PKI, eIDAS and PSD2 to provide identity and signing services. Feel free to get in touch with us if you want to discuss the presented model.
Publish Date: 9 August 2022
Written and Edited by: Jarmo Miettinen & Ammar Bukhari
Reference:
- PSD2 :
- In Finland till the end of year 2010 there were several banks calling a bank calculated hash as a digital signature. That was very confusing when there was real digital signature services available at the same time.
- https://globalplatform.org/technical-committees/trusted-execution-environment-tee-committee/
- https://www.eba.europa.eu/sites/default/documents/files/document_library/Publications/Draft%20Technical%20Standards/2022/EBA-RTS-2022-03%20RTS%20on%20SCA%26CSC/1029858/Final%20Report%20on%20the%20amendment%20of%20the%20RTS%20on%20SCA%26CSC.pdf
- https://www.eba.europa.eu/sites/default/documents/files/documents/10180/2622242/4bf4e536-69a5-44a5-a685-de42e292ef78/EBA%20Opinion%20on%20SCA%20elements%20under%20PSD2%20.pdf?retry=1
- https://thepaypers.com/thought-leader-insights/what-is-the-impact-of-eu-digital-id-wallets-on-banks-and-financial-institutions–1255579
- https://www.eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money/regulatory-technical-standards-on-strong-customer-authentication-and-secure-communication-under-psd2
- Image by Tumisu from Pixabay