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 (3DS) 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 look at the data necessary to initiate a 3DS flow and which parties "know about" that data. In order for a payment handler (browser or third party) to initiate a 3DS flow, the payment handler would presumably need access to all the data known to the browser.

Data Requirements

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

The fields below were drawn directly from JSON Message Samples version 2.1.0.

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.

Data Known to 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.)

Data about the browser

Note: This is the data that might be made available through a new browser API.

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

Data Potentially Known to the Browser

Data about the merchant / transaction

The following come from the merchant and should thus be considered for inclusion 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 Known to the Payment Handler

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

Defined in Basic Card

• 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)

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.