Risk Analysis, Device Identification, and Privacy

Overview

• EMV^® 3DS goals and limitations
• Discussion about potential improvements

EMV® 3DS Design Goals

• Remove explicit user enrollment (auto-enrollment done by issuer)
• Avoid friction during transaction (most of the time)
• Use consistency of device identification for risk analysis by issuer
• Avoid data corruption by securing the channel between user environment and card network (since network-to-issuer already secured)
• Satisfy regulatory requirements (e.g., Europe, India, South Africa, Singapore, etc.)
• Consistent user experience

Different EMV® 3DS Trust Environments

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

Some Comparisons

	SDK	JS
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.

Limitations to this Approach

• Limited accuracy
• 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

Note: use case for bank-issued payment handlers since user visiting origin doing risk assessment

On FIDO2

Some comments Ian has heard:

• Roll-out of FIDO2 is in progress, but not yet ubiquitous on either the authenticator side or the relying party side.
• 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), implies enrollment friction.

On Browser-generated Identifiers

• Would not require enrollment
• Cf. advertising IDs for native apps (IDFA, AAID)
• Should this be added to the Web?

Browser-generated ID Criteria

• "Unique"
• Does not include PII
• Not reused across origins
• Resettable by user
• Proof ID was generated in trusted environment (e.g., signature)
• May need information about who minted it (e.g., version info)
• Not required: same ID used by all browsers on same device

Discussion Topics

• Low-friction FIDO2 enrollment
• Leveraging authentication by other parties (e.g., user is logged into Google account)
• Browser-generated IDs that are secure, resettable, origin-bound. What are security requirements in more detail?
• Other related topics (e.g., EATs)?

Note: Good to find solutions that work for multiple payment methods!