Re: [w3c/payment-handler] Open Window Algorithm and tracking through 1ps (#351)

I had a couple thoughts that I hope might be helpful:

1. As [@snyderp mentioned](https://github.com/w3c/payment-handler/issues/351#issuecomment-551321908), the privacy-invasive bit isn't the act of loading two different first-party contexts at the same time; it's the fact that one can send a message that puts both parties' user IDs into the same JS environment at the same time. In the brave new world, users need to consent to that message.

1. The core Payment Handler UI seems like a reasonable consent flow for this joining of first-party identities. That is:
   1. The user [clicks](https://www.w3.org/TR/payment-request/#show-method) something on the payee to start the flow.
   1. The browser shows the user a list of applicable payment methods, with whatever explanatory text it feels is appropriate. At worst, this can be the same text used to explain things within a `requestStorageAccess()` call.
   1. If the user clicks on a particular payment method, that's treated as consent to pass the payee's message (which might include a user ID) over to the payment provider.
   1. The user might then cancel out of the payment provider's flow, but they'd already consented to join identities before even entering that flow, and that can't be undone.

1. To the extent that this isn't sufficient, but `requestStorageAccess()` in a "standard 3p context" does have the power to join user IDs, I think we can integrate that here. I don't know of a specification for ["make the payment handler context a standard 3p content"](https://github.com/w3c/payment-handler/issues/351#issuecomment-555237335), and it seems complicated to have one notion that covers iframes, `window.open()`ed tabs, first-party contexts opened from a decorated link, etc., so I won't try to lean on that idea here. Instead, what if https://w3c.github.io/payment-handler/#handling-a-paymentrequestevent started with a call to `requestStorageAccess()` before it fires an event on the registered service worker? On success, the normal service worker can run and can open first-party windows. On failure, the next step probably has to be to open a payment-provider-provided URL in an iframe-like window that lets the user log in. Does that work privacy-wise? @johnwilander @Brandr0id (and not sure who owns this for Mozilla), does that make sense with the `requestStorageAccess()` API?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/issues/351#issuecomment-564797883