PCI Watch

Tracking changes across the Payment Card Industry

EMV® 3-D Secure Use of FIDO® Data in 3-D Secure Messages White Paper

v1.0 Whitepapers
3-D Secure

EMV<sup>®</sup> 3-D Secure White Paper Use of FIDO® Data in 3-D Secure Messages Version 1.0 October 2020 Use of FIDO Data in 3-D Secure Messages Legal Notice

/ 13

Legal Notice

This document summarizes EMVCo’s present plans for evaluation services and related policies and is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or non-infringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document.

Messages Contents

1.1 History of EMV<sup>®</sup> 3-D Secure 4 1.2 FIDO® Alliance, Inc 4 1.3 EMVCo, FIDO Alliance Collaboration for EMV 3DS 4 1.3.

3.1 FIDO Eco-system Events 6 3.1.1 Registration (Attestation) 6 3.1. 6.

7.1 FIDO Alliance Metadata Service (MDS) 13 7.2 Next Steps 13

Messages Introduction 1 Introduction

/ 13 1.1 History of EMV<sup>®</sup> 3-D Secure To reflect current and future market requirements, the payments industry recognised the need to create a new 3-D Secure specification that would support App-based authentication and integration with digital wallets, as well as traditional browser-based e-commerce transactions. This led to the development and publication of the EMV<sup>®</sup> 3-D Secure—Protocol and Core Functions Specification. The specification takes these new payment channels into account and supports the delivery of industry leading security, performance and user experience.

1.2 FIDO® Alliance, Inc The FIDO (Fast IDentity Online) Alliance, www.fidoalliance.org, was formed in July 2012 to address the lack of interoperability among strong authentication technologies and remedy the problems users face with creating and remembering multiple usernames and passwords. The FIDO Alliance is changing the nature of authentication with standards for simpler, stronger authentication that define an open, scalable, interoperable set of mechanisms that reduce reliance on passwords. FIDO authentication is stronger, private, and easier to use when authenticating to online services.

1.3 EMVCo, FIDO Alliance Collaboration for EMV 3DS 1.3.1 EMVCo & FIDO Alliance Joint Press Release (June-2018) EMVCo, the global technical body that manages the EMV<sup>®</sup> Specifications, and the FIDO Alliance, an industry consortium developing open, interoperable authentication standards, have expanded their collaboration to include a work item to define in detail how EMV 3-D Secure (3DS) messages may be used to pass FIDO authenticator attestation data and signatures in a manner that is both scalable and interoperable across the EMV payments ecosystem. This work builds upon the pre-existing liaison relationship between the organisations. The initial collaboration focused on how FIDO’s authentication protocol can be used to support EMVCo’s cardholder verification technology, leading to User Verification Caching (UVC) extensions of the FIDO specifications. UVC allows an app to specify user caching time — i.e., how long a user who has already been verified by his/her authenticator can wait before being required to re-authenticate. External References:

  • EMVCo, W3C, FIDO Alliance Interest Group Press Release
  • EMVCo and the FIDO Alliance to Address FIDO Authentication in EMV<sup>®</sup> 3-D Secure Use Cases Messages Executive Summary / 13 2 Executive

Summary

In many EMV 3DS transactions, the user journey begins with a merchant-initiated authentication. That authentication could be for a user login (user identification) or at the time of initiating check-out. As this authentication precedes the 3DS transaction, there is value in communicating details about the merchant-initiated authentication to the issuer. When merchants use strong authentication methods such as FIDO Authentication, the details regarding that authentication can potentially be more valuable to the issuer/ACS performing authentication of user for that EMV 3DS transaction. When applying Risk Based Decisioning for that transaction, ACS/Issuer could leverage the data received about that user or device via a merchant-initiated FIDO authentication. This in theory could provide the ACS/Issuer enough data to increase the probability of a frictionless experience for the user. In view of such a capability, EMVCo and FIDO Alliance started to work together towards the following use-cases. Use-Case FIDO assertion/assurance data (with any attestation elements) in current state FIDO enhancements with additional data FIDO Data Relying Party Attestation data from Device, Merchant Assertion data with available details Attestation data from device (e.g. Authenticator attestation unique Id, Credential Id associated with merchant) Authentication time-stamp Authenticator model Merchant 3DS Requestor Authentication Indicator 06 (v2.1.0) 07 (v2.2.0), (v2.3.0 Draft) Communication of FIDO authentication data in EMV 3DS messages was introduced in 3DS V2.1.0. This allowed merchants to communicate merchant-initiated FIDO authentication data to assist in the risk assessment performed by the Access Control Server. However, the structure of the data was not defined by FIDO Alliance or EMVCo, thereby allowing merchants to populate the data based on their implementation. To promote standardisation of this data for use in EMV 3DS messages, the EMVCo 3DS Working Group (3DSWG) and the FIDO Alliance EMV Working Group started a roadmap to define the data structure and to address individual use-cases as milestones. The first output of this collaboration is a defined data-set that will allow merchants to populate a structured set of data elements related to the merchant-initiated FIDO authentication and for the ACS/Issuer to receive a consistent set of values for the same user/device along with other data they would already receive as part of the EMV 3DS transaction. Under this model, the merchant would indicate availability of the standard data-set via a new value in 3DS Requestor Authentication Indicator Field. The ACS/Issuer would be able identify that the merchant had performed a FIDO authentication prior to initiation of the EMV 3DS transaction and will also receive the data about the authentication event as defined in later parts of this document.

Messages FIDO Protocol Features

/ 13 3 FIDO Protocol Features The FIDO protocols use standard public key cryptography techniques to provide stronger authentication. During registration with an online service, the user’s client device creates a new key pair. It retains the private key and registers the public key with the online service. Authentication is done by the client device proving possession of the private key to the service by signing a challenge. The client’s private keys can be used only after they are unlocked locally on the device by the user. The local unlock is accomplished by a user–friendly secure action such as swiping a finger, entering a PIN, speaking into a microphone, inserting a second–factor device or tapping a button. The FIDO protocols are designed from the ground up to protect user privacy. The protocols do not provide information that can be used by different online services to collaborate and track a user across the services. Biometric information, if used, never leaves the user’s device.

3.1 FIDO Eco-system Events 3.1.1 Registration (Attestation) 1. User is prompted to choose an available FIDO authenticator that matches the online service’s acceptance policy. 2. User unlocks the FIDO authenticator using a fingerprint reader, a button on a second– factor device, securely–entered PIN or other method. 3. User’s device creates a new public/private key pair unique for the local device, online service and user’s account. 4. Public key is sent to the online service and associated with the user’s account. The private key and any information about the local authentication method (such as biometric measurements or templates) never leave the local device.

3.1.2 Authentication (Assertion) 1

Online service challenges the user to login with a previously registered device that matches the service’s acceptance policy. 2. User unlocks the FIDO authenticator using the same method as at Registration time. 3. Device uses the user’s account identifier provided by the service to select the correct key and sign the service’s challenge. 4. Client device sends the signed challenge back to the service, which verifies it with the stored public key and logs in the user.

Messages FIDO Building Blocks & Equivalent EMV 3DS Components

/ 13 4 FIDO Building Blocks & Equivalent EMV 3DS Components As FIDO Authentication data is included in EMV 3DS messages, it is beneficial to understand the components that are part of each framework or specification implementation and how they contribute to this flow of data. The following list will present the FIDO building blocks and equivalent components in EMV 3DS implementation.

  • User Device—The device that user has used to register with the FIDO service. In EMV 3DS Context, this would be the user device (PC/Mobile Phone/Other devices) where the EMV 3DS transaction would be initiated.
  • Relying Party App—The merchant application that will interact with the user for authentication. In EMV 3DS Context, this would be equivalent of the 3DS Requestor application/environment.
  • Authenticator—The system (Software/Hardware or both) that implements FIDO protocol and enables registration and authentication of the user and the device.
  • Relying Party App Server—The server component of Relying Party environment which interfaces with the Relying Party App and the FIDO server. In EMV 3DS context, this would be equivalent to the 3DS Requestor environment.
  • FIDO Server—The server that implements FIDO protocols to enable any online service to leverage FIDO authentication for its users. In EMV 3DS this role is typically performed by the ACS/Issuer however ACS/Issuer can also leverage FIDO as a method to authenticate the user. Messages How FIDO Works (EMV 3DS Context) / 13 5 How FIDO Works (EMV 3DS Context) FIDO Authentication is the event where a user uses an authenticator on client platform to authenticate to a relying party. The enrolment of user with the authenticator happens as a predecessor of this authentication step. In EMV 3DS context, this authentication can happen as part of a challenge or as this specific use-case details, as merchant authentication of the user (cardholder) before EMV 3DS flow is initiated. The assurance the issuer/ACS could derive from the authentication performed by the merchant (with supplied authentication data) could potentially increase the probability of frictionless authentication in subsequent transaction. The following graphics1 illustrate how FIDO authentication works using FIDO Alliance framework. 1 Graphics property of FIDO Alliance, Inc. FIDO® is a trademark (registered in numerous countries) of FIDO Alliance, Inc. Messages How FIDO Works (EMV 3DS Context) / 13 Messages Data-set defined by FIDO Alliance / 13 6 Data-set defined by FIDO Alliance The following data set was defined by FIDO Alliance as the structure that would be provided by a merchant if they would like to share the details about merchant-initiated FIDO authentication that preceded the EMV 3DS transaction. This data set was deliberately designed to ensure there is enough data about the authenticator on the device, user verification/presence along with information that the issuer/ACS could verify with FIDO Metadata service should they choose to do so.
  • Public Key—The public corresponding to the authenticator on the device for the user for that specific merchant. In case of multiple authenticators registered by the user for that specific merchant. All the corresponding public keys will be provided.
  • AAGUID (FIDO2)—Authenticator Attestation Globally Unique ID (FIDO2) is the globally unique identifier for the authenticator that was used to complete user authentication.
  • AAID (UAF)—Authenticator Attestation ID (UAF) is the globally unique identifier for the authenticator that was used to complete user authentication.
  • UV— User verification is the flag that through true, false values indicates the authenticator was used with a user verification (e.g., Client PIN, Biometrics).
  • UP—User presence is the flag that through true, false values indicates that the user had an explicit action (e.g., biometrics/gesture) performed as part of the authentication.
  • UsedForThisTransaction—Flag that indicates for each public key if that authenticator was used. In case of multiple authenticators in the device having been used for that specific authentication, corresponding flags will be set to true. The following table provides a technical overview of how FIDO Authentication data would be formatted and included in 3DS messages. The format and presence condition will help the ACS/Issuer learn how to interpret the data and apply necessary logic to process these data elements. Key authTime FIDOAuthenticatorRef erences rpId appId Type String (Required) array of FIDOAuthenticatorRe ference Objects String (present if and only if appId is not) String (present if and only if rpId is not)

Description

ISO 8601 encoded time of when the FIDO authentication was performed User’s authenticators registered with this merchant RP ID for U2F or FIDO authenticators AppID for UAF Authenticators

Messages Data-set defined by FIDO Alliance

/ 13 Key publicKey aaguid Aaid usedForThisTransacti on Up Uv Type String (Required) String (present if and only if aaid is not) String (present if and only if aaguid is not) boolean (Required) boolean (never present if usedForThisTransact ion is false) boolean (never present if usedForThisTransact ion is false) Description Base64url encoding of the public key raw format (e.g., ALG_KEY_ECC_X962_RAW or ALG_KEY_RSA_2048_RAW, see https://fidoalliance.org/spec s/common-specs/fido-registryv2.1-ps-20191217.html#publickey-representation-formats) related to the FIDO credential registered on this authenticator for this merchant. The AAGUID of the FIDO2 authenticator (or the encoding of 16 zero bytes if not available). In the case of a U2F authenticator it will be the Base64 encoded serialized JSON encoded attestationCertificateKeyIden tifiers list (see FIDO Metadata Statements) The AAID of the UAF Authenticator True if this Authenticator was used to authenticate the current session at the merchant ("User Presence"), True if the authentication involved some affirmative user gesture (such as touching the authenticator) ("User Verification"), True if the authenticator collected proof that an authorized user was present during authentication, e.g., PIN or Biometric

Messages Data-set defined by FIDO Alliance

/ 13 6.1 Dataset Characteristics

  • Small size & simple structure
  • Issuer learns the Authenticator model and could even lookup more details from FIDO Metadata Service.
  • UVM if present tells the issuer whether and what type of user verification was performed. In the case of WebAuthn UVM would at least include the up, uv bits taken from the authentication response.
  • Issuer could learn that a new public key was properly registered by the same user. This might be relevant if public key X is provided in one transaction and another public key Y is provided in a subsequent transaction. With this proposal the subsequent transaction would also include public key X. Messages FIDO Authentication Data Example / 13 7 FIDO Authentication Data Example This is an example of FIDO Authentication Data. It is based on a user having a single authenticator of model "0132d110-bf4e-4208-a403-ab4f5f12efe5" that was used for this transaction. User presence check "up" and User verification "uv" have been performed. The user authenticated to "emvco.com". { "rpId": "https://emvco.com", "authTime": "2020-08-08T07:42:17Z", "FIDOAuthenticatorReferences": [ { "publicKey": "BJDLvkKkuXRpn3bWh_hiJQb8lJNd9kTXEmQgEwoHezkNI_VPGd3vrjrWyZTfgxVDl9_Tp ixrVjmEAEmegmfL2WI", "aaguid": "0132d110-bf4e-4208-a403-ab4f5f12efe5", "uv": true, "up": true, "usedForThisTransaction": true } ] } 7.1 FIDO Alliance Metadata Service (MDS) The issuer ACS may choose to make use of the FIDO Metadata Service to verify the authenticator data that is received in the FIDO Authentication Data via EMV 3DS. For example, the issuer could use this data to verify the authenticator used for cardholder authentication has been tested and is compliant with FIDO testing standards and when uv and up flags are not present to check whether FIDO Metadata for the given aaguid/aaid specifies that the authenticator always performs user verification.

7.2 Next Steps As stated in introduction of this paper, FIDO Alliance and EMVCo have explored how they could collaborate on different use-cases that allow use of FIDO technology in EMV 3DS transactions. The use of FIDO Authentication data in EMV 3DS Messages is the first outcome of this collaboration. Both FIDO Alliance and EMVCo will continue to work together to promote other use-case along with enhancing the capabilities of verification of FIDO authentication data wherever applicable and use of FIDO Authentication as 3DS Challenge method. Future deliverables on different use-cases will be detailed in separate communications and specifications. © 2020 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV<sup>®</sup> is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.