How EMVCo, FIDO, and W3C Technologies Relate

W3C Group Note

More details about this document
This version:
https://www.w3.org/TR/2022/NOTE-htr-20221213/
Latest published version:
https://www.w3.org/TR/htr/
Latest editor's draft:
https://w3c.github.io/wpsig/
History:
https://www.w3.org/standards/history/htr
Commit history
Editor:
Ian Jacobs (W3C)
Feedback:
GitHub w3c/wpsig (pull requests, new issue, open issues)
[email protected] with subject line [htr] … message topic … (archives)

Abstract

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:

Status of This Document

This section describes the status of this document at the time of its publication. 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 is not yet a public document. The expectation is that, once approved by W3C, FIDO, and EMVCo, it will be made public.

This document was published by the Web Payment Security Interest Group as a Group Note using the Note track.

Group Notes are not endorsed by W3C nor its Members.

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 W3C Patent Policy does not carry any licensing requirements or commitments on this document.

This document is governed by the 2 November 2021 W3C Process Document.

1. Goals

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.

1.1 Deliver Best-in-Class User Experience

We seek to:

1.2 Enhance Security, Reduce Fraud, and Increase Approval Rates

We seek to:

1.3 Reduce Integration Effort and Cost

We seek to:

1.4 Protect User Privacy

We seek to:

1.5 Meet Regulatory Requirements

We seek to:

2. 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:

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 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:

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:

  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.

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:

From a user experience perspective:

2.4 FIDO2

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 gain access 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 while never storing shared secrets or biometric data in the cloud.

2.5 Payment Request API and Payment Apps

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.

2.6 Secure Payment Confirmation (SPC)

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:

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.

3. How Technologies in Scope Help Achieve Goals

The tables below summarize how the technologies in scope can help achieve the goals.

3.1 Deliver Best-in-Class User Experience

Goals How Technologies and standards help
Alleviate the burdens associated with passwords
  • FIDO2 supports password-less authentication
  • 3-D Secure discourages the use of static passwords and supports biometric through third-party application ("out-of-band") authentication
  • SRC checkout does not require a password to access the list of cards - other forms of verification may be used
Reduce the friction of user authentication processes to access the list of cards
  • FIDO2 supports single touch multifactor authentication
  • Web Authentication provides access to FIDO authenticators from a web page
  • 3-D Secure may be used in conjunction with SRC as part of access to the list of cards.
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
  • Secure Payment Confirmation streamlines authentication during checkout (using Web Authentication)
  • FIDO2 supports single touch multifactor authentication
  • Web Authentication 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
  • Secure Payment Confirmation supports both (FIDO) registration and authentication without leaving the merchant site.
Reduce confusion that can arise from very different checkout experiences across the Web
  • Secure Payment Confirmation makes it easier for users to reuse authentication credentials across different merchant sites ("register once, authenticate across the Web") while protecting user privacy.
  • 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
  • For information about authenticator management, see Recommended Account Recovery Practices for FIDO Relying Parties

3.2 Enhance Security, Reduce Fraud, and Increase Approval Rates

Goals How Technologies and standards help
Prevent account takeover and security attacks
  • FIDO2 cryptographic login credentials are unique across every website
  • 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 an authorized party can use a card
  • 3-D Secure can provide issuing banks with data (from data collection in the browser) that is used for risk assessment, and provide issuing bank with a challenge step-up for cardholder authentication
  • 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-D Secure can provide issuing banks with data (from data collection in the browser) that is used for risk assessment

3.3 Reduce Integration Effort and Cost

Goals 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 (although the system that processes the Payment Tokens may still be)

3.4 Protect User Privacy

Goals 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, the protocol limits the ability to track users across sites.

3.5 Meet Regulatory Requirements

Goals 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.
  • The transaction dialog of Secure Payment Confirmation adds support for dynamic linking to the capabilities already enabled through FIDO / Web Authentication
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 and verified locally is a strong asset of the FIDO approach and is in line with certain major privacy requirements and regulations.

4. Authentication Flows

Below we describe some of the ways that the technologies in scope relate, especially through the lens of 3-D Secure authentication. The technologies in scope may also be used in other authentication scenarios (e.g., SPC with Secure Remote Commerce) but we do not discuss those relationships here in detail. In the previous version of this document we discussed other relationships among the technologies (e.g., Payment Request API used to implement a Secure Remote Commerce flow), but since then we have turned our focus to authentication flows.

4.1 Using FIDO and SPC with 3-D Secure

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

4.1.1 Issuer environment

Authentication Method Relying Party (RP) 3DS Flow Initiated by Validated by Note
IE-1 SPC or FIDO Issuer Challenge Issuer Issuer Issuer environment; for SPC see 3DS 2.3

In more detail:

  • In this scenario, the issuing bank initiates a challenge flow and uses SPC or FIDO as the authentication mechanism.

4.1.2 Merchant environment

Authentication Method Relying Party (RP) 3DS Flow Initiated by Validated by Note
ME-1 FIDO Merchant/PSP Frictionless Merchant/PSP Merchant/PSP Delegated authentication. See FIDO Authentication and EMV 3-D Secure – Using FIDO for Payment Authentication
ME-2 SPC Merchant/PSP Frictionless (though Issuer may challenge) Merchant/PSP Merchant/PSP Delegated authentication, e.g., RP is PSP for reuse across merchants
ME-3 SPC Issuer Challenge Merchant/PSP Issuer Merchant environment; see 3DS 2.3

In more detail:

  • ME-1. In this anticipated FIDO scenario, the consumer has an account with the merchant and logs in. The merchant (who is thus the RP) may provide that information as (prior authentication data) input to the 3-D Secure protocol. For more information on this data, see Technical Note: FIDO Authentication and EMV 3-D Secure – Using FIDO for Payment Authentication.
  • ME-2. In this anticipated SPC scenario, the user has registered a FIDO credential previously with the payment service provider (PSP) used by the merchant. When the user selects a payment instrument, the PSP detects that there is an associated credential and prompts the user to authenticate. The resulting assertion can be used in the manner described in ME-1. Because the PSP is the RP, the user can reuse the registered FIDO credential across multiple merchants, reducing registration friction.
  • ME-3. In this scenario, the issuing bank is the RP. When the user selects a payment instrument, the merchant (or PSP) contacts the issuing bank (via 3-D Secure) which returns any associated FIDO credentials. The merchant can then prompt the user to authenticate with these credentials, and pass the resulting assertion back to the issuer for validation (again via 3-D Secure). Because the issuer is the RP, the user can reuse the registered FIDO credential across multiple merchants and multiple payment service providers, further reducing registration friction.

5. Potential Technology or User Experience Improvements

This section identifies some payment experience improvements for consideration in current or future specifications (or their implementations).

A. FAQ

A.1 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.

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.

A.2 How do these technologies relate to PSD2?

A.2.1 EMV® 3-D Secure

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 (and following versions) 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.

A.2.2 FIDO / Web Authentication

See the FIDO Alliance's Meet PSD2 Requirements with FIDO and (jointly developed with EMVCo) Technical Note: FIDO Authentication and EMV 3-D Secure – Using FIDO for Payment Authentication.

A.2.3 Secure Payment Confirmation

Secure Payment Confirmation adds dynamic linking capabilities to FIDO / Web Authentication. See also notes on Using SPC to fulfill PSD2 Requirements for SCA and Dynamic Linking.

A.3 How do these technologies relate to GDPR?

See the FIDO white paper FIDO Authentication and the General Data Protection Regulation.

A.4 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:

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