New release of the EMV® 3-D Secure Protocol and Core Functions Specification

Written by: Makis Gravanis

November 27, 2017 - What has changed within a year?

On the 25th October 2016, EMVCo published the first version of the EMV 3DS 2.0 Specification (EMV® 3-D Secure Protocol and Core Functions Specification v2.0.0). UL’s response to this announcement is captured in this blogpost, in which the challenges and advantages of the two versions, 3DS 2.0 and 3DS 1.0, were discussed. Considering UL’s leading role in the payment industry we could not miss the opportunity to focus on an in-depth analysis of 3 D-Secure 2.0 and provide the public with our white paper.

One year after the first release of the specifications, an updated version of the document has been published (EMV® 3-D Secure Protocol and Core Functions Specification v2.1.0). This updated version is a large collection of (small) changes and improvements to evolve the EMV 3DS 2.0 Specification. The intention was to it more consistent, easier to understand and to clarify the purpose of certain properties of the ecosystem as well as adding some new functionality such as the 3DS Requestor Initiated device channel.
This article aims to discuss and summarize the changes that have been announced regarding the recent release of the latest version of the EMV 3DS 2.0 Specification document. For simplicity, these changes have been classified according to their nature. The changes to the specification include the addition of a feature, several clarifications and additional Data Elements and Error Codes.

Additional features

In the first release of the specification only two device channels (App & Browser) were used as part of the 3DS 2.0 ecosystem. However, this situation has changed with the introduction of a new device channel; the 3DS Requestor Initiated (3RI) channel. The 3DS Requestor Initiated device channel allows 3-D Secure authentication without the presence of the cardholder. For example, this may be used by e-commerce merchants to confirm with the card issuers that a cardholder’s account is still valid. Moreover, the introduction of 3RI supports merchants with any recurring transactions. However, according to the published specifications, the 3RI device channel will only be used for the non-payment (02-NPA) message category, which permits the non-payment authentication of a cardholder (i.e. cardholder Identification & verification for mobile wallets and secure requests of tokens for card on file). As far as payment authentications are concerned, cardholders always need to be in order to avoid fraudulent transactions.

Clarifications and changes on naming, format and acceptable values

The new specifications have gone through a thorough review and many changes regarding the consistency of the ecosystem have been implemented. These changes refer to naming (e.g. acsInterface, acsUiTemplate, sdkInterface, sdkUiType, acsEphemPubKey, sdkEphemPubKey etc.), acceptable format (two-character format with leading zeros for the single character sub-fields) and value changes (zero values ‘0’, or ‘00’ became non acceptable).

Furthermore, the ambiguities in the first version of the specification (2.0.0) have been resolved. Many textual corrections and clarifications of the transaction flow have been included in the latest version (2.1.0) in order to prevent incorrect implementations arising from the previously existing ambiguities and errors. For example, the way that the interaction counter was described in the past could have led to an implementation where the counter would only increase its value in case the cardholder entered the wrong challenge data. However, the initial intention of this counter was to keep track of the number of total interactions that the cardholder has with the ACS and not only the failing ones. The new specification thus includes changes to the description of the Interaction Counter to resolve this ambiguity.
Clarifications were also given regarding the conditions under which conditional data elements are required to be present in the 3-D Secure messages. Under this update, the elements Purchase Amount and Purchase Currency are considered required fields when the 3DS Requestor Authentication Indicator equals to ‘02’ (recurring transaction) or ‘03’ (instalment transaction) for a non-payment transaction.

New Data Elements and Error Codes

Besides the above mentioned changes that relate to already existing data elements, new data elements have been introduced in the latest core protocol specification document (e.g. cardholderInfo, sdkMaxTimeout). The Cardholder Information Text (i.e. ‘cardholderInfo’) data element is introduced to allow the ACS to return additional information to the cardholder during a frictionless transaction in case of a failed authentication process. The SDK Maximum Timeout data element (i.e. ‘sdkMaxTimeout’) is one of the latest additions to the core protocol specification and indicates the maximum time that the SDK allows for a full authentication flow to be completed. More specifically, the time period from the moment that the TLS handshake has been completed and the first Challenge Request (CReq) message is sent by the 3DS SDK to the ACS until the final Challenge Response (CRes) is received by the 3DS SDK from the ACS, should not exceed 5 minutes (the minimum value a 3DS SDK is allowed to set the SDK Maximum Timeout to). Table 1 summarizes the additional data elements and provides information on which device channel and message category they are used.
Table 1 New data elements/fields introduced in the EMV® 3-D Secure Protocol and Core Functions Specification v2.1.0 (source: EMV® 3-D Secure Protocol and Core Functions Specification v2.1.0)

Data Element/Field Name

Description

Device Channel

Message Category

threeDSCompInd

“Indicates whether the 3DS Method successfully completed.”

02-BRW

01-PA

02-NPA

threeDSRequestorAuthenticationInd

“Indicates the type of Authentication request. This data element provides additional information to the ACS to determine the best approach for handing an authentication request.”

01-APP 02-BRW

01-PA  02-NPA

threeRIInd

“Indicates the type of 3RI request. This data element provides additional information to the ACS to determine the best approach for handing a 3RI request.”

03-3RI

02-NPA

acsHTMLRefresh

“Optional HTML provided by the ACS in the CRes message to be utilised in the Out of Band flow when the HTML is specified in the ACS UI Type during the Cardholder challenge. If the ACS HTML Refresh is present in the CRes message, the SDK will display it when the app is moved to the foreground.”

01-APP

 

01-PA 

02-NPA

broadInfo

“Unstructured information sent between the 3DS Server, the DS and the ACS.”

01-APP

02-BRW

03-3RI

01-PA

02-NPA

cardholderInfo

Text provided by the ACS/Issuer to Cardholder during a Frictionless transaction that was not authenticated by the ACS. The Issuer can optionally provide information to Cardholder. For example, “Additional authentication is needed for this transaction, please contact (Issuer Name) at xxx-xxx-xxxx.””

01-APP

02-BRW

01-PA

02-NPA

dsEndProtocolVersion

“The most recent active protocol version that is supported for the DS. Note: Optional within the Card Range Data (as defined in Table A.6).”

N/A

 

01-PA

02-NPA

dsStartProtocolVersion

“The most recent active protocol version that is supported for the DS. Optional within the Card Range Data (as defined in Table A.6).”

N/A

01-PA

02-NPA

sdkMaxTimeout

Indicates maximum amount of time (in minutes) for all exchanges.”

01-APP

 

01-PA

 

threeDSServerOperatorID

“DS assigned 3DS Server identifier. Each DS can provide a unique ID to each 3DS Server on an individual basis.”

01-APP  02-BRW       03-3RI

01-PA         02-NPA

acsCounterAtoS

“Counter used as a security measure in the ACS to 3DS SDK secure channel.”

01-APP

01-PA         02-NPA

acsOperatorID

“DS assigned ACS identifier. Each DS can provide a unique ID to each ACS on an individual basis”

01-APP  02-BRW       03-3RI

01-PA         02-NPA

billAddrLine3

“Third line of the street address or equivalent local portion of the Cardholder billing address associated with the card used for this purchase”

01-APP  02-BRW       03-3RI

01-PA         02-NPA

shipAddrLine3

“The third line of the street address or equivalent local portion of the shipping address requested by the Cardholder.”

01-APP  02-BRW       03-3RI

01-PA         02-NPA

sdkCounterStoA

“Counter used as a security measure in the 3DS SDK to ACS secure channel.

01-APP

 

01-PA 

02-NPA

serialNum

“If present in PReq message, the DS returns Card Range Data that has been updated since the time of the PRes message. If absent, the DS returns all card ranges. If present in the PRes message, indicates the current state of the Card Range Data (the specific value is only meaningful to the DS). The 3DS Server should retain this value for submission in a future PReq message to request only changes that have been made to the card range data since the PRes message was generated.”

01-APP

02-BRW

01-PA

02-NPA

 

Another change in the EMV 3DS 2.0 Specification document touches the Preparation Request and Response (PReq/PRes) Message Handling requirements. So far, the PReq and PRes messages were utilized by the 3DS Server to cache information about the version supported by the ACS and communicate any URL to be used for the 3DS Method call. This mechanism has been enhanced in the latest version of the specification to allow for partial cache updates. A DS can return the optional Serial Number (new added data element) in the PRes message representing the current state of the card range data. The 3DS Server can retain the Serial Number for inclusion in a future PReq message, which allows the DS to return in the PRes message only the changes to the card range data since the previous PRes message in which the Serial Number was used.
To enhance the functionality of the 3DS 2.0 ecosystem in case an error occurs, two more Error Codes have been added to the specification: Error Codes ‘307’ and ‘405’. Error Code ‘307’ is returned by the DS in case the 3DS Server includes an invalid Serial Number in the Preparation Request message. The other Error Code that was added, ‘405’, indicates a System Connection Failure during the establishment of a connection between two components.

In conclusion, it is crystal clear that EMVCo took into consideration the needs of the fast-moving market of e-commerce and put in a lot of time and effort to reviewing the document in detail. The result of this review and consequently the improvement of the specifications show that EMVCo has taken 3DS 2.0 seriously and works methodically towards changing the status quo of the online payment market. Furthermore, in contrast to 3DS 1.0, the second version (2.0) of the 3D-Secure is developed with a collective effort of a large group of people and international organizations. That indicates to us that 3DS 2.0 will be more technically consistent and will eliminate the interoperability issues that might have existed in the past. EMVCo seems to have put its expectations high regarding 3DS 2.0, but what is left to be seen now, is the market’s reaction. With the updated specifications EMVCo has expressed its intention to introduce a product that will constantly evolve, taking into consideration the e-commerce market needs.

If you are interested to deep-dive in the 3DS 2.0 specs join UL’s EMV 3-D Secure 2.0 Masterclass. Please follow the link for courses dates and further information.

Disclaimer

These are the personal opinions of UL’s employees and its guests and should not be misunderstood as representing the opinion of UL's clients, suppliers or other relations.