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

EMV® 3-D Secure White Paper Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Version 2.0 November 2023 EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Page 2 / 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. © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Page 3 / 13 Contents 1 Introduction ............................................................................................................. 4 1.1 History of EMV® 3-D Secure ........................................................................... 4 1.2 FIDO® Alliance, Inc. ........................................................................................ 4 1.3 EMVCo–FIDO Alliance Collaboration for EMV 3DS.......................................... 4 2 Background ............................................................................................................ 4 2.1 Supported Protocol .......................................................................................... 5 3 Overview: FIDO Protocol Features .......................................................................... 6 3.1 FIDO Ecosystem Events .................................................................................. 6 3.1.1 Registration (Attestation)........................................................................... 6 3.1.2 Authentication (Assertion) ......................................................................... 6 3.2 Support for Synced Passkeys........................................................................... 6 4 Dataset Defined to Support Issuer Validation of FIDO Authentication Data ............. 8 4.1 Attestation ....................................................................................................... 8 4.2 Assertion ....................................................................................................... 10 4.3 Challenge Formats ........................................................................................ 12 4.3.1 Registration ................................................................................................... 12 4.3.2 Authentication................................................................................................ 12 5 FIDO Alliance Metadata Service ........................................................................... 13 6 Open Issues and Next Steps ................................................................................ 13 © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data 1 Introduction Page 5 / 13 1.1 History of EMV® 3-D Secure To reflect current and future market requirements, the payments industry recognised the need to create a new EMV® 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 by EMVCo, the global technical body that manages the EMV Specifications, of the EMV 3-D Secure—Protocol and Core Functions Specification, which takes into account these payment channels and supports the delivery of industry-leading security, performance, and user experience. 1.2 FIDO® Alliance, Inc. The FIDO® (Fast IDentity Online) Alliance was formed in July 2012 as an industry consortium developing open, interoperable authentication standards, to address the lack of interoperability among strong authentication technologies and remedy the challenges faced by users 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 and interoperable set of mechanisms that reduce reliance on passwords. FIDO authentication is stronger, private, and easier to use for online services. 1.3 EMVCo–FIDO Alliance Collaboration for EMV 3DS In 2016, EMVCo and the FIDO Alliance began work to provide stronger authentication experiences for Cardholders and have produced several publications to date: • EMVCo, W3C, FIDO Alliance Interest Group Press Release • EMVCo and the FIDO Alliance to Address FIDO Authentication in EMV® 3-D Secure • Use of FIDO Data in 3-D Secure Messages o FIDO Authentication and EMV 3-D Secure: Reducing Fraud and Friction for Online Payments • EMVCo, FIDO Alliance and W3C Continue Collaboration to Promote Consumer Privacy while Ensuring Convenient and Secure Checkout Experiences 2 Background In 2020, EMVCo and the FIDO Alliance came together to define and publish a white paper titled “Use of FIDO® Data in 3-D Secure Messages”, which explains how the use of FIDO Authentication Data in 3DS messages can streamline e-commerce checkout while reducing friction for consumers. In the white paper, EMVCo and the FIDO Alliance described a data structure that provides guidance on how Issuers can use FIDO Authentication Data for risk evaluations. This data structure primarily includes a success signal to the bank informing it of a successful authentication. In this case, the bank does not receive sufficient information or evidence to validate the authentication results, but instead depends on the Merchant to verify the authentication results obtained from the FIDO Authentication. © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Page 5 / 13 As authentication flows evolve and Merchants increasingly build seamless experiences using FIDO standards, where authentication is controlled by the Merchant environment, it has become apparent that in some scenarios the Issuer may require more data to assess risk and validate the authentication cryptographically. EMVCo has now defined an enhanced data structure to enable validation by banks. Further details are provided in the current document, which replaces the previous white paper. This paper applies to a scenario in which the FIDO Relying Party is not the Issuer and the authentication results are shared with the Issuer, allowing for further validation. The FIDO Alliance has reviewed this paper and endorses its publication. 2.1 Supported Protocol The enhanced data structure described in this document is intended to be supported on EMV 3DS v2.2 and above. © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Page 6 / 13 3 Overview: FIDO Protocol Features The FIDO protocols use standard public key cryptography techniques to provide strong 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 performed by the client device proving possession of the private key to the service by signing a challenge. The client’s private key can be used only after it is unlocked locally on the device by the user. The local unlock is accomplished by a user-friendly and 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. 3.1 FIDO Ecosystem Events 3.1.1 Registration (Attestation) 1. The user is prompted to choose and authenticate using an available FIDO authenticator. 2. The user activates the FIDO authenticator using a fingerprint reader, securely entered PIN or any other secure activation method. 3. The user’s device creates a new public/private key pair unique for the online service and the user’s account. 4. The public key is sent to the online service and associated with the user’s account. However, the private key is not sent to the online service and biometric measurements or templates never leave the local device. 3.1.2 Authentication (Assertion) 1. An online service challenges the user to authenticate with a previously registered credential that matches the service’s acceptance policy. 2. The user activates the FIDO authenticator. 3. The device uses the user’s credential identifier provided by the service to select the correct key and sign the service’s challenge. 4. The client device sends the signed challenge back to the service, which verifies it with the stored public key and authenticates the user. 3.2 Support for Synced Passkeys In March 2022, the FIDO Alliance announced support for synchronising FIDO credentials across consumer devices – these are commonly referred to as passkeys, or, more specifically, synced passkeys. This indicates that the private key generated as part of the public/private key pair during the Registration step is no longer limited to the local device. In scenarios where a synced passkey is established at the time of registration rather than a local device key pair, Issuers and ACSs should note that authenticator details (device details such as Authenticator © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Page 7 / 13 Attestation Global Unique Identifier (AAGUID)) will not be available during the Registration stage, which is why Relying Parties will not be able to transmit this information downstream over the 3DS rails. Issuers and Issuer ACSs should consider reduced information during the registration (attestation) stage for cases where a synced passkey is being used. In scenarios where synced passkeys are generated at the time of Registration, the Merchant or its provider may provide unique device information to the Issuer to ensure that the Issuer can link the FIDO credential to the unique device information provided. How this unique device information is generated is out of scope of this document. © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Page 8 / 13 4 Dataset Defined to Support Issuer Validation of FIDO Authentication Data The following enhanced dataset was defined by EMVCo jointly with the FIDO Working Group as the structure that would be provided by a Merchant in case of registration (attestation) and authentication (assertion) if the Merchant would like to share details about key FIDO Ecosystem events enabling Issuers to validate the authentication outcome. Note: In the scenario covered in this white paper, Cardholder ID&V has been completed with the Issuer prior to initiating FIDO registration. However, it should be noted that other scenarios are also possible. For instance, the Merchant can initiate FIDO registration with the Cardholder first, followed by Issuer ID&V. In such cases, references to Prior Authentication Data will not be present. 4.1 Attestation In this step, the Cardholder is enrolled to use FIDO as a form of authentication for future transactions. • Relying Party ID (rpID) As defined by the FIDO Alliance, a Relying Party is a website or other entity that uses a FIDO protocol to directly authenticate users (i.e., performs peer entity authentication). The Relying Party ID enables Issuers to uniquely identify the Merchant application managing the authentication process. • Attestation Blob (attestationBlob) This is the response received by the Relying Party when successfully creating a FIDO credential for a given Cardholder. FIDO UAF and FIDO2/WebAuthn credentials are supported. This response contains multiple data elements, such as: 1. User verification and user presence evidence. 2. Public key and algorithm by the authenticator used to generate the key pair allowing the Issuer to store the public key and bind it to the Cardholder identity and take note of the algorithm for future use of signature validation. 3. Authenticator details may be present (for example, the AAGUID or AAID), allowing the Issuer to look up the authenticator in the FIDO Alliance Metadata Service and obtain the characteristics of the authenticator. 4. A challenge message may include a previous ACS Transaction ID reference, which could assist the Issuer in linking the attestation to a previous EMV 3DS transaction performed using the Issuer-preferred authentication method. • Prior Authentication Data (Optional) In cases where the Merchant has completed ID&V between the Issuer and the Cardholder before the FIDO registration, a prior authentication transaction ID – specifically the ACS Transaction ID and the DS Transaction ID – will be available. This information would allow the Issuer to validate if successful ID&V has been completed between the Cardholder and the Issuer before the Merchant sets up FIDO as an authentication method. The following table provides a technical overview of how FIDO Authentication data would be formatted for attestations and included in 3DS messages. The format will help the ACS/Issuer learn how to interpret the data and apply the necessary logic to process these data elements. © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Page 9 / 13 Field Name messageCategory threeDSReqAuthData1 threeDSRequestorPriorAuthe nticationInfo=>threeDSReqP riorRef threeDSRequestorPriorAuthe nticationInfo=>threeDSReqP Proposed Value PA or NPA This will be structured as a JSON with two fields: { "rpId":"", "attestationBlob": "", deviceBindingInfo" :"", "FIDOMessageType": "Register" or "Authenticate" "version":"" } ACS Transaction ID 02 Justification NPA for attestations should be used where the intent is to purely submit attestation data to the Issuer where no payment is being performed simultaneously. PA for attestations should be used for payments transactions where the same EMV 3DS message is used to submit FIDO attestation data to the Issuer as information for future FIDO assertions. rpId will include the Relying Party ID. attestationBlob will contain the response received by the Relying Party when successfully creating a FIDO credential for a given Cardholder. Certain fields as part of the FIDO statements generated from the WebAuthn registration (navigator.credentials.create) calls are set to type ArrayBuffer. Before submitting the attestationBlob, the Relying Party must ensure that it is Base64url-encoded. Issuers and ACSs should ensure that fields are appropriately decoded before processing. For more information, refer to https://www.w3.org/TR/webauthn1/#authenticatorattestationresponse. deviceBindingInfo is where the Merchant can provide a unique identifier for the device (format: 32 bytes, alphanumeric). FIDOMessageType: This will allow the Merchant to specify the format of the value populated in the attestationBlob. Specifying the format will ensure that the Issuer uses the accurate parsing format after decoding the blob. For example: Specifically in the case of synced passkeys, some assertions may be populated at the time of registration of a new device. version: To specify version number to allow for future enhancements as the JSON message format evolves. This information will only be present where the Merchant has completed successful Cardholder ID&V with the Issuer before initiating FIDO registration. 1 In EMV 3DS v2.2 the data needs to be properly formatted as a string (with delimiters as necessary). © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Field Name Proposed Value Justification Page 10 / 13 riorAuthMethod threeDSRequestorPriorAuthe nticationInfo=>threeDSReqP riorAuthTimestamp threeDSReqAuthMethod threeDSReqAuthTimestamp Timestamp of prior challenge 07 Timestamp of the FIDO attestation Format accepted = YYYYMMDDHHMM To specify to the Issuer that authentication was performed using a FIDO authenticator (FIDO attestation data signed). 4.2 Assertion In this step, the enrolled Cardholder returns to the Merchant application and uses FIDO as a form of authentication during checkout. • Relying Party ID (rpID) As defined by the FIDO Alliance, a Relying Party is a website or other entity that uses a FIDO protocol to directly authenticate users (i.e., performs peer entity authentication). The Relying Party ID enables Issuers to uniquely identify the Merchant application managing the authentication process. • Assertion Blob (assertionBlob) This is the response received by the Relying Party when authenticating a Cardholder using a previous enrolled FIDO credential. FIDO UAF and FIDO2/WebAuthn credentials are supported. This response contains multiple data elements such as: 1. User verification and user presence evidence. 2. Signed payload for the Issuer to verify using the public key received at the time of attestation. If the Issuer has performed a prior ID binding (after Cardholder ID&V) between the user public key and the card number, the Assertion Blob proves that the correct user key pair has been used. 3. Challenge message including transaction data such as Merchant Identifier, Currency Code, Purchase Amount and a timestamp. This additional transaction data provides increased evidence to the Issuer about what the Cardholder agreed to authenticate. In cases where the Relying Party used the SPC extension as part of the assertion, Issuers will additionally receive SPC Data in the Assertion Blob. The following table provides a technical overview of how FIDO Authentication data would be formatted for assertions and included in 3DS messages. The format and presence condition will help the ACS/Issuer learn how to interpret the data and apply the necessary logic to process these data elements. © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Page 11 / 13 Field Name messageCategory Proposed Value NPA or PA Justification threeDSReqAuthData2 This will be a JSON structure with the following two fields: { "assertionBlob":"", "rpId":"", "deviceBindingInfo":"", "version":"", "spcUsed":"" } threeDSReqAuthMethod 07 threeDSReqAuthTimestamp Timestamp of the FIDO assertion Format accepted: YYYYMMDDHHMM rpId will include the Relying Party ID. assertionBlob will contain the response received by the Relying Party when successfully authenticating the Cardholder using the previously stored credential. Certain fields as part of the FIDO statements generated from the WebAuthn registration (navigator.credentials.get) calls are set to type ArrayBuffer. Before submitting the assertionBlob, the Relying Party must ensure that all data is Base64url-encoded. Issuers and ACSs should ensure that the necessary fields are appropriately decoded before processing. For more information, refer to https://www.w3.org/TR/webauthn1/#authenticatorassertionresponse deviceBindingInfo is where the Merchant can provide a unique identifier for the device (format: 32 bytes, alphanumeric). version: To specify version number to allow for future enhancements as the JSON message format evolves. spcUsed: a Boolean value (True/False) to specify to the Issuer if it should look for SPC data in the ClientDataJson as part of the assertionBlob. To specify to the Issuer that authentication was performed using a FIDO authenticator. 2 In EMV 3DS v2.2 the data needs to be properly formatted as a string (with delimiters as necessary). © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Page 12 / 13 4.3 Challenge Formats 4.3.1 Registration To ensure protection from replay attacks and enable banks to link to a previous authenticated transaction, Relying Parties should follow a specific format for Challenges included in the Client Data JSON when processing a FIDO registration, specifically for payment scenarios. The challenge should have the following format: • 1 byte representing the length of the random value (i.e., byte array length) • + random challenge value in a byte array • + acsTransID of the prior ID&V transaction (Note: acsTransID will only be present for cases where prior ID&V has been completed between the Cardholder and the Issuer). 4.3.2 Authentication Similarly to the registration step, Relying Parties should follow a specific format for Challenges included in the Client Data JSON when processing a FIDO Authentication for payment scenarios specifically. Describing the challenge data in this format will ensure that transactional data is signed by the authenticator. The challenge should be in the following format: • 1 byte representing the length of the random value (i.e., byte array length) • + random challenge value in a byte array • + transaction timestamp in YYYYMMDDHHMM format • + 3-digit Currency Code + Currency Exponent + Purchase Amount in minor units • + “|” delimiter • + MerchantName – maximum 40 characters. This applies to both Payment and Non-Payment scenarios. In case of Non-Payment scenarios, Currency Code, Currency Exponent and Purchase Amount should be zero-filled. © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages to Support Issuer Validation of FIDO® Authentication Data Page 13 / 13 5 FIDO Alliance Metadata Service The Issuer ACS may choose to use the FIDO Alliance 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 that the authenticator used for Cardholder authentication has been tested and is compliant with FIDO testing standards, and to check whether FIDO Alliance Metadata for the given aaguid/aaid specifies that the authenticator always performs user verification. Issuers should note that an attestation statement can be relied on only when an AAGUID/AAID is also present. 6 Open Issues and Next Steps More information will be made available once device public key implementations are rolled out by platforms, and once there is more clarity as to the type of information shared with Relying Parties during the Registration and Authentication step. © 2023 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® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.