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:
EMV® 3-D Secure (hereafter referred as 3-D Secure), EMV® Payment Tokenisation, and EMV® Secure Remote Commerce (hereafter referred as SRC)
FIDO Client-to-Authenticator Protocol (CTAP)
W3C Web Authentication, Payment Request API, and Payment Apps
Status of This Document
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
This is a draft document for discussion within the Web Payment Security Interest Group.
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:
The use of technologies in scope in other contexts (e.g., FIDO authentication in open banking flows, or Payment Request API with open banking flows).
Payment requests initiated by a native mobile app
Non-card based / alternative payments
Peer-to-peer payments, business-to-business payments or other payment relationships
Alleviate the burdens associated with passwords (creation, memorization, data theft, etc.).
Streamline user experiences (although that does not necessarily imply "no friction" user experiences). Examples include:
Reduce the friction of user authentication processes in different phases of checkout, including access to a list of cards stored in the cloud or authentication during a transaction.
Reduce typing and other friction associated with providing addresses, contact information, and payment credentials as part of completing checkout. In other words, we seek to streamline the checkout experience by reducing the number of user interactions and minimizing other friction.
Reduce confusion that can result from redirecting the user away from a merchant site to a payment site.
Create a familiar user experience which allows a user to act with confidence, and reduce confusion that can arise from very different checkout experiences across the Web.
Improve lifecycle management of credentials (e.g., no disruption when cards are updated or compromised, or authenticator management)
1.2 Enhance Security, Reduce Fraud, and Increase Approval Rates
We seek to:
Prevent account takeover, phishing, all forms of password theft, and replay attacks. In general, we seek to reduce reliance on passwords.
Ensure that only authorized parties can use a payment card.
Improve the ability of account issuers to assess transaction risk to increase transaction approval rates and reduce fraud and chargebacks.
1.3 Reduce Integration Effort and Cost
We seek to:
Lower the cost for merchants (or their payment service providers) to create a streamlined and secure checkout experience. All parties can lower development costs by leveraging standard and interoperable APIs.
Provide a means to reduce some PCI SSC non-compliance in certain implementations
1.4 Protect User Privacy
We seek to:
Limit sharing user information to the minimum necessary to complete a transaction and reduce fraud, and help ensure that only relevant parties have access to that data.
Protect biometric data.
Prevent tracking users across sites while recognizing the role of risk assessment in payments.
1.5 Meet Regulatory Requirements
We seek to:
Make it easier to meet strong customer authentication regulatory requirements (e.g., under Payment Service Directive 2 (PSD2) in Europe, as well as in India, Singapore, and other jurisdictions).
Principal Capabilities of Technologies in Scope
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:
FIDO2 and 3-D Secure both relate to multi-factor authentication.
Payment Request API and SRC both involve improving the user experience of during checkout. SRC focuses on PAN-based payments; Payment Request API is more general but PAN-based payments fall within its purview. SRC may be implemented in a variety of ways, and the W3C Web Payments Working Group is discussing "how to implement SRC using Payment Request API."
EMVCo technologies are not limited to Web-based payments.
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.
2.1 EMV® Payment Tokenisation
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:
If a physical card is replaced, or the PAN data is lost, stolen, or otherwise compromised, an ecommerce Merchant may still use the stored Payment Token that will be associated with the new replacement card and its associated account data including a new PAN for future transactions through a lifecycle management process.
A merchant may be able to reduce the scope of their cardholder data environment as it relates to PCI SSC compliance in partnership with a payment service provider by replacing PAN with Payment Tokens or using Token Reference IDs. For the latter, the payment service provider stores the Payment Token while the merchant stores the Token Reference ID.
2.2 EMV® 3-D Secure
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:
First, data about the user and its environment (e.g., mobile app or browser) is gathered and sent to the issuing bank via payment networks, as input to risk analysis. The data may also include FIDO and identity data. In many cases, the resulting checkout experience will minimize UX friction. If the issuing bank has confidence that the user is authorized to use the card for this transaction, the issuing bank informs the merchant (or their payment service provider) and no additional user interaction is required.
In some cases (e.g., unusual purchases, high value purchases, to meet regulatory requirements, etc.), the issuing bank may invoke an optional second step ("the step-up") and request additional (multifactor) authentication of the user from within the context of the merchant site.
Merchants that leverage EMV® 3-D Secure for cardholder authentication can benefit from increased security and increased approval rates.
2.3 EMV® Secure Remote Commerce (SRC)
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:
Increase consistency across the remote environment by enabling solutions that can deliver interoperability and convenience;
Reduce ecosystem complexity by enabling consistent and simplified integration processes and interfaces among stakeholders;
Enhance the security of remote commerce websites and applications through the introduction of dynamic data as well as the secure transmission of payment and checkout information;
Provide integration compatibility for other EMV Specifications, including EMV® 3-D Secure and EMV® Payment Tokenisation;
Reduce repetitive manual PAN entry by enabling the consistent identification of the consumer, potentially lowering shopping cart abandonment;
Facilitate consumer recognition, through a payment icon, which can be used on a royalty-free basis;
Facilitate industry innovation by providing a baseline for remote commerce across new devices, remote-checkout environments and technologies.
From a user experience perspective:
Users register their cards with SRC systems. The cards are associated with a user identity so that they may be later retrieved from the same environment or from different environments (e.g., different wallets or browsers).
During a transaction, user identity may be verified to access the list of cards stored with SRC systems – users are shown metadata (e.g., last 4 digits of the funding PAN, card artwork) to facilitate selection of eligible cards. Upon selection of a card, users may need to authenticate for the transaction, after which relevant payment credentials (e.g., a Payment Token) are retrieved from the SRC system and returned to the party that initiated the payment request (the "SRC Initiator").
FIDO2 refers to the combination of two technologies: Web Authentication and Client-to-Authenticator Protocol (CTAP).
Web Authentication enables FIDO authentication in the browser. Instead of authenticating a user with a password, a Web site (what FIDO calls the Relying Party) requests that the browser prompt the user to use FIDO authentication. If the user has not yet enrolled on this Web site, the user first registers a FIDO authenticator. When the user next visits the site, the user is authenticated by demonstrating that they are still in control of the authenticator.
Authenticators communicate with the platform on which the browser runs by way of the Client-to-Authenticator Protocol (CTAP). Authenticators may be built into a device (e.g., a biometric reader built into a laptop or phone) or communicate with the device over a variety of connection types (e.g., USB, NFC, or Bluetooth).
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.
2.4.1 FIDO Registration
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.
2.4.2 FIDO Authentication
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:
Verification of user presence whereby the user makes a gesture with the authenticator (for example, touches a security key or taps an NFC-enabled FIDO token on a FIDO-enabled device).
Verification, locally by the authenticator, of a PIN code or of biometric data submitted by the user. This type of local user verification constitutes a strong authentication factor (knowledge or inherence).
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.
2.5 Payment Request API and Payment Apps
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 user establishes an identity directly with a payment app that supports SRC. This might be done using Web Authentication, name and password, or other mechanisms.
A payment app that supports SRC may seek identity information elsewhere in the environment (e.g., via the W3C Credential Management API).
Merchants may provide hints.
FIDO2 supports single touch multifactor authentication
WebauthN provides access to FIDO authenticators from a web page
Reduce the friction of user authentication process to authenticate for the transaction
3-D Secure supports frictionless user authentication for the transaction via information about the consumer and the consumer's environment (including the device) and (optionally) from FIDO authentication
FIDO2 supports single touch multifactor authentication
WebauthN provides access to FIDO authenticator from a web page
Reduce typing and other friction associated with providing addresses, contact information, and payment credentials as part of completing checkout
Payment Request API supports the streamlined reuse of data during checkout
SRC improves the user experience by providing quick access from any device to payment credentials, addresses and contact information stored in the cloud
Reduce confusion that can result from redirecting the user away from a merchant site to a payment site
Payment Request API, Payment Handler API, and 3-D Secure implementations keep the user close to the merchant site
Reduce confusion that can arise from very different checkout experiences across the Web
Payment Request API enables a consistent, browser-based user experience across sites
Improve lifecycle management of credentials
Payment tokens improve lifecycle management – this includes automatic token updates in the case of card changes, and removes the need to update a card at each merchant site in case of account data compromise
3.2 Enhance Security, Reduce Fraud, and Increase Approval Rates
How Technologies and standards help
Prevent account takeover and security attacks
FIDO2 cryptographic login credentials are unique across every website, never leave the user’s device, and are never stored on a server
SRC can enable access to tokens and dynamic data for consumer-initiated transactions
Reduce account data compromise and PCI SSC non-compliance
Payment tokens replace the card number (PAN) in the payment ecosystem.
Token Domain Restriction Controls can limit the use of a payment token to its intended use or channel
Ensure that only authorized parties can use a card
User verification may be required to add a card or access a list of SRC cards
Improve the ability of account issuers to assess transaction risk
3.3 Reduce Integration Effort and Cost
How Technologies and standards help
Lower front-end integration costs
A standard API for front-end development is expected to reduce integration cost
Remove or reduce the scope of PCI SSC compliance
Payment tokens replace the card number (PAN) in the payment ecosystem and are not subject to PCI SSC Cardholder Data Environment requirements.
3.4 Protect User Privacy
How Technologies and standards help
Protect biometric data
FIDO2 biometric data, when used, never leaves the user’s device.
Prevent tracking users across sites
Because FIDO cryptographic keys are unique for each Web site, so the protocol limits the ability to track users across sites.
3.5 Meet Regulatory Requirements
How Technologies and standards help
Make it easier to meet strong customer authentication regulatory requirements
3-D Secure can enable strong customer authentication - Issuing banks may authenticate their consumers with their choice of 2-factor solutions compliant with the local regulation.
FIDO provides a 2-factor authentication solution compliant with regulations such as PSD2 in Europe. The first factor is inherence (biometrics) or knowledge (e.g., a PIN). The second factor is the possession of the FIDO authenticator.
Make it easier to meet privacy regulatory requirements
With FIDO, the fact that the user verification data (PIN code or biometric data) is stored in the authenticator, verified locally and never transmitted to or shared with servers is a strong asset of the FIDO approach and is in line with privacy requirements and regulations.
Merchants can call 3-D Secure without using SRC or Payment Request or FIDO. In this case, the merchant (or their payment service provider) embeds code in a Web page that routes information about the user's browser through a variety of servers to the user's issuing bank, which conducts risk analysis. The protocol returns an authentication value or embeds a step-up user experience in the merchant page for more information. Other parties (e.g., token service providers) might also initiate 3-D Secure flows.
Merchants can call SRC without using Payment Request or FIDO. Like the 3-D Secure flow, this involves the merchant (or PSP) using code in the merchant site that communicates with a variety of servers.
Merchants can use Payment Request API for basic card payments, essentially replacing a Web form with an API for the same data.
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:
SRC First. SRC is the "anchor" protocol. We describe an SRC flow and then other technologies in relation to it.
SRC through Payment Request. Although SRC may be implemented in a variety of ways, we focus on how to leverage Payment Request API. Please note that Payment Request API transfers some functionality historically embedded in a merchant site into the user's environment through a combination of browser capability and payment app capability. In other words, it moves some SRC, 3-D Secure, and Payment Tokenisation functionality from "the merchant side" to "the user side."
FIDO Variations. FIDO authentication may take place at a variety of times during these flows, and for different reasons, including:
By merchants. Merchants may wish to authenticate the user (e.g., the user logs into their account with the merchant because of a loyalty program)
By payment app distributors
By SRC Systems
By issuing banks (e.g., as input to 3-D Secure)
By digital identity providers (in federated digital identity scenarios).
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.
4.1 A Word on Terminology
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:
The SRC "Digital Payment Application" is the overall checkout experience on the merchant site.
The "SRC Initiator (SRC-I)" is the part of the merchant Web site that calls Payment Request. SRC refers to the "SRC trigger"; Web payments refers to this as the "buy button" — the button that, when pressed, calls Payment Request API 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 SRC "Digital Card Facilitator" is a Payment App that supports interactions with SRC, 3-D Secure, and Payment Tokenisation services. We refer to these services collectively as the "SRC System". A Payment App may support interactions with more than one SRC System.
Most of the time, we refer to "the browser" as the entity that implements Payment Request API. However, since non-browsers may also implement Payment Request API, a more general term we sometimes use is "the mediator."
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:
Merchants may wish to authenticate users, then share authentication results with other parties (e.g., issuing banks as part of 3-D Secure flows). Merchants may wish to share boolean information ("authentication succeeded"), a few parameters, or even the entire authentication assertion.
An issuing bank may wish to create FIDO credentials that may be used by itself and another origin (e.g., a merchant or payment app). This would allow a merchant to authenticate a user during a transaction (rather than redirecting the user to an issuing bank, or embedding issuing bank code in a page), then forward the authentication assertion to the issuing bank for verification. For more information, see discussion of cross-domain credential use.
SRC systems may wish to authenticate users (e.g., for access to card metadata). However, in the use case where a user has multiple cards enrolled in multiple SRC systems, there is a desire to reduce the total number of authentications as part of showing the user a complete list of enrolled cards.
A payment app may display user interface from an SRC System to authenticate the user. The SRC system may wish to pass the authentication assertion as input to a 3-D Secure subsystem.
Potential Technology or User Experience Improvements
This section identifies some payment experience improvements for consideration in current or future specifications (or their implementations).
How can FIDO authentication be used as part of 3-D Secure flows? EMVCo and FIDO are discussing data requirements. The Web Payments Working Group is also discussing a Secure Payment Confirmation proposal for how to streamline Web Authentication for 3-D Secure from within Payment Request API.
Web Authentication 1.0 does not allow authentication from an iframe from different origin than the "top origin." The Web Authentication Working Group is discussing enhancements to Web Authentication Level 2 to support this use case. This may be necessary for the flow where the SRC system (from origin A) authenticates the user from within a payment app (from origin B).
FIDO credentials are created for a Relying Party identified by a URL. We may want to consider scenarios where a Relying Party wants to authorize another entity to access the FIDO credentials on their behalf and retrieve the FIDO attestation data after successful user verification. In particular, for an SRC payment method (through Payment Request), we may want to avoid the creation of multiple FIDO credentials for the same consumer, and the need to authenticate the consumer several times in the same checkout session (using FIDO or 3-D Secure) - e.g., authenticate to the merchant and/or to the browser and/or to the payment app. This would require an enhancement to the Web Authentication Level 1 specification.
The browser (mediator) could retrieve registered Payment Instruments from each payment app and display them in a consolidated list, to avoid the need for a "wallet selector" and provide a consistent user experience. This has not yet been implemented by browsers but could be useful when implementing an SRC payment method. When users want to add a card (payment instrument), they could enter the card information on the browser payment sheet and the browser could redirect to the appropriate payment app.
Device identity plays an important role today in risk mitigation (e.g., 3-D Secure) but raises privacy concerns. Especially as browsers begin to reduce the ability to fingerprint the device, what technologies (e.g., trust tokens, entity attestation tokens, token binding) can be used to meet risk mitigation requirements?
A.1 Can you do 3-D Secure through Payment Request API without SRC?
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.
A.2 How do these technologies relate to PCI SSC Compliance?
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.
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.
A.3 How do these technologies relate to PSD2?
A.3.1 Payment Request
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.
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:
Dynamic-linking, because the transaction text is cryptographically linked to the assertion
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.
A.5 How does FIDO relate to OpenID Connect and OAuth 2.0?
FIDO is used for authentication. OAuth 2 enables the delegation of authentication to other parties.
In more detail:
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to a service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the Authorization Server, or by allowing the third-party application to obtain access on its own behalf.
In a common pattern for OAuth, the resource owner authenticates to the Authorization Server before the Authorization Server issues an access token to the client application that is used on API calls to the Resource Server. The Authorization Server can choose to use any authentication mechanism, including FIDO.
OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It provides a secure verifiable, answer to the question: "What is the identity of the person currently using the browser or native app that is connected to me?" OpenID Connect lets developers authenticate their users across websites and apps in a federated manner without having to own and manage credentials. The OAuth 2.0 authorization framework provides for authentication of the end user, including through the use of FIDO. FIDO metadata about authenticators helps to characterize the security levels of authentication in detail, which is useful in OpenID Connect and other protocols.
A.6 Can FIDO authentication be limited to specific individuals?
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.