How EMVCo, FIDO, and W3C Technologies Relate

W3C Interest Group Note

This version:
https://www.w3.org/TR/2020/NOTE-htr-20201105/
Latest published version:
https://www.w3.org/TR/htr/
Editor:
Ian Jacobs (W3C)
Participate:
GitHub w3c/wpsig
File a bug
Commit history
Pull requests

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

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

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

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

Typical user journey with Payment Request

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
  • SRC checkout does not require a password to access to the list of cards - other forms of verification may be used
Reduce the friction of user authentication processes to access list of cards
  • A variety of mechanisms (currently discussed in the Card Payment Security Task force of the W3C Web Payments Working Group) may be available to establish the user's identity for SRC interactions, including:
    • 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
  • 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, 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
  • 3-D Secure can provide issuing banks with data (from fingerprinting the browser via JavaScript) that is used for risk assessment and 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 fingerprinting the browser via JavaScript) 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.

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, so 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.
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.

4. Transaction Flows

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.

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:

4.2 Basic Flows

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.

4.3 FIDO Authentication Variations

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:

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

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

A.3.2 FIDO / Web Authentication

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:

  • Non-repuditation, because the message is shown to the user (providing protection against Javascript injection attacks) and
  • Dynamic-linking, because the transaction text is cryptographically linked to the assertion

The Web Payments Working Group is also discussing dynamic-linking in the context of a Secure Payment Confirmation proposal.

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

A.4 How do these technologies relate to GDPR?

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

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:

For more information, see the FIDO white paper Enterprise Adoption Best Practices – Integrating FIDO & Federation 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.