SB nº 227: EMV® 3-D Secure Key Features

EMV^® Specification Bulletin No. 227 September 2021 EMV^® 3-D Secure Key Features v2.3.0.0 This Specification Bulletin No. 227 introduces new 3-D Secure features included in version 2.3.0.0 of the 3-D Secure Protocol and Core Functions Specification.

Applicability

This Specification Bulletin applies to:

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

Related Documents

EMV^® 3-D Secure Protocol and Core Functions Specifications, Version 2.1.0, 2.2.0

Effective Date

• September 2021 countries. Contents EMV^® 3-D Secure Key Features v2.3.0.0. Table 1. 1. Table 1. 1. Table 1. 1. Table 1. 1. 1. 1. 2. 2.1. 2.1. 2. 2.2. 2. 2.4. 2.4. 2. 3. countries. 3. 3.2. 3.2. 3. countries. 3. 3. 4. 4. Figure 4. Figure 4. countries. Figure 4. 4.2. 4.2. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. countries. 4.2. 4.2. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. Figure 4. 4.2. 4. 4.3. 4.3. Figure 4. Figure 4. 5. 5.1. 5.1. 5.1. 5.1. countries. 5.1. 5. 5.5. 5.5. 5. 5. 5.7. 5. countries. 5.8. 5.8. 5. 5.9. 5.9. 5.9. 5.9. 5.9. 5. 6. 6.2. 6.2. 6.2. 6.2. A. Table A. A. Table A. A. Table A. A. countries. Table A. A. Table A. Table A. Table A. A. A. A.13. Table A. A.13. Table A. A.13. Table A. A.13. Table A. A.13. Table A. A.13. Table A. A.13. Table A. A.13. A.13. A. Table A. A.14. Table A. A.14. Table A. A. A. A. A. A. A. A. countries. B. Table B. B. Table B. B. Table B. B. Table B. B. Table B. B. Table B. B. B. countries. Throughout Specification To facilitate enhanced version number management, a fourth digit is added to the 3-D Secure Protocol and Core Functions Specification version number: 2.3.0.0. Data Element name/Terminology updates:
• ACS Start Protocol Version/ACS End Protocol Version data elements updated to a single element: ACS Protocol Version
• DS Start Protocol Version/DS End Protocol Version updated to a single element: DS Protocol Version
• BIN range to card range.
• All instances of White List, whitelisted, whitelisting updated to Trust List. Figure 4.26 and Figure 4.27 were updated to include this data element update.
• All instances of challenge window changed to challenge iframe.
• Annex A Section and Table references may be updated throughout the specification to reflect changes made in Annex A for version 2.3.0.0 countries. Chapter 1 Introduction 1.3 Normative

References

Table 1.1 Normative References Reference Publication Name Bookmark IETF BCP 47 Tags for Identifying Languages https://tools.ietf.org/html/bc p47 RFC 2397 The "data" URL scheme https://datatracker.ietf.org/ doc/html/rfc2397 RFC 3986 Uniform Resource Identifier (URI): Generic Syntax https://tools.ietf.org/html/rfc 3986 RFC 791 INTERNET PROTOCOL https://tools.ietf.org/html/rfc 791 RFC 4291 IP Version 6 Addressing Architecture https://tools.ietf.org/html/rfc 4291 1.4 Acknowledgments The following ISO Standards are referenced in this specification. The latest version including all published amendments shall apply unless a publication date is explicitly stated. Table 1.2 ISO Standards Reference Publication Name Bookmark ISO/IEC 7812-1:2015 ISO/IEC 7812-1:2015 Identification cards—Identification of issuers—Part 1: Numbering system ISO/IEC 7813:2016 ISO/IEC 7813:2016 Information technology— Identification cards—Financial transaction cards ISO/IEC 7816-5:2004 ISO/IEC 7816-5:2004 Identification cards—Integrated circuit cards—Part 5: Registration of application providers

countries.

1.5

Definitions

Table 1.3 Definitions Term Definition 3DS SDK 3-D Secure Software Development Kit (SDK). A component that is incorporated intointeracts with the 3DS Requestor App. The 3DS SDK performs functions related to 3-D Secure on behalf of the 3DS Server. App Screen Orientation The orientation of the app screen display on the device, which may differ from the device orientation (for example, if the app supports Portrait-only or Landscape-only display, or if the device is in multi-window or splitscreen mode). The orientation is considered Landscape if the display is wider than it is tall, and Portrait otherwise. Base64url Encoding applied to the 3DS Method Data, Device Information, WebAuthn Credential List and the CReq/CRes messages as defined in RFC 7515. Bank Identification Number (BIN) The first six or eight digits of a payment card account number that uniquely identifies the issuing financial institution. 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). Device Binding In this specification, the process to link the Consumer Device used for a transaction to the Cardholder Account and/or Cardholder. Fully Qualified URL A Fully Qualified URL contains all the information necessary to locate a web resource, and is defined as an `Absolute-URL string` with scheme `https`, encoded in 'UTF-8' using 'url-code-points' from https://whatwg.org/. Refer to https://url.spec.whatwg.org/#absolute-url-string and to https://url.spec.whatwg.org/#url-code-points Note: A Fully Qualified URL does not contain credentials (https://url.spec.whatwg.org/#include-credentials). Example: https://server.domainname.com/acs/auth(*ret

countries.

Term Definition iframe An iframe (short for inline frame) is a frame within a frame. It is used to embed a piece of HTML content from other sources in an HTML document. Refer to: w3c: https://www.w3.org/html/wg/spec/the-iframe-element.html#theiframe-element OR whatwg: https://html.spec.whatwg.org/#the-iframe-element OOB Authentication App App on a Consumer Device that is used by the ACS to authenticate the Cardholder as part of the 3-D Secure flow, for example a mobile banking app. See Section 3.2 for details of the OOB flow. Operation Request (OReq) Message The OReq message sequence is created to communicate operational information serving as an alert, a reminder, report, or call to action. This message is not part of the 3-D Secure authentication message flow. Operation Response (ORes) Message The ORes message acknowledges receipt of the OReq message sequence. The message is created by the recipient of the OReq message and sent to the source of the OReq message. Protocol Version Defines the message interoperability between the EMV 3-D Secure components. Refers to the version of the EMV 3-D Secure specification that the component supports. Responsive Design Responsive design is an approach to make the web page content adjust to the dimensions of the device's screen for a better user experience. The approach is based on the use of three web techniques when designing the web pages:

• Flexible grid to create the web page layout that dynamically adapt to the screen width.
• Media queries to allow the page to adopt different CSS styles depending on the browser and device screen.
• Flexible media to make images scalable to the size of the viewport. Secure Payment Confirmation FIDO-based authentication to securely confirm payments initiated via the Payment Request API on a Browser (refer to Web Payments Working Group (w3.org) for additional information). Token Service Provider A role within the Payment Tokenisation ecosystem that is authorised by a Token Programme to provide Payment Tokens to registered Token Requestors. Refer to the EMV^® Payment Tokenisation Specification Technical Framework. Trust List Whitelisting In this specification, the process of an ACS enabling the Cardholder to place the 3DS Requestor on their trusted beneficiaries list. countries. Term Universal App Link WebAuthn Definition Standard HTTPS links for opening a specific mobile app, installed on a device. The implementation is platform-specific. Android App Links: https://developer.android.com/training/app-links iOS Universal Links: https://developer.apple.com/ios/universal-links Defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Refer to https://www.w3.org/TR/webauthn-2/ 1.6 Abbreviations Table 1.4 Abbreviations Abbreviation

Description

AOC Attestation of Compliance LOA Letter of Approval OReq Operation Message ORes Operation Response Message SPC Secure Payment Confirmation 1.7 3-D Secure Protocol Version Number Table 1.5 Protocol Version Numbers is removed from the Specification. Protocol Version Number statuses are now obtained in Specification Bulletin 255.

1.8 Supporting Documentation

• EMV^® 3-D Secure—Split-SDK Specification
• EMV^® 3-D Secure Browser Flow Best Practices
• EMV^® 3-D Secure Payment Token Message Extension
• EMV^® 3-D Secure Device Acknowledgement Message Extension
• EMV^® 3-D Secure Travel Industry Message Extension
• EMV^® Specification Bulletin 255—3-D Secure Protocol Version Numbers 1.9 Terminology and Conventions 3DS SDK When this specification refers to the 3DS SDK, EMVCo has defined two options for a 3DS SDK implementation. The options are as follows: countries. 1. Default SDK—Software component designed as an SDK that is integrated into a 3DS Requestor App. This SDK option is defined in the EMV^® 3-D Secure—SDK Specification, in which is referred to as the 3DS SDK. In earlier versions of this 3-D Secure core specification, this is referred to as the 3DS SDK. 2. Split-SDK—Client-server implementation of the 3DS SDK. Some functions of the Split-SDK entity can be performed by either a Split-SDK Client or a Split-SDK Server or in some situations, both. The Split-SDK has multiple variants depending on the Consumer Device and the 3DS Requestor environment. These variants include the Limited SDK, Shell SDK, and Browser SDK and each are defined in the EMV^® 3-D Secure—Split-SDK Specification. Unless explicitly noted otherwise, the term 3DS SDK applies as identified above. Refer to the applicable 3DS SDK specification for detailed information regarding the SDK options. Activate(s) the 3DS SDK Detailed information about the 3DS SDK activation can be obtained in the applicable 3DS SDK specification. Perform(s) the Challenge Detailed information about the 3DS SDK performing the challenge can be obtained in the applicable 3DS SDK specification. countries. Chapter 2 EMV 3-D Secure Overview 2.1 Acquirer Domain 2.1.1 3DS Requestor Environment 2.1.1.1 3DS Requestor To process 3-D Secure transactions:
• App-based—3DS Requestor App integrates with the 3DS SDK as defined in the applicable EMV 3-D Secure 3DS SDK Specificationspecification. The 3DS SDK displays the User Interface (UI) to Cardholders. 2.1.2 3DS Integrator (3DS Server and 3DS Client) The 3DS Integrator provides the approved 3DS SDK component or the 3DS Method functionality to 3DS Requestors for integration into with their 3DS Requestor App and/or website.

2.2 Interoperability Domain 2.2.2 Directory Server Certificate—Authority These certificates include:

• TLS client and server certificates used in the communication between the 3DS Server and the DS, and between the DS and the ACS.
• Signing Certificates used to sign messages data elements passed from the ACS to the 3DS SDK.
• Certificates used to sign data elements passed from the 3DS SDK to the DS. 2.4 3-D Secure Messages 2.4.9 Operation Request Message (OReq) The OReq message sequence is created to communicate operational information serving as an alert, a reminder, report, or call to action. This message is not part of the 3-D Secure authentication message flow.

2.4.10 Operation Response Message (ORes) The ORes message acknowledges receipt of the OReq message sequence. The message is created by the recipient of the OReq message sequence and sent to the source of the OReq message.

2.7 Challenge Flow Outline New Note added after Step 6: Note: For the Browser-based model, the CRes message is sent after Step 8.

countries.

Chapter 3 EMV 3-D Secure Authentication Flow Requirements For an App-based model, also refer to the applicable EMV 3-D Secure—3DS SDK Specification specification for detailed requirements and implementation guidelines.

3.1 App-based Requirements Step 2: The 3DS Requestor App The 3DS Requestor App uses the Cardholder Account Number and optionally other cardholder information to identify the Payment System. Payment Systems are identified by their ISO RID (as defined in Table 1.2). The 3DS Server provides to the 3DS Requestor App through the 3DS Requestor Environment the:

• Directory Server ID value (which is the Payment System’s RID) that is used to identify the key for the Device Information encryption.
• Message Version Number used in the CReq/CRes messages. The 3DS Server shall: Existing Req 11 was moved to Step 2 from Step 5 without edit. [Req 419] Use the protocol version lists from the ACS Protocol Versions and the DS Protocol Versions obtained from the PRes message and the protocol version supported by the 3DS SDK to set the highest common Message Version Number. If no PRes message information is available, then the 3DS Server may use a Message Version Number supported by the 3DS Server. The 3DS Requestor App invokes activates the createTransaction method within 3DS SDK to initiate 3-D Secure Cardholder authentication. Note: As described in the applicable EMV^® 3-D Secure 3DS SDK Specification specification, the 3DS SDK encrypts the Device Information by using the DS public key. This key is identified based on the Directory Server ID that is passed to the createTransaction methodwhen the SDK is activated. Step 4: The 3DS Requestor Environment New Note following [Req 1]. Note: For a Split-SDK refer to Section 4 of the EMV 3-D Secure Split-SDK Specification. During the execution of this Step, the 3DS SDK shall: countries. [Req 2] Obtain the Device Information, SDK Reference Number, and SDK App ID. Refer to the applicable EMV 3-D Secure—3DS SDK Specification specification and Annex A of this specification for additional detail. Step 5: The 3DS Server New Requirement (including text from Note below Step 14 after [Req 12]. Deleted Note following Req 14. 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. If no PRes message information is available, then the 3DS Server may send an AReq message for all Cardholder accounts. 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 6: The DS The DS shall: [Req 390] If the SDK Type = 02, 03, 04 or 05, verify the signature in the SDK Server Signed Content as defined in section 6.2.2.4. If the verification fails, the DS returns to the 3DS Server an Error Message (as defined in Section A.9) with Error Component = D and Error Code = 308 and ends processing. [Req 394] Determine if the SDK Type and the SDK Reference Number are valid for the transaction according to DS rules. If not, the DS returns to the 3DS Server an Error Message (as defined in section A.9) with Error Component = D and Error Code = 305 and ends processing. [Req 420] Identifies the DS public key used by the SDK to encrypt Device Information from the key identifier in the SDK Encrypted Data. If the DS detects an error with the key identifier, the DS returns to the 3DS Server an Error Message (as defined in Section A.9) with Error Component = D and Error Code = 311 and ends processing. countries. Step 7: The ACS The ACS shall: [Req 386] Check whether the SDK Device Information Data Version Number data elements correspond to the Data Version Numberis recognised. If not recognised, the ACS proceeds with processing the transaction and does not error due to the unrecognised Data Version Number. If the Device Information data elements do not match the Data Version, the ACS returns an error message (Error Code = 203) or proceeds to process the transaction. New Note following [Req 30]: Note: SPC authentication is not supported in the App-based authentication flow; therefore, Transaction Status = S is not allowed. [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, SDK Maximum Timeout and SDK Type. The ACS performs the following: No change to bullets a–e. [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: b. Sets the Authentication Method = 12. (subsequent bullets renumbered accordingly) Step 8: The DS The DS shall: [Req 421] If the DS creates the ARes message on the ACS’ behalf (for example, the DS returns a Transaction Status = A), then the DS sets the ACS Reference Number equal to the DS Reference Number and the ACS Transaction ID equal to the DS Transaction ID. countries. Step 9: The 3DS Server [Req 355] Convey If the Cardholder Information Text has to the 3DS Requestor environment. The 3DS Requestor displays the Cardholder Information Text received to the Cardholder as depicted in Section A.20been provided by the ACS for this transaction the 3DS Server shall ensure the Cardholder Information Text is displayed on the 3DS Requestor App. Step 10: The 3DS Requestor App The 3DS Requestor App invokes the "doChallenge method" performs the challenge by making a call to the 3DS SDK. Refer to the EMV 3-D Secure SDK Specification for additional information about this method. Step 14: T he 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 or for an OOB authentication (ACS UI Type = 04 or 06) refer to Section 3.2 for UI details. Step 15: The Cardholder Interaction with the 3DS SDK [Req 59] was moved from Step 16: The 3DS SDK to Step 15. [Req 59] If the Cardholder abandons the challenge during the processing of Step 12 through Step 15 the 3DS SDK sets the Challenge Cancelation Indicator to the appropriate value in the CReq message and sends the CReq message to the ACS using the secure link established in [Req 56]. Note: For ACS UI Type = 04 or 06, see Section 3.2 for OOB authentication requirements. Step 16: The 3DS SDK The 3DS shall: [Req 58] Send the one CReq message to the ACS using the secure link established in [Req 56] and wait for the ACS CRes message response before sending another CReq message.

3.2 Challenge Flow with OOB Authentication Requirements Unchanged text in this section is provided for context. An Out-of-Band (OOB) Challenge Flow is identical to a standard 3-D Secure Processing Flow as defined in Section 3.1 with the following exceptions: Step 7: The ACS recognises that an OOB interaction with the Cardholder is required.

countries.

Step 13: The challenge information in the CRes message consists only of Cardholder instructions on how to perform the OOB authentication. Between Step 13 and Step 15: The ACS initiates an OOB interaction with the Cardholder rather than interacting with the Cardholder via the 3DS SDK. During the OOB authentication the Cardholder authenticates to the ACS or a service provider/Issuer interacting with the ACS. See Section 3.2.1 for additional OOB requirements. The method used for the OOB communication and the authentication method itself is outside the scope of this specification. An example of an OOB communication could be a push notification to a banking app that completes authentication and then sends the results to the ACS. The ACS may use a combination of OOB automatic switching options (OOB App URL, 3DS Requestor App URL) to switch between the 3DS Requestor App and the OOB Authentication App following the requirements in Section 3.2.2. Step 17: The ACS receives only an acknowledgement that the Cardholder may have performed the OOB authentication, thus in [Req 61] the ACS gathers the information on whether the authentication was successful from the OOB interaction with the Cardholder instead of the CReq message. If the ACS determines that the Cardholder did not authenticate, then the ACS can update the Cardholder instructions through another CRes message. How an authentication decision is made for an OOB authentication is outside the scope of this specification, however the ACS needs access to the result of the OOB authentication before Step 18. Note: The 3DS Requestor should consider that an OOB authentication can take longer for the Cardholder to complete and therefore should adjust the 3DS SDK’s challenge time-out accordingly. The requirements defined in this section 3.2 describe the additional flow and requirements specific to ACS UI Type 04 and 06.

3.2.1 OOB Requirements This section defines additional requirements for an OOB flow. Step 15 The Cardholder Interaction with the 3DS SDK The 3DS SDK shall: [Req 399] For ACS UI Type = 04, set the OOB Continuation Indicator = 01 when the Cardholder selects the button with the OOB Continuation Label. [Req 400] For ACS UI Type = 04 or 06, if the 3DS Requestor App comes to the foreground, set the value of the OOB Continuation Indicator field = 02, and continue automatically (without UI interaction by the Cardholder) with Step 16 in the App-based flow (send a CReq message to the ACS).

countries.

3.2.2 OOB Automatic Switching Features This specification defines the following automatic switching features for an OOB authentication:

• The OOB App URL (in the CRes message) that the 3DS SDK uses to automatically switch to the OOB Authentication App when the Cardholder chooses to transfer control.
• The 3DS Requestor App URL (in the CReq message) that the OOB Authentication App uses to automatically transfer control to the 3DS Requestor App when the OOB Authentication App has concluded the Cardholder interaction. To accommodate error scenarios, when an automatic switching between the two apps is unsuccessful, the 3DS SDK automatically sends a CReq message (once the 3DS Requestor App has returned to the foreground) so that the ACS understands the latest status of the authentication attempt. The ACS may then choose next authentication steps dependent on whether an authentication via the OOB Authentication App occurred. Note that when an OOB Authentication App is on a different device than the 3DS Requestor App then automatic switching is not possible and the Cardholder must manually switch to the app on a secondary device. The following additional requirements apply if an automatic switching feature is utilised. Step 13: The ACS Before [Req 51], the ACS additionally prepares the CRes message for an OOB authentication. If using the OOB App URL feature, the ACS shall: [Req 401] For ACS UI Type = 04 or 06, set the OOB App URL to the URL value used during installation of the OOB Authentication App. [Req 402] For ACS UI Type = 06, include in the OOB challenge HTML code an action that triggers a location change to the HTTPS://EMV3DS/openoobApp URL when the Cardholder selects the button. Note: If the ACS includes additional actions (for example, Complete button) for the Cardholder in the HTML code, it uses the HTTPS://EMV3DS/challenge URL as defined in [Req 164]. Step 14: The 3DS SDK If the OOB App URL is present in the CRes message, then the 3DS SDK performs an additional requirement for this step: After having performed [Req 54], as part of [Req 55] the 3DS SDK shall: countries. [Req 403] For ACS UI Type = 04, display a button with the OOB App Label used for the switch to the OOB Authentication App. Step 15: The Cardholder Interaction with the 3DS SDK The Cardholder interacts with the 3DS SDK User Interface (UI). For example, selects the OOB Continuation button or the OOB App Label button.

3.2.2.1 OOB App URL Requirements If the OOB App URL is present in the CRes message, then the 3DS SDK shall: [Req 404] For ACS UI Type = 04, attempt to open the OOB Authentication App by using the OOB App URL when the Cardholder selects the button with the OOB App Label. [Req 405] For ACS UI Type = 06: a. Intercept a location change event that is sent to the specific HTTPS://EMV3DS/openoobApp URL. b. Attempt to open the OOB Authentication App by using the OOB App URL. [Req 406] If the attempt to open the OOB Authentication App is successful, then continue with Section 3.2.2.2. [Req 407] If the attempt to open the OOB Authentication App fails (for example, the platform method to open the OOB App URL returns an error), then: a. Set the OOB App Status to the appropriate value as defined in Table A.1. b. Set the OOB Continuation Indicator = 02. c. Continue automatically (without UI interaction by the Cardholder) with Step 16 in the App flow. Note: If the OOB Authentication App is not present on the device, then the device Operating System (OS) attempts to open the OOB App URL using the device’s default browser.