Copyright © 2020 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
EMVCo, FIDO Alliance and W3C have all taken steps to improve online payment security through the development of interoperable technical specifications. In this document we describe the core capabilities provided by some of their specifications, what problems can be solved by combining them, and potential changes to improve how they work together. The technologies in scope for this document are:
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This is a draft document for discussion within the Web Payment Security Interest Group.
This document was published by the Web Payment Security Interest Group as an Interest Group Note.
GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to public-securepay@w3.org (archives).
Publication as an Interest Group Note does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The disclosure obligations of the Participants of this group are described in the charter.
This document is governed by the 15 September 2020 W3C Process Document.
This document describes how the technologies in scope may be used together to address a specific use case: secure card payment during an e-commerce guest checkout on the Web (i.e., browser-based scenarios). Our focus is on the guest checkout use case where the user provides information to a merchant, rather than situation where the merchant reuses information previously provided by the user ("card-on-file"). We make no assumptions about the nature of the user's device (mobile phone, laptop, etc.). The goals for this use case are listed below.
There are inherent tensions among some of the goals we list below. We wish to reduce fraud, but not at the expense of user privacy or regulatory requirements. We want to improve the user experience, but not at the expense of security and cost. For editorial reasons, we do not repeat these inherent tensions in the descriptions below.
Please also note that we are explicitly not addressing in this document:
See below for more information on how the technologies in scope can help achieve our goals.
We seek to:
We seek to:
We seek to:
We seek to:
We seek to:
In this section we summarize the principal capabilities of the technologies in scope. In some cases, the specifications from different organizations may describe similar capabilities, at least at a high level. For example:
The descriptions below are simplified and tailored to the particular guest checkout use case that is the focus of this piece. For more complete descriptions of these technologies, please see corresponding materials from EMVCo, FIDO, and W3C.
When making an online purchase and selecting a credit, debit or prepaid card for payment, the cardholder shares their payment data with a merchant. The cardholder may further agree for that merchant to store those payment credentials as a "card-on-file" to facilitate future payments. The cardholder data that is traditionally shared or stored as card-on-file payment data has traditionally included the number embossed/printed on the card (the Primary Account Number, or PAN), the card expiry date, cardholder name, alongside the billing address and shipping address. If the PAN and Expiry Date data being stored or processed is exposed to a malicious actor, the stolen account data can be used to perform unauthorized and fraudulent transactions. EMV® Payment Tokenisation defines an ecosystem where surrogate payment data ("Payment Tokens") can be used to replace PANs in a variety of use cases, including card-on-file. Merchants (or their payment service providers) can assume the role of a Token Requestor to request Payment Tokens that will replace PANs being stored in their card-on-file datastore. By substituting Payment Tokens for PANs, Merchants and their payment service providers can remove PAN from their cardholder data environment and may reduce the risk of subsequent fraud should there be an account data compromise event.
Payment Tokens offer security benefits as compared to PANs. The Payment Token is restricted in its use by the enforcement of related transactional "Token Domain Restriction Controls" (domain restriction controls) during transaction processing. These domain restriction controls reduce opportunities for unauthorized use or misuse, for example by limiting use of a Payment Token to a specific channel such as e-commerce, for a specific transaction through use of token cryptograms, or to a specific Merchant. Existing security related mechanisms such as use of a card verification numbers can still be used in conjunction with Payment Tokens and domain restriction controls.
Payment Tokens offer additional benefits as well:
EMV® 3-D Secure enables issuing banks to assess an eCommerce payment transaction and authenticate the cardholder if required. The protocol consists of up to two phases:
Merchants that leverage EMV® 3-D Secure for cardholder authentication can benefit from increased security and increased approval rates.
Secure Remote Commerce (SRC) outlines the overall architecture, provides requirements, contains APIs and a Java Script based SDK and user interface guidelines - with an objective to deliver the following benefits:
From a user experience perspective:
FIDO2 refers to the combination of two technologies: Web Authentication and Client-to-Authenticator Protocol (CTAP).
Many smartphones and laptops ship from the factory with FIDO authenticators already built in, making FIDO authentication a natural, low-friction and scalable approach for consumer authentication (e.g., to a list of cards or to authenticate during a transaction).
FIDO protocols involve two steps: registration and authentication.
The FIDO standards are based on public key cryptography. During FIDO registration, the user creates a PIN code or registers biometric data and the authenticator then generates a public/private key pair specific to the Relying Party. The key pair is not known to any other party. Registration involves sending the public key in a protected way to the Relying Party server.
FIDO Authentication consists of two steps: local user verification followed by on-line authentication. The local user verification step is a prerequisite for the on-line authentication step.
The local user verification step can be either:
For the on-line authentication step, the Relying Party server sends a message to the authenticator which is then cryptographically signed with the private key stored in the authenticator that was used at registration. The signed response is returned to the server where it is verified.
The on-line authentication step thus proves the possession of the FIDO authenticator and constitutes a second factor of authentication.
Payment Request API defines a new browser capability that makes it easier and faster (than Web forms) for merchants to request payment and for users to complete a checkout by returning stored information (e.g., contact information, addresses, and payment credentials). The merchant declares supported payment methods through the API. When the user clicks a "buy button," this causes the browser to determine which payment apps the user has (or could install on the fly) for those payment methods. Payment apps come in three flavors: native mobile apps, Web sites, or the browser itself (e.g., many browsers store basic card information). If only one payment app matches what the merchant accepts, the browser can launch it automatically. If multiple payment apps match, the browser prompts the user to choose one. The user then interacts with a payment app to complete the transaction. The browser returns data from the payment app to the merchant (or their payment service provider, whoever called the API).
The Payment Handler API defines how Web-based payment apps register the payment methods they support with the browser, how the browser launches the payment app, and how the payment app returns data upon completion of user interaction. How a payment app stores information, authenticates the user, and communicates with payment services (e.g., token service providers, issuing banks, etc.) lies outside the scope of the Payment Handler API.
Payment Request API and payment apps can be used with a variety of payment methods. The following diagram illustrates an example of user journey that these APIs enable, with optional selection of payment app.
The tables below summarize how the technologies in scope can help achieve the goals.
Goals | How Technologies and standards help |
---|---|
Alleviate the burdens associated with passwords |
|
Reduce the friction of user authentication processes to access list of cards |
|
Reduce the friction of user authentication process to authenticate for the transaction |
|
Reduce typing and other friction associated with providing addresses, contact information, and payment credentials as part of completing checkout |
|
Reduce confusion that can result from redirecting the user away from a merchant site to a payment site |
|
Reduce confusion that can arise from very different checkout experiences across the Web |
|
Improve lifecycle management of credentials |
|
Goals | How Technologies and standards help |
---|---|
Prevent account takeover and security attacks |
|
Reduce account data compromise and PCI SSC non-compliance |
|
Ensure that only authorized parties can use a card |
|
Improve the ability of account issuers to assess transaction risk |
|
Goals | How Technologies and standards help |
---|---|
Lower front-end integration costs |
|
Remove or reduce the scope of PCI SSC compliance |
|
Goals | How Technologies and standards help |
---|---|
Protect biometric data |
|
Prevent tracking users across sites |
|
Goals | How Technologies and standards help |
---|---|
Make it easier to meet strong customer authentication regulatory requirements |
|
Make it easier to meet privacy regulatory requirements |
|
It is possible to use the capabilities of the technologies in scope independently. For example:
In the flows we have considered we look instead at how all of these technologies may be used together. To do so, we have adopted this approach:
Although FIDO reduces the friction of any single authentication (compared to other authentication approaches), together EMVCo, FIDO, and W3C are working to reduce the total number of authentications required to complete a transaction, through combinations of delegation and caching.
One challenge when considering how specifications relate is how to align their respective terms and definitions. However, a few brief notes here may help explain how components combine for our use case:
show()
. The SRC-I role may be fulfilled by the merchant or their payment service provider (e.g., via an iframe). Because Payment Request moves some functionality to the user side, it is possible that some SRC-I functionality is carried out by the browser in its implementation of Payment Request.The Web Payments Working Group is developing Proposed Architecture for SRC through Payment Request API and corresponding flow diagrams. Please note that this is work-in-progress.
FIDO authentication could enhance the basic flow in a variety of ways. We continue to discuss how to minimize the total number of user gestures required in different use cases. For example:
This section identifies some payment experience improvements for consideration in current or future specifications (or their implementations).
In theory one should be able to describe how to initiate 3-D Secure processes through Payment Request independent of SRC.
The Web Payments Working Group is discussing a proposal that involves a 3-D Secure user experience enhanced by Web Authentication, outside the context of SRC.
From a Payment Request perspective, if the merchant accepts PAN-based card payments, then the Payment Request API is in scope for PCI DSS. W3C and PCI SSC are in conversation to understand any potential impact of Payment Request API on PCI DSS compliance. For relevant PCI DSS good practice (e.g., if using Payment Request API from within an iframe), see PCI SSC FAQ 1292.
For information about Payment Tokenisation and PCI DSS, see How does PCI DSS apply to EMVCo Payment Tokens?.
EMVCo is working closely with PCI SSC to maintain the Security Evaluation for 3-D Secure solutions, via the PCI 3DS defined and operational process.
The Web Payments Working Group has discussed with various open banking initiatives (e.g., STET, Open Banking UK, Berlin Group) how PSD2 requirements could map to the Payment Request ecosystem. Of particular interest are variations in when strong customer authentication can take place during the flows. See slides from Herve Robache for some discussion about this topic.
See the FIDO white paper How FIDO Standards Meet PSD2’s Regulatory Technical Standards Requirements On Strong Customer Authentication.
In March 2020 the Web Payments Working Group decided to remove the extension for transaction confirmation from Web Authentication Level 2 due to lack of browser support. Discussions are ongoing for how to address the PSD2 (RTS, article 5) dynamic linking use case. Transaction confirmation had involved the Relying Party server sending a transaction text to the client to be displayed to the user and cryptographically linked to the assertion if the user approved the transaction. The goal of the use case is to provide non-repuditation and "dynamic-linking" as follows:
The Web Payments Working Group is also discussing dynamic-linking in the context of a Secure Payment Confirmation proposal.
EMV® 3-D Secure supports all EU SCA factors, including inherence, through a range of authentication methods, such as the facilitation of biometrics (e.g., biological and behavioral). These factors can be delivered in or out-of-band, or using FIDO Authentication Standards. EMV 3-D Secure v2.2.0 was specifically designed to support an improved user experience for biometrics.
An EBA Opinion published on 16 October 2019 references the RTS and states (at point 15) that the "[EMV] 3DS v2.2. communication protocol… should enable the application of the full range of SCA exemptions specified in the RTS and the out-of-scope of SCA transactions, such as payee-initiated transactions." For more information, see EMV® 3-D Secure and the PSD2 Requirements for Strong Customer Authentication.
See the FIDO white paper FIDO Authentication and the General Data Protection Regulation.
FIDO is used for authentication. OAuth 2 enables the delegation of authentication to other parties.
In more detail:
For more information, see the FIDO white paper Enterprise Adoption Best Practices – Integrating FIDO & Federation Protocols.
At times it may be useful for multiple people (e.g., within a family) to be able to use the same authenticator (e.g., built into a phone). However, at other times, it may be useful to limit authentication to one or more individuals (e.g., allow the parents to make online purchases, but not the kids). FIDO2 authenticators can perform multi-factor authentication based on a fingerprint, PIN, etc. (assuming they have been designed to do so). However, there are no inherent protections against people sharing PINs or registering other people's fingerprints. Identity registration processes can be layered on top of FIDO2 authentication, with attendant complexity.