-
Notifications
You must be signed in to change notification settings - Fork 42
2020 Mar proposed changes
Below is a list of change proposals to discuss at the Web Payments Working Group’s March 2020 face-to-face meeting. These proposals derive from a Payment Handler Privacy Threat Model analysis.
Status:
The Payment Handler API defines Web-based payment handlers through an extension to the service worker registration interface. It is a property of service workers that they can be installed without explicit user action. For privacy and security reasons, however, we do not want the full set of payment handler capabilities to be in operation prior to some form of explicit user consent. There may be multiple opportunities to secure user consent (e.g., installation, first use).
Prior to securing user consent, browsers should not, for example:
-
Propagate events such as hasEnrolledInstrument
-
Enable ordinary "skip-the-sheet" functionality. Note: It may be possible to skip the sheet but insert a user consent step.
Browsers should also require explicit user consent for native payment handlers.
Several implementation capabilities enable streamlined flows through automation, including:
-
Skip-the-sheet, where the browser launches a payment handler automatically.
-
Preferred payment handlers. Although this capability does not yet exist, we have discussed user configuration of a preferred payment handler that would enable the browser to launch it automatically when it can be used for a transaction.
-
No user interaction. For some payments use cases, flows may be highly automatable. In these cases, payment handlers may not need to open windows for user interaction.
However, users should at some point consent to these features (especially when used together). For example, if a payment handler is launched with "skip-the-sheet," the browser should ensure (no later than first usage) that the user has an opportunity to manually confirm a transaction, especially if the payment handler itself does not offer this to the user.
Notes for the proposal:
-
There may be multiple opportunities to request consent (e.g., on installation or first usage).
In the Chrome implementation of Payment Handler API, the browser displays the origin of the payment handler distributor in secure chrome at the top of a modal window. However, to reduce the risk of confusion, this proposal is for additional browser notification that user is being asked to complete a payment. This might take multiple forms, such as:
-
Displaying a notice to the user before opening the payment handler window.
-
Displaying a notice prior to completing a transaction with the payment handler.
However, we do not wish to create a cumbersome user experience, and so the UX should allow the user to reduce the frequency of notifications, such as:
-
An option not to see the notification on a given origin for this payment handler.
-
An option not to see the notification on any origin for this payment handler.
Ideally the browser would show similar UX for other cross-origin interaction such as single sign-on, share, or credentials exchange.
Read the Cross Origin Awareness proposal
When using Payment Request API, merchants want some assurances about the nature of the user’s payment journey. The decision to use Payment Request for a given payment method might depend on answers to these questions:
-
Does the user have access to a payment handler at all?
-
Does the user have a payment handler that is immediately ready for payment?
A “yes” answer to the second question is useful when the merchant wants the greatest assurance of minimal friction for the user to complete the payment.
However, in some cases, the merchant might prefer a particular payment method and accept more friction —the user might have to sign up for an account or adding an instrument to the payment handler before completing payment. A “yes” to the first question is useful for this case.
Payment Request includes two methods corresponding to the two questions: canMakePayment and hasEnrolledInstrument.
Notes:
-
When done, add a link to the update from blog post on canMakePayment and hasEnrolledInstrument
-
When done add a link to the update from August 2018 description
By design, payment handlers enable users to share information stored by one origin (that of the payment handler) with others (merchants or their PSPs). However, most browsers are moving in the direction of limiting cross-origin sharing of stored information (whether cookies, IndexedDB, or other storage mechanisms). See, for example, WebKit ITS 2.1.
In Chrome’s current implementation of Payment Handler API, when a payment handler opens a new browsing context (modal window) it has first-party storage access.
We propose instead that payment handlers have third-party storage access by default, but they may request user consent to open in a first-party context.
Read the storage proposal.
Owner: danyao
The root enabler of the tracking threat exposed by hasEnrolledInstrument and canMakePayment is that a malicious payment handler can persist the browsing history either locally or to a backend when it is only supposed to answer a question about user’s enrollment state. In other words, the bug is that a WRITE operation is allowed when READ access is all that is required.
Read the read-only before show() proposal.
Owner: danyao
Skip-the-sheet and just-in-time installation are two features shipped in Chrome that have proven to be popular among payment handler flows. However, some edge cases in Chrome’s implementation are not well-defined (e.g. crbug.com/1055360, crbug.com/1054595, crbug.com/922683, crbug.com/922683, crbug.com/1040542, crbug.com/1032741), and these can cause confusion for developers. It would be helpful to standardize these flows as part of Payment Handler API or Payment Method Manifest.
Read the skip the sheet proposal and just-in-time installation proposal.
Notes:
-
When done, add a link to the update from blog post on canMakePayment and hasEnrolledInstrument
-
When done add a link to the update from August 2018 description
Owner: Adrian.
We would like to reduce the total number of user gestures required to complete a transaction at the same time as we increase our confidence that the user intends to make a payment. To that end, one idea is for a payment handler to register with the browser that it wants to do Web Authentication during its operations. This would allow the browser to combine two gestures --launch payment handler, initiate Web Authentication-- into a single gesture.
Context: