Re: [w3c/payment-request] Add hasEnrolledInstrument() again (for 1.1) (#931)

> Can you elaborate when/how that'd happen with PaymentRequest?

1. Install a [payment handler](https://w3c.github.io/payment-handler/) or and [Android payment app](https://web.dev/android-payment-apps-developers-guide/) from `https://payment-app.example`.
2.  Visit `https://shop.example`.
3. `https://shop.example` calls `new PaymentRequest([{supportedMethods: 'https://payment-app.example', data}]).hasEnrolledInstrument()`.
4. User agent silently passes data from `https://shop.example` to the `https://payment-app.example` payment app.

Passing data between origins silently is not something desirable from privacy perspective. Would you agree?

That's why my preference had been to remove the `hasEnrolledInstrument()` method, the `"canmakepayment"` event in Payment Handler API, and the `IS_READY_TO_PAY` intent filter from Android payment apps.

However, I can see how the use case of validating the `object data` is desirable. Do you have any ideas how that can be done in a privacy preserving way?

For example, the spec could define a "read-only mode" for the payment app, so it cannot write user identifying information to disk or have any network access when the user agent passes `object data` into it. That _may be feasible_ for `"canmakepayment"` event, but I am not aware of how this can be guaranteed for native Android or IOS apps, aside from operating system support. Does iOS have this ability?

-- 
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-request/pull/931#issuecomment-967144414