Device Acknowledgement Message Extension

Business Overview

The Split-SDK was introduced with v2.3.1 of the Core Specification, but some 3DS Requestors were willing to operate the Split-SDK in a 3DS v2.1 or v2.2 environment. The Device Acknowledgement Message Extension enables the 3DS Requestors to communicate to the ACS that the transaction originates from the Split-SDK for a v2.2. authentication.

The Device Acknowledgement Message Extension carries data related to the Split-SDK to the ACS for use in risk decisioning.

In response to the Device Acknowledgement Message Extension in the AReq message, the ACS can acknowledge data received in the EMV 3-D Secure SDK Device Information, particularly for Device Information Data Version 1.3 or higher.

Benefits by Actor

Merchant
  • ability to operate a Split-SDK for all 3DS protocol versions
Issuer
  • understands that the transaction originates from a Split-SDK, and adjusts the risk analysis and challenge accordingly (for more information, refer to the Split-SDK section).
DS
  • monitors the use of Split-SDK across the different protocol versions
  • monitors what Device Information versions are supported by the ACS.

 

Technical Features

 

The Device Acknowledgement Message Extension is present in the AReq message version 2.2.0 for the App-based flow, when the transaction originates from a Split-SDK.
The Device Acknowledgement Message Extension is only present in the ARes message version 2.2.0 if the ACS:

  • acknowledges the supported Device Information, and/or
  • provides additional data to the Split-SDK in case of a challenge (Transaction Status = C).

Table 6.1 below lists the data elements that may be provided in relation to the Device Acknowledgement Message Extension.

Table 6.1: 3DS Data Elements Related to the Device Acknowledgement Message Extension

Data Element/Field Name

Description

Version

Extension Version Number

Version number of the message extension.

2.2

Default-SDK Type

 

Indicates the characteristics of a Default-SDK.

SDK Variant: SDK implementation characteristics

Wrapped Indicator: If the Default-SDK is embedded as a wrapped component in the 3DS Requestor App

Example:
“defaultSdkType”: {
“sdkVariant”:”01″,
“wrappedInd”:”Y”
}

2.2

SDK Authentication Type

Authentication methods preferred/supported by the 3DS SDK in order of preference.

2.2

SDK Server Signed Content

Contains the JWS object (represented as a string) created by the Split-SDK Server for the AReq message.

2.2

SDK Signature Timestamp

Date and time indicating when the 3DS SDK generated the Split-SDK Server Signed Content converted into UTC.

2.2

SDK Type

 

Indicates the type of 3DS SDK.

This data element provides additional information to the DS and ACS to determine the best approach for handling the transaction.

2.2

Split-SDK Type

 

Indicates the characteristics of a Split-SDK.

Split-SDK Variant: Implementation characteristics of the Split-SDK client

Limited Split-SDK Indicator: If the Split-SDK client has limited capabilities

Example:
“splitSdkType”: {
“sdkVariant”:”01″,
“limitedInd”:”Y”
}

2.2

Split-SDK Server ID

DS-assigned Split-SDK Server identifier.

Each DS can provide a unique ID to each Split-SDK Server on an individual basis.

2.2

Authentication Method

Indicates the authentication types that the Issuer will use to challenge the Cardholder when in the ARes message or what was used by the ACS when in the RReq message.

2.2

Device Information Recognised Version

Indicates the highest Data Version of the Device Information supported by the ACS.

2.2

Device User Interface Mode

Indicates the user interface mode that the ACS will present to the Cardholder for a challenge. 

2.2