Many Signals Available

Since the risk landscape changes over time, risk engines want as many useful and trusted signals as they can get.

Device Data APIs

• Geolocation
• Web Authentication
• Vehicle Information API
• Battery Status API
• Screen Orientation API
• Device Memory

HTTP Headers

• Accept-Charset
• Accept-Language
• User-Agent
• X-Forwarded-For
• Cookie

Additional Techniques

• Font detection
• JavaScript feature detection
• CSS @supports
• OS and Hardware Level Features
• Transaction-specific data
  • Some available through Payment Request API
• Safe browsing databases

User Problems

• Some device data shared without user consent
• UX for getting user consent can be challenging
  • See the recent Workshop on Permissions and User Consent

Merchant/Bank Problems

• Some data unreliable or can be spoofed
• Higher development cost when APIs or libraries unavailable
• Regulatory changes (e.g., GDPR) will add complexity to data collection and management
• Browser vendors likely to reduce access to some user data (e.g., ITP 2)

Goals

• Provide relevant data to issuing banks, card networks, and other parties for (identity) risk analysis to reduce fraud.
• Enable low-friction user experiences to reduce cart abandonment.
• Protect user privacy, including increasing transparency about which parties receive user device data.

Is the Status Quo Good Enough?

• Device data information is broadly available and banks, card networks, and other parties to a payment are using it for risk analysis today.
• Low friction for users, but some users seek additional privacy protections.
• Is the status quo good enough? Is industry motivated to change?

Opportunity: FIDO 2

Image courtesy of Adam Powers.

On FIDO 2

• Strong signal that a transaction is valid.
• Streamlined user experience envisioned with FIDO 2: single-gesture, 2-factor authentication. Can eliminate passwords.
• Compelling properties: hardware-based, phishing-resistant, range of certified authenticators, browser support growing, etc.
• Two steps: enrollment, authentication
• "Resettable" by the user who can un-enroll then re-enroll; user can thus reduce tracking when desired.

Is FIDO 2 Good Enough?

• Will parties doing risk analysis invest in WebAuthn?
• If not, what is missing?
• What are the perceived obstacles to adoption?
• Should we just focus on WebAuthn or do we also need other approaches?
• What are expectations about cross-browser access to built-in authenticators and on what time scale?

Are There Use Cases where FIDO 2 is Not Sufficient?

Example scenarios:

• Transition period before broad adoption
• Users do not (yet) have authenticators
• For some (trusted) merchants, users may prefer a user experience without any authentication gesture.
• Authentication is only as strong as the initial enrollment (ID & V), and that enrollment is likely to involve more data
• Risk engines want supplementary data for risk analysis (e.g., user location)

Additional Ideas for Browser / Device Data

• DeviceDataAPI
• User Confidence Score by the browser or browser maker
• Browser initiates 3DS flows with data it knows

Discussion

• Is the status quo good enough? If not, why not?
• Is WebAuthn good enough? If not, why not?
• Are there other ways to use WebAuthn that provide high-value signals but don't require enrollment?
• Support for any of the proposals?

NEXT OPPORTUNITY: To discuss use cases in person is the W3C Workshop on Strong Authentication and Identity, 10-11 December in Redmond, Washington (USA). Hosted by Microsoft. Position papers due 29 October!