Payment app identifier to manifest filename mapping

[rsolomakhin]

Let's figure out how to map payment app identifier (e.g., https://alipay.com/some/path) to the manifest filename (e.g., https://alipay.com/some/path/payment-manifest.json). I prefer fixed filename because of simplicity for both user agent implementers and payment app writers.

@adrianhopebailie wrote:

I don't like this model of fixed names for the manifests at all. This feels like the favicon debacle all over again. If you want to identify a payment method use the actual URL where the manifest file is not an origin that then gets converted into a URL by some magic formula.

Favicon is indeed not ideal design, because user agents try to download https://example.com/favicon.ico when the user wants to see https://example.com/some/path/to/resource. We've all been annoyed at seeing 404 /favicon.ico in our server logs.

However, I believe that I'm proposing something more similar to index.html pattern, i.e., user is pointing their user agent to https://example.com/some/path/to/resource but sees the contents of https://example.com/some/path/to/resource/index.html instead.

The user agent will dereference https://alipay.com/some/path/payment-manifest.json only when a merchant wants to use https://alipay.com/some/path for payments. Therefore, there should be no spurious 404 /some/path/payment-manifest.json in server logs.

[adrianhopebailie]

However, I believe that I'm proposing something more similar to index.html pattern, i.e., user is pointing their user agent to https://example.com/some/path/to/resource but sees the contents of https://example.com/some/path/to/resource/index.html instead.

I believe that the decision to serve index.html is made by the server. That is not to say this isn't still worth discussing but I don't think that is a good example.

[maxpassion]

As explained by Rouslan, I do not see there is a big problem for fixed manifest file name currently. It is simple and easy to deploy. Is there any better way to do this?

[ianbjacobs]

I want to note here that the same issue is being discussed about payment method identifiers. I think we are likely to resolve the issue first about PMIs then should apply that to payment app identifiers.

Ian

[adrianhopebailie]

@ianbjacobs - actually I think we can close this issue because the current plan is to have a single manifest (the URL of which is a PMI, or derived from a PMI) and the properties of the default app for that method will be in that manifest.

i.e. There is no "payment app manifest" there is a "payments manifest" which describes the payment method and optionally payment apps for that method.

@rsolomakhin @maxpassion Am I correct?

[ianbjacobs]

@adrianhopebailie,

My understanding is that for some payment methods, there is a desire to include payment app info in the payment manifest.

My understanding is also that for other payment methods (e.g., basic card) we are not likely to have a payment method manifest but will still want payment app manifests on the Web.

[rsolomakhin]

You are both correct.

[adrianhopebailie]

NOTE ON TERMINOLOGY To avoid confusion I am distinguishing between a manifest (a data structure defined to describe something) and a manifest file (a file containing data that adheres to the manifest data structure format)

To summarize, I believe we have consensus that we need to:

1. Define a data structure for describing a payment app (a payment app manifest)
2. Define a data structure for describing a payment method (a payment method manifest)
3. Define a mechanism for fetching a payment method manifest file at a URL that is (or is derived from) a payment method identifier and that contains a payment method manifest.
4. Design the payment method manifest such that it can contain embedded payment app manifest(s) as the values of properties such as default_app or allowed_apps or similar. (i.e. Where the the data type of a property of the payment method manifest is a payment app then the manifest will contain either a payment app identifier or an embedded payment app manifest.

This issue addresses a 5th requirement which you have raised and @rsolomakhin agrees is a requirement, namely the need to:

1. Define a mechanism for fetching a payment app manifest file at a URL that is (or is derived from) a payment app identifier

I think that before we do this we need to finalize what the Payment App Identifier will look like because there are some questions I'm not sure we've answered:

1. Is it a always URL, and if so:
2. Is it equivalent to the scope of the ServiceWorker for web-based Payment Apps? (I believe there have been some concerns about this)
3. If the payment app is a native app what does the URL point to?

I believe that requirements 2 - 4 are in the scope of the Payment Method Identifier specification and are being worked on by @maxpassion in parallel to the other work being done on the PMI spec (per resolution on the call yesterday)

I believe that 1 and 5 are in the scope of the Payment Apps API specification and should be on the TODO list of the Payment Apps task force.

@ianbjacobs , @rsolomakhin , @maxpassion Do we agree?

[rsolomakhin]

All this seems right, thank you for writing it up.

[tommythorsen]

@adrianhopebailie

Is [the Payment App Identifier] equivalent to the scope of the ServiceWorker for web-based Payment Apps? (I believe there have been some concerns about this)

I did raise a concern about this in the previous payment apps task force meeting, in the context of merchant-recommended payment apps. The current spec says that these should be provided by means of the Payment App Identifier, but that only works if you can find the manifest file based on the PAI. If we use the scope of the ServiceWorker for the PAI, that's not the case.

It is still possible to use the ServiceWorker scope as the PAI, but then the merchant needs to recommend apps by means of the url to the manifest file instead of the PAI (and we need to change section 4.4 to say this).

[adrianhopebailie]

If we use the scope of the ServiceWorker for the PAI, that's not the case.

Can you explain why?

[tommythorsen]

@adrianhopebailie

Can you explain why?

Well, I'm not an expert on ServiceWorkers, but from what @jakearchibald says here, it seems that the scope can be set relatively independently of the location of the service worker .js file. That means that we can't derive the location of the .js from the scope url.

[adrianhopebailie]

Right, but we can define some restrictions that make this easier to standardize I'd think. So we could say:

1. A ServiceWorker that tries to register itself as a payment app MUST use the default scope (./ relative to the service worker .js file).
2. The location of a payment app's ServiceWorker .js file can be derived by taking the URL ./payment-app.js relative to the payment app identifier.

So the following would work together:

• Payment App Identifier = http://psp.example/app/v1
• Service Worker Scope = http://psp.example/app/v1
• Payment App js file = http://psp.example/app/v1/payment-app.js

The implications of this are:

1. Versioned payment apps must use different identifiers if multiple versions are supposed to co-exist (I think this is a good thing).
2. Browsers need to define a mechanism for native payments apps register themselves via the paymentapp.js file (could be that the file is a native payment app manifest instead of a ServiceWorker but could also be left to implementers)

[rsolomakhin]

Agreed with everything here except the native app standardization bit. Let's say, "Browsers need to define a mechanism for native payment apps to register themselves," and leave it at that. Would that be OK?

[adrianhopebailie]

We need to think carefully about this because we are hitting the issue I raised before with @jakearchibald and @marcoscaceres about the browser not being able to get information about the payment app without actually installing the ServiceWorker.

This was the use case I was trying to explain (badly) on the Manifest issue list and I think we haven't solved it yet.

Is it practical for the browser to fetch the .js and execute it in an isolated context to see if it registers a ServiceWorker and if it does then it has the data it needs (like a logo, supported methods etc)? The browser wouldn't actually install the ServiceWorker until the user decides to do so.

Or are we better off deriving a manifest file URL from the payment app identifier and having the URL of the .js file in that manifest?

This would mean the ServiceWorker .js file could be at any location where the scope is still the identifier.

• Payment App Identifier = http://psp.example/app/
• Service Worker Scope = http://psp.example/app/
• Payment App manifest file = http://psp.example/app/payment-app.manifest
• Payment App js file = Any legal location given scope above, defined in the manifest

This also solves the native app issue somewhat because the manifest can define where to get a native app in some browser defined way (already proposed in the Manifest spec btw).

[tommythorsen]

@adrianhopebailie

Or are we better off deriving a manifest file URL from the payment app identifier and having the URL of the .js file in that manifest?

+1

[jakearchibald]

Is there somewhere I can read up on why a separate payment app js file is needed? I thought we decided that reinventing things like service worker is a bad idea?

[tommythorsen]

I think the payment app js file mentioned above, is actually the service worker js file.

[jakearchibald]

I'm struggling to get a handle on this issue while all the specs are in flux. Is there an example somewhere of how this pieces together, end-to-end. FWIW, this could go in an explainer.md or readme in the root of the repo (example), in case others are struggling to get a handle on what's going on.

Specifically, how are things expected to work (or not work) when the payment provider "foo" is supported by a shop, but it's not one of the stored "user agent-based payment app"s?

[ianbjacobs]

Hi @jakearchibald,

Section 4 intends to give the overall story (with some design rationale in there as well): https://w3c.github.io/webpayments-payment-apps-api/#model

That's different from a concrete example or two, which I agree would be useful. We'll talk about that in the task force.

Regarding your question:

how are things expected to work (or not work) when the payment provider "foo" is supported by a > shop, but it's not one of the stored "user agent-based payment app"s?

I'd like to rewrite your question in the terms of the spec: what happens when a payee accepts the "foo" payment method but the user does not have any registered payment apps that support that payment method?

A couple of things might happen:

1) The payee (merchant) might recommend some payment apps that the user could use. When the user selects one of these payment apps, it is registered with the user agent.

2) If there are no matching payment apps, then the merchant learns this within payment request API and can build a fallback checkout page. This process of calling the API then building a fallback page would happen prior to any user interface being displayed.

3) Payment request API also defines canMakePayment(), which gives the payee some additional tools to query the user's environment before calling show().

Does that help?

Ian

[dlongley]

@jakearchibald,

This won't help with your specific question about what happens when a user doesn't have a Payment App (or anything in particular about manifests), but in case you haven't seen it, there is a Web Payments Overview document if you want to get a high-level view of how everything fits together end-to-end:

https://www.w3.org/TR/webpayments-overview/

[jakearchibald]

Thanks! I think I now know enough to have a go at writing… something.

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), 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.

[dlongley]

@jakearchibald,

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?

Yes, that's how the work has been proceeding and it's my understanding that there's consensus on it.

I'll let others respond in more detail to your comments on displaying/getting recommended apps installed (I think you've got the right idea in general though), but I did want to say ...

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 believe this may be related to whatever we come up with in #73, so I wanted to link to it.

[ianbjacobs]

@jakearchibald,

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?

I would say yes. We are still working out the details, but this is definitely the direction.

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.

Ok

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.

Agreed. I chatted about user consent yesterday with @marcoscaceres ; stay tuned for a proposal.

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.

That's what we discussed yesterday. (That's not explicit in the spec, so this will be a good fix.)

Thanks for the suggestions. I am looking forward to the proposal from @marcoscaceres, which I think will address a number of issues:

• the ones you raised above
• how to leverage (and not respecify) Web Manifest
• how to update payment method data after the initial registration
• how to address payment apps (by origin); this one will need discussion.

Ian

[jakearchibald]

how to address payment apps (by origin); this one will need discussion.

To clarify, I think the API should handle full URLs, so an origin can have many payment apps, but when presenting them to the user the origin is the security-important part.

[ianbjacobs]

@jakearchibald,

You wrote:

Payees should just link to the manifest.

We are working on a spec that defines a manifest file for payment methods. But as of right now we do not, for Web-based payment apps, require a manifest file for payment apps. (If I understand were @marcoscaceres is thinking the spec should go, there may be even less reason soon to have a Web-based payment app manifest file.)

The current spec says that payees link to service worker code (through a "payment app identifier"). What are your thoughts on payees linking to service worker code (and we would call that URL the "payment app identifier")?

Ian

[jakearchibald]

@ianbjacobs

The "scope" of the service worker is its primary key. So if you're trying to identify a particular active service worker on another origin, the "scope" is the thing to use.

My blog has a service worker at https://jakearchibald.com/sw.js, but the scope of the service worker is https://jakearchibald.com/.

[ianbjacobs]

@jakearchibald,

Does using the scope limit us to being able to identify one payment app per origin?

Ian

[jakearchibald]

Nope. For instance:

https://jakearchibald.github.io/svgomg/sw.js has scope https://jakearchibald.github.io/svgomg/ https://jakearchibald.github.io/streaming-html/sw.js has scope https://jakearchibald.github.io/streaming-html/sw-stream

A single service worker registration can change its script url throughout its life, but its scope cannot change.

[ianbjacobs]

@jakearchibald,

Thank you for the example (and patience as I learn about these "Web things")

Ian

[adrianhopebailie]

how to leverage (and not respecify) Web Manifest

Hooray! Another reason it is great to have @marcoscaceres involved in this.

The "scope" of the service worker is its primary key

This is the point I have been trying make :smile: (See https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-261786242)

Web-based payment apps ARE service workers, therefor we should identify a web based payment app the same way a Service Worker is identified (using the scope URL).

Can we agree that the thing we are calling the Payment App Identifier must be the scope of the service worker?

The challenge now is providing some sort of discovery mechanism to the browser for recommended payment apps. If the payee simply gives the browser a list of Payment App Identifiers (scope URLs) then the browser is able to determine if the apps are already installed or not and for those that are it has meta-info like the icon and label.

But, for all of the apps that are not installed the browser can't go any further. i.e. a GET on the URL will return an undefined result. My compromise was to define a convention for the relative location of either the Service Worker script (./payment-app.js) or a payment app manifest file (./manifest.json`).

In this case the browser can at least know where to go to install the service worker. Without this, it is stuck.

The advantage of pointing to a manifest file is that the browser can get information about the app without executing the service worker registration logic.

The alternative is that for each recommended payment app the merchant supplies both the payment app identifier (scope URL) and a URL to the manifest or service worker script.

So the recommended apps data in the payment request might look something like this:

   [{ 
      "id" : "http://bobpay.com/paymentapp/v1", 
      "manifest" : "http://bobpay.com/paymentapp/v1/manifest.json"
    },
    {
      "id" : "http://alicepay.com/", 
      "script" : "http://alicepay.com/sw.js"
    }]

1. Do we prefer a convention for a relative URL (assuming we will still decide if that should apply to script or manifest file or both)? 2. If we prefer a more verbose payment request as shown above, do we still want to support the idea of a manifest file that allows the browser to get data about the app without executing it's registration flow?

I think that the security issue @jakearchibald raises about the security risk introduced if the app provides a logo and label, is very important. We've come up against this "How do we verify an apps integrity?" question multiple times and I don't know if we have a good answer.

Presenting the user with a list of URLs as "recommended payment apps" seems like a non-starter, no?

[adrianhopebailie]

I am reminded from the email thread on this topic of a 3rd option which is:

1. The Payment App Identifier is the service worker scope (e.g. http://bobpay.com/paymentapp/v1)
2. There is a payment app manifest file at the SAME url

The manifest file would follow the format defined by https://github.com/w3c/manifest/ and can therefor specify the URL of the service worker script (per https://github.com/w3c/manifest/pull/507).

Therefor the response to a GET of http://bobpay.com/paymentapp/v1 would return something like:

{
  "lang": "en",
  "dir": "ltr",
  "name": "BobPay v1.0",
  "description": "The best way to pay!",
  "short_name": "bobpayv1",
  "scope": "/",
  "icons": [{
    "src": "icon/lowres.webp",
    "sizes": "64x64",
    "type": "image/webp"
  },{
    "src": "icon/lowres.png",
    "sizes": "64x64"
  }, {
    "src": "icon/hd_hi",
    "sizes": "128x128"
  }],
  "serviceworker": {
    "src": "sw.js",
    "scope": "/",
    "use_cache": false
  }
}}

Note:

• We'd likely need to restrict the allowed values for "scope" since we are explicitly saying already that the scope is http://bobpay.com/paymentapp/v1. Either the browser can pre-validate the manifest with some payment app manifest specific logic OR simply ignore the provided value when processing a manifest in the context of registering a payment app.
• Both the app and the service worker have a scope defined in the manifest file. We'd probably want these to be the same and restricted per point above.
• There are some manifest attributes (like start_url that make no sense for payment apps so we'd likely say that these are ignored (which the mnaifest spec already allows for).

Looking forward to the proposal from @marcoscaceres!

[rsolomakhin]

I was under the impression that the group prefers HTTP Link headers to map identifiers to useful things. For example:

$ curl --head https://bobpay.com | grep Link
Link: <payment-manifest.json>; rel="payment-method-manifest"

ServiceWorker can be installed this way as well:

$ curl --head https://alicepay.com | grep Link
Link: </js/sw.js>; rel="serviceworker"; scope="/"

[jakearchibald]

I think that the security issue @jakearchibald raises about the security risk introduced if the app provides a logo and label, is very important. We've come up against this "How do we verify an apps integrity?" question multiple times and I don't know if we have a good answer.

This needs an answer before we continue with this issue.

The whole question of how to present recommended-but-not-installed payment apps is based around the idea that we want the browser to be able to display the options in a blessed UI and potentially (if selected) install the service worker, and grant permission for that to be a payment app.

If presenting that information in a blessed UI lowers security, we do not want the browser to do it. If that's the case, all this stuff about manifests & link headers is redundant.

In summary:

1. Figure out what data is needed about a payment app before it's registered with the user agent.
2. Figure out how to provide that data.

We're currently debating step 2 & struggling because we haven't completed step 1. We might find out the answer to 1 is "none".

Presenting the user with a list of URLs as "recommended payment apps" seems like a non-starter, no?

Why?

[adrianhopebailie]

Presenting the user with a list of URLs as "recommended payment apps" seems like a non-starter, no?

Why?

I am struggling to think of another case where a user is given a list of URLs for applications and expected to pick on of these to trigger installation of the application. i.e. No icon, no description, not even a label.

Is this really an option?

[adrianhopebailie]

I was under the impression that the group prefers HTTP Link headers to map identifiers to useful things.

This is also a good option and would be consistent, which I think is a very good thing!

So you are suggesting @rsolomakhin something like this?

1. Payment App ID and SW Scope: https://bobpay.com/paymentapp/v1
2. A HEAD request to that would return link relations to both the manifest file (if there is one) and the Service Worker script file.

What would a GET request on that URL return or do we leave that undefined?

[jakearchibald]

If it can't be done securely, then not doing it is the only option.

Manifests keep being pushed for recommend-but-not-installed payment apps, but if no one can think of a way of using them that isn't a security threat to the user, we're wasting our time.

[jakearchibald]

Seriously, stop pushing for a manifest until its usage is defined. It feels like we're arguing about the tools before we decide what to build.

[adrianhopebailie]

Seriously, stop pushing for a manifest until its usage is defined. It feels like we're arguing about the tools before we decide what to build.

I don't think that is the case. The proposal has always been to display a list of recommended apps to the user in the form of icons and labels. If you are suggesting the only safe way to present a list of recommended apps to the user is a list of URLs then I would propose we forget about the idea of recommended apps at all (or only show the user recommended apps they already have installed).

My case for using a manifest IF we do want to display a list of icons and labels is that this seems safer than executing the service worker registration logic FIRST just so the script can provide these.

Personally, I'd be happy for us to drop recommended apps entirely as I think it massively over-complicates the payment app spec, but I think I am in the minority on that.

[jakearchibald]

My position is still https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-274094501.

Drop the presentation of recommended-but-not-installed payment apps (and therefore manifests) until the security questions are answered.

[adrianhopebailie]

Drop the presentation of recommended-but-not-installed payment apps (and therefore manifests) until the security questions are answered.

👍

Some more evidence that recommended payment apps are adding complexity that we are perhaps not ready for in v1: https://github.com/w3c/webpayments-payment-apps-api/issues/92#issuecomment-274165751

[adamroach]

It seems that presenting to the user a combination of icon/name/domain would serve the purpose of giving the user the information they need to make a decision (domain), while allowing for some degree of branding (which seems to be important here).

[adrianhopebailie]

@adamroach the security concern is, who provides the icon and label?

If I have never installed a payment app from my bank and then I see their name and logo appear under an origin that is similar (but not the same) as theirs I am very likely to select that app and run through the registration process which may include providing all my online banking login details.

[jakearchibald]

Like I said https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-273201675

The icon and label as provided by the manifest only serve to weaken security. Given the function (payment) this should be taken a lot more seriously.

[msporny]

Personally, I'd be happy for us to drop recommended apps entirely as I think it massively over-complicates the payment app spec, but I think I am in the minority on that.

You're not alone on that one, @adrianhopebailie.

+1 for dropping recommended apps entirely for three reasons 1) implementation complexity, 2) security concerns, 3) it will lead to a skewed playing field (skewed toward major payment app providers).

[ianbjacobs]

This is a helpful discussion, thanks everyone.

I'll bring the security issue to the task force for discussion this week or next. Given that we have heard there is interest in this feature, we'll continue to try to work through these issues.

Ian

[adamroach]

@jakearchibald -- It's not that I don't take security seriously; it's just that you haven't outlined any threat that the proposed approaches actually make worse; or, if you have, you haven't described how it does so.

Let's back up. The state of the art today is that a malicious or hacked merchantsite.com could contain a "Check out with Paypal"-branded button on their site, with the button linking to a "checkout flow" on evil.com.

Keeping that in mind, describe a scenario that the proposed "Recommended Payment" functionality enables that isn't currently possible. Start with the user clicking on "buy," and describe the steps that take place up to the point that money leaves that user's possession and enters the hands of someone they did not desire to pay.

[jakearchibald]

Browser security is built around the idea that there are parts of the UI under the site's control, and therefore to be trusted as much as you trust the site, and parts that are under the browser's control, and to be trusted as much as you trust the browser.

For instance, if the site says "I am secure" - you trust this less than if the browser says "this site is secure".

What we're talking about is a new UI flow, where multiple origins are represented in the same space, controlled by the browser. This thread seems to be suggesting that the current origin would get to choose which origins appear here, and those origins would control how they appear (text & icon).

So now we're mixing the model up. Origins are being presented to the user, by the browser, for the first time, on their terms. It will appear like my browser (not the site) is suggesting I use "PayPal", but it is in fact evil.com pretending to be PayPal.

Given that we do not allow origin-controlled text into permission prompts, I'm not sure we should be ok with this.

[jakearchibald]

@adamroach

Keeping that in mind, describe a scenario that the proposed "Recommended Payment" functionality enables that isn't currently possible. Start with the user clicking on "buy," and describe the steps that take place up to the point that money leaves that user's possession and enters the hands of someone they did not desire to pay.

As I've been pointing out in my comments (https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-273201675), I'm not party to the internal discussion of this group, so I'm trying to piece things together from what I can find on specs & on GitHub.

I keep asking how this data is going to be used, and what the flow is for a recommended payment app. If this group has already shown that browser UI can be used to show recommended payment apps in a safe & beneficial way, I'd love to see it! Sorry I haven't been able to find it myself.

Pointing me to the existing evidence seems more productive than me guessing and being told I'm right/wrong 😄.

[dlongley]

@adamroach,

Keeping that in mind, describe a scenario that the proposed "Recommended Payment" functionality enables that isn't currently possible. Start with the user clicking on "buy," and describe the steps that take place up to the point that money leaves that user's possession and enters the hands of someone they did not desire to pay.

1. User clicks "buy" on merchant.com.
2. merchant.com includes a list of recommended payment apps via URLs that may be dereferenced to get a title and icon for each app. One app is from "evil.com" (why would the merchant do this? ...more on that later).
3. The browser displays the title and icon to the user and a URL for installing the payment app. Note: the browser treats these bits as opaque and simply shows whatever the app origin serves to the user. The evil.com app shows "PayPal" with a PayPal icon.
4. The user clicks an install link for what they believe to be PayPal and install the evil.com app.
5. The user chooses evil.com's fake PayPal app to pay.
6. The user enters their payment credentials into evil.com.
7. evil.com steals their money.

Now, getting back to that original question: "Why would the merchant recommend a payment app that would steal the user's money?" This seems like a silly thing to do, especially because now the merchant will never get that money. However, if "there's no present day incentive for this attack" is the reasoning for deviating from the existing browser security model, I don't think it's a strong argument.

For example, imagine a future where:

1. The PaymentRequest API is virtually ubiquitous. People only pay using it; they don't trust websites that don't use it.
2. People begin to trust their payment apps to help them avoid shopping on fraudulent merchant websites.
3. In order for someone to set up a successful evil-merchant.com, they have to get a user to install a payment app.
4. If evil-merchant.com can recommend a fake PayPal app (i.e. get the browser to display "PayPal" themed visuals in a way that the user thinks they are trusting the browser, not the site), then the user may install it and get robbed.

[jakearchibald]

All of this depends on the intended user flow. If recommended payment apps can be registered via a special payments browser UI, there's a security concern as we're adding an origin level permission without ever showing the user the origin.

If the browser simply links to the other origin so it can install and present permission prompts, then it's really just a link, and I don't see why this should sit in trusted browser UI. It risks looking like a browser endorsement, whereas a link on a page doesn't.

But again, I'm just guessing because no one's detailing how this API is supposed to work in a secure way. 😢