PCI Watch

Tracking changes across the Payment Card Industry

EMV® 3-D Secure Approval – Test Requirements for ACS as System Under Test

v2.15 Test Cases & Test Environments
3-D Secure

EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test Version 2.15 11 Oct 2024

countries.

countries.

EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15

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 noninfringement. 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.

countries.

EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15

Version 1.0 1.1 1.2 1.3 1.4 1.5 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Date 05 Mar 2020 20 Mar 2020 24 Apr 2020 17 Jun 2020 27 Jul 2020 11 dec 2020 29 Jan 2021 14 May 2021 10 Dec 2021 10 Jan 2022 28 Jan 2022 14 Mar 2022 22 Jul 2022 23 Sep 2022 28 Oct 2022 25 Nov 2022 Revision Log

Description

Initial version Clarification about endpoint connections Editorial Changes Notes, clarifications added for pIrq/pIrs and pOrq/pOrs management. New section: “Secure Security Requirement for proprietary messages” New section 3.1.1 Timeout values for Requirement 234 Grace period: for testing purpose, the ACS has to send the RReq message within 30 seconds provided in the AReq message. P3DS_TP-133: requirement about presence of ‘whitelistingInfoText’ field in CRes: new dedicated section 3.1.3 Important information have been updated for ACS in the document [TEST_REQ_ALL_SUT] v2.0 Upgraded version of [TEST_REQ_ALL_SUT] to version 2.1 Upgraded version of [TEST_REQ_ALL_SUT] to version 2.2 New RRes timeout value defined in 3.1.1. Timeout values Update the Proprietary Information Request Message (pIrq) to manage the communication of the correct/incorrect Challenge Data Entry 2 (from [3DS_Core_2.3.0])  See section 3.3.2 in Table Proprietary Application Form Values P3DS_TP-246: new ACS requirement defined in new section “3.1.4 challengeHTMLDataEntry when acsUiType = 06 (HTML OOB)” Upgraded version of [TEST_REQ_ALL_SUT] to version 2.4 Upgraded reference of [TEST_REQ_ALL_SUT] to version 2.5 Upgraded reference of 2.3.0 specifications to 2.3.1 specifications Upgraded reference of [TEST_REQ_ALL_SUT] to version 2.6 Update the Proprietary Information Request Message (pIrq) to manage the communication of the correct answer to the UI information Template in HTML  See section 3.3.2 in Table Proprietary Application Form Values Updated version of referred documents:

countries.

EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15 Page v

  • [TEST_REQ_ALL_SUT] 2.10 14 Dec 2022 P3DS_IM-19: the fraud detection mechanic shall be disabled (see new section 3.7) 2.11 30 June 2023 Updated version of referred documents:
  • [TEST_REQ_ALL_SUT] 2.12 21 July 2023 Updated version of referred documents:
  • [TEST_REQ_ALL_SUT] 2.13 27 Oct 2023 Updated version of referred documents:
  • [TEST_REQ_ALL_SUT] 2.14 26 Apr 2024 Updated version of referred documents:
  • [TEST_REQ_ALL_SUT] 2.15 11 Oct 2024 Update from EMV® Specification Bulletin No. 255 v4 July 2024: 3DS 2.1.0 is sunsetted
  • All references to 3DS 2.1.0 are removed Updated version of referred documents:
  • [TEST_REQ_ALL_SUT] countries. EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15 3. 3.1.1 3.1.2 3.1.3 3.1. 3. 3. 3.3.1 3.3.2 3.3.3 3.3.4 3.3. 3. 3.4. 3. 3. 3. countries. EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15 / 15 1

References

Short name [TEST_REQ_ALL_SUT] [3DS_Core_2.2.0] [3DS_SDK_Spec_2.2.0] [3DS_Core_2.3.1] [3DS_SDK_Spec_2.3.1] [3DS_Split_SDK_Spec_2.3.1] Reference Document Test Requirements for all Systems Under Test EMV® 3-D Secure Protocol and Core Functions Specification EMVCo EMV® 3-D Secure – SDK Specification EMVCo EMV® 3-D Secure Protocol and Core Functions Specification EMVCo EMV® 3-D Secure – SDK Specification EMVCo EMV® 3-D Secure – Split-SDK Specification EMVCo Version / Date v2.14 / 11 Oct 2024 v2.2.0 / nov-2018 v2.2.0 / nov-2018 v2.3.1.1 / May-2023 v2.3.1.1 / May-2022 v2.3.1.1 / May-2022

countries.

EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15

/ 15 2

Introduction

This document describes the test requirements for ACS as System Under Test

countries.

EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15 3 Test requirements for ACS as SUT

/ 15 3.1 ACS default data or message definition 3.1.1 Timeout values According to Requirement 234 [3DS_Core_2.x.0], the ACS shall set the ARes timeout value. The timeout value of 7 seconds is expected to be implemented. According to Requirement 242 [3DS_Core_2.x.0], the ACS shall set the RRes timeout value. This timeout value is fixed to 5-seconds in [3DS_Core_2.2.0], but it is configurable depending on DS in [3DS_Core_2.3.1]. For testing purpose, the ACS must set the default timeout value to 5-seconds.

3.1.2 Additional functionalities The following additional functionalities must be supported by the ACS:

  • The ACS shall behave in a pre-determined manner based on a supplied response (CReq or HTML) in a Challenge Flow. This includes resending of a challenge if required.
  • TPP shall be supplied with the POST data that needs to be sent as challenge response via the pIrq message.
  • Provide the ACS public key to be signed by the EMVCo DS CA.
  • ACS certificates shall be signed by the EMVCo DS CA using the web platform.
  • Use a maximum of three (3) transactions for the interaction counter.
  • For the 3RI and NPA channels the Authentication Value will not be checked 3.1.3 whitelistingInfoText presence in CRes If the field ‘threeDSRequestorChallengeInd’ received in AReq is set to ‘09’, then the CRes produced by ACS (not the final one) will include the field 'whitelistingInfoText'. If the field ‘threeDSRequestorChallengeInd’ received in AReq is set to a value not equal to ‘09’, then the CRes produced by ACS (not the final one) will not include the field 'whitelistingInfoText'. 3.1.4 challengeHTMLDataEntry when acsUiType = 06 (HTML OOB) ACS Product Provider share with Test Platform Provider the expected value for 'challengeHTMLDataEntry' when acsUiType = 06 (HTML OOB) when the user manually click on the continuation button. countries. EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15 / 15 3.2 ACS behavior regarding data profile The document [TEST_REQ_ALL_SUT] describe all the configuration data Profiles and how the ACS shall behave depending on card range.

3.3 ACS Connection with Test Servers and Proprietary messages ACS shall be connected with two Test Servers: 1. Challenge Information Test Server (Challenge Info Test Server), two proprietary messages are defined: (details are provided in sub-sections below) a. ACS  Challenge Info Test Server: proprietary Information Request message (pIrq)

  • contains Challenge Data (correct passwords, OTP values, HTML forms, etc.)
  • is sent by the ACS during 3DS transactions utilizing Challenge Flow. b. Challenge Info Test Server  ACS: proprietary Information Response message (pIrs)
  • contains confirmation that the data was successfully received.
  • is sent in response to pIrq. Note1: The pIrq and pIrs message pair may be repeated as necessary, supplying the successful Challenge Data for each iteration of the CReq/CRes exchange. If no pIrq is sent for a subsequent interaction, the old values will be reused. Note2: For test cases referring to Application based Out-of-Band that are using HTML ACS UI Type (acsUiType=05) the SUT needs to send a pIrq with the Application Form value data elements to the Challenge Info Test Server. 2. Out of Band Simulator Test Server (OOB Test Server), two proprietary messages are defined: (details are provided in sub-sections below) a. ACS  OOB Test Server: Proprietary Out-of-Band Request (pOrq)
  • is sent by ACS during Challenge Flow in the case of Out-of-Band authentication.
  • requests the result of Out-of-Band authentication. b. OOB Test Server  ACS: Proprietary Out-of-Band Response (pOrs)
  • is sent during Challenge Flow in the case of Out of Band Authentication.
  • contains the result of out-of-band authentication. The ACS is expected to use this information in the same way as it would in a real life situation. c. The pOrq and pOrs message pair shall be repeated for each challenge attempt. countries. EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15 / 15 Note: For Application based Out-of-Band flows that are using HTML ACS UI Type (acsUiType=05) the ACS needs to send a pIrq with the p_formValues_APP data element to Challenge Info Test Server, in addition with a pOrq to OOB Test Server.

3.3.1 Secure Security Requirement for proprietary messages The ACS to Challenge Info Test Server link shall following the same security requirement as for AReq (See [3DS_Core_2.x.x] §6.1.3.1) The ACS to OOB Test Server link shall following the same security requirement as for AReq (See [3DS_Core_2.x.x] §6.1.3.1).

3.3.2 Proprietary Information Request message (pIrq) [ACS Behavior] In case of Challenge Flow, on reception of the CReq, ACS shall send a proprietary Information Request Message (plrq) to Challenge Info Test Server, providing challenge data as indicated below, prior to returning the CRes. № Field Presence Type/Format 1. messageType R Length: 4 character JSON Data Type: String 2. messageVersion R According to EMVCo 3DS Spec 3. p_messageVersion R x.y.z 4. acsTransID R According to EMVCo 3DS Spec 5. p_formValues_BRW C JSON Object 6. p_formValues_APP C JSON Object Accepted Value pIrq According to EMVCo 3DS Spec 1.0.6 According to EMVCo 3DS Spec Proprietary Browser Form Values, see « Table Proprietary Browser Form Value ». Only applicable to 02-BRW Device Channel. Proprietary Application Form Values, see « Table Proprietary Application Form Values » Only applicable to 01-APP Device Channel. Table Proprietary Browser Form Value Data Element/Field Name Form Action Field Name: action Description URL to post the form data to. Via this URL the ACS receives the challenge data entered by the cardholder in the browser. Correct Form Data Field Name: correctFormData Incorrect Form Data Field Name: incorrectFormData Cancel Form Data Field Name: cancelFormData Correct challenge data as entered by the Cardholder. Full result of the HTML form submission as expected by the ACS. Incorrect challenge data as entered by the Cardholder. Full result of the HTML form submission as expected by the ACS. Data sent to the ACS in case the Cardholder cancels the challenge flow. Full result of the HTML form submission as expected by the ACS. Format JSON Data Type: String Contains fully qualified URL to reach the ACS. JSON Data Type: String JSON Data Type: String JSON Data Type: String Message Inclusion pIrq = R pIrq = R pIrq = R pIrq = R

countries.

EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15

/ 15 Table Proprietary Application Form Values Data Element/Field Name Description Correct Challenge Data Field Name: correctChallengeData Incorrect Challenge Data Field Name: incorrectChallengeData Correct Challenge Data 2 Field Name: correctChallengeData2 Correct challenge data as entered by the Cardholder. For HTML UI this should be the full result of the HTML form submission as expected by the ACS. Incorrect challenge data as entered by the Cardholder. For HTML UI this should be the full result of the HTML form submission as expected by the ACS. Correct challenge data as entered by the Cardholder in the 2nd entry box. For HTML UI this should be the full result of the HTML form submission as expected by the ACS. Format JSON Data Type: String JSON Data Type: String JSON Data Type: String Incorrect Challenge Data 2 Field Name: incorrectChallengeData2 Incorrect challenge data as entered by the Cardholder in the 2nd entry box. For HTML UI this should be the full result of the HTML form submission as expected by the ACS. JSON Data Type: String Correct Info Continue Field Name: correctInfoContinueHTML Full result of the HTML form submission as expected by the ACS when the Information Template is acknowledged by the CardHolder (when the user click on the button to continue) JSON Data Type: String Message Inclusion pIrq = R pIrq = R pIrq = C Required when

  • 3DS Core specification is superior to 2.3.0.0
  • Challenge Entry Box 2 object is provided by the ACS pIrq = C Required when
  • 3DS Core specification is superior to 2.3.0.0
  • Challenge Entry Box 2 object is provided by the ACS pIrq = C Required when
  • 3DS Core specification is superior to 2.3.1.0 3.3.3 Proprietary Information Response message (pIrs) [Test Environment Behavior] On reception of each plrq, Challenge Info Test Server shall send a proprietary Information Response Message (plrs) to ACS: № Field Presence Type/Format Accepted Value 1. messageType R Length: 4 character JSON Data Type: String pIrs 2. messageVersion R According to EMVCo 3DS Spec According to EMVCo 3DS Spec 3. p_messageVersion R 1.0.5 Starting value: 1.0.0 4. acsTransID R According to EMVCo 3DS Spec According to EMVCo 3DS Spec 3.3.4 Proprietary Out-of-Band Request (pOrq) [ACS Behavior] In case of Application Out-Of-Band flow, on reception of the subsequent CReq messages (not the first), ACS shall send a proprietary Out-of-Band Request Message (pOrq) to OOB Test Server: [ACS Behavior] In case of Decoupled Authentication flow, after sending the message ARes to DS, ACS shall send a proprietary Out-of-Band Request Message (pOrq) to OOB Test Server: countries. EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15 / 15 № Field Presence Type/Format Accepted Value 1. messageType R Length: 4 character JSON Data Type: String pOrq 2. messageVersion R According to EMVCo 3DS Spec According to EMVCo 3DS Spec 3. p_messageVersion R 1.0.5 Starting value: 1.0.0 4. threeDSServerTransId R According to EMVCo 3DS Spec According to EMVCo 3DS Spec 5. acsTransID R According to EMVCo 3DS Spec According to EMVCo 3DS Spec 3.3.5 Proprietary Out-of-Band Response (pOrs) [Test Environment Behavior] On reception of each pOrq, OOB Test Server shall send a proprietary Out-of-Band Response Message (pOrs) to ACS: № Field Presence Type/Format Accepted Value 1. messageType R According to EMVCo 3DS Spec pOrs 2. messageVersion R According to EMVCo 3DS Spec According to EMVCo 3DS Spec 3. p_messageVersion R 1.0.5 Starting value: 1.0.0 4. p_isOobSuccessful R Boolean true OR false The field “p_isOobSuccessful” is providing the result of the OOB authentication, which has to be processed by the ACS. Note, that for testing purposes it is not feasible to use a grace period of 1 hour as mentioned in the 3-D Secure specifications. Therefore, the ACS has to send the RReq message within 30 seconds provided in the AReq message.

3.4 ACS Network configuration 3.4.1 ACS connection with Test environment ACS is connected with the following elements in Test Environment:

  • DS
  • SDK (App-based flow)
  • CLIENT_BROWSER (Browser-based flow)
  • OOB Test Server (Out-Of-Band authentication flow, Decoupled authentication flow)
  • Challenge Info Test Server (Challenge authentication flow)
  • Notification URL The address for the endpoints OOB Test Server and Challenge Info Test Server will be provided by Test Platform Providers, which are to be configured in the System Under Test: ACS 3.5 DS Public keys and certificates The DS public keys and Certificates are provided by the Test Platform Provider. Test Platform Provider also indicates the associated RIDs for the DS public Keys depending on the algorithm (RSA, EC). countries. EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15 / 15 3.6 Commercial CAs Supported ACS Product Provider shall provide to Test Platform Provider the list of commercial CAs which are supported.

3.7 Disable fraud detection mechanic For the test execution purpose, the ACS Product Provider shall disable the fraud detection mechanic when multiple invalid OTP scenarios are using the same PAN triggers.

countries.

EMV® 3-D Secure Approval Test Requirements for ACS as System Under Test v2.15 *** END OF DOCUMENT ***

/ 15

countries.