How EMVCo, FIDO, and W3C Technologies Relate

We seek to:

• Alleviate the burdens associated with passwords (creation, memorization, data theft, etc.).
• Streamline user experiences. Examples include:
  • Reduce the friction of user authentication processes in different phases of checkout, including access to a list of stored cards (cards on file) 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 and consistent 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, authentication credential management)

We seek to:

• Prevent account takeover, phishing, all forms of password theft, and replay attacks. In general, we seek to reduce reliance on passwords.
• Reduce account data compromise and help ensure PCI SSC compliance.
• 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.

We seek to:

• Lower the cost for merchants (or their payment service providers) to create a user-friendly, streamlined and secure checkout experience. All parties can lower development costs by leveraging standard and interoperable APIs while maintaining interoperability.
• Provide a means to reduce some PCI SSC non-compliance in certain implementations

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.

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).
• Make it easier to meet privacy regulatory requirements (e.g. GDPR in Europe, California Consumer Privacy Act (CCPA), and Australia).

When making an online purchase and selecting a 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 Primary Account Number (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 not only replaces the PAN but is restricted in its use by the enforcement of related transactional "Token Domain Restriction Controls" (domain restriction controls) during token 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.

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:

1. 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 this is a legitimate user for this card and transaction, the issuing bank informs the merchant (or their payment service provider) and no additional user interaction is required.
2. 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 (single- or multi-factor) 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.

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 service provider (referred to by FIDO as the Relying Party) requests that the browser prompt the user to use FIDO authentication. If the user has not yet registered for this service on a 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. Depending on the authenticator type and/or implementation, the user can demonstrate possession through a gesture, PIN or biometric.
• Authenticators communicate with the platform on which the browser runs either through platform-specific APIs or through the Client-to-Authenticator Protocol (CTAP) standard. 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 gain access to a list of cards or to authenticate during a transaction).

FIDO protocols involve two steps: registration and authentication.

Payment Request API defines a 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. 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.

Secure Payment Confirmation is a Web API to support streamlined authentication during a payment transaction. In essence, SPC enhances Web Authentication for payments. It does so through three important capabilities:

• Dynamic linking. With SPC, at transaction time the browser displays a "transaction confirmation dialog" with the transaction amount, currency, beneficiary, and account used to make the payment. The user then authenticates (Web Authentication) and the authenticator signs the displayed transaction data. The resulting FIDO assertion provides cryptographic evidence that the user consented to the transaction ("sign what you see") and is designed to fulfill dynamic linking requirements of PSD2 and similar regulations.
• Shareable credentials. One goal of SPC is to reduce authentication friction during checkout, and one aspect of that is to maximize the number of authentications that the user can perform for a given registration. That is, with consent from the Relying Party, ideally the user could "register once" and authenticate on any merchant origin (and via payment service provider), not just the merchant origin where the user first registered. To that end, an important feature of Secure Payment Confirmation is that the merchant (or another entity) may initiate the authentication ceremony on the Relying Party’s behalf, whether the Relying Party is an issuing bank, payment service provider, or other entity. The Relying Party must opt-in to allowing this behavior during credential creation.
• Registration in a third-party iframe. Web Authentication does not allow registration in a cross-origin iframe. However, in payments flows it is common for banks and other Relying Parties to want to register the user without a disruptive redirection to the bank's Web site. To that end, unlike Web Authentication, SPC supports cross-origin registration from an iframe in a third-party context. For instance, this registration might take place following some other identity and verification (ID&V) flow.

Note: For practical reasons Secure Payment Confirmation was initially specified as a payment method. Thus, in its initial form, SPC is closely tied to Payment Request API.

In a 3-D Secure flow:

1. A consumer uses a payment card to make an online purchase on a device.
2. The merchant sends data about the transaction, account, and device to the card issuer.
3. The issuer (or the "Access Control Server - ACS" acting on their behalf) reviews the data and performs a Risk Assessment. For transactions considered low risk, the issuer may decide to complete the transaction as frictionless which essentially means that the data collected for this transaction was sufficient to let the transaction proceed without any explicit user credential verification. For some transactions (e.g., higher risk, or due to regulatory requirements) 3-D Secure provides an additional layer of security by validating that the individual making the purchase is the legitimate cardholder. In these cases, the issuer can choose to prompt the consumer to authenticate themselves using a one-time-passcode, knowledge-based questions, biometrics or other method.

In this flow, FIDO and Secure Payment Confirmation may be used for cardholder authentication initiated either by the issuer or by the merchant (or its service provider).

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.

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:

• 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.

For more information, see the FIDO white paper Enterprise Adoption Best Practices – Integrating FIDO & Federation Protocols.