2020 3p context

One of the main goals of developing an ecosystem of payment handlers has been to streamline checkout by making it easy for users to return stored data rather than re-type similar information across the Web. Thus, by nature, payment handlers are meant to share information with different origins.

However, as was pointed out by Pete Snyder in payment handler issue 351, browsers generally are moving in a direction of reducing this sort of access to global storage. As Pete wrote:

If I'm reading [Payment Handler API] correctly, this would enable types of tracking that other parts of the web platform are trying to address (specifically, double-keying, or partitioning, storage by 1p-3p to prevent the 3p from tracking the user across the web). If I read the spec correctly, the standard would allow the payment processor to track the user across pages that use the processor, since the processor would always have access to the same global storage, instead of different storage for each 1p it appears under.

Updating the spec so that open window doesn't create a top-level-context, but a 3p context, would solve this problem, and would be inline with the privacy protections being pursued by partitioning storage, Storage Access API, etc.

The following proposal follows discussion on the issue 351 thread.

Proposal

• By default (and without prior consent), payment handlers will only have 3p access to storage.
• Users can consent to granting 1P storage access to a payment handler (identified by its origin).

Forms of Consent

Consent to grant 1P storage access may take a variety of forms. For example:

• (a) At payment handler install time: browser can offer user an option to opt-in, e.g. "would you like to allow wallet.example to access storage on all origins?" The default should be "no".
• (b) During first use of a payment handler: browser may prompt user to opt-in if no previous consent exists.
• (c) Periodically, during payment handler invocation: browser has the discretion to re-prompt user to opt-in based on signals such as the time of last consent and activity with the payment handler.

Note: For both (b) and (c), Chrome, Firefox and Safari developers all indicated desire to reuse the same prompting strategy as the respective Storage Access API implementations.

Revocation of Consent

• Users may explicitly revoke consent.
• Browsers (at their discretion) may revoke consent after some period of inactivity with this payment handler.