PCI Watch

Tracking changes across the Payment Card Industry

SB nº 196: EMV® 3-D Secure Updates, Clarifications & Errata

v1.0 Specification Bulletins
3-D Secure

EMV<sup>®</sup> Specification Bulletin No. 196 October 2017 EMV 3-D Secure Updates, Clarifications & Errata This Draft Specification Bulletin No. 196 provides updates, clarifications and errata incorporated into the EMV 3-D Secure Protocol and Core Functions Specification since the October 2016 v2.0.0 publication. This Bulletin No. 196 provides updates by date for the two draft iterations, and the October 2017 final version of the specification.

Applicability

This Specification Bulletin applies to:

  • EMV 3-D Secure Protocol and Core Functions Specifications, Version 2.0.0 Updates are provided by draft date, in the order in which they appear in the specification. Deleted text is identified using strikethrough, and red font is used to identify changed text. Unedited text is provided only for context.
  • Please note that draft versions of the protocol specification released since the October 2016 v2.0.0 included the version number 2.0.1. The October 2017 version number has been updated to version 2.1.0.

Related Documents

The following publication should also be referenced for specification updates:

  • Bulletin No.190:

Requirement

Numbering Scheme and Error Processing, December, 2016 The following publications have been updated since their initial release:

  • EMV 3-D Secure SDK Specification
  • EMV 3-D Secure SDK Technical Guide
  • EMV 3-D Secure SDK—Device Information Effective Date 1 October 2017 countries. October Publication of EMV 3-D Secure Protocol and Core Functions Specifications, Version 2.1.0 Table 1. 1. Table 1. 1. 2.2. 2.2. 2.4. 2.4. 2.4. 2.5. 2.6. 3. 3. 3. countries. 3. 4. 4.2. 4.2. 4.2.3. 4.2.3. 4.2. 4.2.4. 4.2.5. 5.1. 5.1. 5.1. countries. 5.1. 5. 5.5. 5.5.2. 5.5.2. 5.5.2. 5. 5. 5.8. 5. 5.9.5. 5.9.8. 5.9. 6.1. 6.2.2. 6.2.3. 6.2.3. 6.2.3. A. A. Table A. A.5. countries. A.5. Table A. A.5. Table A. A.5. Table A. A. A.6. Table A. A.7. A.7. Table A. A.7. Table A. A.7. Table A. A.7. Table A. JSON Example—Updated to reflect Table A. A.7. Table A. JSON Example—Updated to reflect Table A. A.7. Table A. A.7. Table A. B. Table B. B. Table B. B. Table B. B. Table B. B. B. Table B. D.1 TLS Cipher Suites for TLS 1.2 D.1. D.1. countries. D.2. D. June Publication of EMV 3-D Secure Protocol and Core Functions Specifications, Version 2.0.1.Draft. 1. Table 1. 1. Table 1. 3. 3. 3. countries. 5.1. 5.1. Table 5. 5. 5.5.2. 5.5.2. 5. 5.9. 6.2.2. 6.2.2. 6.2.3. 6.2.3. 6.2.3. 6.2.4. 6.2.4. A. Table A. A.5. Table A. A.5. Table A. A.5. Table A. A. A.6. A.7. Table A. A.7. countries. Table A. A.7. Table A. A.7. Table A. Table B. Table B. Table B. Table B. Table B. D.1. D.1.2 TLS Cipher Suites 1. D.1.3 TLS Cipher Suites 1. D.2. April Publication of EMV 3-D Secure Protocol and Core Functions Specifications, Version 2.0.1 Table 1. 2.5. 3. 3. countries. 3. 4.2. 4.2.3. 4.2.5. 4.3.1. 5.1. Table 5. 5. 5.5. 5.5.2. countries. 5.5.2. 5. 5.9. 5.9.3. 5.9.3. 5. 5.9.8. 6.1. 6.1.4. 6.1.4. 6.1. 6.2.2. 6.2.2. 6.2.3. 6.2.4. 6.2.4. 6.2.4. 6.2.4. Table A. A.5. Table A. A.5. Table A. A. Table A. A. A.7. Table A. A.7. Table A. A.7. countries. Table A. A.7. Table A. A.7. Table A. A.7. Table A. countries. October Publication of EMV 3-D Secure Protocol and Core Functions Specifications, Version 2.1.0 Throughout specification: Updated all instances of:
  • "2.0.1" to "2.1.0"
  • "base64" to "base64url"
  • "standard TLS" to "TLS"
  • "PCI DSS" to "Payment System security requirements" Chapter 1

Introduction

Table 1.3: Definitions (New and Updated)

  • 3DS Requestor Initiated (3RI)
  • Ends processing
  • Message Version
  • Preparation Request (PReq) Message
  • Preparation Response (PRes) Message
  • Protocol Version
  • Base64url 1.7 3-D Secure Message Protocol Version Number The following table provides the Message Protocol Version Number status for the 3-D Secure Protocol and Core Functions Specification. Table 1.5 Message Protocol Version Number 1.8 Supporting Documentation These documents as well as EMV 3-D Secure FAQS are located on the EMVCo website under the 3-D Secure heading.
  • EMV 3-D Secure JSON Message Samples
  • EMV 3-D Secure Best Practices—User Interface Chapter 2 EMV 3-D Secure Overview 2.2.1 Directory Server
  • Maintaining ACS and DS Start and End Protocol Versions versions and 3DS Method URLs 2.2.2 Directory Server Certificate Authority
  • Signing certificates used to sign messages passed from the ACS to the 3DS SDK and from the ACS to the 3DS Server countries.

2.4.7 Preparation Request Message (PReq) The PReq message is sent from the 3DS Server to the DS to request information about the Protocol Version Number(s) version supported by available ACSs and the DS and if one exists, any corresponding 3DS Method URL.

2.4.8 Preparation Response Message (PRes) The 3DS Server can utilise the PRes message to cache information about the Protocol Versions supported by available ACSs and the DS, and if one exists, about the corresponding 3DS Method URL.

2.4.9 Error Message Error messages provide additional information about an error that occurred during message processing between the 3DS Server, the DS, the ACS, and the 3DS SDK.

2.5.3 Processing Payment EMV Payment Tokens Added section number and title to existing Note. 2.6.2 3DS Requestor Environment—Browser-based 1.1 3DS Requestor and 3DS Server—The 3DS Requestor communicates with the 3DS Server. The 3DS Server determines the ACS and DS Start and End Protocol Versions and, if present obtains the 3DS Method URL for the requested card range and returns the information to the 3DS Requestor. The ACS version and DS Protocol Versions and 3DS Method URL data was previously received by the 3DS Server via a PRes message. Chapter 3 EMV 3-D Secure Authentication Flow Requirements 3.1 App-based Requirements Step 2 The 3DS Requestor App The 3DS Requestor App provides to the SDK the:

  • the Directory Server ID value (which is the Payment System’s RID), and
  • Message version (obtained from the 3DS Requestor Environment) and obtains the:
  • the SDK Transaction ID,
  • SDK App ID, and the
  • Device Information, and.
  • Protocol Version (Version used by the SDK for this transaction) Note: If the message version is null, the SDK will utilise the highest version of the protocol that it supports. If the message version is present, the SDK will utilise that version of the protocol (assuming the SDK supports the version), otherwise the SDK will error. Step 5 The 3DS Server Note: The 3DS Server can use the ACS Start Protocol Version, ACS End Protocol Version, DS Start Protocol Version and DS End Protocol Version obtained from the PRes message to verify that the ACS and DS support the protocol version used by the 3DS Server. [Req 18] Check that the Message Version Number is supported by the DS and the ACS. countries.
  • If not, the DS returns to the 3DS Server EITHER an:
  • ARes message (as defined in Table B.2) with Transaction Status set to the appropriate response as defined by the specific DS and ends processing, OR [Req 23] If the connection cannot be established with the ACS then the DS returns to the 3DS Server a message as specified proceeds as specified in [Req 233] and ends processing.EITHER an: ARes message (as defined in Table B.2) with Transaction Status set to the appropriate response as defined by the specific DS and ends processing. Error Message (as defined in Section A.5.5) with Error Component = D and Error Code = 405 with detailed information about the issue in the Error Description and ends processing. [Req 24] If the DS does not receive an ARes message from the ACS (as defined in Section 5.5), the DS returns to the 3DS Server a message as specified in [Req 235] and ends processing. Step 7 ACS Note: The ACS uses the Device Information received in the AReq message to recognise the device, assess transaction risk, and determine if it can complete the authentication with this device. [Req 318] The ACS shall not initiate an interaction with the Cardholder as part of a Frictionless transaction. Cardholder interaction shall be done as part of a Challenge flow. [Req 32] If a challenge is deemed necessary (Transaction Status = C), the ACS determines whether an acceptable challenge method is supported by the 3DS SDK based in part on the following data elements received in the AReq message: Device Channel, Device Rendering Options Supported, and SDK Maximum Timeout. [Req 305]
  • If the ACS Server Reference Number does not represent a participating ACS Server the DS shall:
  • Return to the 3DS Server an Error Message (as defined in Section A.5.5) with Error Component = D and Error Code = 303 and ends processing, OR
  • Send an ARes message to the 3DS server (as defined in Table B.2) with Transaction Status set to the appropriate response as defined by the specific DS. [Req 40] Evaluate based in part on the 3DS Requestor Challenge Indicator, the ACS Challenge Mandated Indicator and the ACS Rendering Type preferencewhether to perform the requested challenge.
  • If the 3DS Requestor continues without performing the requested challenge, receive the RReq message from the DS and Validate as defined in Section 5.9.9. If the message is in error, the 3DS Server ends processing. Format the RRes message as defined in Table B.9 and send to the DS. Further processing is outside the scope of 3-D Secure processing. [Req 64] If the Cardholder abandons the challenge during the processing of Step 16 and Step 17, or if the ACS receives an abandonment CReq message from the 3DS SDK (as defined in [Req 60]), then the ACS sets the Challenge Completion Indicator = Y in the CRes message and sets the Challenge Cancellation Indicator to the appropriate value in the RReq message. countries.

3.2 Challenge Flow with OOB Authentication Requirements Step 17 If the ACS determines the cardholder did not authenticate, it can update the cardholder instructions through another CRes message. When a Cardholder returns to the 3DS Requestor App from another app, the ACS can also utilise the Challenge Additional Info Text element (for the Native UI) or the ACS HTML Refresh element (for the HTML UI) to improve the UI experience. In this scenario, the SDK will automatically display these data elements when the 3DS Requestor App is moved to the foreground. Note: The 3DS Requestor should consider that an OOB authentication can take longer for the Consumer to complete and therefore should adjust the SDK’s challenge time-out accordingly.

3.3 Browser-based Requirements Step 2 3DS Server/3DS Requestor The 3DS Requestor uses the Cardholder Account Number and optionally other cardholder information to request the ACS Start Protocol Version, ACS End Protocol Version, DS Start Protocol Version, and DS End Protocol Version Message Version Number and if present, the 3DS Method URL for that BIN range from the 3DS Server. [Req 80] Retrieve the ACS Start Protocol Version and ACS End Protocol Version, DS Start Protocol Version and DS End Protocol Version Message Version Number, and, if present, the 3DS Method URL (stored from a previously received PRes message) for that BIN range. [Req 82] Pass the 3DS Server Transaction ID, ACS Start Protocol Version and ACS End Protocol Version, DS Start Protocol Version and DS End Protocol Version Message Version Number and if present, the 3DS Method URL back through the 3DS Requestor Environment to the 3DS Requestor. If the DS Start Protocol Version and DS End Protocol Version are not present for the BIN range, then the default values for the DS Start Protocol Version and DS End Protocol Version located in the PRes message shall be utilised. [Req 95] Check that the Message Version Number is supported by the DS and the ACS.

  • If not, the DS returns to the 3DS Server EITHER an:
  • ARes message (as defined in Table B.2) with Transaction Status set to the appropriate response as defined by the specific DS and ends processing, OR [Req 100] If the connection cannot be established with the ACS then the DS returns to the 3DS Server a message as specified proceeds as specified in [Req 233] and ends processing.EITHER an: ARes message (as defined in Table B.2) with Transaction Status set to the appropriate response as defined by the specific DS and ends processing. Error Message (as defined in Section A.5.5) with Error Component = D and Error Code = 405 with detailed information about the issue in the Error Description and ends processing. countries. [Req 101] If the DS does not receive an ARes message from the ACS (as defined in Section 5.5), the DS returns to the 3DS Server a message as specified in [Req 235] and ends processingEITHER an: ARes message (as defined in Table B.2) with Transaction Status set to the appropriate response as defined by the specific DS and ends processing, OR Error Message (as defined in Section A.5.5) with Error Component = D and Error Code = 402 with detailed information about the issue in Error Description and ends processing. [Req 319] The ACS shall not initiate an interaction with the Cardholder as part of a Frictionless transaction. Cardholder interaction shall be done as part of a Challenge flow. [Req 109] If a challenge is deemed necessary, (Transaction Status = C) the ACS determines whether an acceptable challenge method is supported by the 3DS Server considering the 3DS Requestor Challenge Indicator based on the Device Channel data element received in the AReq message. [Req 306]
  • If the ACS Server Reference Number does not represent a participating ACS Server the DS shall:
  • Return to the 3DS Server an Error Message (as defined in Section A.5.5) with Error Component = D and Error Code = 303 and ends processing, OR
  • Send an ARes message to the 3DS server (as defined in Table B.2) with Transaction Status set to the appropriate response as defined by the specific DS. [Req 117] a. Evaluate based in part on the 3DS Requestor Challenge Indicator, the ACS Challenge Mandated Indicator and the ACS Rendering Type preference whether to perform the requested challenge.
  • If the 3DS Requestor continues without performing the requested challenge, receive the RReq message from the DS and Validate as defined in Section 5.9.9. If the message is in error, the 3DS Server ends processing. Format the RRes message as defined in Table B.9 and send to the DS. d. Construct a form containing the CReq message, and optionally if provided by the 3DS Requestor, the 3DS Requestor Session Data (as defined in Table A.3). New Note following [Req 118] Note: ACS implementations that use JavaScript or redirection must also support a fall-back for environments that do not support JavaScript. [Req 140] Send the final CRes message via an HTTP POST (for example, utilising JavaScript) through the browser to the Notification URL that was sent in the initial CReq AReq message using the secure link established in Step 10. Step 22 Note: The 3DS Requestor should notify their 3DS Server and DS if invalid CRes messages are being received. countries. 3.4 3RI-based Requirements 3RI-based implementations shall support only Non-Payment Authentication (NPA) transactions. [Req 280] Check that the Message Version Number is supported by the DS and the ACS.
  • If not, the DS returns to the 3DS Server EITHER an:
  • ARes message (as defined in Table B.2) with Transaction Status set to the appropriate response as defined by the specific DS and ends processing, OR [Req 285] If the connection cannot be established with the ACS then the DS returns to the 3DS Server a message as specified proceeds as specified in [Req 233] and ends processing.EITHER an: ARes message (as defined in Table B.2) with Transaction Status set to the appropriate response as defined by the specific DS and ends processing. Error Message (as defined in Section A.5.5) with Error Component = D and Error Code = 405 with detailed information about the issue in the Error Description and ends processing. [Req 286]
  • If the DS does not receive an ARes message from the ACS (as defined in Section 5.5), the DS returns to the 3DS Server a message as specified in [Req 235] and ends processing. [Req 291]
  • not authenticated because the Issuer is rejecting authentication and requesting that authorisation not be attempted (Transaction Status = R) [Req 292]
  • For a Payment Authentication (Message Category = 01-PA), the ECI value and Authentication Value may be generated and included in the ARes message as defined by the DS. [Req 308]
  • If the ACS Server Reference Number does not represent a participating ACS Server the DS shall:
  • Return to the 3DS Server an Error Message (as defined in Section A.5.5) with Error Component = D and Error Code = 303 and ends processing, OR
  • Send an ARes message to the 3DS server (as defined in Table B.2) with Transaction Status set to the appropriate response as defined by the specific DS. Chapter 4 EMV 3-D Secure UI Templates, Requirements, and Guidelines 4.1 3-D Secure User Interface Templates Note Activation During Shopping (ADS) is not a supported UI template within the 3-D Secure specification. countries. Note: Cardholder Terms and Conditions is not supported within 3-D Secure UI templates unless regulatory requirements mandate such inclusion during cardholder payment authentication. [Req 314] All Device Rendering Options supported shall be supported by the SDK and ACS components.

4.2.1 Processing Screen Requirements New Figure:

  • Figure 4.5: Sample OOB Template—App-based Processing Flow
  • Figure 4.12: Sample Challenge Additional Information Text—PA *Subsequent Figures are renumbered. Notes: If the Cardholder has been authenticated, then the Cardholder is returned to the merchant. If the Cardholder has not authenticated, then the UI is updated to reinforce the expected Cardholder action.

4.2.2 Native UI Templates Details of the UI rendering process through an SDK are separately described in the EMV 3-D Secure SDK—ImplementationTechnical Guide. The use of a carriage return in any UI data element is permitted only as specified in Table A.1. While the issuer provides the content for the UI, the SDK is responsible for rendering the content. As such, the SDK has the ability to fine tune the UI to best display on the cardholder device. With the SDK’s knowledge of the device screen size, font size, etc., the SDK can optimise the content provided by the issuer (for example, by removing an extra line feed that would cause scrolling). Issuers should understand that the formatting provided in the CRes message may not be exactly what is displayed to the cardholder. Updated Figures:

  • Figure 4.4: Sample OTP/Text Template—App-based Processing Flow
  • Figure 4.6: Sample Native UI OTP/Text Template—PA
  • Figure 4.8: Sample Native UI—Single-select Information—PA
  • Figure 4.9: Sample Native UI—Multi-select Information—PA
  • Figure 4.10: Sample OOB Native UI Template—PA
  • Figure 4.11: Sample Challenge Information Text Indicator—PA 4.2.3.1 3DS SDK [Req 316] When Challenge Additional Information Text is present, the SDK would replace the Challenge Information Text and Challenge Information Text Ind

Shown in part. Read the original for the full text.