This wiki is for discussion purposes and does not represent consensus. Questions? Contact the Web Payments Working Group ([email protected]).

Goals

In scenarios where near-zero user interactions are desired or Web Authentication is unavailable, to improve on the status quo of risk engines using JavaScript to get as much data as possible without user consent, it is desirable to do the following:

• Offer higher value or more reliable data to risk engines than what can be achieved today through JavaScript. For example, browsers have information about CPU and GPU but do not make it available through ordinary JavaScript queries.
• Increase confidence in the accuracy of this data by having browser makers "vouch" for it (expressed through digital signatures).
• Give users the ability to consent to or deny the sharing of this data.
• Provide mechanisms to further limit sharing of this data to unauthorized parties.
• Enable browsers to share more or less data with these parties based on browser confidence in payment handlers.

Notes on attack vectors

• Browsers may be compromised. Therefore we consider how browser makers can play a role in "vouching" for the integrity of a browser as part of increasing confidence in device data returned by a browser API.
• Merchant Web sites may be subject to cross-site scripting attacks, which could tamper with JavaScript from an issuing bank injected as part of a payment flow. Therefore, we consider how an API called in a restricted context (namely payment request event handling within a Web-based payment handler) can reduce XSS attack risk.
• Payment handlers may be bad actors. Therefore, we consider mechanisms such as whitelists to reduce the risk of fraudulent payment handlers.

How it Could Work

Flow diagram

For discussion, let's call this browser API the Device Data API. Below we assume it is used by Web-based payment handlers (using Payment Handler API).

• During checkout, the user pushes the "buy" button which invokes Payment Request API.

• The browser shows the matching authorized payment handlers. The browser may use a variety of approaches to determining whether a payment handler is authorized, including through a payment method manifest, a safe browsing whitelist, etc.

• The user selects a Web-based payment handler to make a payment. The payment handler calls the Device Data API.

• The browser does some checks here such as determining whether the call is made in a valid service worker context and checking whether user has granted consent to share Device Data with the payment handler origin. The browser may trigger errors.

• The call to the Device Data API includes:

  • A list of high-value data fields the payment handler wants (from among a standardized list; for example see Chrome's fingerprint.proto, which is only available in very restricted contexts today.)
  • A URL identifying a payment handler public key (used for encryption). The browser should check that the origin of this URL is the same as the origin of the payment handler (service worker) scope.
  • A globally unique identifier for this transaction.

• The browser sends a "request to sign the data" to the browser maker server. The request includes:

  • The data set requested by the payment handler. The browser can further reduce the data set based on its own risk assessment of the payment handler. The data is then encrypted by the browser using the public key retrieved from the payment handler server. This ensures the browser maker server does not have access to the data.
  • A URL for retrieving a public key from the payment handler server.

  Note: Because of the server connection, some information about the transaction is shared, namely which payment handler the user is using. We expect browser maker servers to implement privacy protection mechanisms in light of this interaction.

  Note: One can imagine implementations where the browser does not contact a remote server but instead leverages secure hardware services on a device. It seems like the protocol should allow for that. Note that the payment handler would still need to fetch a key for validation.

• The browser maker's server performs two proprietary operations:

  • A determination of the integrity of the browser. For example, if the user is logged into a Google account, Google might use proprietary approaches to assess risk.
  • A risk analysis of the payment handler that made the call (e.g., via certificates or certification by third parties).

  The server then:

  • Signs the encrypted data and the original globally unique identifier using browser maker private key.
  • Encrypts (using payment handler public key) and signs (using browser maker private key) an indicator of trust in the browser integrity. In its simplest form, the indicator could be binary (trust/don't trust). Note that if the server does not trust the browser, it will still respond (via the browser) to the payment handler but not provide any data. If a corrupt browser forges the server signature, that can be detected by the payment handler. If the server trusts the browser but not the payment handler, the server will warn the browser who should not return any data to the payment handler.

• If successful, the payment handler decrypts the response data, confirms via the signature that the browser maker trusts the browser, verifies that the response includes the unique identifier originally sent by the payment handler, and feeds it to a risk engine.

FAQ

What is additional background for this proposal?

WebAuthn and other FIDO2 specifications collectively enable users to authenticate easily to online services with desktop or mobile devices with phishing-resistant security. The protocol offers strong security properties in conjunction with streamlined, multifactor authentication. Single-gesture multifactor authentication promises to enable streamlined and secure payments.

Web Authentication involves an enrollment operation, and some parties have indicated concerns about the user experience friction that would add to some types of transactions.

To further reduce friction, EMVCo's 3D Secure 2 specification, for example, takes this two-step approach:

• JavaScript is injected into a merchant site to create a device fingerprint that issuing banks use as input to risk analysis. The issuing bank can tell the merchant that the risk is low, and the merchant will likely have the payment authorized without further user interactions.
• Or, the issuing bank can request a "step up", essentially an explicit user authentication to gather additional information for risk analysis.

From a browser perspective, JavaScript for device fingerprinting is an anti-pattern because doing so breaches privacy in non-transparent ways and browsers are constantly looking for ways to protect user privacy. In addition in some contexts (such as desktop browsers), an extension can intercept arbitrary JavaScript calls and change their results.

Rather than continue the status quo of an arms race between browsers and payment handlers, the following is an attempt to establish a framework that works for both parties. It should be recognized that financial institutions frequently feed the "signals" from browsers into black-box machine learning algorithms (often operated by third parties, e.g., FireEye). There is no one signal that indicates risk and the resulting risk scores are constantly changing in real-time based on real-world conditions. Thus, a risk score cannot be performed by a browser and a browser can only serve to provide the signals back to the algorithms that have a more global perspective.

In what follows we mostly refer to Web-based payment handlers, although we could broaden the discussion to native apps as well.

What are the incentives for various stakeholders to use this?

Users

• Ability to grant explicit consent to share data with trusted parties in exchange for a seamless payment experience.

Merchants

• Lower friction for users at checkout
• Easier checkout development and maintenance (since no JavaScript injection)
• Better performance (faster page loads)

Issuing Banks

• High value data not otherwise available through JavaScript
• Browser confidence signals about data accuracy.
• High quality, trusted payment handlers can access more data, increasing their value to customers.

Browsers

• Provide users with increased security and privacy, and a good user experience. Creating this type of API would be consistent with other efforts to reduce silent access to user data such as ITP2.
• Ability to distinguish themselves in the market by tailoring data they are willing to return to payment handlers based on their own risk analysis.
• Increase opportunities for risk detection (since browsers will communicate with browser maker servers).
• Increase user trust in Web commerce.

Card Networks

• Help certify payment handler quality in the ecosystem (e.g., to inform browser risk assessments).
• The data available through this API can be used within a framework such as 3DS2.

When might this API be of interest compared to WebAuthn?

WebAuthn shows great promise, especially with imminent one-touch multifactor authentication user experiences. However, one can imagine some scenarios where a Device Data API might be of interest:

• If the user prefers less friction (e.g., one less user gesture, no need for hardware) with trusted payment handlers.
• If the user's environment does not yet support WebAuthn, or the user has no compliant hardware.
• As a complement to WebAuthn to gather additional data, with user consent.

Notes and Questions

• This mechanism requires server calls, but we are assuming the user is online during the e-commerce transaction. However, some server calls might be substituted for secured on-device activities in some caess.
• As the risk ecosystem evolves and the value of different signals changes, the API could evolve without developers having to change code.

Acknowledgments

Bits and pieces of this document were provided by Rouslan Solomakhin, Ian Jacobs, and Adam Powers.