- From: pes <notifications@github.com>
- Date: Wed, 30 Oct 2019 11:18:38 -0700
- To: w3c/payment-handler <payment-handler@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-handler/issues/351/548047085@github.com>
> So an interesting question is: what information can be sent by the merchant to the payment handler once the user selects the payment handler to pay? My concern isn't related to the information that can be exchanged, its related to which storage the web payment handler context receives. If the frame is a 1p context, that will allow for tracking to occur across 1p pages. If its a 3p context (and so all the restrictions placed on nested contexts would apply) then most methods of tracking are prevented. > That would be the same as if the user were to cancel the payment handler before completing payment. > I believe that the payment handler approach would support that use case. A (Web-based) payment handler is a Web site, so the user should be able to interact with it with different identities. Again, my concern is not whether the API would allow people to long in with multiple identities, its that the spec, as written, would allow the payment handler to link those multiple presented identities together (since they're all happening in the same storage context). Having the context be 1p / top level makes that possible; having it be 3p / nested-context prevents most methods of that, since the storage the payment handler context gets when opened from store1.com would be distinct from the storage the payment handler context gets when opened from store2.com -- 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-548047085
Received on Wednesday, 30 October 2019 18:18:40 UTC