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.
• Some current and emerging signals include Web Authentication, token binding (see slide deck and piece by MS and intent to implement by Google), device fingerprinting through JavaScript, and persistent cookies.
• 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.

Browser-Based Risk Analysis Signals for Discussion

• A device data API where the browser returns high value device data with user consent to authorized payment handlers.
• A standard for a privacy-protecting user confidence score from the browser
• An API for a user-resettable opaque string that, when paired with payment credentials, increases confidence over time in payments associated with those credentials.
• Browsers doing fingerprinting (natively, not through JavaScript) as part of 3DS2 or similar flows. See 3DS Data Sources.

TPAC Discussion Ideas

Tuesday (WPWG)

• Clearly establish what different parties want
• What do we need to do to make Web Authentication a success (e.g., demonstrating streamlined user experience).
• Determine whether there are any use cases (e.g., guest checkout) for which WebAuthn is not the desired approach. If so, is there interest in a browser API to provide additional signals?
• Identify gaps in those approaches and which working group or organization might work on what

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

Notes

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.
• Question: What is the status of authentication caching discussions? (See FIDO & PSD2)