[w3c/payment-handler] Limit information available during canmakepayment event (Issue #413)

(Below I quote previous text from the Chrome team, moving it from this pull request [1] to an issue)
[1] https://github.com/w3c/webpayments/pull/261

When a Payment Request is constructed, the Payment Handler specification [requires the user-agent to fire a `"canmakepayment"` event](https://w3c.github.io/payment-handler/#handling-a-canmakepaymentevent)[^event]
to any matching installed Service Workers. The Service Worker is able to handle the event and return (via [respondWith](https://w3c.github.io/payment-handler/#respondwith-method)) either `true` or `false`.

[^event]: Not to be confused with the `canMakePayment()` **method** of the  Payment Request API. The "canmakepayment"` event is fired at> construction  time, not in response to a `canMakePayment()` call, and is used to answer `hasEnrolledInstrument()` instead.

To support native Android apps, Chrome also [fires an `IS_READY_TO_PAY` intent](https://web.dev/android-payment-apps-developers-guide/) to the matching installed native applications.

The `"canmakepayment"` event (and `IS_READY_TO_PAY` intent) [currently conveys](https://w3c.github.io/payment-handler/#canmakepaymenteventinit-dictionary) the following information to the Payment App:

 - `topOrigin` - e.g., https://merchant.example (browser-determined)
 - `paymentRequestOrigin` - e.g., https://psp-iframe.example (browser-determined)
 - `methodData` - a sequence of arbitrary [method data](https://www.w3.org/TR/payment-request/#paymentmethoddata-dictionary) (merchant-supplied)

The transfer of this information is invisible to the user and without consent (reminder that it happens on Payment Request **construction**, long before any UI might be shown). Because Payment Apps run [in a 1p context](#types-of-payment-apps), it could be used to track the user.

#### Proposed Mitigation

Remove the `topOrigin`, `paymentRequestOrigin`, and `methodData` fields from `"canmakepayment"` event. The payment app may still respond based on its own knowledge (e.g., checking 1p data for this user), but that knowledge is compressed into only one bit for the merchant to consume (`true`/`false`).


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

Message ID: <w3c/payment-handler/issues/413@github.com>