Device Binding during Web Payments

Reminder of overall UX goals for Web payments

• Avoid redirects (keep user in merchant context)
• Reduce number of registrations (e.g., through credential use cross-origin)
• Support streamlined strong authentication
• Support privacy-friendly risk assessments
• Create UX consistency across merchants, banks, and payment systems

Objectives to aid in fulfilling authentication requirements

• Provide cryptographic evidence that offers significant confidence to a relying party operating in a third-party context that they have seen this device‡ previously.
• Leverage the full range of Web APIs in development, in particular SPC.

Device binding mechanisms and properties

Why not just use 3p cookies?

👍: Can be used to silently confirm for a returning user that WebAuthn can be used on this device.

👎:

• 3p cookies are at risk, and in any case different browsers support 3p cookie creation differently
• Cookies set in a 1p context (e.g., during an ID&V process) are not available in a 3p context (e.g., during authentication)
• Even when set may not persist for long
• Risk of theft reduces their value (cf DBSC design)

Idea for how to use APIs in combination

Potential good practice

• Any successful ID&V process can/should be followed by the (silent) establishment of a DBSC session with that origin and an option for the user to do an SPC registration.

Discussion

• Are there other reliable approaches to device binding not mentioned here?
• From a regulatory perspective, do the signatures (cryptographic evidence) need to be done by the authenticator or can they be done by the browser?
• The proposed good practice is to establish a DBSC session after successful ID&V. Would it also be useful to establish a session in the case of failure as a future risk signal?
• What changes are needed (if any) to these APIs to make them useful when used in combination?