Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Icon Solutions welcome the opportunity to respond to the consultation on the Regulatory Technical Standards (RTS). Having fully reviewed the document we do not believe that all of the significant feedback can be captured in the context of the specific questions posed in the document, so we have provided a more extensive set of comment which we hope will be useful.
Scope and Definitions.
Balancing the original Intent of PSD2. As part of the general intent of PSD2, we recognise dual goals of standardisation whilst allowing for future innovation and there is a difficult balance in trying standardise payments across all of the EU countries, without being too prescriptive for innovation to occur. In our view, the Draft RTS is left too open, and the resulting ambiguities will make it difficult or impossible to determine whether a particular implementation conforms to the RTS. A standard must be something against which specific items can be measured, and the RTS as drafted fails this test.
More specific documents. We note that the EBA ‘Guidelines on the Security of Internet Payments’ were more detailed and specific than the RTS. Many of the requirements in that document could be consolidated into the RTS, providing a single source for EBA security advice. We would also draw attention to other vendor-neutral standards in this area which provide more specific guidance such as EMV Issuer and Application Security and NIST Digital Authentication Guidelines.
Context Missing. Taken alone, the core draft RTS text is difficult to interpret due to lack of context. In general, the document covers physical card payments, mobile payments and online only direct Bank payments, but some sections seem applicable only to a particular class of technology (e.g. smart cards). The text leaves it ambiguous whether this is the case. We would suggest being more specific in the situations referenced and the actual technical standards that the EBA expects to be applied.
Phrasing of requirements. In order to be precise with intent and direction, we would strongly recommend that the EBA follow the RFC 2119 standard in the use of key words MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe the mandate of the EBA requirements. Use of the term “including, but not limited to” may also be construed incorrectly – we would recommend that imperative minimum standards be set out first, with optional or additional standards set out after.
Specifying participants. Additional clarity could be added by specifying which specific participant in the payment scenarios envisaged by the EBA are required to perform actions such as Verification. Failure to specify the actor, or use of the ambiguous term “PSP”, may lead actors to believe incorrectly that the action is not required of them.
Existing Best Practice versus Future Solutions. Several bodies already exist that have significant experience, currently provide oversight, and have published standards that have been validated by the industry. We would recommend that the EBA should make use of those bodies and standards where applicable for current technologies, while still allowing future innovation to occur thereafter.
For example, we would recommend the nomination of the European Union Agency for Network and Information Security (ENISA) as the body to oversee Information standards, while referencing the existing publications and standards of the US National Institute of Standards and Technology (NIST).
Other specific agencies and bodies where security testing and certification has taken place, can be used as reference by the EBA – for example PKCS, OpenGroup, IEEE, IETF, ISO/IYU, ETSI, PCI-DSS, EMVCo could all be referenced and relied upon for commons and specific standards already in operations by PSD2 participants.
Reference Lists and Regulating Suppliers. Articles 5 and 6 refer to security features of devices and software such as protection features, tamper resistance and trusted execution, but no specific standards are provided against which to evaluate devices. Even if such standards were specified, it would be impractical for individual organizations to perform an assessment of each device proposed for this purpose. We would therefore support EBA future actions to set up a separate EU or EBA organisation, that would maintain lists of:
a. EBA approved SCA physical devices manufacturers and specific devices that have been approved for Article 5 and Article 6 use, covering all variant categories.
b. EBA approved authorities or industry bodies that publish and update the standards for specific Article 5 and Article 6 devices.
c. EBA approved organisations and companies that can provide testing and auditing services for Article 5 and Article 6 devices.
d. EBA approved organizations to oversee specific standards needed for Browser, operating system, cryptography or any other non-physical technical security standards.
e. The method by which security compromises of any existing standards or devices may be reported to a central authority, which may then be cascaded to any EU Member State competent authority, who may then take immediate steps to safeguard PSUs.
Icon additional comments to the Consultation Paper. Finally, we note that the actual EBA RTS draft Articles are only half of the complete Consultation Paper and that there are other distinct proposals mentioned by the EBA in the rest of the document that significantly affect the reading of the original EU Directive 2015/2366. We have therefore included direct responses to the 10 questions proposed, and then a further section, requesting clarity or making suggestions to other proposals.
==========================================
Q1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
NOTE: There are several parts to provisions proposed in Chapter 1, so it is not possible to give a simple Yes/No answer to Question 1. The question seems to refer only to Article 1 of Chapter 1 and we have answered accordingly – other Articles are addressed in responses to subsequent questions.
Regarding the overall reasoning and procedures of authentication, there is a notable absence of verification standards that usually correspond to the specific uses of certain methods of authentication. Specific details on the combined authentication/verification minimum requirements on binding, issuing, enrolment, storage, checking, renewal and revocation is needed to ensure that correct and secure operations for each combination of SCA application can be performed with minimum matching errors for all participants in the process.
To this end, we would recommend strongly the consideration of the EBA to include verification standards which correspond to specific methods of authentication.
Article 1 – Authentication procedure and Authentication code
Article 1 fails to distinguish between Authentication (the PSU proves their identity) and Authorisation (the PSU approves the execution of a specific operation). Authentication should enable access to further actions, such as personally viewing sensitive payments data, selecting a bank account to pay from or to perform the entry of payment details which will then require Authorisation (SCA with dynamic linking as described in Article 2) for execution. Authorisation with dynamic linking should be applicable to single payments (for a specific amount and for a specific payee), batches or sequences of payments, creation of a single trusted beneficiary, granting an AISP enduring permission to retrieve Payment Account data, and granting a PSP enduring permission to check the availability of a specific amount, related to a card-based payment transaction.
Article 1.1 – we believe the RTS should provide a technical specification of EU 2015/2366 Article 4 (30). For example, NIST Special Publication 800-63B provides an in-depth description of Digital Authentication and the standards by which they may be applied. Specifically, there is a specific detail in the different levels of Authentication assurance that may be given, with the associate combination of elements.
The EU and EBA may choose to replicate to the same level of detail the need for Assurance levels (2 or 3) and the expectations by the EBA/ECB for their suggested permissible combination of authentication elements and the minimum associated technical or security standards for each of the elements used.
We query the reason why a single factor authentication may not be used for the purpose of low level authentication, particularly online for accessing basic payment accounts information, as the consumer experience would be significantly disrupted from current operations.
In general we would recommend an escalating level of authentication and authorisation, taking into account risk factors such as behavioural analytics and pattern analysis, rather than the current binary approach of full SCA with defined exceptions.
Article 1.3 – we would suggest a clarification to the wording of paragraph (e):
“(e) prevent, detect and block any suspected fraudulent payment transactions before the ASPSP’s final transaction authorisation.”
We would also recommend the inclusion of a condition that the ASPSP or PSP should be required to immediately notify the payer of the fraud detection and transaction block through a known, secure and separate channel.
Section (e) should include a mandatory check of the validity of EIDAS certificates for PISPs and AISPs using OCSP or a similar online mechanism each time a request is made, in order to ensure that all certificates and permissions are valid, before proceeding with further actions.
The mechanism described in (e) ii potentially requires a level of mandated information to be provided specifically from the PISP, AISP and when they are communicating in the secure session, such as PSU’s device type, device ID, IP address etc. This information is available today where the ASPSP has created and secured their own website or mobile application and therefore would be able to get sufficient data to then perform a fraud or behavioural analytics checks. This same level of payer/customer protection should be maintained when an AISP or PISP is involved. ASPSPs should be empowered to block transaction requests that do not provide that information without compromise to the PSD2 2015/2366 Article 35 (access on non-discriminatory terms).
Section (e) iv refers to “customer device” and (e) v refers to “payer’s device”. These are not defined in PSD2 2015/2366 Article 4 and are also not detailed in the EBA RTS. We would recommend the EBA to detailing the two terms for clarity, and also to follow NIST SP 800-63B to distinguish between a ‘sole-purpose payment device’ - such as an RSA Token generator, EMV Card, EMV or NFC POS terminal or mPOS device – which are specifically tested and tamper proof, and a ‘multi-purpose payment device’, such as mobiles, tablets or laptops, which are not purpose-built and have not been issued by an ASPSP or PSP, and therefore require a different level of scrutiny during fraud and analytics preventions. "
We agreed with the reasoning to the EBA remaining neutral as to when the dynamic link should occur as this may vary depending on the type of transaction interaction (physical or remote), and we strongly agree that the procedure should always take place.
However, we found this section difficult to read as the terms may relate to different payment scenarios and can broadly be interpreted in different ways. This may stem from the lack of definition of ‘electronic payment transaction’ in Article 4, but referenced in Article 97 (2) of the original PSD2 2015/2366 document and we would recommend the addition of a definition by the EBA, such as “physical electronic payment” or “remote electronic payment”, for which there are already two clearly distinct and separate technical standards for which the EBA should provide more detailed implementation guidance.
Given a good articulation in the early rationale of the document, we draw attention to section 3.2, which provided detail, but was missing from the actual RTS Draft text:
24… Indeed, according to the requirements for SCA proposed in this CP, the authentication code can be either a single piece of data that is being input by the payer on the interface of the relevant PSP or can be generated from several pieces of data, such as a one-time password that is being input by the payer on the interface of the relevant PSP, the amount, and the payee of the transaction. Alternatively, the authentication code can take the form of digital signatures of such data using keys stored in the authentication elements.
25. This clarification means, for example, that the one-time password (OTP) linked to the amount and payee may be alternatively generated by the payer’s PSPs with or without any action required by the payer itself, according to the technological solution adopted…
Reading the above, we found it difficult then to get the same meaning from the draft of Article 2 as implied by these earlier statements; the term ‘Authentication Code’ conflicted with existing Industry variations of use for that term and was too broadly applied to too many scenarios (physical versus remote) to provide application or implementation guidance.
Below, we have tried to highlight our understanding and constructively seek clarity for various scenarios to which the actual text of Article 2 may apply.
Article 2.1 – As noted previously the blanket use of the term “authentication code” and lack of relevance to specific scenarios and actions is confusing.
Article 2.1 (a) - It is often the case that the payee of a transaction is different from the entity with which the consumer is interacting. For example, merchants frequently use an acquirer who would be the payee for transaction, and who settles with the merchant periodically. A PSU may refuse to approve a transaction where the payee is apparently different from the merchant with whom they are transacting.
Article 2.2 (a) – We agree with the sentiment of this provision but the wording lacks specificity which leaves an open interpretation. We would suggest replacing the phrase “Any change to the amount or payee shall result in a change of the authentication code” with the following statements:
• Authorisation codes generated via SCA SHALL only be presented once to the ASPSP for transaction approval, and whether approved or declined, that same authorisation code MUST NOT be able to be successfully for any further transaction approval requests.
• Any change to the amount or payee SHALL require SCA to be applied again by the ASPSP, with a new authorisation code generated specific to the new amount and/or payee combination.
Article 2.2 (b) - There is insufficient definition of what the EBA considers a channel, device or mobile application and required level of independence or separation to provide the required confidentiality, authenticity or integrity required.
We recommend a separate definition “Channel”, “Device” and “Mobile Application” plus the technical or security standards the EBA would require to be applied to each of these for the use of input, session or display, in order for this requirement to be operable in the real-world.
We recommend also the EBA provides definitions of the terms ‘independent’ and ‘segregated’ – for example, is a new tab in the same browser “segregated”? What about a new browser window? What about a different app on the same device?
We are concerned about the implications for card payments made at physical POS terminals. The draft would seem to require the amount and payee to be displayed by some device other than the POS terminal, e.g. the PSU’s mobile phone. The knock-on effects of such a requirement would be significant – slowing down check-out at supermarkets, hence requiring more lanes, more cashiers and higher staff costs; mobile data communications costs, especially when roaming; etc.
As a particular best practice for multi-channel procedures, we drawn attention to the NIST SP 800-63B, sections 5.1.3, 5.1.3.1 and 5.3.1.2. We would particularly recommend that the EBA consider section 5.1.3.2. where known risks of interception and redirection in the use of any OOB methods (SMS or Voice) over a Public Switch Telecoms Network as a secondary verification channel is now strongly discouraged. In our reading of the draft RTS, such use of SMS or voice would still be permissible.
Article 3.1 – The phrase ‘use of non-repeatable characters’ is subject to multiple interpretations, e.g. the same character may not be used anywhere else in the password; or just not allowed next in the key sequence.
Article 3.2 – Rather than simply mentioning “mitigation measures”, we would recommend that the RTS spells out best practice standards, as the NIST document does. More detail of the specific authentication methods, with corresponding requirements for verification standards, would support correct implementation by ASPSPs and PSPs.
Article 4.2 – Rather than simply mentioning “anti-cloning features”, we would recommend that the RTS spells out best practice standards. Also, this Article does not mention the risk of theft of the possession element. For some devices (such as passive RSA hard tokens) theft is sufficient to give a bad actor access to the possession element. For other devices (such as smartcard readers), additional compromises would be needed before the bad actor could use the element. The RTS should spell out requirements in this area.
We would also recommend that Paragraphs 2 and 3 from Article 6 be moved to this section.
Article 5.1 – The requirement for ‘a sufficiently low likelihood’ of an unauthorised party being authenticated must be quantified.
Article 5.2 – This article refers to “the devices and the software provided to the payer” with a possible interpretation that these devices and software must be provided by the ASPSP. It should be made clear whether multifunction devices such as mobile phones are permitted under this Article; and if so, what specific devices sufficiently “guarantee resistance” against unauthorised use of the elements. In particular we would question whether the use of TouchID on an Apple iPhone would comply with the RTS, given that the capture of biometric details and association with PSU’s ID is not under secure control of the ASPSP, and there are known security bypasses that have been widely publicised with all iPhones in market. If indeed TouchID does not comply with RTS requirements, use of mobile phones to read inherence elements would seem to be a future possibility rather than a current reality.
Article 6.3(a) – There is a mention but no definition of a trusted execution environment. We would recommend that the EBA adopts or references the Trusted Execution Environment and Secure Element standards as laid out by Global Platform - TEE and SE standards or Trusted Platform Module (TPM) standards ISO 11889-1. We also note that there is currently an exercise to merge the two standards into the Global Platform TEE standards, and would therefore support the adoption or reference to Global Platform standards.
Additionally, we would recommend that the EBA refers to existing guidance that has been issued by the ECB and ERPB, such as: https://www.ecb.europa.eu/paym/cons/pdf/131120/recommendationsforthesecurityofmobilepaymentsdraftpc201311en.pdf
Article 6.3(b) – ASPSPs and PSPs are wholly reliant on the manufacturers of multi-purpose devices such as mobile handsets, tablets or laptop devices to provide adequate security information. Hence PSPs can only comply with this Article on a “reasonable endeavours” basis.
Article 7.1 We are slightly confused by the wording of this paragraph and have recommended the following amendments:
The overall security of the strong customer authentication procedure and standards implemented by either ASPSP or PSP shall be tested annually, evaluated and audited by an external, independent and certified auditors, according to the latest available EBA RTS and associated approvals lists. A list of certified auditors in each Member State will be maintained and shall be made publicly available via the internet by the local Competent Authority.
Article 7.2. The review referred to in paragraph 1 shall be provided in the form of a report ensuring that the strong customer authentication procedure and standards encompasses measures to comply with this Regulation.
Article 7.3. The report referred to in paragraph 2 shall be made fully available to competent authorities annually, who will share reports with the EBA. Where non-compliance or breaches occur, Member States’ competent authorities shall be responsible for enforcement of compliance, remedy plans and where required, fines.
Article 8.1(a) - There is a problem with the reference to “sensitive payment data” which the EBA has refused to define, but which Article 4 (32) of PSD2 defines as “data … which can be used to carry out fraud”. Some ASPSPs use items of data from the information of the payment account to authenticate the customer on the telephone. This data may include items such as recent transaction details or postcode. This interpretation would prevent ASPSPs from displaying any payments transactions data and payments account data under this exemption.
We believe the EBA must outline the standard and minimum expectations of what constitutes ‘sensitive payment data’ in order for this mandate to be operable.
In paragraph ii we would recommend the removal of ‘months’ in the RTS draft, to be replaced by a certain number of days (such as 30 days), as the number of days in each month varies and the calculation of each month’s variations causes unnecessary complexity in requirements.
Article 8.1(b) – We assume there will be flexibility for member states transposing this provision to vary the currency and/or amounts of this Article.
The second point seems to be a re-interpretation of the current requirement to do an EMV PIN validation after three consecutive contactless transactions at POS terminals over 24 hours. Changing the criterion from a simple transaction count over a 24-hour period to a cumulative value calculation over an unbounded period may require significant changes in ASPSP systems, so the EBA should present evidence that the value-based approach would result in significantly reduced fraud levels.
There are also exceptions situations that arise from the ability to perform SCA, depending on the location, activity and terminal type; we draw attention to the operation of Contactless Card payments in the UK with Transport for London, where there is no capability for SCA to be implemented.
Article 8.1(d) – In line with exemption on Contactless transactions, we would recommend the EBA to change from a Cumulative Value based SCA initiation system, to a Consecutive Transaction based SCA initiation system, so ASPSP operations are simplified.
In general, we would support the EBA’s inclusion of new terms which would support:
1. The ASPSPs and PSPs being able to request SCA from a customer regardless of whether the transaction falls under normal exemption rules.
2. The ASPSPs and PSPs being able to waive SCA upon their own reasoning, provided that liability is accepted by the ASPSP or PSP in the case that the transaction is later disputed by the payer.
3. Clear guidance on which actor in the payments chain will bear the liability in each of the exemptions scenarios.
Authentication elements include the Personalised Security Credentials (PSCs), i.e. the personalised features provided by the payment service provider to the PSU for the purposes of authentication, as well as devices and software used to generate or receive authentication codes that may either be provided by the payment service provider to the payment service user or possessed by the payment service user without being provided by the payment service provider. In that respect, PSPs should ensure the protection of the confidentiality and integrity of PSCs, authentication devices and software, in compliance with the requirements included in Chapter 3 of these RTS.
Many of our clients and other colleagues in the industry found the term “personalised security credentials” (PSC) difficult to comprehend as it is used to mean potentially any of the three SCA elements that have been bound to their payment service user. As knowledge, possession and inherence all differ in both collection, provision, interaction and fundamentally are involved with different SCA procedures, we have answered this question, highlighting where each SCA element may different in the current blanket terms given in the RTS.
We disagree with the EBA’s reasoning specifically on the point made in “or possessed by the payment service user without being provided by the payment service provider”. We reference a recent issue with AndroidPay HCE, where the PSU device relies on a manufacturer, OS and Apps that can access the PSU’s PSC issued tokenised card details.
http://www.bbc.co.uk/news/technology-37495102
Unlike the Apple iPhone ApplePay, the PSC credentials in any AndroidPay pay enabled phone with a Secure Element and Trusted Execution Environment can be accessed by many third parties, all of which may be outside of the knowledge or control of the ASPSP or PSP. Therefore, we do not believe that ASPSPs or PSPs should be held responsible for any devices or software used by the PSU unless it has been issued by them and can be directly checked by the ASPSP or PSP for security when needed. As an aside here, we would welcome future regulation on the mandated access and security for ASPSPs and PSPs to mobile device manufacturers for the use of payments – as it is a large and evolving field, we would suggest a separate review and legislation beyond PSD2.
For knowledge elements of PSCs, we understand the situations where users may choose their own Memorized Secrets (such as Online Password or Card PIN) and in this case, specific procedures for issuance, binding, storage, authentication and reset/recovery should apply. For Devices or Software, or for Biometrics, separate measures and rules should apply – therefore in our answer below and where appropriate, we have tried to support the EBA’s further separation of PSCs related to SCA elements and we have suggested procedures that may be considered as an industry security standard without prejudice to existing supplier PSCs (unless they pose a known risk to PSU security).
Article 9.1 – We believe substantial improvements to the wording of this section are required, and we provide some suggestions as follows:
(a) Data related to personalised security credentials are masked when displayed and not readable in their full extent in any format, once bound to the PSU. This includes but is not limited to ‘starring’ a password or PIN on an electronic display or keypad when being input, and obscuring/ redacting a Card PAN on a physical receipt.
(b) Personalised security credentials data as well as cryptographic material related to the encryption of the personalised security credentials are not stored in plain text and will at a minimum apply techniques such as “salting”, “nonces” and appropriate industry encryption standards whenever stored by an ASPSP or PSP.
(c) Secret cryptographic material related to the encryption of the credentials is stored in devices or processing environments that have been fully tested and certified to appropriate levels. For security standards of devices and environments, please see the industry standards as detailed in Article 4 of this RTS.
2. The process related to the management of cryptographic material used to encrypt or otherwise render unreadable the personalised security credentials shall be fully documented within the specific SCA authentication procedure used by the ASPSP or PSP, and shall be submitted for audit under the schedule specified by the Member State’s designated competent authority. The EBA or the Member State’s competent authority will publish notices if new security issues are made known, and may provide instructions or remedies related to PSCs for the protection of PSUs.
Article 10 - Whilst we agree in principle, the mention of card based transactions initiated by the payee is specific enough to refer to the current standards that apply for card-payments acceptance terminals.
For the purposes of clarity and quicker implementation we would recommend that the EBA includes reference to current standards being used in market and to advocate the use of these to ensure both payee and payer security:
1. For Physical Card Acceptance:
EMV Terminal Applications standards
EMV Terminal Type Approvals standards, in addition to:
PCI Pin Transaction Security (PTS) standards
PCI Point to Point Encryption (P2PE) standards
2. For Electronic and Remote Card Transaction Processing:
PCI Data Security Standards (applicable to all)
PCI Payment Applications Standards (including Mobile Apps)
Article 11 – It is unclear which security measures are referred to here, and the actor(s) responsible for defining, implementing and enforcing them.
Article 12 to Article 15 – These articles suffer from the same lack of clarity regarding responsibilities as in Article 11, above.
Generally, we view the current text as insufficient to be operable or measurable against correct implementation and would recommend here that the EBA follows or adapts the detailed guidelines within NIST SP 800-63B, Section 6 “Authentication Lifecycle Management”, as well as in the individual Authenticator sections detailing each element and specific standards for their secure operation.
Article 16 - Again we suggest the EBA adds more specificity as to documentation and reporting responsibilities. As there have not been any specific technical standards mentioned in this document, it would currently be impossible for a certified auditor define objective and quantitative tests to check for compliance. Indeed, it is moot as to which certification an auditor would require. We would recommend the EBA to look to the example of the PCI Security Standards Council which operates specific training and examinations to appoint Qualified Security Assessors.
Also, use of the terms “periodically” and allowing the “periodicity” to be defined by PSPs does not seem sufficient as regulation – at a minimum, we suggest that an Audit take be conducted by externally appointed auditors and be reported to Member State competent authorities and at least one social engineering and penetration test take place bi-annually.
Article 17 - As terminals are mentioned, reference to the latest baseline security standards would help to support actual implementation.
In particular, ‘secure bilateral identification’ requires reference to specific standards depending on the payment method, for example:
1. We would recommend combined DDA with application cryptogram (CDA) for both physical Payment Cards and Terminals. The current RTS draft would allow Static Data Authentication (SDA) Cards and Terminals, which have known flaws.
2. For remote/internet PISP initiated credit transfers, we would suggest the use of Json Web Tokens with HMAC-256 to ensure a good starting level of security. The current RTS draft would allow use of Json Web Tokens with RS or ES asymmetric keys which have critical known flaws.
Article 18(a) – We believe there is a critical problem with this Article, which can be resolved by removing the words “allowing the identification of the communicating parties”. While a unique session identifier is essential to correlate messages within a dialogue, it is not possible to require the session identifier to also allow identification of the communicating parties. For example, a session established between a PSU and a PISP cannot possibly uniquely identify the PSU, because the PSU does not assert their identity until after the session is established. Moreover, the PSU does not assert their identity to the PISP, but rather to the ASPSP, potentially via a different session on an independent or segregated device per Article 2.
Article 19 – While we appreciate that the EBA has to remain technologically neutral, nevertheless we expected a strong recommendation from the EBA for the mandated adoption of APIs as a suggested Interface.
APIs are common, widely used and allow 3rd parties to not only access the services in consistent and technologically superior ways, but also allow flexible architecture that would support third parties to build services on top of the pure services provided by ASPSPs and PSPs in-line with the goal of supporting future payments innovations in the EU.
The failure to refer to specific standards may well lead to a disparate service offering from each ASPSP or PSP. This will cause undue costs to integrate for Merchants and PISPs, as well as a confusion for customer/payers when using two different payment products from different providers.
In particular we are disappointed that the EBA has not explicitly outlawed “screen-scraping” technology, which we believe is not only dated, costly and redundant when APIs are provided, but also inherently insecure.
Article 19.1(a) – Identification of PSPs to the ASPSP should rely on Qualified certificates (per Article 20) issued for this purpose.
Article 19.1(b) - As written this could be interpreted as making all services available to all PSPs. This could be easily resolved by adding the word “respectively” at the end of the clause.
Article 21.4(a) – This article suffers a similar problem to Article 18. Not all messages can contain unambiguous reference to the payment service user, because some messages are exchanged before the PSU has asserted their identity. Only the ASPSP needs to know the identity of the PSU, and the purpose of the authorisation code issued by the ASPSP is to differentiate between several requests (purportedly) from the same PSU.
Article 21.5 – AISPs and PISPs should never be in possession of Personalised Security Credentials, neither at rest nor in transit. Instead, per 19.1(c), AISPs and PISPs should rely on the authentication procedures provided by the ASPSP. The only reason for AISPs or PISPs to have access to Personalised Security Credentials is if a “screen scraping” technology is in use. As discussed in relation to Article 19, such technologies are inherently insecure precisely because of the risk of compromise of PSCs. If a PSU discovered that their PSCs had been compromised, it would be virtually impossible to track down the source of the breach.
Authentication codes should not be treated as confidential. Correctly implemented, they can only be used by the third party to which they were originally issued, for the purpose for which they were issued. An authentication code in the hands of a bad actor should be completely harmless.
A further complication is that ISO20022 is defined as XML, where modern APIs overwhelmingly favour JSON. This would require further work to agree a JSON representation of the ISO20022 XML document structures. In particular, Json Web Tokens is a technology that is perfectly suited to this domain, but would be very difficult to use within ISO20022 messages.
A third complication is that several of the messages needed to implement the business processes required for PSD2 have no representation in the current ISO20022 message set. For example, a request by an AISP for authorisation to request account information on behalf of a PSU has no corresponding ISO20022 message.
Unless a very significant effort is put into enhancing and extending the ISO20022 message standards, it will not be possible to use them for this purpose, and even where they are pressed into service, will not provide a significant level of interoperability.
It would also be tremendously helpful if the EBA made the list of qualified trust service providers in each Member State territory more readily available and web searchable by Member States rather than having to Google and search through web pages, to read through a PDF or XML..
http://certifiedsignature.eu/2015/07/20/eu-trusted-lists-of-certification-service-providers-tsl-ts-119-612/
Allowing AISPs to request account data more frequently than twice daily would risk overloading ASPSP systems. If a particular application requires more real-time information about changes to the PSU’s account information it seems reasonable for the AISP to negotiate special access to the information outside the scope of PSD2, possibly using a more efficient “push” mechanism rather than a polling “pull” mechanism.
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
Introduction:Icon Solutions welcome the opportunity to respond to the consultation on the Regulatory Technical Standards (RTS). Having fully reviewed the document we do not believe that all of the significant feedback can be captured in the context of the specific questions posed in the document, so we have provided a more extensive set of comment which we hope will be useful.
Scope and Definitions.
Balancing the original Intent of PSD2. As part of the general intent of PSD2, we recognise dual goals of standardisation whilst allowing for future innovation and there is a difficult balance in trying standardise payments across all of the EU countries, without being too prescriptive for innovation to occur. In our view, the Draft RTS is left too open, and the resulting ambiguities will make it difficult or impossible to determine whether a particular implementation conforms to the RTS. A standard must be something against which specific items can be measured, and the RTS as drafted fails this test.
More specific documents. We note that the EBA ‘Guidelines on the Security of Internet Payments’ were more detailed and specific than the RTS. Many of the requirements in that document could be consolidated into the RTS, providing a single source for EBA security advice. We would also draw attention to other vendor-neutral standards in this area which provide more specific guidance such as EMV Issuer and Application Security and NIST Digital Authentication Guidelines.
Context Missing. Taken alone, the core draft RTS text is difficult to interpret due to lack of context. In general, the document covers physical card payments, mobile payments and online only direct Bank payments, but some sections seem applicable only to a particular class of technology (e.g. smart cards). The text leaves it ambiguous whether this is the case. We would suggest being more specific in the situations referenced and the actual technical standards that the EBA expects to be applied.
Phrasing of requirements. In order to be precise with intent and direction, we would strongly recommend that the EBA follow the RFC 2119 standard in the use of key words MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe the mandate of the EBA requirements. Use of the term “including, but not limited to” may also be construed incorrectly – we would recommend that imperative minimum standards be set out first, with optional or additional standards set out after.
Specifying participants. Additional clarity could be added by specifying which specific participant in the payment scenarios envisaged by the EBA are required to perform actions such as Verification. Failure to specify the actor, or use of the ambiguous term “PSP”, may lead actors to believe incorrectly that the action is not required of them.
Existing Best Practice versus Future Solutions. Several bodies already exist that have significant experience, currently provide oversight, and have published standards that have been validated by the industry. We would recommend that the EBA should make use of those bodies and standards where applicable for current technologies, while still allowing future innovation to occur thereafter.
For example, we would recommend the nomination of the European Union Agency for Network and Information Security (ENISA) as the body to oversee Information standards, while referencing the existing publications and standards of the US National Institute of Standards and Technology (NIST).
Other specific agencies and bodies where security testing and certification has taken place, can be used as reference by the EBA – for example PKCS, OpenGroup, IEEE, IETF, ISO/IYU, ETSI, PCI-DSS, EMVCo could all be referenced and relied upon for commons and specific standards already in operations by PSD2 participants.
Reference Lists and Regulating Suppliers. Articles 5 and 6 refer to security features of devices and software such as protection features, tamper resistance and trusted execution, but no specific standards are provided against which to evaluate devices. Even if such standards were specified, it would be impractical for individual organizations to perform an assessment of each device proposed for this purpose. We would therefore support EBA future actions to set up a separate EU or EBA organisation, that would maintain lists of:
a. EBA approved SCA physical devices manufacturers and specific devices that have been approved for Article 5 and Article 6 use, covering all variant categories.
b. EBA approved authorities or industry bodies that publish and update the standards for specific Article 5 and Article 6 devices.
c. EBA approved organisations and companies that can provide testing and auditing services for Article 5 and Article 6 devices.
d. EBA approved organizations to oversee specific standards needed for Browser, operating system, cryptography or any other non-physical technical security standards.
e. The method by which security compromises of any existing standards or devices may be reported to a central authority, which may then be cascaded to any EU Member State competent authority, who may then take immediate steps to safeguard PSUs.
Icon additional comments to the Consultation Paper. Finally, we note that the actual EBA RTS draft Articles are only half of the complete Consultation Paper and that there are other distinct proposals mentioned by the EBA in the rest of the document that significantly affect the reading of the original EU Directive 2015/2366. We have therefore included direct responses to the 10 questions proposed, and then a further section, requesting clarity or making suggestions to other proposals.
==========================================
Q1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
NOTE: There are several parts to provisions proposed in Chapter 1, so it is not possible to give a simple Yes/No answer to Question 1. The question seems to refer only to Article 1 of Chapter 1 and we have answered accordingly – other Articles are addressed in responses to subsequent questions.
Regarding the overall reasoning and procedures of authentication, there is a notable absence of verification standards that usually correspond to the specific uses of certain methods of authentication. Specific details on the combined authentication/verification minimum requirements on binding, issuing, enrolment, storage, checking, renewal and revocation is needed to ensure that correct and secure operations for each combination of SCA application can be performed with minimum matching errors for all participants in the process.
To this end, we would recommend strongly the consideration of the EBA to include verification standards which correspond to specific methods of authentication.
Article 1 – Authentication procedure and Authentication code
Article 1 fails to distinguish between Authentication (the PSU proves their identity) and Authorisation (the PSU approves the execution of a specific operation). Authentication should enable access to further actions, such as personally viewing sensitive payments data, selecting a bank account to pay from or to perform the entry of payment details which will then require Authorisation (SCA with dynamic linking as described in Article 2) for execution. Authorisation with dynamic linking should be applicable to single payments (for a specific amount and for a specific payee), batches or sequences of payments, creation of a single trusted beneficiary, granting an AISP enduring permission to retrieve Payment Account data, and granting a PSP enduring permission to check the availability of a specific amount, related to a card-based payment transaction.
Article 1.1 – we believe the RTS should provide a technical specification of EU 2015/2366 Article 4 (30). For example, NIST Special Publication 800-63B provides an in-depth description of Digital Authentication and the standards by which they may be applied. Specifically, there is a specific detail in the different levels of Authentication assurance that may be given, with the associate combination of elements.
The EU and EBA may choose to replicate to the same level of detail the need for Assurance levels (2 or 3) and the expectations by the EBA/ECB for their suggested permissible combination of authentication elements and the minimum associated technical or security standards for each of the elements used.
We query the reason why a single factor authentication may not be used for the purpose of low level authentication, particularly online for accessing basic payment accounts information, as the consumer experience would be significantly disrupted from current operations.
In general we would recommend an escalating level of authentication and authorisation, taking into account risk factors such as behavioural analytics and pattern analysis, rather than the current binary approach of full SCA with defined exceptions.
Article 1.3 – we would suggest a clarification to the wording of paragraph (e):
“(e) prevent, detect and block any suspected fraudulent payment transactions before the ASPSP’s final transaction authorisation.”
We would also recommend the inclusion of a condition that the ASPSP or PSP should be required to immediately notify the payer of the fraud detection and transaction block through a known, secure and separate channel.
Section (e) should include a mandatory check of the validity of EIDAS certificates for PISPs and AISPs using OCSP or a similar online mechanism each time a request is made, in order to ensure that all certificates and permissions are valid, before proceeding with further actions.
The mechanism described in (e) ii potentially requires a level of mandated information to be provided specifically from the PISP, AISP and when they are communicating in the secure session, such as PSU’s device type, device ID, IP address etc. This information is available today where the ASPSP has created and secured their own website or mobile application and therefore would be able to get sufficient data to then perform a fraud or behavioural analytics checks. This same level of payer/customer protection should be maintained when an AISP or PISP is involved. ASPSPs should be empowered to block transaction requests that do not provide that information without compromise to the PSD2 2015/2366 Article 35 (access on non-discriminatory terms).
Section (e) iv refers to “customer device” and (e) v refers to “payer’s device”. These are not defined in PSD2 2015/2366 Article 4 and are also not detailed in the EBA RTS. We would recommend the EBA to detailing the two terms for clarity, and also to follow NIST SP 800-63B to distinguish between a ‘sole-purpose payment device’ - such as an RSA Token generator, EMV Card, EMV or NFC POS terminal or mPOS device – which are specifically tested and tamper proof, and a ‘multi-purpose payment device’, such as mobiles, tablets or laptops, which are not purpose-built and have not been issued by an ASPSP or PSP, and therefore require a different level of scrutiny during fraud and analytics preventions. "
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
(NOTE: we suggest moving Article 2 to become a separate Chapter, to make the draft RTS easier to read.)We agreed with the reasoning to the EBA remaining neutral as to when the dynamic link should occur as this may vary depending on the type of transaction interaction (physical or remote), and we strongly agree that the procedure should always take place.
However, we found this section difficult to read as the terms may relate to different payment scenarios and can broadly be interpreted in different ways. This may stem from the lack of definition of ‘electronic payment transaction’ in Article 4, but referenced in Article 97 (2) of the original PSD2 2015/2366 document and we would recommend the addition of a definition by the EBA, such as “physical electronic payment” or “remote electronic payment”, for which there are already two clearly distinct and separate technical standards for which the EBA should provide more detailed implementation guidance.
Given a good articulation in the early rationale of the document, we draw attention to section 3.2, which provided detail, but was missing from the actual RTS Draft text:
24… Indeed, according to the requirements for SCA proposed in this CP, the authentication code can be either a single piece of data that is being input by the payer on the interface of the relevant PSP or can be generated from several pieces of data, such as a one-time password that is being input by the payer on the interface of the relevant PSP, the amount, and the payee of the transaction. Alternatively, the authentication code can take the form of digital signatures of such data using keys stored in the authentication elements.
25. This clarification means, for example, that the one-time password (OTP) linked to the amount and payee may be alternatively generated by the payer’s PSPs with or without any action required by the payer itself, according to the technological solution adopted…
Reading the above, we found it difficult then to get the same meaning from the draft of Article 2 as implied by these earlier statements; the term ‘Authentication Code’ conflicted with existing Industry variations of use for that term and was too broadly applied to too many scenarios (physical versus remote) to provide application or implementation guidance.
Below, we have tried to highlight our understanding and constructively seek clarity for various scenarios to which the actual text of Article 2 may apply.
Article 2.1 – As noted previously the blanket use of the term “authentication code” and lack of relevance to specific scenarios and actions is confusing.
Article 2.1 (a) - It is often the case that the payee of a transaction is different from the entity with which the consumer is interacting. For example, merchants frequently use an acquirer who would be the payee for transaction, and who settles with the merchant periodically. A PSU may refuse to approve a transaction where the payee is apparently different from the merchant with whom they are transacting.
Article 2.2 (a) – We agree with the sentiment of this provision but the wording lacks specificity which leaves an open interpretation. We would suggest replacing the phrase “Any change to the amount or payee shall result in a change of the authentication code” with the following statements:
• Authorisation codes generated via SCA SHALL only be presented once to the ASPSP for transaction approval, and whether approved or declined, that same authorisation code MUST NOT be able to be successfully for any further transaction approval requests.
• Any change to the amount or payee SHALL require SCA to be applied again by the ASPSP, with a new authorisation code generated specific to the new amount and/or payee combination.
Article 2.2 (b) - There is insufficient definition of what the EBA considers a channel, device or mobile application and required level of independence or separation to provide the required confidentiality, authenticity or integrity required.
We recommend a separate definition “Channel”, “Device” and “Mobile Application” plus the technical or security standards the EBA would require to be applied to each of these for the use of input, session or display, in order for this requirement to be operable in the real-world.
We recommend also the EBA provides definitions of the terms ‘independent’ and ‘segregated’ – for example, is a new tab in the same browser “segregated”? What about a new browser window? What about a different app on the same device?
We are concerned about the implications for card payments made at physical POS terminals. The draft would seem to require the amount and payee to be displayed by some device other than the POS terminal, e.g. the PSU’s mobile phone. The knock-on effects of such a requirement would be significant – slowing down check-out at supermarkets, hence requiring more lanes, more cashiers and higher staff costs; mobile data communications costs, especially when roaming; etc.
As a particular best practice for multi-channel procedures, we drawn attention to the NIST SP 800-63B, sections 5.1.3, 5.1.3.1 and 5.3.1.2. We would particularly recommend that the EBA consider section 5.1.3.2. where known risks of interception and redirection in the use of any OOB methods (SMS or Voice) over a Public Switch Telecoms Network as a secondary verification channel is now strongly discouraged. In our reading of the draft RTS, such use of SMS or voice would still be permissible.
Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
We find Articles 3, 4, and 5 incomplete and insufficiently detailed. We would refer the EBA to NIST NIST SP 800-63B (https://pages.nist.gov/800-63-3/sp800-63b.html) where these issues are dealt with in a more detailed and comprehensive manner.Article 3.1 – The phrase ‘use of non-repeatable characters’ is subject to multiple interpretations, e.g. the same character may not be used anywhere else in the password; or just not allowed next in the key sequence.
Article 3.2 – Rather than simply mentioning “mitigation measures”, we would recommend that the RTS spells out best practice standards, as the NIST document does. More detail of the specific authentication methods, with corresponding requirements for verification standards, would support correct implementation by ASPSPs and PSPs.
Article 4.2 – Rather than simply mentioning “anti-cloning features”, we would recommend that the RTS spells out best practice standards. Also, this Article does not mention the risk of theft of the possession element. For some devices (such as passive RSA hard tokens) theft is sufficient to give a bad actor access to the possession element. For other devices (such as smartcard readers), additional compromises would be needed before the bad actor could use the element. The RTS should spell out requirements in this area.
We would also recommend that Paragraphs 2 and 3 from Article 6 be moved to this section.
Article 5.1 – The requirement for ‘a sufficiently low likelihood’ of an unauthorised party being authenticated must be quantified.
Article 5.2 – This article refers to “the devices and the software provided to the payer” with a possible interpretation that these devices and software must be provided by the ASPSP. It should be made clear whether multifunction devices such as mobile phones are permitted under this Article; and if so, what specific devices sufficiently “guarantee resistance” against unauthorised use of the elements. In particular we would question whether the use of TouchID on an Apple iPhone would comply with the RTS, given that the capture of biometric details and association with PSU’s ID is not under secure control of the ASPSP, and there are known security bypasses that have been widely publicised with all iPhones in market. If indeed TouchID does not comply with RTS requirements, use of mobile phones to read inherence elements would seem to be a future possibility rather than a current reality.
Article 6.3(a) – There is a mention but no definition of a trusted execution environment. We would recommend that the EBA adopts or references the Trusted Execution Environment and Secure Element standards as laid out by Global Platform - TEE and SE standards or Trusted Platform Module (TPM) standards ISO 11889-1. We also note that there is currently an exercise to merge the two standards into the Global Platform TEE standards, and would therefore support the adoption or reference to Global Platform standards.
Additionally, we would recommend that the EBA refers to existing guidance that has been issued by the ECB and ERPB, such as: https://www.ecb.europa.eu/paym/cons/pdf/131120/recommendationsforthesecurityofmobilepaymentsdraftpc201311en.pdf
Article 6.3(b) – ASPSPs and PSPs are wholly reliant on the manufacturers of multi-purpose devices such as mobile handsets, tablets or laptop devices to provide adequate security information. Hence PSPs can only comply with this Article on a “reasonable endeavours” basis.
Article 7.1 We are slightly confused by the wording of this paragraph and have recommended the following amendments:
The overall security of the strong customer authentication procedure and standards implemented by either ASPSP or PSP shall be tested annually, evaluated and audited by an external, independent and certified auditors, according to the latest available EBA RTS and associated approvals lists. A list of certified auditors in each Member State will be maintained and shall be made publicly available via the internet by the local Competent Authority.
Article 7.2. The review referred to in paragraph 1 shall be provided in the form of a report ensuring that the strong customer authentication procedure and standards encompasses measures to comply with this Regulation.
Article 7.3. The report referred to in paragraph 2 shall be made fully available to competent authorities annually, who will share reports with the EBA. Where non-compliance or breaches occur, Member States’ competent authorities shall be responsible for enforcement of compliance, remedy plans and where required, fines.
Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
We believe there are significant problems with this section compounded by loose wording of some provisions.Article 8.1(a) - There is a problem with the reference to “sensitive payment data” which the EBA has refused to define, but which Article 4 (32) of PSD2 defines as “data … which can be used to carry out fraud”. Some ASPSPs use items of data from the information of the payment account to authenticate the customer on the telephone. This data may include items such as recent transaction details or postcode. This interpretation would prevent ASPSPs from displaying any payments transactions data and payments account data under this exemption.
We believe the EBA must outline the standard and minimum expectations of what constitutes ‘sensitive payment data’ in order for this mandate to be operable.
In paragraph ii we would recommend the removal of ‘months’ in the RTS draft, to be replaced by a certain number of days (such as 30 days), as the number of days in each month varies and the calculation of each month’s variations causes unnecessary complexity in requirements.
Article 8.1(b) – We assume there will be flexibility for member states transposing this provision to vary the currency and/or amounts of this Article.
The second point seems to be a re-interpretation of the current requirement to do an EMV PIN validation after three consecutive contactless transactions at POS terminals over 24 hours. Changing the criterion from a simple transaction count over a 24-hour period to a cumulative value calculation over an unbounded period may require significant changes in ASPSP systems, so the EBA should present evidence that the value-based approach would result in significantly reduced fraud levels.
There are also exceptions situations that arise from the ability to perform SCA, depending on the location, activity and terminal type; we draw attention to the operation of Contactless Card payments in the UK with Transport for London, where there is no capability for SCA to be implemented.
Article 8.1(d) – In line with exemption on Contactless transactions, we would recommend the EBA to change from a Cumulative Value based SCA initiation system, to a Consecutive Transaction based SCA initiation system, so ASPSP operations are simplified.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
Yes, we are concerned. Whilst the exemptions provide a good basis for easier transactions and data services, the EBA should give specific direction that the ASPSP or PSPs maust always be able to initiate the requirement of SCA, based on clear applications of Fraud or other Behavioural Analytics that may warrant the transaction to be authenticated.In general, we would support the EBA’s inclusion of new terms which would support:
1. The ASPSPs and PSPs being able to request SCA from a customer regardless of whether the transaction falls under normal exemption rules.
2. The ASPSPs and PSPs being able to waive SCA upon their own reasoning, provided that liability is accepted by the ASPSP or PSP in the case that the transaction is later disputed by the payer.
3. Clear guidance on which actor in the payments chain will bear the liability in each of the exemptions scenarios.
Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
From the rationale section:Authentication elements include the Personalised Security Credentials (PSCs), i.e. the personalised features provided by the payment service provider to the PSU for the purposes of authentication, as well as devices and software used to generate or receive authentication codes that may either be provided by the payment service provider to the payment service user or possessed by the payment service user without being provided by the payment service provider. In that respect, PSPs should ensure the protection of the confidentiality and integrity of PSCs, authentication devices and software, in compliance with the requirements included in Chapter 3 of these RTS.
Many of our clients and other colleagues in the industry found the term “personalised security credentials” (PSC) difficult to comprehend as it is used to mean potentially any of the three SCA elements that have been bound to their payment service user. As knowledge, possession and inherence all differ in both collection, provision, interaction and fundamentally are involved with different SCA procedures, we have answered this question, highlighting where each SCA element may different in the current blanket terms given in the RTS.
We disagree with the EBA’s reasoning specifically on the point made in “or possessed by the payment service user without being provided by the payment service provider”. We reference a recent issue with AndroidPay HCE, where the PSU device relies on a manufacturer, OS and Apps that can access the PSU’s PSC issued tokenised card details.
http://www.bbc.co.uk/news/technology-37495102
Unlike the Apple iPhone ApplePay, the PSC credentials in any AndroidPay pay enabled phone with a Secure Element and Trusted Execution Environment can be accessed by many third parties, all of which may be outside of the knowledge or control of the ASPSP or PSP. Therefore, we do not believe that ASPSPs or PSPs should be held responsible for any devices or software used by the PSU unless it has been issued by them and can be directly checked by the ASPSP or PSP for security when needed. As an aside here, we would welcome future regulation on the mandated access and security for ASPSPs and PSPs to mobile device manufacturers for the use of payments – as it is a large and evolving field, we would suggest a separate review and legislation beyond PSD2.
For knowledge elements of PSCs, we understand the situations where users may choose their own Memorized Secrets (such as Online Password or Card PIN) and in this case, specific procedures for issuance, binding, storage, authentication and reset/recovery should apply. For Devices or Software, or for Biometrics, separate measures and rules should apply – therefore in our answer below and where appropriate, we have tried to support the EBA’s further separation of PSCs related to SCA elements and we have suggested procedures that may be considered as an industry security standard without prejudice to existing supplier PSCs (unless they pose a known risk to PSU security).
Article 9.1 – We believe substantial improvements to the wording of this section are required, and we provide some suggestions as follows:
(a) Data related to personalised security credentials are masked when displayed and not readable in their full extent in any format, once bound to the PSU. This includes but is not limited to ‘starring’ a password or PIN on an electronic display or keypad when being input, and obscuring/ redacting a Card PAN on a physical receipt.
(b) Personalised security credentials data as well as cryptographic material related to the encryption of the personalised security credentials are not stored in plain text and will at a minimum apply techniques such as “salting”, “nonces” and appropriate industry encryption standards whenever stored by an ASPSP or PSP.
(c) Secret cryptographic material related to the encryption of the credentials is stored in devices or processing environments that have been fully tested and certified to appropriate levels. For security standards of devices and environments, please see the industry standards as detailed in Article 4 of this RTS.
2. The process related to the management of cryptographic material used to encrypt or otherwise render unreadable the personalised security credentials shall be fully documented within the specific SCA authentication procedure used by the ASPSP or PSP, and shall be submitted for audit under the schedule specified by the Member State’s designated competent authority. The EBA or the Member State’s competent authority will publish notices if new security issues are made known, and may provide instructions or remedies related to PSCs for the protection of PSUs.
Article 10 - Whilst we agree in principle, the mention of card based transactions initiated by the payee is specific enough to refer to the current standards that apply for card-payments acceptance terminals.
For the purposes of clarity and quicker implementation we would recommend that the EBA includes reference to current standards being used in market and to advocate the use of these to ensure both payee and payer security:
1. For Physical Card Acceptance:
EMV Terminal Applications standards
EMV Terminal Type Approvals standards, in addition to:
PCI Pin Transaction Security (PTS) standards
PCI Point to Point Encryption (P2PE) standards
2. For Electronic and Remote Card Transaction Processing:
PCI Data Security Standards (applicable to all)
PCI Payment Applications Standards (including Mobile Apps)
Article 11 – It is unclear which security measures are referred to here, and the actor(s) responsible for defining, implementing and enforcing them.
Article 12 to Article 15 – These articles suffer from the same lack of clarity regarding responsibilities as in Article 11, above.
Generally, we view the current text as insufficient to be operable or measurable against correct implementation and would recommend here that the EBA follows or adapts the detailed guidelines within NIST SP 800-63B, Section 6 “Authentication Lifecycle Management”, as well as in the individual Authenticator sections detailing each element and specific standards for their secure operation.
Article 16 - Again we suggest the EBA adds more specificity as to documentation and reporting responsibilities. As there have not been any specific technical standards mentioned in this document, it would currently be impossible for a certified auditor define objective and quantitative tests to check for compliance. Indeed, it is moot as to which certification an auditor would require. We would recommend the EBA to look to the example of the PCI Security Standards Council which operates specific training and examinations to appoint Qualified Security Assessors.
Also, use of the terms “periodically” and allowing the “periodicity” to be defined by PSPs does not seem sufficient as regulation – at a minimum, we suggest that an Audit take be conducted by externally appointed auditors and be reported to Member State competent authorities and at least one social engineering and penetration test take place bi-annually.
Question 7: Do you 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, and the resultant provisions proposed in Chapter 4 of the draft RTS?
We disagree with several of the parts in Chapter 4 and we detail as follows:Article 17 - As terminals are mentioned, reference to the latest baseline security standards would help to support actual implementation.
In particular, ‘secure bilateral identification’ requires reference to specific standards depending on the payment method, for example:
1. We would recommend combined DDA with application cryptogram (CDA) for both physical Payment Cards and Terminals. The current RTS draft would allow Static Data Authentication (SDA) Cards and Terminals, which have known flaws.
2. For remote/internet PISP initiated credit transfers, we would suggest the use of Json Web Tokens with HMAC-256 to ensure a good starting level of security. The current RTS draft would allow use of Json Web Tokens with RS or ES asymmetric keys which have critical known flaws.
Article 18(a) – We believe there is a critical problem with this Article, which can be resolved by removing the words “allowing the identification of the communicating parties”. While a unique session identifier is essential to correlate messages within a dialogue, it is not possible to require the session identifier to also allow identification of the communicating parties. For example, a session established between a PSU and a PISP cannot possibly uniquely identify the PSU, because the PSU does not assert their identity until after the session is established. Moreover, the PSU does not assert their identity to the PISP, but rather to the ASPSP, potentially via a different session on an independent or segregated device per Article 2.
Article 19 – While we appreciate that the EBA has to remain technologically neutral, nevertheless we expected a strong recommendation from the EBA for the mandated adoption of APIs as a suggested Interface.
APIs are common, widely used and allow 3rd parties to not only access the services in consistent and technologically superior ways, but also allow flexible architecture that would support third parties to build services on top of the pure services provided by ASPSPs and PSPs in-line with the goal of supporting future payments innovations in the EU.
The failure to refer to specific standards may well lead to a disparate service offering from each ASPSP or PSP. This will cause undue costs to integrate for Merchants and PISPs, as well as a confusion for customer/payers when using two different payment products from different providers.
In particular we are disappointed that the EBA has not explicitly outlawed “screen-scraping” technology, which we believe is not only dated, costly and redundant when APIs are provided, but also inherently insecure.
Article 19.1(a) – Identification of PSPs to the ASPSP should rely on Qualified certificates (per Article 20) issued for this purpose.
Article 19.1(b) - As written this could be interpreted as making all services available to all PSPs. This could be easily resolved by adding the word “respectively” at the end of the clause.
Article 21.4(a) – This article suffers a similar problem to Article 18. Not all messages can contain unambiguous reference to the payment service user, because some messages are exchanged before the PSU has asserted their identity. Only the ASPSP needs to know the identity of the PSU, and the purpose of the authorisation code issued by the ASPSP is to differentiate between several requests (purportedly) from the same PSU.
Article 21.5 – AISPs and PISPs should never be in possession of Personalised Security Credentials, neither at rest nor in transit. Instead, per 19.1(c), AISPs and PISPs should rely on the authentication procedures provided by the ASPSP. The only reason for AISPs or PISPs to have access to Personalised Security Credentials is if a “screen scraping” technology is in use. As discussed in relation to Article 19, such technologies are inherently insecure precisely because of the risk of compromise of PSCs. If a PSU discovered that their PSCs had been compromised, it would be virtually impossible to track down the source of the breach.
Authentication codes should not be treated as confidential. Correctly implemented, they can only be used by the third party to which they were originally issued, for the purpose for which they were issued. An authentication code in the hands of a bad actor should be completely harmless.
Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
Article 19.3 – Simply mentioning ISO20022 is far from sufficient to provide any level of interoperability between parties. Even if the RTS were to specify the use of pain.001.x messages for payment initiation, and pain.002.x message for the response to the payment initiation, there are so many optional fields in those messages that two perfectly conformant implementations would be unlikely to be interoperable. The same applies to camt.060.x / camt.052.x or camt.053.x for account information request and response. The EBA would have to go much further, and provide Message Implementation Guides as a minimum. This would be further complicated by the need to include data elements that do not form part of the standard message, such as the Device ID, IP address etc. that are needed for fraud detection purposes. These would have to be placed in a defined Envelope within the Supplementary Data of the messages, or alternatively carried in proprietary data outside of the ISO20022 message structure. Either approach would require significant effort to define standards.A further complication is that ISO20022 is defined as XML, where modern APIs overwhelmingly favour JSON. This would require further work to agree a JSON representation of the ISO20022 XML document structures. In particular, Json Web Tokens is a technology that is perfectly suited to this domain, but would be very difficult to use within ISO20022 messages.
A third complication is that several of the messages needed to implement the business processes required for PSD2 have no representation in the current ISO20022 message set. For example, a request by an AISP for authorisation to request account information on behalf of a PSU has no corresponding ISO20022 message.
Unless a very significant effort is put into enhancing and extending the ISO20022 message standards, it will not be possible to use them for this purpose, and even where they are pressed into service, will not provide a significant level of interoperability.
Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?
We agree.It would also be tremendously helpful if the EBA made the list of qualified trust service providers in each Member State territory more readily available and web searchable by Member States rather than having to Google and search through web pages, to read through a PDF or XML..
http://certifiedsignature.eu/2015/07/20/eu-trusted-lists-of-certification-service-providers-tsl-ts-119-612/
Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
We agree.Allowing AISPs to request account data more frequently than twice daily would risk overloading ASPSP systems. If a particular application requires more real-time information about changes to the PSU’s account information it seems reasonable for the AISP to negotiate special access to the information outside the scope of PSD2, possibly using a more efficient “push” mechanism rather than a polling “pull” mechanism.