Privacy and Web Payments

Background

• During TPAC, Web Payment Security IG rated privacy in payments as a priority
• Goal: series of chats with PING about current and emerging technologies
• Inaugural chat: EMV^® 3-D Secure (3DS)

EMV® 3DS Design Goals

• Use consistency of device id for risk analysis by issuing bank ("issuer")
• Remove explicit user enrollment (auto-enrollment done by issuer)
• Avoid friction during transaction
• Avoid data corruption by securing the channel between user environment and card network (since network-to-issuer already secured)
• Satisfy regulatory requirements (Europe, India, South Africa, etc.)
• Create a consistent user experience

Different EMV® 3DS Trust Environments

• Controlled (SDKs for Android, iOS, Windows Mobile)
• Open (JavaScript for Web)

Some Comparisons

	SDK	JS
Software Certification	Yes	No
Data Encryption	Yes	No
Unique ID	Yes	No
UX Controlled*	Yes	No

Web approach: Browser fingerprinted via injected JS from issuer.

^*Not covered in this deck.

EMV® 3DS on the Web

• User enters card info in PSP form (part of merchant page).
• PSP requests authentication from issuer (3DS handles routing). Invisible iframe from issuer injected to fingerprint device
• Frictionless: If issuer satisfied by data, returns auth results without explicit user gesture.
• Step-up: Otherwise, issuer requests user auth; merchant shows issuer challenge through iframe; issuer returns auth results.

Note: We expect similar flows with payment handlers instead of merchant-side PSP.

Limitations to this Approach

• Limited accuracy
• Potential spoofing
• Browsers will limit fingerprinting (cf. Safari ITP and Firefox ETP)
• Lacks privacy protection (e.g., cannot be turned off or reset)

How can we improve this?

On Cookies

• Why not just use cookies after first visit?
• Cross-origin: user at merchant origin but JS from issuer origin
• If set by merchant origin, subject to spoofing en route to issuer

On FIDO2

• FIDO and EMVCo are working on FIDO data as input to 3DS flows to reduce need for step-up.
• Why not just use FIDO instead of 3DS? Some reasons cited:
  • Typically more data sought for better risk assessment.
  • Roll-out of FIDO2 not yet ubiquitous.
  • User may prefer "no authentication gesture" with trusted merchants.
  • Authentication is only as strong as the initial enrollment (ID & V), suggests explicit enrollment friction.

Discussion Topics

• Alternatives to fingerprinting (e.g., trust tokens)
• Cacheing FIDO2 authentication results
• Low-friction FIDO2 enrollment
• Delegated authentication (e.g., user is logged into Google account)

Questions from EMVCo (1/3)

• Beyond limiting third party cookies, what specific information will be limited by browsers and in what time frame?
• What is the impact of the restrictions on the ability of third party device ID vendors (e.g., ThreatMetrix, In-Auth and mSignia) who currently access 100+ variables from the browser to identify a specific device?
• What impact will this have on authentication techniques based on behavioral biometrics (e.g., typing speed or finger pressure on the screen)?

Questions from EMVCo (2/3)

• Do the browser vendors see a difference between identifying a user and identifying a device?
• What device identifiers (managed through browsers and with user consent) could be offered through browsers that will allow device identification/binding to continue or improve for issuer risk assessment?

Questions from EMVCo (3/3)

• Limiting fraud will affect both advertising and removing payment fraud, but these are different use cases. What options are available (e.g., FIDO, trust tokens) to meet privacy objectives without sacrificing payment security? Can we outline a migration path and timeline from the existing mechanisms to a new world?
• On what time frame could PING review 3DS?