3DSDataSources

This is a draft document with no consensus. It is for discussion purposes. Questions? Ian Jacobs <[email protected]>.

Background

Some aspects of 3-D Secure 2 risk analysis involve device fingerprinting through JavaScript. The Web Payments Working Group has discussed the idea of creating a browser-based API for providing data to authorized parties. This offers an opportunity to improve privacy over the status quo.

In this document we organize 3DS data requirements by source, providing clues to what additional information might be needed through different APIs so that a payment handler can initiate a 3DS flow.

Data Requirements

EMVCo's 3-D Secure 2 specification defines data requirements in section "B.1 AReq Message Data Elements".

In the Payment Request ecosystem, some data that would be provided as input to a 3-D Secure 2 flow comes from a variety of sources:

• The merchant via Payment Request API
• The merchant via an extension to Payment Request API (cf the draft 3-D Secure 2 with Payment Request API)
• The browser as implementer of Payment Request API (e.g., shipAddrCity)
• The payment method data stored either in the browser or payment handler (e.g., acctNumber)
• 3-D Secure protocol data that is managed by the payment handler (browser or third party).
• Other data (e.g., browserIP, browserUserAgent) typically retrieved through JavaScript calls from a merchant site or via included JavaScript.

Mapping AREQ Data to Sources

In the following sections we organize the AReq Message Data Elements into their different sources (within the Payment Request API ecosystem). This intends to suggest a limited scope for a new browser API that would return some of the data elements to authorized parties.

The data is drawn from JSON Message Samples version 2.1.0.

Data Managed by the Browser

Defined in Payment Request API

• email
• homePhone
• mobilePhone
• workPhone
• shipAddrCity
• shipAddrCountry
• shipAddrLine1
• shipAddrLine2
• shipAddrLine3
• shipAddrPostCode
• shipAddrState
• purchaseAmount
• purchaseCurrency
• purchaseExponent
• shipIndicator (Indicates shipping method chosen for the transaction.)

Defined in Basic Card

Note: This may also be managed by the Payment Handler

• cardExpiryDate
• acctNumber
• billAddrCity
• billAddrCountry
• billAddrLine1
• billAddrLine2
• billAddrLine3
• billAddrPostCode
• billAddrState
• cardholderName
• acctType (credit, debit; if removed from Basic Card this will be data managed by the payment handler)

Other Data that the Browser Might Provide through an API

• browserAcceptHeader
• browserIP
• browserJavaEnabled
• browserLanguage
• browserColorDepth
• browserScreenHeight
• browserScreenWidth
• browserTZ
• browserUserAgent

Data from the Merchant/PSP

Defined in 3DS Extension to Payment Request API

The following are being discussed in 3-D Secure 2 with Payment Request API

• acquirerBIN
• acquirerMerchantID
• merchantCountryCode
• merchantName
• merchantRiskIndicator
• mcc (merchant category code)
• transType (transaction type, such as goods and services, check acceptance)
• threeDSRequestorChallengeInd (variations on whether merchant wants a challenge flow)
• reorderItemsInd
• preOrderPurchaseInd
• preOrderDate
• recurringExpiry
• recurringFrequency
• purchaseInstalData (Indicates the maximum number of authorisations permitted for instalment payments.)

Data Managed by the Payment Handler

Note: A browser may choose to operate as a payment handler.

3DS Protocol data

• threeDSCompInd
• threeDSRequestorID
• threeDSRequestorName
• threeDSRequestorURL
• threeDSServerURL
• threeDSServerTransID
• threeDSServerRefNumber
• messageCategory (payment or non-payment)
• messageType (AREQ)
• messageVersion (3DS version number)
• threeDSRequestorAuthenticationInd (nature of this authentication request)
• threeDSRequestorAuthenticationInfo (Information about how the 3DS Requestor authenticated the cardholder before or during the transaction)
• threeDSRequestorPriorAuthenticationInfo (Information about how the 3DS Requestor authenticated the cardholder as part of a previous 3DS transaction.)
• threeDSServerOperatorID
• dsReferenceNumber (directory server info)
• dsTransId (directory server info)
• dsURL (directory server info)
• broadInfo (Unstructured information sent between the 3DS Server, the DS and the ACS.)
• payTokenInd (A value of True indicates that the transaction was de-tokenised prior to being received by the ACS.)
• messageExtension

User account data

• acctInfo (detailed information about the cardholder known to the payment handler)
• acctID

Computable data

• purchaseDate
• addrMatch (boolean: do billing and shipping addresses match?)
• deviceChannel (02 = browser, 03?)

Unsure

• deliveryTimeframe. Might come from merchant or might be determined by data known to the brower.
• deliveryEmailAddress. PR API does not yet include this.
• giftCardAmount, giftCardCurr, giftCardCount. Some of this might be known to the browser (but depends on card type).

Privacy and Security Considerations

• The browser may limit access to this API to authorized origins. In the case of the Payment Request API ecosystem, one way to authorize origins is through a Payment Method Manifest.
• The browser must receive user consent before sharing data with these authorized origins. There may be different consent granularities.