Response to discussion on RTS on strong customer authentication and secure communication under PSD2

Go back

2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?

In terms of possession elements, it is difficult for any
possession element or even behavior-based characteristic to naturally
fulfill strict security requirements. Indeed, as shown by various
high-profile attacks on biometrics, most of these elements can be
attacked successfully by a determined attacker. The most important
single characteristic is for any secret key material to be adequately
defended from malicious access and to be used appropriately defending
access. While embedding such secret key material in hardware tokens
is usually a step forward, high security access is also possible through
software. Note that poor security hardware tokens that are difficult
to update may pose their own problems (including signatures created using
broken hash functions). Thus, we encourage open innovation via
standards for possession elements both in hardware and software.

3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?

Privacy is a critical consideration when using
behavior-based characteristics. In particular, behavior-based
characteristics should be determined locally and client-side, and user
appropriate controls and awareness should be satisfied. Failure to
exercise this precaution could lead to violations of data protection
regulations.

5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?

The EBA should favor standards for strong authentication
that may be implemented on royalty-free terms, for the entirety of the
authentication stack. In addition, solutions should allow for multiple
types of possession elements as different applications will demand
different levels of assurance.

14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?

Historically, risks are most acute at the weakest link in
the transaction, particularly in terms of user control over their
credentials. One of today's most important vectors is phishing since
ordinary users may have trouble determining faked websites. In
collaboration with the FIDO Alliance, W3C is working on standards to
help address this problem. Cloud computing has given rise to another
issue that must be considered: long-term storage of credentials. The
FIDO approach to be standardized at W3C will reduce the risk of
attacks on backend credential databases, as no symmetric
authentication credentials (such as passwords) are stored on the
server.

17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?

W3C is currently developing (or expects to develop) open
standards in several relevant areas:

* Web cryptography, to enable developers to implement secure
application protocols on the level of Web applications, including
message confidentiality and authentication services, by exposing
trusted cryptographic primitives from the browser.

* Web application security, to ensure that Web applications are
delivered as intended, free from spoofing, injection, and
eavesdropping.

* Strong authentication, to reduce the use of shared secrets,
(i.e., passwords) as authentication credentials, facilitating instead
multi-factor authentication support as well as hardware-based key
storage.

* Hardware security, to provide Web Applications with access to secure
services enabled by hardware modules.

* Payment initiation, to make payments easier and more secure on the
Web, by streamlining checkout and making it easier to bring new and
secure payment methods to ECommerce.

18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?

The discussion paper refers to EBA requirements for Common and open"
standards and poses a challenge in provision 63 to 'Define what makes
a standard "common" and "open"'. We would like to bring to the EBA's
attention the Open Stand [1] statement of principles for open
standards development published in 2012 by W3C, the IETF, the Internet
Architecture Board, the Internet Society, and the IEEE. We hope that
these principles can inform the EBA discussion about open standards.

In W3C's experience, global participation in transparent processes
--characterized in the Open Stand principles-- is critical to ensuring
that regional needs are met, and that technology achieves global
adoption. The discussion paper includes this statement:

"Article 98 states that EBA shall develop draft regulatory
technical standards specifying "the requirements for common and
secure open standards of communication." However, PSD2 does not
mandate EBA to develop or maintain these open and common standards
of communication themselves or to appoint a central entity in
charge of developing or maintaining these standards."

Successful open standards reflect the needs and input of
diverse global stakeholders. W3C recommends that the EBA adopt relevant existing open standards
from W3C, IETF and similar organizations, or, join the efforts of
those organizations to develop new global standards in support of
PSD2. We believe that in collaboration with the EBA, we can help
achieve the goal cited in the discussion paper to "ensure the
interoperability of different technological communication solutions"
where those solutions involve the Web."

19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.

Given the volume of cross-border transactions (as well as
the anticipated growth in that area), any solution should not be
bound only to national or even European regulations, but should be
ultimately compatible with them. Thus, E-IDAS will help, but is not
sufficient. To help ensure compatibility of global technology
with E-IDAS and other regional requirements, we recommend direct
participation in the global standards processes.

Name of organisation

World Wide Web Consortium (W3C)

Please select which category best describes you and/or your organisation.

[Other"]"

If you selected ‘Other’, please provide details

The World Wide Web Consortium (W3C) is an international standards body for Web technologies, founded in 1994 by Tim Berners-Lee, Web inventor. Both authors of this response are members of the W3C staff but we are replying as individuals rather than on behalf of W3C. We appreciate the opportunity to provide some initial thoughts on the potential implications of the revised Payment Services Directive (PSD2) on Web technology. We hope this response will foster a more comprehensive and ongoing collaboration between our organizations. We will reach out separately to discuss that collaboration. Signed: Harry Halpin, W3C Team Contact <hhalpin@w3.org> and Ian Jacobs, Web Payments Activity Lead <ij@w3.org>.

Please select which category best describes you and/or your organisation.

[ "]"