-
Notifications
You must be signed in to change notification settings - Fork 41
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.
Status: work-in-progress
TODO:
-
Add a short summary for each proposal
-
Discuss the summaries over a meeting
-
Write more detailed explainers and link from this doc. Note: More than one topic below might be covered by the same explainer.
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.
Notes for the proposal:
-
Determine whether we also want to talk here about explicit consent to allow the payment handler to remember the user for transactions on other sites (e.g., implemented as Storage Access API).
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.
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 for the proposal:
-
Describe events in terms of lifecycle / state machine model
-
Describe expected behavior in incognito mode.
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.
Notes for the proposal:
-
A possible mitigation strategy: until the user has selected a payment handler for a transaction, the browser disallows network and write access to persistent storage. A well-behaving payment handler can persist user enrollment states when it is first installed or when it is first used for a payment. It can correctly respond to subsequent
hasEnrolledInstrumentorcanMakePaymentcalls by reading its states. -
There is an open question on how to deal with native payment handlers. There are two possible approaches: (1) take no particular precautions and rely on the user to use good judgement on which app they install (2) stop firing IS_READY_TO_PAY intent, and require the native app to register some data with the browser.
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.
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. The browser can integrate the authentication into the "sheet", for example as follows:
-
The "Ok" button is replaced by the same UI that is used to authenticate the user when WebAuthn is invoked (e.g. a fingerprint image)
-
The sheet has language explaining what will happen when the user clicks the button such as: "Confirm your fingerprint to pay $10 to Bob’s Hardware"
-
Scanning the fingerprint (or providing whatever authenticator gesture is required) does the following:
-
Invokes WebAuthn using a standard challenge based on the payment detail and the credential registered by the payment handler.
-
If successful, the browser launches the payment handler and feeds it the authentication assertion data.
-
Thus, the payment handler does not need to re-authenticate the user, eliminating one user gesture.
-
Context: