PCI Watch

Tracking changes across the Payment Card Industry

SB n° 204: EMV® 3-D Secure Protocol and Core Functions Specification v2.1.0 – Updates, Clarifications & Errata

v7.0 Specification Bulletins
3-D Secure

EMV® Specification Bulletin No. 204 v7 June 2023 EMV® 3-D Secure Protocol and Core Functions Specification version 2.1.0 – Updates, Clarifications & Errata This Specification Bulletin (SB) No. 204v7 provides updates, clarifications and errata incorporated into the EMV 3-D Secure Protocol and Core Functions Specification since the October 2017 v2.1.0 publication. This SB 204v7 also includes v2.1.0 content consolidated from SB 224v1 for clarity.

Applicability

This Specification Bulletin applies to:

  • EMV® 3-D Secure Protocol and Core Functions Specifications, Version 2.1.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.

Related Documents

The following publications should also be referenced for specification updates:

  • EMV® 3-D Secure JSON Message Samples
  • EMV® 3-D Secure FAQs

Effective Date

June 2023

Contents EMV® 3-D Secure Protocol and Core Functions Specification version 2.1. 1. Table 1. 1. 3. 5. 5.8. 5.8. A. Table A. Table A.

1. 4.1. 4.2.2. 4.2. 4.2. 4.3.2. 5.1. 5.8. 6.1.4. A. Table A. A.5. A. Table A. 4.1. 4.2. 4.2.1.

4.2.2. 4.2. 4.2.4. 4.2.5. 4.2. 4.2.6. 4.2.7. A. Table A. 1. Table 1. 4. 4. 4.2. 4.2.1. 4.2.2.

4.2.4. 4.2.5. 4.2.7. 4.3. 4. 4.3.2. 5.1. 5.1. 6.2.2. 6.2.2. 6.2.3. 6.2.3. 6.2.4. 6.2.4. 6.2.4. 6.2.4. A. Table A. A.5. Table A. A.7. A.7. A.7.

Table A. A. Table A. 1. 3. 4. Figure 4. Figure 4. 4.2.1. 4.2. 4.2.2. 4.2. 4.2. 4.2. 4.2.5.

4.2. 4. 4.3.1. 4.3.1. 4.3. 4.3.2. 4.3. Figure 4. Figure 4. Figure 4. 5.1. 5.5. 5.

A. Table A. A.5. A.5. Table A. A.7. Table A. A.7. Table A. A.7. Table A. A.7. Table A. A.7. Table A. A. Table A. B. Table B. 3. 4. 4.2.5. 5.5. 5.8. 6.2.4.

6.2.4. A. Table A. A.5. A.5. Table A. A.7. Table A. A.7. Table A. 3. 4.2.5. 5.1. 5.1. 5.8. 6.1. 6.2.4. 6.2.4. A. Table A. Table 1.

3. 4. Updated: Figure 4. 4.2. Updated: Figure 4. 4.2. Updated: Figure 4. 5.1. 5.1. 5.5.2. 5.7. 5.8. 5.9. 6.2.3. 6.2.3. 6.2.4. A. Table A. A. A.7. Table A. A.7. Table A. A.7.

B. Table B.

June 2023 v7 Overview and Objectives The 3-D Secure Browser Flow is used to process transactions where the Cardholder has initiated interactions with the 3DS Requestor through a Browser. Adherence by the 3DS Requestor and the ACS to the iframe requirements documented in this 3-D Secure (3DS) Specification Bulletin is critical to the successful processing of the Browser Flow. The new requirements for 3-D Secure (3DS) Specification v2.1.0 and v2.2.0 are the same as for v2.3.1.1, therefore the 3DS Requestor and ACS should have a consistent implementation for the Browser flow and the Challenge. The bulletin also provides clarifications and additional requirements in case the ACS receives multiple CReq messages for the Browser flow – for example, if the 3DS Requestor refreshes the Merchant web page during the Challenge, in case the Cardholder requested a page refresh on their Browser. Chapter 1 Introduction 1.5

Definitions

Table 1.3 Definitions Term Definition Browser A Browser is a dedicated software application for accessing information on the World Wide Web, for example Chrome, Safari, Edge, Firefox. When a user requests a web page from a particular website, the Browser retrieves the necessary content from a web server and then displays the page on the consumer’s screen. In the context of 3-D Secure, the Browser is a conduit to transport messages between the Acquirer Domain and the Issuer Domain. A Browser is distinguished from a UI component, for example, a WebView, or Custom Tabs, which can be used to display content within an App on a mobile device. The Browser flow is invoked by a Browser, whereas the EMVCo specification does not support a UI component within an app invoking the Browser flow. In the context of 3-D Secure, the browser is a conduit to transport messages between the 3DS Server (in the Acquirer Domain) and the ACS (in the Issuer Domain).

1.8 Supporting Documentation

  • EMV® 3-D Secure Browser Flow Best Practices Chapter 3 EMV 3-D Secure Authentication Flow Requirements 3.3 Browser-based Requirements Step 10: The 3DS Server The 3DS Server shall: [Req 117] For a transaction with a challenge (Transaction Status = C): a. Evaluate, based in part on the 3DS Requestor Challenge Indicator, the ACS Challenge Mandated Indicator and the ACS Rendering Type whether to perform the requested challenge.
  • If the 3DS Requestor accepts the challenge:
  • Send necessary information (as defined in Table B.2) from the ARes message to the 3DS Requestor Environment.
  • Continue with step b through e of this requirement and then Step 11.
  • 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. The 3DS Server may continue with Step 22. b. Format the CReq message according to the format specified in Table B.3 for a Browser-based implementation. c. Base64url-encode the CReq message. d. Construct a form containing the CReq message, and if provided by the 3DS Requestor, the 3DS Requestor Session Data (as defined in Table A.3). e. Pass Send the CReq message using an HTTP POST through the Cardholder Browser HTML iframe as defined in Section 5.8.2 and Section A.5.4 (Browser CReq and CRes POST) to the ACS URL received in the ARes message, by causing the cardholder browser to POST the form to the ACS URLusing a server-authenticated TLS link as defined in Section 6.1.4.2. Step 11: The ACS The ACS shall: [Req 119] Receive the CReq message from the Browser and:
  • Accept a Base64url-encoded CReq message with or without padding,
  • Validate the message as defined in Section 5.9.6,
  • Accept the Base64url-encoded Session Data with or without padding. If the message is in error, the ACS ends processing. New Requirement 442 was added at the end of Step 11, directly after Requirement 121. [Req 442] If the ACS receives more than one CReq message, the ACS either:
  • Restarts or continues the challenge with the Cardholder, OR
  • Returns an Error Message if it is not possible to continue or restart the authentication. Step 12: The ACS and Browser The ACS shall: [Req 307] The ACS shall not lead the Cardholder outside of the authentication flow by redirecting to any registration or marketing pages. Any redirection shall be used for authentication purposes only and within the iframe. The ACS shall only load external resources that are needed to improve the Cardholder authentication experience and security (e.g., logos). [Req 122] Send the ACS UI to the Cardholder over the channel established by the HTTP POST in Step 10. The ACS shall allow the content of the UI to be framed. The Browser displays the ACS UI to the Cardholder. Chapter 5 EMV 3-D Secure Message Handling Requirements 5.8 Browser-based Message Handling 5.8.1 3DS Method Handling The 3DS Requestor shall: [Req 261] Render a hidden HTML iframe in the Cardholder browser and send a form with a field named threeDSMethodData containing the JSON Object via HTTP POST to the ACS 3DS Method URL obtained from the PRes message cache data. Open a hidden HTML iframe in the Cardholder Browser with:
  • the iframe attributes set as defined in Table A.19.
  • the sandbox attributes set as defined in Table A.20. For Browser compatibility, iframe shall be made hidden with the following style setting: “visibility:hidden”. For example: style="visibility:hidden". Send a form with a field named threeDSMethodData containing the JSON object via HTTP POST to the ACS 3DS Method URL obtained from the PRes message cache data. The ACS shall: [Req 263] Recall the 3DS Server Transaction ID received in the initial 3DS Method POSTValidate the Base64url-encoded threeDSMethodData with or without padding from the initial 3DS POST method, and retrieve the 3DS Server Transaction ID, then Base64url-encode the JSON object and send via a form with a field named threeDSMethodData in the Cardholder Browser HTML iframe using an HTTP POST method to the 3DS Method Notification URL. Refer to Table A.2 for detailed information about 3DS Method Data.

5.8.2 Browser Challenge Window iframe Requirements The Browser challenge will occur within the Cardholder Browser, and the ACS will provide a formatted challenge UI to the Cardholder within the Browser challenge windowiframe. The 3DS Requestor shall: [Req 265] Select the size of the HTML iframe to be generated by the 3DS Requestor from one of the windowiframe sizes specified in the Challenge Window Size data element. [Req 266] Utilise a server-authenticated TLS session as defined in Section 6.1.4.2. [Req 267] Create a 3-D Secure challenge windowiframe by generating a CReq message, creating an HTML iframe in the Cardholder Browser, with the following settings:

  • iframe attributes as defined in Table A.19
  • sandbox attributes as defined in Table A.20 and generatinggenerate an HTTP POST through the iframe to the ACS URL that was received in the ARes message. [Req 268] Post the CReq message containing the selected size in the Challenge Window Size data element to the ACS as defined in Table A.1. [Req 324] Provide a fallback mechanism for redirection in environments that do not support JavaScript. Note: If the Cardholder initiates a page refresh, the 3DS Requestor repeats the previous steps starting from [Req 265] using the same iframe size and attributes. The ACS shall: [Req 269] Receive the CReq message and respond with the HTML to render the challenge user interface within the iframe. Note: During completion of the challenge by the Cardholder, there may be several interactions required. After challenge completion, the ACS generates the RReq message. After receiving the corresponding RRes message, the ACS generates the CRes message and invokes the Browser to send an HTTP POST (for example, using JavaScript) to the Notification URL containing the CRes message as defined in Table A.1. This completes the challenge. The 3DS Requestor shall: [Req 270] Close the challenge windowiframe upon receiving the CRes message by refreshing the parent page and removing the HTML iframe. A.9 iframe and Sandbox Attributes Table A.19 specifies the iframe attributes that the 3DS Requestor uses when it creates the challenge or 3DS Method iframe. Table A.19: iframe Attributes Attribute14 Value allowfullscreen false allowpaymentrequest false height as per Challenge Window Size sandbox refer to Table A.20 srcdoc may be used to initialise redirection content width as per Challenge Window Size allow="payment *; publickeycredentials-get *"15 enable access to WebAuthn and SPC (Secure Payment Confirmation) API and Payment Request API Table A.20 specifies the sandbox attributes that the 3DS Requestor uses when it creates the challenge or 3DS Method iframe. Attribute Table A.20: Sandbox Attributes

Description

Inclusion allow-forms Allows the processing of forms. R allow-scripts Allows the processing of scripts. Note the R allow-scripts permission does not give the iframe the ability to create pop-ups or modal windows, which can help prevent clickjacking attacks from occurring. allow-same-origin Gives the iframe permission to only use the R data from the same ACS domain. 14 Attributes not listed in Table A.19 should not be present. 15 Use the following syntax, if supported by the Browser

Attribute allow-pointer-lock Description Inclusion Gives access to the mouse position and events. R Note: this attribute is not needed for the 3DS Method iframe. allow-downloads- Prevents downloads to be initiated for content without-user-activation in the iframe without user action. Not Allowed allow-downloads Prevents downloads to be initiated for content in the iframe. Not Allowed allow-modals Prevents to open modal window from the iframe. Not Allowed allow-orientation-lock Prevents to lock the screen orientation. Not Allowed allow-popups Prevents pop-up windows. Not Allowed allow-popups-to-escape- Prevents pop-ups to open new windows without Not Allowed sandbox inheriting the sandboxing. allow-presentation Prevents to initiate a presentation session. Not Allowed allow-storage-accessby-user-activation Prevents access to the parent's storage capabilities. Not Allowed allow-top-navigation Prevents access to the top-level browsing context. Not Allowed allow-top-navigationby-user-activation Prevents access to the top-level browsing context also with user interaction. Not Allowed

February 2020 v6 Chapter 1 Introduction 1.10 Constraints The Specification or any implementation of the Specification is not intended to replace or interfere with any international, regional, national or local laws and regulations; those governing requirements supersede any industry standards. Chapter 3 3-D Secure Authentication Flow Requirements Step 14: The 3DS SDK [Req 55] Display the UI based upon the ACS UI Type selected and the data elements populated. Refer to Section 4.2 and to the applicable 3DS SDK specification for UI details. If the CRes message for a Native UI contains a URL(s) directing the 3DS SDK to fetch data from an external server (i.e., an Issuer Image or Payment System Image for use with a Native UI), establish an additional secure link to the external server as defined in Section 6.1.4.1 and fetch and display the received data within the UI. If a secure link cannot be established, the 3DS SDK proceeds with the challenge displays all other provided mandatory and optional UI data elements and does not send an error message to the ACS. Chapter 4 EMV 3-D Secure User Interface Templates, Requirements, and Guidelines 4.1.3 3-D Secure Interface Templates The 3DS SDK shall: [Req 395] Support the UI template orientation(s) (i.e., portrait and landscape) according to the device capabilities. 4.2.2.1 3DS SDK/ACS The 3DS SDK shall for the CReq/CRes message exchange: [Req 362] For the ACS UI Type and the device screen orientation, display the supported provided mandatory and optional UI data elements in their applicable zones and order as defined in Table A.18 and depicted in Figure 4.1 and Figure 4.2. The expected format is depicted in Sections 4.2.3 and 4.2.6.

If the 3DS 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. Requirement 398 is a new requirement to align with the existing implementation of the 3DS SDK; no impact is expected to the 3DS SDK. [Req 398] For the ACS UI Type, the 3DS SDK returns to the ACS an Error Message (as defined on Section A.5.5) with Error Component = S and Error Code = 201 if any mandatory UI data elements are missing as defined in Table A.18. The ACS shall for the CReq/CRes message exchange: [Req 387] Only include the mandatory and the optional ACS-chosen UI data elements for the selected ACS UI Type as defined in Table A.18.

4.2.3 Native UI Templates Figure 4.21 Sample Challenge Information Text Indicator—PA (Updated) 4.2.5 HTML UI Display Requirements [Req 374] Create HTML with form elements in the applicable zones as outlined in Figure 4.1 and Figure 4.2 to support both portrait and landscape UI templates. The expected format is outlined in Section 4.2.6.

4.3.2.1 ACS The ACS shall for the CReq/CRes exchange: [Req 380] Create HTML with form elements in the applicable zones as outlined in Figure 4.1 and Figure 4.2 to support both portrait and landscape UI templates. The format is outlined in the UI templates in Section 4.3.3.

Chapter 5 EMV 3-D Secure Message Handling Requirements Section 5.1.5 is a new section. Subsequent headings were renumbered as applicable.

5.1.5 Data Version Numbers [Req 396] The 3DS SDK shall implement the latest Data Version of the 3DS SDK Device Information. [Req 397] The ACS shall implement all active Data Versions of the 3DS SDK Device Information. Note: Refer to EMV® 3-D Secure SDK—Device Information. 5.8.1 3DS Method Handling [Req 263] Recall the 3DS Server Transaction ID received in the initial 3DS Method POST, then Base64url encode the JSON object and send via a form with a field named threeDSMethodData in the Cardholder browser HTML iframe using an HTTP POST method to the 3DS Method Notification URL. Refer to Table A.2 for detailed information about 3DS Method Data. Chapter 6 EMV 3-D Secure Security Requirements 6.1.4.1 For App-based CReq/CRes New paragraph added at the end of Section 6.1.4.1. If the CRes message contains a URL(s) directing the 3DS SDK to fetch data from an external server, an additional link is established using a TLS protocol, with server authentication by the 3DS SDK based on a commercial server certificate.

Annex A 3-D Secure Data Elements Throughout Annex A, all instances of http have been replaced with https for all domain examples. A.4 EMV 3-D Secure Data Elements Update notice: This 11 February 2020 version of SB 204v6 removes the 3DS Requestor App URL that was incorrectly included in the version published 7 February 2020. Table A.1 EMV 3-D Secure Data Elements Data Element/ Field Name Description Source Length/Format/ Values Device Channel Message Category Message Inclusion Conditional Inclusion OOB Continuation Label Note: If present, either of the following must also be present:

  • Challenge Information Header, OR
  • Challenge Information Text Refer to Table A.18 for additional information. Data Element/ Field Name Submit Authentication Label Description Source Length/Format/ Values Device Channel Message Category Message Inclusion Conditional Inclusion Note: If present, either of the following must also be present:
  • Challenge Information Header, OR
  • Challenge Information Label, OR
  • Challenge Information Text Refer to Table A.18 for additional information. A.5.4 Browser CReq and CRes POST The following table defines the data elements sent in the Browser POST to the ACS for the CReq flow, and to the Notification URL in the CRes flow. An HTML form is utilised within the cardholder browser and the data is sent redirected via the cardholder browser in an HTTP POST. Note: The end result of the redirection must be similar as if an HTML tag was utilised. A.8 UI Data Elements Table A.18 specifies the placement and the presence of UI data elements on the UI with respect to the zones defined in Section 4.1.
  • M = Mandatory presence
  • O = Optional presence
  • N = Not present Table A.18: UI Data Elements Data Element Challenge Additional Information Text Challenge Information Header Challenge Information Label Challenge Information Text Challenge Information Text Indicator Challenge Selection Information Expandable Information Label Expandable Information Text Issuer Image OOB Continuation Label Payment System Image Field Name challengeAddInfo challengeInfoHeader challengeInfoLabel challengeInfoText challengeInfoTextIndicat or challengeSelectInfo expandInfoLabel expandInfoText issuerImage oobContinueLabel psImage Zone 3 3 3 3 3 3 4 4 2 3 2 Portrait Top-down Display Order Landscape Top-down Display Order 3 3 2 2 4 4 3 3 3 3 5 5 12 12 13 13 1 1 6 6 1 1 OTP N M M M O N O O O N O ACS UI Type Single Select Multi Select N N M M M M M M O O M M O O O O O O N N O O OOB O M O M O N O O O M O Data Element Resend Information Label Submit Authentication Label Why Information Label Why Information Text Field Name resendInformationLabel Zone 3 Portrait Top-down Display Order 8 Landscape Top-down Display Order 6 submitAuthenticationLabe 3 7 6 l whyInfoLabel 4 10 10 whyInfoText 4 11 11 OTP O M O O ACS UI Type Single Select Multi Select N N M M O O O O OOB N N O O [ August 2019 SB224v1 ] The 3-D Secure version 2.1.0 content in this August 2019 SB224v1 section was originally published in Specification Bulletin 224v1. SB 224v1 is now consolidated into this SB204v6 version for clarity. Therefore, this SB 204v6 now contains all updates to version 2.1.0 since the October 2017 publication of the EMV 3-D Secure Protocol and Core Functions specification. Chapter 4 EMV 3-D Secure User Interface Templates, Requirements, and Guidelines This SB 224v1 contains new Figures added to Chapter 4 of the 3-D Secure Protocol and Core Functions specification. Existing graphics with no updates were renumbered accordingly and are not included in this draft bulletin. 4.1.3 3-D Secure Interface Templates Figure 4.2 illustrates the zones and placement of UI data elements within the zones in landscape mode. Figure 4.2: UI Template Zones—Landscape Note: The Cancel action can be implemented as a function on a controller for the platform. The 3DS SDK shall: [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 and Figure 4.2. The expected format is depicted in sections 4.2.3 and 4.2.6. The ACS shall: [Req 359] For the App-based HTML UI Type and Browser-based UI, create HTML with form elements within the applicable zones as outlined in Figure 4.1 and Figure 4.2. The format is outlined in sections 4.2.6 and 4.3.3. Figure 4.3Figure 4.2 through Figure 4.4 illustrate the consistency of the look and feel across device channels and implementations. Figure 4.4 illustrates the consistency of the UI in landscape mode. Figure 4.4: UI Template Examples—App-based—Landscape Figure 4.5: Sample Native UI OTP/Text Template with/without Device Header Note: The device header is optional and may not be present depending on the 3DS Requestor implementation and OS constraints. Figure 4.5 depicts sample formats with or without a device header.

4.2.1 Processing Screen Requirements Figure 4.7Figure 4.4 and Figure 4.8 provide sample formats for the App-based Processing screen that contains both the Processing Graphic and the Logo.

Figure 4.8: Sample App-based Processing Screen—Landscape 4.2.1.1 3DS SDK/3DS Requestor App The 3DS SDK shall for the AReq/ARes message exchange: [Req 143] Integrate the Processing Graphic and if requested, the DS logo into the centre of the Processing screen as depicted in Figure 4.7Figure 4.4 and Figure 4.8 with or without a white box. The 3DS Requestor App shall for the AReq/ARes message exchange: [Req 145] Display the Processing screen supplied by the 3DS SDK during the entire AReq/ARes message cycle and overlay on the merchant checkout page including the overlay the Header Zone as depicted in Figure 4.7Figure 4.4 and Figure 4.8. The 3DS SDK shall for the CReq/CRes message exchange: [Req 389] Ensure that the Cancel action is not actionable while displaying on the Processing screen. 4.2.2.1 3DS SDK/ACS The 3DS SDK shall for the CReq/CRes message exchange: [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 and Figure 4.2. The expected format is depicted in Sections 4.2.3 and 4.2.6. [Req 369] Display Provide the Cancel action. This can be implemented as a button in the top corner of the header zone as depicted in Figure 4.1 and Figure 4.2 and/or as a function on a controller for the platform.

4.2.3 Native UI Templates Figure 4.11Figure 4.4 through Figure 4.21Figure 4.9 depict sample Native UI Templates. The UI content is provided by the ACS in the CRes message which contains the information needed to properly display the UI. Figure 4.11Figure 4.8 and Figure 4.12 provide sample formats for a one-time passcode (OTP)/Text during a Payment Authentication transaction. This sample UI provides a format using expandable fields for additional information. Figure 4.12: Sample Native UI OTP/Text Template—PA—Landscape Figure 4.14Figure 4.10 and Figure 4.15 provide sample formats that allow multiple options to be presented to the Cardholder to obtain single response. For example, asking the Cardholder if they prefer the OTP to be sent to the Consumer Device or to the email address on file. Note: To optimise the Cardholder experience, the Challenge Selection Information can be displayed horizontally or vertically in landscape.

Figure 4.15: Sample Native UI—Single-select Information—PA—Landscape Figure 4.16Figure 4.11 and Figure 4.17 provide sample formats that allows multiple options to be presented to the Cardholder to obtain multiple responses on a single screen. For example, asking the Cardholder to select the cities where they have lived. This example also depicts a screen with no Issuer or Payment System branding. Note: To optimise the Cardholder experience, the Challenge Selection Information can be displayed horizontally or vertically in landscape. Figure 4.17: Sample Native UI—Multi-select Information—PA—Landscape Figure 4.18Figure 4.12 and Figure 4.19 provide sample OOB formats to display instructions to the Cardholder.

Figure 4.19: Sample OOB Native UI Template—PA—Landscape 4.2.4.3 3DS SDK The 3DS SDK shall: [Req 154] Control the l

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