What's new in 3DS 2.3.1

Version 2.3.1 of the EMV® 3-D Secure (EMV 3DS) specification introduced some new functionality and changes. These are available in the 3DS Server component when the ProtocolVersion configuration setting is set to a value of 2.3.1.

Details on some of the more major changes can be found in the sections below:

• Card Range Changes
• Operation Messages
• SPC-Based Authentication
• Device Binding
• Whitelist now called Trust List
• Decoupled Authentication Fallback

Card Range Changes

In version 2.3.1 of the EMV® 3-D Secure specification, the way card ranges are returned has changed significantly. In order to support the new data format in the component, a new CardRangeData event was added, along with new Ranges and ACSProtocolInfos properties.

When the RequestCardRanges method is called, the CardRangeData event will fire for each card range data object received in the response. Within this event handler, the Ranges and ACSProtocolInfos collections can be checked to determine the ranges, as well as the protocol versions and associated information supported by the ACS for each range.

Optionally, the DS may return a list of URLs that the 3DS Server can use for communication with the DS. If present, these will be available via both the DSURL event and the DSURLs property.

When using 2.3.1, if UseJsonDOM is false, the card ranges will need to be cached and processed after the RequestCardRanges method returns. The card ranges would then need to be processed in the order indicated by the CardRangeRecordsReadOrder configuration setting. A check will also need to be made for overlap of ranges. If issue(s) are found, the ReportCardRangeError configuration setting should be used to report the error to the directory server.

New ACS Information Indicator Values

Version 2.3.1 of the specification introduced new ACS Information Indicator values. These are exposed in the Indicator property for each object in the ACSProtocolInfos collection. The new values are defined follows:

• 05 - Device Binding Supported
• 06 - WebAuthn Authentication Supported
• 07 - SPC Authentication Supported
• 08 - Transaction Risk Analysis Excemption Supported
• 09 - Trust List Exemption Supported
• 10 - Low Value Exemption Supported
• 11 - Secure Corporate Payments Exemption Supported

Operation Messages

Operation Messages provide the DS with the ability to communicate operational information to a 3DS Server or to an ACS, serving as an alert, reminder, report, or call to action. Operation Messages can be independent of, or related to, a payment/non-payment authentication transaction, and are not part of the 3-D Secure authentication flow.

Operation Messages can be used to convey operational information about the overall EMV 3DS program system health and management. For example:

• Reporting on turnaround times and performance
• Detecting and flagging rogue players in the ecosystem
• DS can communicate key exchange/certificate updates/reminders
• Exchanging information on compromised devices

When an Operation Request Message (OReq) is received, CheckResponse should be called to validate the message. Afterwards, details are made available in the Operation property.

If any OReq data element fails validation, Operation.MessageStatus will be set to 02. If the OReq is valid, Operation.MessageStatus will be empty.

There may be more than one OReq message sent in a sequence, and CheckResponse should be called for each. The current instance of the Server object can be cached for the duration of the OReq sequence until the final OReq is received. The Operation.SequenceNumber should also be set prior to calling CheckResponse. The component will verify the sequence number of the received OReq to ensure it's not out of sequence.

If the OReq is valid, determine if the final OReq has been received (Operation.SequenceNumber equals Operation.SequenceTotal). If these values match, the final OReq in the sequence has been received, and GetOperationResponse can be used to generate the ORes message.

For valid OReq messages that are not the final OReq in the sequence, the response should be HTTP Status 200 (OK) with an empty HTTP body.

SPC-Based Authentication

SPC (Secure Payment Confirmation) provides a method to perform a challenge using preestablished FIDO credentials when using a Browser. The SPC authentication can be initiated by the 3DS Requestor via an extra AReq/ARes message pair or by the ACS via a standard Browser Challenge Flow.

For an SPC authentication to execute correctly, the following prerequisites apply:

1. The ACS has an enrolled FIDO authenticator on the device for this Cardholder.
2. The 3DS Requestor and/or the ACS have detected that the Cardholder Browser supports the related SPC APIs (allow="payment *; publickey-credentialsget *"). For the ACS, this information can be obtained via the Browser User Agent data element or via data obtained via the 3DS Method.

SPC-based authentication can be enabled in the browser-based flow with the following additions:

Prior to sending the initial authentication request packet (AReq) using the SendAuthRequest method, the ThreeDSRequestorSpcSupport configuration setting should be set to Y to indicate that SPC is supported by the 3DS Requestor.

If SPC is accepted by the ACS, the resulting TransactionStatus should be S. The response will also contain a list of enrolled FIDO (WebAuthn) credentials associated with the cardholder, and SPC transaction data. This data is available in the following configuration settings:

• WebAuthnCredentialListCount
• WebAuthnCredentialListWebAuthnCredential
• WebAuthnCredListRelyingPartyId
• SPCTransactionAdditionalData
• SPCTransactionChallenge
• SPCTransactionChallengeInfoText
• SPCTransactionCurrency
• SPCTransactionDisplayName
• SPCTransactionIcon
• SPCTransactionIssuerImage
• SPCTransactionIssuerImageDark
• SPCTransactionIssuerImageMonochrome
• SPCTransactionPayeeName
• SPCTransactionPayeeOrigin
• SPCTransactionPSImage
• SPCTransactionPSImageDark
• SPCTransactionPSImageMonochrome
• SPCTransactionTimeout
• SPCTransactionValue

If a new instance of the Server component will be used after authentication to send the second AReq, the AuthenticationInformation value should be saved to be used later.

This information is relayed to the 3DS Requestor implementation, and the 3DS Requestor invokes the SPC authentication (SPC API) against the WebAuthn Credential list. The cardholder authenticates using the FIDO authenticator on their device, and the 3DS Requestor retrieves the Assertion Data from the SPC API call.

The 3DS Server is then configured to includes this FIDO Assertion Data is then included in a new authentication request by setting the ReqAuthData and a ReqAuthMethod of 09. If the AuthenticationInformation value was saved earlier, it can be set via the same configuration setting. If the 3DS Requestor encounters an error during SPC API invokation, this can be indicated using the SPCIncompletionIndicator.

The SendAuthRequest method should then be called again to transmit this data to the ACS (by way of the DS) in a second AReq.

When SendAuthRequest returns, the 3DS Server proceed the same as the regular browser-based flow when the ARes is returned.

When SPC authentication is to be performed, the authenticaton must be completed within 9 minutes. The component will automatically start an internal timer that can be checked using the CheckSPCTimeout configuration setting. This will return the number of seconds left for SPC authentication to complete. If the time has expired before receiving the Assertion Data from the 3DS Requestor, checking this configuration setting will cause the component to automatically send the second AReq message with an SPCIncompletionIndicator value of 03, indicating that SPC authentication timed out.

Device Binding

Device binding is supported in version 2.3.1 of the protocol. This enables merchants to remember consumer devices. On the challenge screen, cardholders are asked if they wish to be remembered on their device and can reduce the need for authentication challenges initiated from that device in the future.

Before a device is bound, the cardholder may be prompted during the challenge process to "remember the device." If the user gives consent, the RReq packet will contain a DeviceBindingStatus. On a subsequent transaction, the DeviceBindingStatus can be set accordingly prior to sending the authentication request.

The 3DS Server can query the DeviceBindingStatus in a 3RI transaction by using a ThreeRIInd value of 13, indicing a Device Binding Status Check. An ACSInformationIndicator value of 05 indicates that Device Binding is supported by the ACS.

Whitelist now called Trust List

In version 2.3.1 of the specification, the Whitelist concept is now referred to as a Trust List. The overall functionality is the same: allowing 3DS Requestors to maintan a trusted beneficiary list.

The ACS indicates that it supports Trust Lists via the ACSProtocolInfos.Indicator field returned when retrieving card ranges.

When sending the AReq packet via the SendAuthRequest method, the TrustListStatus config can be set to Y or N to indicate whether or not the 3DS Requestor is trust listed by the cardholder. At this time, the TrustListStatusSource should be 01, indicating that the status is provided by the (3DS Server).

There is also a Trust List status check option in the ThreeRIIndicator config. This indicates that the purpose of the 3RI transaction is to check the Trust List status.

The TrustListStatus and TrustListStatusSource configuration settings are the 2.3.1 equivalent for the WhitelistStatus and WhitelistStatusSource configuration settings used for 2.2.0.

Decoupled Authentication Fallback

New in version 2.3.1 of the specification is the concept of Decoupled Authentication Fallback, which allows for decoupled authentication to be used as a fallback mechanism if other authentication pathways fail for some reason.

To indicate support for Decoupled Fallback, a DecoupledRequestIndicator value of F or B can be used, where F indicates decoupled authentication can be used only as a fallback mechanism, while B indicates that decoupled authentication can be used as either a primary OR fallback mechanism.

When the results request (RReq) is received, a TransactionStatus of D, along with a TransactionStatusReason value of 29 or 30 would indicate that decoupled fallback should be performed. At this time, a separate 3RI transaction should be initiated within 60 seconds. The following settings should be used for the new transaction: