PCI Watch

Tracking changes across the Payment Card Industry

SB n° 207: EMV® 3-D Secure Updates, Clarifications & Errata

v1.0 Specification Bulletins
3-D Secure

EMV<sup>®</sup> Specification Bulletin No. 207 December 2018 EMV<sup>®</sup> 3-D Secure Updates, Clarifications & Errata This Specification Bulletin No. 207 provides updates, clarifications and errata incorporated into the EMV 3-D Secure Protocol and Core Functions Specification since version 2.1.0 (including SB 204v4). EMV<sup>®</sup> 3-D Secure Key Features v2.2.0 This Specification Bulletin No. 207 introduces new 3-D Secure features included in version 2.2.0 of the 3-D Secure Protocol and Core Functions Specification. These features include:

  • Additional support for upcoming PSD2 Regulation (Whitelisting and Acquirer Exemptions)
  • Support for 3RI Payments
  • Introduction of a new Authentication Method: Decoupled Authentication
  • Enhancements for OOB User Experiences—Note: These enhancements are only partially described in this bulletin (i.e., the addition of the 3DS Requestor App URL). As these enhancements have SDK impact, they will be fully described and reflected in the EMV 3-D Secure SDK specification version 2.2.0.

Applicability

This Specification Bulletin applies to:

  • EMV<sup>®</sup> 3-D Secure Protocol and Core Functions Specifications, Version 2.2.0 Updates are provided 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. countries. EMV<sup>®</sup> 3-D Secure Key Features v2.2.0. Table 1. 1. Table 1. 1. Table 1. 2.3. 2.4. 2.4. 2.4. 2.4. 2.5. 2. 3. countries. 3. 3. 3. Figure 3. countries. 4. 4.2. 4.2.1. 4.2.2. Figure 4. Figure 4. countries. 4.2. Figure 4. 4.2. 4.2.5. 4.2. 4.3. 4.3.1. 4.3. 4.3.2. 4.3. 4. 5.1. 5.1. 5.1. 5. 5.9.3. 5.9.3. 5.9. 5.9. 6.2.2. A. Table A. A.5. A.5. Table A. A.5. countries. Table A. A.7. Table A. A.7. Table A. A.7. Table A. A.7. Table A. A. Table A. B. Table B. B. Table B. B. Table B. B. Table B. B. Table B. B. Table B. D.1.1 Cipher Suites for TLS 1.2 countries. Chapter 1

Introduction

The 3-D Secure authentication protocol supports two Message Categories:

  • Non-Payment Authentication—Identity verification and account confirmation.
  • Confirmation of Account—Verification of Account The 3-D Secure authentication protocol can be initiated through three Device Channels:
  • 3DS Requestor Initiated—Confirmation of account information and Cardholder authentication with no direct Cardholder present. For example, a subscription-based ecommerce merchant confirming that an account is still valid or Cardholder authentication when the 3DS Requester and the ACS utilises Decoupled Authentication.

1.3 Normative

References

Table 1.1 Normative References Reference Publication Name Bookmark RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 https://tools.ietf.org/ht ml/rfc5246 RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3 https://tools.ietf.org/ht ml/rfc8446

countries.

1.5

Definitions

Table 1.3 Definitions Term Definition 3DS Requestor Initiated (3RI) 3-D Secure transaction initiated by the 3DS Requestor for the purposes of confirming that an account is still valid or for Cardholder authentication. The first main use case being recurrent transactions (TV subscriptions, utility bill payments, etc.) where the merchant wants to perform a payment transaction to receive authentication data for each bill or a non-payment transaction to verify that a subscription user still has a valid form of payment. The second main use case is when the 3DS Requestor requests Decoupled Authentication as a method to authenticate the Cardholder. Base64URL Encoding applied to the 3DS Method Data, Device Information and the CReq/CRes messages as defined in RFC 7515. Decoupled Authentication Decoupled Authentication is an authentication method whereby authentication can occur independent from the cardholder’s experience with the 3DS Requestor. The authentication method used for Decoupled Authentication is outside the scope of this specification, however one method could be a push notification to a banking app that completes authentication and then sends the results to the ACS. Decoupled Authentication is applicable to all Device Channels. Information Only Information Only is a Transaction Status value, whereby the ACS acknowledges the 3DS Requestor’s preference to not challenge on the transaction since the data sent was only for informational purposes. Whitelisting In this specification, the process of an ACS enabling the cardholder to place the 3DS Requestor on their trusted beneficiaries list. 1.7 3-D Secure Protocol Version Number Table 1.5 Protocol Version Numbers Reference Publication Name 2.2.0 Active

countries.

Chapter 2 EMV 3-D Secure Overview 2.3.4 Access Control Server The ACS contains the authentication rules and is controlled by the Issuer. ACS functions include:

  • Authenticating the Cardholder for a specific transaction
  • Authenticating the Cardholder or confirming account information for a 3RI transaction 2.4.5 Results Request Message (RReq) The RReq message communicates the results of the authentication or verification. The message is sent by the ACS through the DS to the 3DS Server. There is only one RReq message per authenticationAReq message. The RReq message is not present only in an a authentication requiring a Cardholder challengeFrictionless transaction.

2.4.6 Results Response Message (RRes) There is only one RRes message per RReq messageauthentication. The RRes message is present only in an authentication requiring a Cardholder challenge.

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) supported by available ACSs and the DS and if one exists, any corresponding 3DS Method URL. This message is not part of the 3-D Secure authentication message flow.

2.4.8 Preparation Response Message (PRes) The PRes message is the DS response to the PReq message. The 3DS Server can utilise the PRes message to cache information about the Protocol Version(s) supported by available ACSs and the DS, (for example, about which Protocol Version(s) are supported).and if one exists, about the corresponding 3DS Method URL. This message is not part of the 3-D Secure authentication message flow.

2.5.2 Challenge Flow In addition to the AReq and ARes messages that comprise the Frictionless flow, the Challenge flow consists of completes with the CReq, CRes, RReq, and RRes messages. The Challenge flow also includes CReq and CRes messages except in the case of Decoupled Authentication.

2.7 Challenge Flow Outline 6

ACS to 3DS Client Note: For Decoupled Authentication, instead of utilising the CReq and CRes messages, the ACS authenticates the cardholder outside of the EMV 3DS protocol.

countries.

Chapter 3 EMV 3-D Secure Authentication Flow Requirements 3.1 App-based Requirements Added Note following Figure 3.1: Note: For a Decoupled Authentication challenge, instead of utilising the CReq and CRes messages (Steps 10 through 17 and Step 23), the ACS authenticates the cardholder outside of the EMV 3DS protocol. The Decoupled Authentication flow is portrayed in Figure 3.4 and outlined below. Step 5 The 3DS Server Updated Note following Req. 14: Note: In addition, the 3DS Server can use the ACS Information Indicator to identify the features that the Account Range supports (for example, Decoupled Authentication and/or Whitelisting). Step 7 The ACS [Req 26] Check whether the Consumer Device is supported unless transaction will be processed as a Decoupled Authentication. If device not supported, the ACS returns to the DS an ARes message with a Transaction Status = U and Transaction Status Reason code = 03 and ends processing. Updated Note following Req 26: 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. Added Note following Req 26: Note: When Decoupled Authentication is utilised, the consumer device that initiated the transaction does not need to be supported when the ACS has alternative approaches to authenticating the Cardholder. [Req 29] Use the values of the 3DS Requestor Challenge Indicator, the 3DS Requestor Authentication Indicator and the 3DS Requestor Decoupled Requestor Indicator received in the AReq message when evaluating the transaction disposition as defined in [Req 30]. [Req 30] Evaluate the values received in the AReq message and determine whether the transaction is:

  • requiring a Cardholder challenge using Decoupled Authentication (Transaction Status = D)
  • authentication not requested by the 3DS Server for data sent for informational purposes only (Transaction Status = I) [Req 321] If a Decoupled Authentication challenge is deemed necessary (Transaction Status = D), the ACS determines whether an acceptable challenge method is supported by the ACS based in part on the following data element received in the AReq message: 3DS Requestor Decoupled Max Time. The ACS performs the following: a. Sets the Transaction Status = D for Decoupled Authentication. b. Sets the ACS Decoupled Confirmation Indicator = Y. c. Stores the 3DS Server Transaction ID and DS Transaction ID (for subsequent RReq processing). countries. [Req 322] For a Decoupled Authentication transaction, (Transaction Status = D), do the following asynchronous process: a. Start timer against the 3DS Requestor Decoupled Max Time. b. Authenticate the cardholder. How an authentication decision is made is outside the scope of this specification, however the ACS objective is to complete the Cardholder authentication before the 3DS Requestor Decoupled Max Time expires. Step 8: The DS [Req 37] Send the ARes message to the 3DS Server as received from the ACS using the secure link established in [Req 12]. Step 9: The 3DS Server [Req 323] For a Decoupled Authentication transaction (Transaction Status = D), send necessary information (as defined in Table B.2) from the ARes message to the 3DS Requestor Environment. [Req 355] If the Cardholder Information Text has been provided by the ACS for this transaction the 3DS Server shall ensure the Cardholder Information Text is displayed on the 3DS Requestor website. New and updated Notes at the end of Step. Note: The next step for:
  • Decoupled Authentication transaction, the next step is Step 18
  • Challenge Flow is Step 10 (Step 10 through Step 23 and the first requirement of Step 24 are applicable only for a Challenge Flow [Transaction Status = C]). Note: For a Decoupled Authentication transaction, as defined in [Req 345], the 3DS Server is now expected to wait for the ACS to authenticate the Cardholder at which time the ACS will send an RReq message. Step 11: The 3DS Requestor Environment [Req 45] If the content protection fails, the SDK reports the error to the 3DS Requestor App and ends 3-D Secure processing. Step 13: The ACS [Req 52] If the content protection fails the ACS ends 3-D Secure processing. Step 16: The 3DS SDK [Req 57] If the content protection fails, the SDK reports the error to the 3DS Requestor App and ends 3-D Secure processing. countries. Step 18: The ACS Updated Step introduction (applicable to all requirements in step): The ACS shall for all Challenge flow transactions (ARes Transaction Status = C) and for Decoupled Authentication transactions (ARes Transaction Status = D) once the authentication as defined in [Req 322].b has completed or the timer as defined in [Req 322].a has expired do the following: [Req 66] Ensure that one RReq message is sent to the DS for each ARes message with a Transaction Status = C or D. [Req 345] Ensure for a Decoupled Authentication transaction that:
  • An RReq message is sent immediately upon obtaining an authentication result (whether successful or not).
  • An RReq message without an authentication result is sent when the 3DS Requestor Decoupled Max Time expires—with a grace period of 1 hour. Step 20 The 3DS Server [Req 346] For a Decoupled Authentication transaction, at a minimum wait the specified 3DS Requestor Decoupled Max Time plus 30 seconds for the RReq message. If an RReq message is never received, further processing is outside the scope of 3- Secure processing. Note: If the RReq message is not received, then the 3DS Server should assume that the Decoupled Authentication is not successful. Step 22 The ACS New Note following [Req 75]: Note: 3-D Secure processing completes for Decoupled Authentication transactions. Step 23: The ACS Updated Step introduction (applicable to all requirements in Step): The ACS shall for a Challenge flow transaction (ARes Transaction Status = C) (as a continuation of receiving the CReq message in Step 17), do the following: [Req 76] If the content protection fails the ACS ends 3-D Secure processing. Step 24 The 3DS Requestor Environment Updated Step introduction (applicable to all requirements in Step): The 3DS SDK shall for a Challenge flow transaction (ARes Transaction Status = C):

3.2 Challenge Flow with OOB Authentication Requirements Step 17: (2nd paragraph) When a Cardholder returns to the 3DS Requestor App from another an OOB app on the same device, further Cardholder action will not be required to complete the authenticationthe 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 elementspost a CReq message when the 3DS Requestor App is moved to the foreground.

countries.

Note: OOB authentication as defined in this section is a sperate authentication flow from the Decoupled Authentication flow.

3.3 Browser-based Requirements Added after Figure 3.3: Note: For a Decoupled Authentication challenge, instead of utilising the CReq and CRes messages (Steps 11 through 15 and Step 21), the ACS authenticates the cardholder outside of the EMV 3DS protocol. The Decoupled Authentication flow is portrayed in Figure 3.4 and outlined below. Step 6: The 3DS Server Added Note after Req 92: 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. In addition, the 3DS Server can use the ACS Information Indicator to identify the features that the Account Range supports (for example, Decoupled Authentication and/or Whitelisting). Step 8 The ACS Added Note after Req 103: Note: The ACS uses the Device Information received in the AReq message and the 3DS Method to recognise the device, assess transaction risk, and determine if it can complete the authentication. When Decoupled Authentication is utilised, the consumer’s device that initiated the transaction does not need to be supported when the ACS has alternative approaches to authenticating the Cardholder. [Req 106] Use the values of the 3DS Requestor Challenge Indicator, the 3DS Requestor Authentication Indicator and the 3DS Requestor Decoupled Requestor Indicator received in the AReq message when evaluating the transaction disposition as defined in [Req 107]. [Req 107] Evaluate the values received in the AReq message and determine whether the transaction is:

  • requiring a Cardholder challenge using Decoupled Authentication (Transaction Status = D)
  • authentication not requested by the 3DS Server for data sent for informational purposes only (Transaction Status = I) [Req 325] If a Decoupled Authentication challenge is deemed necessary (Transaction Status = D), the ACS determines whether an acceptable challenge method is supported by the ACS based in part on the following data element received in the AReq message: 3DS Requestor Decoupled Max Time. The ACS performs the following: a. Sets the Transaction Status = D for Decoupled Authentication. b. Sets the ACS Decoupled Confirmation Indicator = Y. c. Stores the 3DS Server Transaction ID and DS Transaction ID (for subsequent RReq processing). [Req 326] For a Decoupled Authentication transaction, (Transaction Status = D), do the following asynchronous process: a. Start timer against the 3DS Requestor Decoupled Max Time. countries. b. Authenticate the cardholder. How an authentication decision is made is outside the scope of this specification, however the ACS objective is to complete the Cardholder authentication before the 3DS Requestor Decoupled Max Time expires. Step 9: The DS [Req 114] Send the ARes message to the 3DS Server as received from the ACS using the secure link established in [Req 100]. Step 10 The 3DS Server [Req 327] For a Decoupled Authentication transaction (Transaction Status = D), send necessary information (as defined in Table B.2) from the ARes message to the 3DS Requestor Environment. [Req 356] If the Cardholder Information Text has been provided by the ACS for this transaction the 3DS Server shall ensure the Cardholder Information Text is displayed on the 3DS Requestor website. Note: The next step for:
  • Decoupled Authentication transaction is Step 16. Note: For a Decoupled Authentication transaction, as defined in [Req 347], the 3DS Server is now expected to wait for the ACS to authenticate the Cardholder at which point in time the ACS will send an RReq message. Step 16 The ACS Updated Step introduction (applicable to all requirements in Step): The ACS shall for all Challenge Flow transactions (ARes Transaction Status = C) and for a Decoupled Authentication transaction (ARes Transaction Status = D) once the authentication as defined in [Req 326].b has completed or the timer as defined in [Req 326].a has expired, do the following: [Req 128] Ensure that one RReq message is sent to the DS for each ARes message with a Transaction Status = C or D.Send one RReq message to the DS for each ARes message with an ARes Transaction Status = C. [Req 347] Ensure that or a Decoupled Authentication transaction that:
  • An RReq message is sent immediately upon obtaining an authentication result (whether successful or not).
  • An RReq message without an authentication result is sent when the 3DS Requestor Decoupled Max Time expires—with a grace period of 1 hour. Step 18 The 3DS Server [Req 348] For a Decoupled Authentication transaction, at a minimum wait the specified 3DS Requestor Decoupled Max Time plus 30 seconds for the RReq, If an RReq message is never received, further processing is outside the scope of 3-D Secure processing. Note: If the RReq message is not received, then the 3DS Server should assume that the Decoupled Authentication is not successful. countries. Step 20 The ACS Note: 3-D Secure processing completes for Decoupled Authentication transactions. Step 21 The ACS Updated Step introduction (applicable to all requirements in Step): The ACS shall for a Challenge Flow transaction (ARes Transaction Status = C) (as a continuation of receiving the CReq message in Step 11): do the following: 3.4 3RI-based Requirements 3RI-based implementations shall support only Non-Payment Authentication (NPA) transactions.The 3RI flow supports two primary main use cases: confirmation of account information (accomplished through Steps 1–6) and Cardholder authentication (accomplished through Steps 1–13). Figure 3.4: 3-D Secure Processing Flow Steps—3RI-based (Updated) Step 2: The 3DS Server Added Note at end of Step: 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. In addition, the 3DS Server can use the ACS Information Indicator to identify the features that the Account Range supports (for example, Decoupled Authentication and/or Whitelisting). countries. Step 4 The ACS [Req 290] Use the values of the 3RI Indicator, the 3DS Requestor Decoupled Requestor Indicator and the 3DS Requestor Prior Transaction Authentication Information received in the AReq message when evaluating the transaction disposition as defined in [Req 291]. [Req 291] Evaluate the values received in the AReq message and determine whether the 3RI transaction is:
  • requiring a Cardholder challenge using Decoupled Authentication (Transaction Status = D)
  • authentication not requested by the 3DS Server for data sent for informational purposes only (Transaction Status = I) [Req 292] If a transaction is deemed authenticated (Transaction Status is = Y or A) then the ACS performs the following:
  • For a Payment Authentication (Message Category = 01-PA), the ACS shall:
  • Generate the ECI value and Authentication Value and include in the ARes message as defined by the specific Payment System. [Req 328] If a Decoupled Authentication challenge is deemed necessary (Transaction Status = D), the ACS determines whether an acceptable challenge method is supported by the ACS based in part on the following data element received in the AReq message: 3DS Requestor Decoupled Max Time. The ACS performs the following: a. Sets the Transaction Status = D (Decoupled Authentication) b. Sets the ACS Decoupled Confirmation Indicator = Y c. Stores the 3DS Server Transaction ID and DS Transaction ID (for subsequent RReq message processing). Step 5: The DS [Req 297] Send the ARes message to the 3DS Server as received from the ACS using the secure link established in [Req 275]. Step 6 The 3DS Server [Req 357] If the Cardholder Information Text has been provided by the ACS for this transaction the 3DS Server shall ensure the Cardholder Information Text is conveyed on the 3DS Requestor website. Note: 3-D Secure processing completes for non-Decoupled Authentication transactions. Note: For a Decoupled Authentication transaction, as defined in [Req 353], the 3DS Server is now expected to wait for the ACS to authenticate the Cardholder at which point in time the ACS will send an RReq message. Step 7 The ACS The ACS shall: countries. [Req 330] For a Decoupled Authentication transaction (Transaction Status = D), do the following: a. Start a timer against the 3DS Requestor Decoupled Max Time b. Authenticate the Cardholder. How an authentication decision is made is outside the scope of this specification, however the ACS objective is to complete the Cardholder authentication before the 3DS Requestor Decoupled Max Time expires. Step 8 The ACS The ACS shall for a Decoupled Authentication transaction (initial Transaction Status = D) once the authentication as defined in [Req 330].b has completed, or the timer as defined in [Req 330].a has expired, do the following: The ACS shall: [Req 349] Format the RReq message as defined in Table B.8. [Req 350] Establish a secure link with the DS as defined in Section 6.1.3.2. [Req 351] Send the RReq message to the DS. [Req 352] Ensure that one RReq message is sent to the DS for each ARes message with a Transaction Status = D. [Req 353] Ensure that:
  • An RReq message is sent immediately upon obtaining an authentication result (whether successful or not).
  • An RReq message without an authentication result is sent when the 3DS Requestor Decoupled Max Time expires—with a grace period of 1 hour. Step 9 The DS The DS shall: [Req 332] Receive the RReq message from the ACS and Validate as defined in section 5.9.8. If the message is in error the DS ends processing. [Req 333] Establish a secure link with the 3DS Server as defined in section 6.1.2.2 using the 3DS Server URL extracted from the AReq message. [Req 334] Send the RReq message to the 3DS Server using the secure link established in [Req 333]. Step 10 and Step 11 The 3DS Server The 3DS Server shall: countries. [Req 335] Receive the RReq message or Error Message from the DS and Validate as defined in section 5.9.9. If the message is in error, the 3DS Server ends processing. [Req 336] Format the RRes message as defined in Table B.9 and send to the DS using the secure link established in [Req 333]. [Req 354] For a Decoupled Authentication transaction, at a minimum wait the specified 3DS Requestor Decoupled Max Time plus 30 seconds for the RReq. If an RReq message is never received, further processing is outside the scope of 3-D Secure processing. Note: If the RReq message is not received, then the 3DS Server should assume that the Decoupled Authentication is not successful. [Req 337] Convey the appropriate response to the 3DS Requestor. Step 12 The DS The DS shall: [Req 338] Receive the RRes message or Error Message from the 3DS Server and Validate as defined in section 5.9.10. If the message is in error the DS ends processing. [Req 339] Log the transaction information as required by the DS. [Req 340] Send the RRes message to the ACS as received from the 3DS Server using the secure link established in [Req 333]. Step 13 The ACS The ACS shall: [Req 341] Receive and log the RRes message or Error Message from the DS and Validate as defined in section 5.9.11. If the message is in error the ACS ends processing. Note: 3-D Secure processing completes. countries. Chapter 4 EMV 3-D Secure User Interface Templates, Requirements, and Guidelines This chapter provides requirements, template examples, and guidelines for building the User Interface (UI) to support 3-D Secure authentication for both App-based and Browser-based implementations. 4.1 3-D Secure User Interface Templates Note: The user interface provided by the ACS for Decoupled Authentication is outside the scope of the EMV 3-D Secure protocol. The 3DS SDK shall: [Req 314] All Device Rendering Options supported shall be supported by the SDK and ACS components. Support all Device Rendering Options. [Req 358] For the Native UI Type, display UI data elements provided by the ACS within the applicable zones as defined in Table A.18 and depicted in Figure 4.1. The ACS shall: [Req 342] Support at least one Native Device Rendering Option and HTML. [Req 359] For the App-based HTML UI Type and Browser-based UI, create HTML with form UI data elements within the applicable zones as outlined defined in Table A.18 and depicted in Figure 4.1. The expected format is outlineddepicted in sections 4.2.6 and 4.3.3.

4.2.1 Processing Screen Requirements [Req 360] Display the Cancel action in the top right corner of the Header zone. [Req 361] Display the Cancel action in the top right corner of the Header zone.

countries.

New Figure 4.7. Note subsequent figures were renumbered accordingly. Figure 4.7: Sample Decoupled Authentication Template—App-based Processing Flow Notes:

  • For Decoupled Authentication, the UI provided by the ACS for cardholder authentication is out of scope of the EMV 3-D Secure specifications. 4.2.1.1 3DS SDK/3DS Requestor App Figure 4.6 provides a sample format for the Out of Band template and 3DS Requestor App on the same device for an App-based processing flow. 4.2.2.1 3DS SDK/ACS [Req 362] For the ACS UI Type, display the supported UI data elements in their applicable zones and order as defined in Table A.18 and depicted in Figure 4.1. The expected format is depicted in sections 4.2.3 and 4.2.6. If the SDK receives an unsupported UI data element(s) for this ACS UI Type, the 3DS SDK does not display the UI data elements, proceeds with the challenge and does not send an error message to the ACS. [Req 369] Display the Cancel action in the top right corner of the header zone as depicted in Figure 4.1. [Req 387] Only include the UI data elements supported for the selected ACS UI Type as defined in Table A.18. countries. Figure 4.6 Sample OOB Template (OOB App and 3DS Requestor App on same device)—Appbased Processing Flow Updated Graphic Figure 4.7 Sample Decoupled Authentication Template—App-based Processing Flow Updated Graphic countries.

4.2.3 Native UI Templates Figure 4.14 Sample Challenge AdditionalWhitelisting Information Text—PA Updated Graphic 4.2.4 Native UI Message Exchange Requirements [Req 316] When Challenge Additional Information Text is present, the SDK would replace the Challenge Information Text and Challenge Information Text Indicator with the Challenge Additional Information Text when the 3DS Requestor App is moved to the foreground. 4.2.5.1 3DS SDK/ACS [Req 373] Display the Cancel action in the top right corner of the header zone as depicted in Figure 4.1. [Req 374] Create HTML with the UIform elements in the applicable zones as defined in Table A.18 and depicted outlined in Figure 4.1. The expected format is depicted outlined in section 4.2.6.

countries.

4.2.7 HTML Message Exchange Requirements [Req 317] When the ACS HTML Refresh element is present, the SDK replaces the ACS HTML with the contents of ACS HTML Refresh when the 3DS Requestor App is moved to the foreground.

4.3.1 Processing Screen Requirements 4.3.1.2 The ACS The ACS shall: [Req 177] Create and maintain versions of the HTML that correspond to the sizes of the Challenge Window Size data element as defined in Table A.1 and provide the appropriate size in the CRes message based upon the Challenge Window Size that was provided by the 3DS Server in the AResAReq message. [Req 379] Create HTML with the UI elements in the Branding, Challenge/Processing and Information zones as defined in Table A.18 and depicted in the UI templates in Section 4.3.3.

4.3.2 Browser Display Requirements 4.3.2.1 ACS [Req 380] Create HTML with the UIform elements in the applicable zones as defined in Table A.18 and depictedoutlined in Figure 4.1. The expected format is depicted outlined in the UI templates in Section 4.3.3.

4.3.3 Browser UI Templates Note: For browser-based Decoupled Authentication transactions, the 3DS Requestor website displays the Processing Screen followed by a display of the Cardholder Information Text within the 3DS Requestors checkout page (this is the same as App-based Decoupled transactions, as illustrated in Figure 4.7). 4.4 3RI Considerations 3RI transactions do not have a user interface and therefore there are no user interface considerations. The two types of 3RI transactions have different UI considerations. The first type mainly concerns recurrent transactions where the 3DS Requestor wants to verify that a subscription user still has a valid form of payment. As the cardholder is not present, there is no user interface presented for this type of 3RI transaction. The second type of 3RI transaction is when the 3DS Requestor requests Decoupled Authentication as a method to authenticate the Cardholder, for example, a MOTO transaction. The user interface provided by the ACS for Decoupled Authentication is outside the scope of the EMV 3-D Secure protocol. The 3DS Requestor can optionally display a Processing Screen during AReq/ARes message processing and convey the Cardholder Information Text element if provided by the ACS in the ARes message. For a MOTO transaction, the 3DS Requestor’s customer service representative, can covey the Cardholder Information Text verbally for transactions conducted via a land line or feature phone.

countries.

Chapter 5 EMV 3-D Secure Message Handling Requirements 5.1.4 Protocol and Message Version Numbers [Req 311] 3DS components shall support all active protocol versions. 3-D Secure messages containing an active Message Version Number supported by the 3-D Secure component areshall be processed according to the requirements of the specified protocol version (See Table 1.5).

5.1.5 Message Parsing [Req 196] Message meets applicable technical and security requirements as defined in Annex A and Chapter 6.

5.1.6 Message Content Validation [Req 209] If there are additional data elements received that are not specified for the Message Type, Device Channel and Message Category but the message otherwise passes validation, the message shall be considered valid. However, the additional elements (with the exception of data extensions) shall be ignored and shall not be sent to the next 3DS component in the flow. For the additional data elements received (with the exception of data extensions), the receiving 3DS component shall EITHER:

  • Ignore the additional data elements and not send them to the next 3DS component in the flow OR
  • Check the format of the additional data elements:
  • If the format is correct, ignore the additional data elements and do not send them to the next 3DS component in the flow.
  • If the format is incorrect, the receiving 3DS component responds with an error message to the sending 3DS component. For Example:
  • The DS receives an AReq message from the 3DS Server with additional data elements that are not specified in Table A.1 for the AReq Message Type, Device Channel and Message Category and the DS validates the AReq content and drops the additional elements when sending the AReq message to the ACS. OR
  • If the additional data elements in the AReq message do not pass format checking, the DS can respond with an error message to the 3DS Server.

5.6 PReq/PRes Message Handling Requirements [Req 246] 3DS Servers shall make a call to each registered DS every 24 hours at a minimum, and once per hour at a maximum to refresh their cache, conditional on no errors found during PRes message processing.

countries.

[Req 303]

  • If the 3DS Server submits more than one request for Card Range Data within one hour, the DS:
  • Returns to the 3DS Server an Error Message (as defined in Section A.5.5) with Error Component = D and Error Code = 103.

5.9.3.1 Message in Error The DS: If a message is in error and a specific transaction can be identified, the DS sends to the 3DS Server using the secure link established in [Req 12] for an app-based transaction, [Req 90] for a browserbased transaction, or [Req 275] for a 3RI transaction EITHER an:

5.9.3.2 Error Message Received If an error message is received and a specific transaction can be identified, the DS sends to the 3DS Server using the secure link established in [Req 12] for an app-based transaction, [Req 90] for a browser-based transaction, or [Req 275] for a 3RI transaction EITHER an:

5.9.11 ACS RRes Message Error Handling—01-APP

  • For a message that cannot be recognised, the ACS:
  • If a specific transaction can be identified and the transaction is not a Decoupled Authentication transaction, the ACS:
  • For an RRes message, the ACS Validates the RRes message (as defined in Table B.9 and Section 5.1.6):
  • If any data element present fails validation, the ACS: − If a specific transaction can be identified and the transaction is not a Decoupled Authentication transaction, sends to the 3DS SDK an Error Message (as defined in Section A.5.5) with Error Component = A and Error Code = 203 using the secure link established in [Req 56].
  • If any required data elements are missing, the ACS: − If a specific transaction can be identified and the transaction is not a Decoupled Authentication transaction, sends to the 3DS SDK an Error Message (as defined in Section A.5.5) with Error Component = A and Error Code = 201 using the secure link established in [Req 56].
  • For an Error message, if a specific transaction can be identified and the transaction is not a Decoupled Authentication transaction, the ACS sends to the 3DS SDK an Error Message (as defined in Section A.5.5) with Error Component = A and Error Code = 403 using the secure link established in [Req 56].

5.9.12 ACS RRes Message Error Handling—02BRW

  • For a message that cannot be recognised, the ACS:
  • If a specific transaction can be identified and the transaction is not a Decoupled Authentication transaction, the ACS sends to the 3DS Server (via Browser) a CRes message.
  • For an RRes message, the ACS Validates the RRes message (as defined in Table B.9 and Section 5.1.6):
  • If any data element present fails validation, the ACS: countries. − If a specific transaction can be identified and the transaction is not a Decoupled Authentication transaction, sends to the 3DS Server (via Browser) a CRes message.
  • If any required data elements are missing, the ACS: − If a specific transaction can be identified and the transaction is not a Decoupled Authentication transaction, sends to the 3DS Server (via Browser) a CRes message.
  • For an Error message, if a specific transaction can be identified and the transaction is not a Decoupled Authentication transaction, the ACS sends to the 3DS Server (via Browser) a CRes message. Chapter 6 EMV 3-D Secure Security Requirements 6.2.2.2 DS Decryption
  • Decrypts the SDK Encrypted Data field from the AReq message according to JWE (RFC 7516). The parameter values supported in this version of the specification are: − "alg": RSA-OAEP-256 − If the enc parameter of the JWE in the SDK Encrypted Data field indicates that A128CBC-HS256 was used for encryption: "enc": A128CBC-HS256 − If the enc parameter of the JWE in the SDK Encrypted Data field indicates that A128GCM was used for encryption: "enc": A128GCM − All other parameters: not present
  • Conducts a Diffie-Hellman key exchange process according to JWA (RFC 7518) in Direct Key Agreement mode using curve P-256, QSDK, and dDS to produce a CEK. The parameter values supported in this version of the specification are: − If the enc parameter of the JWE in the SDK Encrypted Data field indicates that A128CBC-HS256 was used for encryption: "enc": A128CBC-HS256 − If the enc parameter of the JWE in the SDK Encrypted Data field indicates that A128GCM was used for encryption: "enc": A128GCM countries. Annex A 3-D Secure Data Elements o 03-3RI—Deviceless Payment Authentication/Verification of Account A.4 EMV 3-D Secure Data Elements Table A.1 EMV 3-D Secure Data Elements Data Element/ Field Name

Description

Source Length/Format/ Values Device Channel 3DS Requestor App URL Field Name: threeDSRequesto rAppURL Merchant app declaring their URL within the CReq message so that the Authentication app can call the Merchant app after OOB authentication has occurred. Each transaction would require a unique Transaction ID by using the SDK Transaction ID. 3DS SDK Length: Variable, maximum 256 characters JSON Data Type: String Value accepted: Fully Qualified URL Example value: merchantScheme://appNam e?transID=b2385523-a66c4907-ac3c-91848e8c0067 01-APP Message Category 01-PA 02-NPA Message Inclusion CReq = O Condition Inclusion

countries.

Data Element/ Field Name Description Source 3DS Requestor Authentication Method Verification Indicator Field Name: threeDSReqAuthM ethodInd Value that DS represents the signature verification performed by the DS on the mechanism (e.g., FIDO) used by the cardholder to authenticate to the 3DS Requestor. Length/Format/ Values Length: 2 characters JSON Data Type: String Values accepted:

  • 01 = Verified
  • 02 = Failed
  • 03 = Not Performed
  • 04–79 = Reserved for EMVCo future use (values invalid until defined by EMVCo)
  • 80–99 = Reserved for DS use Device Channel 01-APP 02-BRW Message Category 01-PA 02-NPA Message Inclusion AReq = C Condition Inclusion Conditional based on DS rules. countries. Data Element/ Field Name 3DS Requestor Challenge Indicator Description Source Length/Format/ Values Device Channel
  • 05 = No challenge requested (transactional risk analysis is already performed)
  • 06 = No challenge requested (Data share only)
  • 07 = No challenge requested (strong consumer authentication is already performed)
  • 08 = No challenge requested (utilise whitelist exemption if no challenge required)
  • 09 = Challenge requested (whitelist prompt requested if challenge required)
  • 510–79 = Reserved for EMVCo future use (values invalid until defined by EMVCo) Message Category Message Inclusion Condition Inclusion countries. Data Element/ Field Name Description Source Length/Format/ Values Device Channel 3DS Requestor Decoupled Max Time Field Name: threeDSRequesto rDecMaxTime Indicates the maximum amount of time that the 3DS Requestor will wait for an ACS to provide the results of a Decoupled Authentication transaction (in minutes). 3DS Server Length: 5 characters JSON Data Type: String Numeric values between 1 and 10080 accepted. 01-APP 02-BRW 03-3RI 3DS Requestor Decoupled Request Indicator Field Name: threeDSRequesto rDecReqInd Indicates whether the 3DS Requestor requests the ACS to utilise Decoupled Authentication and agrees to utilise Decoupled Authentication if the ACS confirms its use. 3DS Server Length: 1 character JSON Data Type: String Values accepted:
  • Y = Decoupled Authentication is supported and preferred if challenge is necessary
  • N = Do not use Decoupled Authentication Note: if the element is not provided, the expected

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