PCI Watch

Tracking changes across the Payment Card Industry

EMV® 3-D Secure Version Number Management Protocol Versions 2.1.0 / 2.2.0

v1.0
3-D Secure

EMV<sup>®</sup> 3-D Secure Version Number Management Protocol Versions 2.1.0 and 2.2.0 Version 1.0 September 2020 EMV<sup>®</sup> 3-D Secure Version Number Management Legal Notice

of iii

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.

Management Contents

1. 1. 1. 1.3.1 1.3.2 1.3.3 1.3.4 1.3. 1. 2. 2. 2.2.1 2.2.2 2.2. 2. 2.3. 2.3. 2. 2.4. 2.4. 3. 3.1. 3.1. 3. 3.2.1 3.2.2 3.2. Sample Flow—3DS Requestor App suggests Protocol Version (Option 1) 10 Sample Flow—3DS Requestor App suggests Protocol Version (Option 2) 10

Management Introduction

of 11 1

Introduction

The EMV 3-D Secure protocol is aimed at securing authentication in browser-based and app-based transactions. Due to new technologies, regulatory requirements, or identified security vulnerabilities, it is important for the EMV 3-D Secure protocol to control different versions and manage how those versions get deployed into production and used during the authentication process.

1.1 Application This document applies to specifications release and management practice of EMV 3-D Secure Protocol versions 2.1.0 and 2.2.0.

1.2 Audience This document is intended for use by implementers of the EMV 3-D Secure protocol.

1.3 Terminology and Conventions The terminology used in this document and their specific meaning is described in the following sections.

1.3.1 Protocol Version Protocol Version defines the interoperability between the EMV 3-D Secure components (3DS Server, DS, ACS, 3DS SDK). For example, 2.1.0. Protocol Version format: MAJOR.MINOR.PATCH

  • MAJOR version for significant specification changes
  • MINOR version for added functionality
  • PATCH version for specification fixes 1.3.2 Specification Bulletin Specification Bulletins provide a reference of updates, clarifications and errata incorporated into the EMV 3-D Secure specifications. For example, EMV Specification Bulletin No. 204 v6. Specification Bulletin format: BULLETIN NUMBER + BULLETIN REVISION VERSION
  • BULLETIN NUMBER is 3-digit number assigned by EMVCo
  • BULLETIN REVISION VERSION for iterative updates, clarifications and errata to the EMV 3-D Secure specifications Management Introduction of 11 1.3.3 Message Version Number Message Version Number is a 3-D Secure data element that refers to the Protocol Version number. Message Version Number is set by the 3DS Server in the AReq message. For example, 2.1.0.
  • The 3DS Server determines the highest common Message Version Number based on its evaluation of the Protocol Version(s) supported by the DS, ACS, 3DS SDK and assigns the Message Version.
  • The Message Version Number for a specific transaction is consistent following the Message Version Number in the AReq transaction across all 3-D Secure protocol messages.

1.3.4 Data Version Data Version defines the set of device identification parameters that the 3DS SDK shall collect. The data version is a means for participating EMV 3-D Secure components to know which set of device identification parameters is being transferred. For example,1.4. Note: Data Version is independent of the Protocol Version. Data Version format: MAJOR.MINOR

  • MAJOR version for significant parameter changes
  • MINOR version for iterative changes on the same parameter structure 1.3.5

Definitions

For the definition of the terms used in this document, refer to the EMV 3-D Secure Protocol and Core Functions Specification, Table 1.3.

1.4 Supporting Documentation The following documents are specific to the EMV 3-D Secure protocol and should be used in conjunction with this document. These documents as well as EMV 3-D Secure FAQs are located on the EMVCo website.

  • EMV 3-D Secure—Protocol and Core Functions Specification versions 2.1.0 and 2.2.0
  • EMV 3-D Secure SDK Specification versions 2.1.0 and 2.2.0
  • EMV 3-D Secure SDK—Device Information Management Protocol Version Management of 11 2 Protocol Version Management This chapter provides an overview of 3-D Secure protocol version management. Protocol version update includes major/minor specification releases, and/or patch releases that impact interoperability. EMV 3-D Secure specifications and 3-D Secure components identify the Protocol Version using a three-part version number.
  • Protocol Version number format: MAJOR.MINOR.PATCH
  • Protocol Version number example: 2.1.0 2.1 Major Release A Major Release occurs when EMVCo has made non-interoperable software changes to the 3-D Secure specification that signals to the industry that the specification has significant changes. For example, the Protocol Version number would be updated from 2.1.0 to 3.0.0. Note: Major Release changes are currently not applicable and are therefore not addressed in detail in this document. Protocol Version impact:
  • Position 1 is incremented
  • Position 2 and 3 are reset to "0" Example:
  • Previous Protocol Version number: 2.1.0
  • New Protocol Version number: 3.0.0 2.2 Minor Release A Minor Release indicates that EMVCo has made non-interoperable software changes to the 3-D Secure specification that signals to the industry that the 3-D Secure specification has new features and/or functionalities for implementation. For example, the Protocol Version number would be updated from 2.1.0 to 2.2.0.

2.2.1 Numbering Protocol Version number impact

  • Position 1 no change
  • Position 2 is incremented
  • Position 3 is reset to "0" Example
  • Previous Protocol Version number:
  • New Protocol Version number: 2.1.0 2.2.0 Management Protocol Version Management 2.2.2 Release Plan of 11 2.2.2.1 Draft Release for Associate and Subscriber Input and Feedback Note: All Minor Release changes to the 3-D Secure specifications(s) are first released as drafts to allow EMVCo Associates and Subscribers to provide input and receive working group feedback on the draft documentation. After the input and resulting feedback is finalised, the documentation is then published as public to the industry. Each draft specification release will include the Protocol Version Number and the draft number in the Specification and the accompanying Draft Specification Bulletin.

2.2.2.2 Documentation 3-D Secure specification-related documentation will be updated to the new Protocol Version number and will be published to the EMVCo website. These documentation updates include:

  • EMV 3-D Secure Protocol and Core Functions Specification
  • EMV 3-D Secure SDK Specification These documents will carry the same Protocol Version number, regardless whether changes were made that impact only one of the documents. If changes were not made to the document, it will be noted under the document’s Revision Log. Any other 3-D Secure documentation will be updated if changes are deemed necessary for that Minor Release.

2.2.3 Communication EMVCo will publish a Bulletin providing the scope of the updates for implementation.

2.3 Patch Release A Patch Release indicates that EMVCo has made non-interoperable changes to the 3-D Secure specification that signals to the industry that the 3-D Secure specification has added functional fixes or security updates following, but related to, a Minor Release. For Protocol Versions 2.1.0 and 2.2.0, Specification Bulletins can be used for the equivalent of Patch Release without impact to the Protocol Version number. However, changing the Protocol Version number will also be an optional approach for patch release.

2.3.1 Numbering Bulletin number impact:

  • Bulletin number is assigned by EMVCo when it is released, no change afterwards Bulletin Revision Version impact:
  • Revision Version is incremented Example:
  • Previous Patch Update for 2.1.0: SB 999v1 (SB 999 is for reference only)
  • New Patch Update for 2.1.0: SB 999v2 Management Protocol Version Management 2.3.2 Release Plan of 11 2.3.2.1 Documentation If patch releases are made, all details would be captured within the Bulletin.

2.3.2.2 Communication EMVCo will publish a Bulletin providing the scope of the updates for implementation. The Bulletin will be published to the public without EMVCo Associates and Subscribers review.

2.4 Editorial Updates Editorial update indicates that EMVCo has made an interoperable change to the 3-D Secure specification, that signals to the industry that the 3-D Secure specification has added updates and/or clarifications following a Minor release. For Protocol Versions 2.1.0 and 2.2.0, editorial updates are presented by Specification Bulletins. For example, the Bulletin Number and Revision Version would be updated from SB 999v5 to SB 999v6.

2.4.1 Numbering Bulletin Number impact:

  • Bulletin Number is assigned by EMVCo when it is released, no change afterwards Bulletin Revision Version impact:
  • Revision Version is incremented Example:
  • Previous Editorial Update for 2.1.0: SB 999v5
  • New Editorial Update for 2.1.0: SB 999v6 2.4.2 Release Plan 2.4.2.1 Documentation If editorial updates are made, all details would be captured within the Bulletin.

2.4.2.2 Communication EMVCo will publish a Bulletin announcing the scope of the updates for implementation. The Bulletin will be published without EMVCo Associates and Subscribers draft review.

Management Identifying Which Message Version to Use

of 11 3 Identifying Which Message Version to Use The 3DS Server is responsible for determining which Message Version to use when initiating authentication messages by ensuring each 3DS component supports the Protocol Version for each 3-D Secure transaction. If the Message Version/Protocol Version is not aligned amongst 3-D Secure components for a 3-D Secure transaction, a Message Error will result.

3.1 DS and ACS For the DS and ACS, the 3DS Server uses the PReq/PRes message pair to identify the Protocol Versions supported by each DS and ACS. The 3DS Server caches this information to build messages that can be processed by the DS and ACS.

3.1.1 PReq/PRes Message Pair The 3DS Server can cache information about the Protocol Versions supported by the available ACS and DS. The data will be organised by the card ranges as configured by a DS. The information provided on the Protocol Versions supported by ACS and the DS can be utilised in the App-based, Browser-based and 3RI flows.

3.1.2 Responsibilities 3.1.2.1 ACS It is the responsibility of the ACS to indicate its active Protocol Versions that is supported for the ACS URL to each DS. How each DS manages this functionality may differ and is not within scope of the 3-D Secure specification.

3.1.2.2 DS It is the responsibility of the DS to provide the active Protocol Versions that the ACS and DS support to the 3DS Server.

  • For the DS, the DS Start Protocol Version and DS End Protocol Version data elements are used.
  • For an ACS, the ACS Start Protocol Version and ACS End Protocol Version data elements are used. 3.1.2.3 3DS Server It is the responsibility of the 3DS Server to make PReq message calls to each registered DS every 24 hours at a minimum, and once per hour at a maximum to refresh their cache of Protocol Versions for the DS and ACS supported for 3-D Secure. Note: The 3DS Server is responsible to ensure each 3-D Secure component supports the Message Version number via the Protocol Version on every 3-D Secure transaction. Otherwise, the 3-D Secure transaction will result in a Message Error. Management Identifying Which Message Version to Use of 11 3.2 3DS SDK For a 3DS SDK, the 3DS Server similarly needs to learn which Protocol Version is supported by the 3DS SDK for an In-App authentication. Guidance on how a 3DS Server could obtain the supported Protocol Version of a 3DS SDK is described below.

3.2.1 Sample Flow—3DS Server determines Protocol Version The 3DS Requestor App knows the Protocol Versions supported by the 3DS SDK during integration of a particular SDK version. This information is typically provided by the 3DS SDK vendor.

  • 3DS Requestor App sends the list of supported protocol versions to the 3DS Server (together with the Cardholder Account Number) using proprietary functions.
  • 3DS Server decides the Protocol Version used based on DS and ACS supported Protocol Versions and the SDK supported Protocol Versions.
  • 3DS Server passes back the Protocol Version to the Request App to be used along with the Directory Server ID.
  • 3DS Requestor App passes the Protocol Version and the Directory Server ID in the createTransaction method to the SDK. Note: A future specification enhancement could define a getSDKProtocolVersions interface for the ThreeDS2Service so that the 3DS Requestor App will not need to maintain the list, but instead can pass the returned value to the 3DS Server directly.

3.2.2 Sample Flow—3DS Requestor App suggests Protocol Version (Option 1) The 3DS Requestor App, using proprietary functions obtains from the 3DS Server the Directory Server ID and list of Protocol Versions supported by the DS and the ACS for the Cardholder Account Number. The 3DS Requestor App invokes the createTransaction method using the highest protocol version from the list to the SDK.

  • If the SDK supports the Protocol Version, the 3-D Secure transaction flow would be undisrupted.
  • If the SDK does not support the Protocol Version, the SDK would throw an InvalidInputException in which case the 3DS Requestor App downgrades the Protocol Version and would make the createTransaction again. This would continue until the Protocol Version is negotiated between the 3DS Requestor App and the SDK.3DS Requestor App shares the suggested Protocol Version with the 3DS Server through proprietary interfaces.

3.2.3 Sample Flow—3DS Requestor App suggests Protocol Version (Option 2) The 3DS Requestor App, using proprietary functions, obtains from the 3DS Server the Directory Server ID and list of Protocol Versions supported by the DS and the ACS for the Cardholder Account Number.

Management Identifying Which Message Version to Use

of 11

  • Because the 3DS Requestor App knows the Protocol Versions supported by the 3DS SDK during the integration of a particular SDK version, it can select the highest common Protocol Version from the list provided by the 3DS Server and the 3DS SDK.
  • The 3DS Requestor App invokes the createTransaction method using the highest common Protocol Version determined in the previous step.
  • 3DS Requestor App shares the suggested Protocol Version with the 3DS Server through proprietary interfaces. © 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.