Re: [w3c/webpayments-payment-apps-api] Payment app identifier to manifest filename mapping (#48)

Thanks! I think I know enough to make sense now.

A "user agent-based payment app" should be registered via a service worker (unless there's good reason to do something else), as this is how it's done with every other sw-based API. Is there consensus on this?

For "recommended payment apps" that aren't yet registered, you need some way to install a service worker for the recommended app should the user choose to use it. Providing a link to the payment app's manifest is one way of doing this, especially now it now supports service worker registration details https://github.com/w3c/manifest/pull/507.

Aside, but kinda what this issue is about: I strongly recommend against magic when it comes to determining the location of the manifest. Payees should just link to the manifest. Service workers have magic around the scopes they can control ([due to legacy sites that ignore SOP](https://jakearchibald.com/2014/launching-sw-without-breaking-the-web/)), and it's a pain in the arse. It's really tough for devs to make sense of it & debug. The magic is a compromise, not a feature.

The way payment apps are presented to the user is super sensitive, and something that should be thought about when designing the API. I'd only recommend showing data from the manifest if the user has already seen it and "accepted" it in the context of the origin that owns the manifest.

Eg, if you display:

```
[Paypal icon] Paypal
evil.com
```

…to the user, where "Paypal icon" and "Paypal" are from the manifest, and "evil.com" is determined by the manifest URL, the details from the manifest only serve to weaken security - the important and reliable data is "evil.com".

Therefore, for recommended payment apps that aren't registered as a "user agent-based payment app", I'm not sure it's wise to show anything from the manifest other than its origin. (You might be able to add the manifest's scope to the end of the origin, since that'd help with origins that have many manifests, but it should be done really carefully.)

For recommended payment apps that are also a registered "user agent-based payment app", you can show manifest details if the user has already accepted them. As in, they've been on the origin in question, and a permission dialog has appeared asking if this origin can become a payment app, and it shows the user how this payment app will be presented to them later. Hopefully they'd see the mismatch between evil.com and the paypal icon at this point. This is one of the reasons we don't let added-to-homescreen websites update their name & icon, we don't want them changing to something misleading without the user's observation.

If you agree with the above, the only safe way for a user to adopt a payment provider is to accept a permission from the origin. Therefore, a recommended payment app doesn't need to be any more than a link. The link, when opened, would show details of its choosing, install its service worker, and ask for permission to be a payment app, as above. Once this is done it could signal completion somehow (sorry that's a bit hand-wavy, but I guess there'll be something similar in place for when the payment app needs to show UI for login & confirmation).

I haven't been keeping up with this repo, so apologies if this post is retreading old ground or is simply… wrong.

-- 
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/webpayments-payment-apps-api/issues/48#issuecomment-273201675