Authentication

This wiki is for discussion of approaches to understanding risk analysis in payment flows, and the role of various Web technologies (such as Web Authentication, Token Binding, and other ideas) in augmenting risk signals.

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

Background

• Different parties in the e-Commerce ecosystem use a variety of signals from the user, merchant, browser, and other parties to assess transaction risk and reduce fraud. Confidence in specific signals may change over time, and new Web technologies such as Web Authentication add to the toolkit of available signals.
• Regulatory bodies (e.g., in Europe via PSD2 but also in other parts of the world) are increasingly requiring multifactor authentication as part of fraud reduction.
• W3C is working with partners in the payments ecosystem such as the FIDO Alliance and EMVCo to understand risk analysis requirements, user privacy expectations, user experience, and current practices.
• The usual tensions between security, privacy, and usability are present in these approaches:
  • Web Authentication supports a variety of strong assurances, but requires enrollment.
  • Device fingerprinting (e.g., as envisioned by the 3D-Secure 2 specification) reduces user friction but involves sharing device information with third parties (issuing banks, in the case of 3-D Secure 2) without explicit user consent.

Goals

• Build shared understanding of risk analysis needs of different stakeholders, and emerging Web technologies that can inform risk analysis.
• Determine whether different stakeholders —users, browser makers, card networks, banks, and merchants— see opportunities to improve current JavaScript fingerprinting practices and promote privacy-protection.

Best Practices

Cascade of approaches

Authentication for a transaction can use any of the mechanisms below, with preference to the order in which they are listed. If the most preferred method isn't available, then the next method can be tried, and so on.

1. Web Authentication
2. Token binding (see slide deck and piece by MS and intent to implement by Google)
3. Device fingerprinting through a browser API (with user consent to authorized payment handlers)
4. Device fingerprinting through JavaScript

Note: The value of these assurance signals may change over time based on how the ecosystem (and fraud) evolves.

Web Authentication User Experience

• Under WebAuthn it is be possible to use a single device touch for 2-factor authentication (e.g., biometric and / or PIN-based user verification that represents both possession of a device and information about and / or knowledge of the user).
• Where it is necessary to use a password as part of 2-factor authentication, users can take advantage of the browser's password manager to reuse stored credentials. We should also look at the role of the Credential Management API here.
• Quesiton: What is the status of authentication caching discussions? (See FIDO & PSD2)

Browser APIs to provide data to authorized payment handlers

Currently, payment handlers have implemented a practice of "fingerprinting" users through their browsers to identify risk attributes for a transaction. From a browser perspective, this is an anti-pattern -- user agent fingerprinting breaches privacy in non-transparent ways and browsers are constantly looking for ways to prevent user agent fingerprinting.

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.

Benefits

• Privacy enhancements
  • One aspect of payment handler authorization is quality control by the payment method owner. For example, a payment method owner might use a payment method manifest to whitelist payment handlers that are authorized to invoke a device-data API. Payment handler authorization can thus be distributed to payment method owners.
  • Another aspect of payment handler authorization is user consent. Users can explicitly consent to sharing some or all of a set of standardized data with a payment handler, and this can be done through a better and more consistent user experience. This is a more transparent approach than sharing data with unidentified parties (e.g., to issuing bank JavaScript embedded in a merchant site).
  • User data related to payment would be sent to the party carrying out the payment on behalf of the user, rather than to the merchant.
• Developer benefits
  • A standard API would lower the cost for developers of gathering the data, since they will not have to create and maintain JavaScript themselves.
  • It can also potentially increase data reliability and consistency.

In addition, we should discuss a standard for privacy-protecting user confidence signals from the browser that could further enhance risk analysis capabilities.

How it might work

• Payment handler receives control from browser via Payment Handler API.
• Payment handler invokes a method to request device data. The payment handler can request specific fields (or "all") from a standardized data set.
• Browser confirms payment handler is authorized to request data, returns data (or error). Browser may not return all the data that was requested for a variety of reasons (e.g., user chooses not to share a piece of information).
• Browser could encrypt data with public key. For example, if the browser knows who the issuing bank is, the browser could encrypt the data with the bank's public key.

TPAC Discussion Ideas

Tuesday (WPWG)

• Clearly establish what different parties want
• Establish whether the cascade described above makes sense, is "complete," should be further developed. What do we need to do to make Web Authentication a success (e.g., demonstrating streamlined user experience).
• Identify gaps in those approaches and which working group or organization might work on what
• Get more browser vendor perspective

Wednesday

• Invite WebAppSec and TAG to a breakout session
• Debrief on Tuesday discussion with WebAppSec, and continue as deemed useful
• Place this conversation in Web App Sec context (e.g., via OWASP top 10)
• Hear Web App Sec ideas/concerns

Other Resources

• 3DS Data Sources