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 w3c/manifest#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 😄 (See #48 (comment))

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]

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: #92 (comment)

[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 #48 (comment)

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 (#48 (comment)), 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. 😢

[tommythorsen]

@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.

I don't think anyone would be against showing the origin of the recommended payment app along with the icon and label. If we prominently display the origin of each recommended payment app, does that take care of your security concerns, or is there more to it?

If you feel that the description in the current specification, on the subject of recommended payment apps, is a bit thin, then you're absolutely right. The reason for this is that we are in the middle of figuring out how everything is supposed to work. We have identified that there is a desire/need for something like recommended payment apps, but the fine details are left to be discussed. The good news is that we're discussing it right now, and I think we're getting somewhere 😄

[jakearchibald]

@tommythorsen

I don't think anyone would be against showing the origin of the recommended payment app along with the icon and label. If we prominently display the origin of each recommended payment app, does that take care of your security concerns, or is there more to it?

Like I said earlier in the thread, in this case the label and icon only serve to weaken security as they're in control of the origin which aims to earn these permissions. This will be happening in a new browser-owned API, which users traditionally trust, and it seems we're talking about breaking/blurring that model.

We have identified that there is a desire/need for something like recommended payment apps, but the fine details are left to be discussed. The good news is that we're discussing it right now, and I think we're getting somewhere

Well, kinda. My major frustration with this thread is that it keeps descending into "How can we fetch a manifest?", but the steps need to be:

1. What should the flow be?
2. What extra data do we need?
3. How do we get that data?

If "What should the flow be?" shows that we cannot use data provided by the other origin for security reasons, then that changes the next two steps considerably.

I've pointed this out here #48 (comment) and here #48 (comment) and here #48 (comment) and here #48 (comment) and here #48 (comment) and here #48 (comment) but as you can see there's still further discussion around manifests and link headers.

One of the champions for "presenting previously unvisited payments apps" needs to show a secure user flow for this feature, then we can start discussing APIs to make it work. If a secure user flow cannot be presented, this issue is dead.

[ianbjacobs]

@jakearchibald,

"One of the champions for "presenting previously unvisited payments apps" needs to show a secure user flow for this feature, then we can start discussing APIs to make it work."

Agreed that we should address that first. It's on the task force's agenda today.

Ian

[tommythorsen]

@ianbjacobs

Agreed that we should address that first. It's on the task force's agenda today.

Was this discussed in the task force meeting? I can't find anything about this in the minutes. If no one else is on top of this, I can take a stab at showing this user flow.

[ianbjacobs]

Hi @tommythorsen,

We did not have time to cover it at this week's call. I think there was a sense that we should continue discussion on some of these issues on GitHub.

Ian

[tommythorsen]

@ianbjacobs and @jakearchibald
I whipped up an example / proposal for how the recommended payment apps flow might look like here.

Based on our discussions so far, recommendations here are done by means of a url only. Icon and label are fetched from the payment app web server instead of being provided by the merchant.

What do you think?

[jakearchibald]

@tommythorsen thanks for putting this together!

With "what we don't want" - I'm not sure you'd ever show this. The page would be able to detect "no matching payment methods" and show links to supported methods.

The above would solve my issues with "A much better experience". Currently the browser is presenting a link of the merchant's choosing, along with a title & icon of the payment app's choosing. I'm really worried this will look like endorsement from the browser, and the title and icon is distracting from the security-sensitive part. I'm not sure "The merchant recommends…" is enough to overcome this.

"Installing the payment app" is problematic because (I assume) it'll involve a browser permission while you're showing two different origins on the screen.

I think we bypass a lot of the security complication if we allow the merchant to detect "no payment apps available", and they just show some links on a page, which are already well-understood by users in terms of who's offering the links, and who controls the content. Because it's a link, there'll be nothing new happening when the payment app requests permission.

[tommythorsen]

@jakearchibald

With "what we don't want" - I'm not sure you'd ever show this. The page would be able to detect "no matching payment methods" and show links to supported methods.

I'm not sure what you mean here. Do you suggest that the browser should know about every payment method in the world and suggest an appropriate payment app? For the most common ones like Visa, PayPal etc., this is feasible, but there's an incredible amount of existing payment methods around the world. I would prefer if the browser did not have to care about these individual payment apps. Having the merchant (who needs to care about the individual payment methods anyway) provide links to payment apps makes much more sense to me.

"Installing the payment app" is problematic because (I assume) it'll involve a browser permission while you're showing two different origins on the screen.

The screens on that page are mockups, they are not supposed to be the final UI design. Security issues like this one can be easily addressed by minor tweaks, such as making the the payment dialog full screen in this case.

I think we bypass a lot of the security complication if we allow the merchant to detect "no payment apps available", and they just show some links on a page, which are already well-understood by users in terms of who's offering the links, and who controls the content. Because it's a link, there'll be nothing new happening when the payment app requests permission.

Sure, but by letting the merchant query for this information, we provide a vector for fingerprinting. Judging by the ruckus around the Battery Status API, it feels like we should step carefully here. This might be an area where you have more expertise than me, though. Do you think, @jakearchibald, that there is a way for us to provide this "no payment apps available" information without exposing 1) information that can be used for fingerprinting, and 2) sensitive information about the user?

[jakearchibald]

@tommythorsen

The page would be able to detect "no matching payment methods" and show links to supported methods.

Do you suggest that the browser should know about every payment method in the world and suggest an appropriate payment app?

Of course not 😄. I said "The page" not "The browser".

Having the merchant (who needs to care about the individual payment methods anyway) provide links to payment apps makes much more sense to me.

That's what I'm saying. Why are we using privileged browser UI to show links when pages can already do it in a less security-sensitive and user-familiar way?

Security issues like this one can be easily addressed by minor tweaks, such as making the the payment dialog full screen in this case.

Right, but at that point we're no better than <a href="…" target="_blank">, so why?

Do you think, @jakearchibald, that there is a way for us to provide this "no payment apps available" information without exposing 1) information that can be used for fingerprinting

https://w3c.github.io/browser-payment-api/#show-method already rejects with a particular error if no supported payment apps are available. A site could use this as a trigger to display a list of recommendations. If this is a fingerprinting issue, I guess we need to take it up with that spec.

FWIW, fingerprinting is kinda possible with your proposal too. If evil.com supports the payments methods "paypal" and "evil.com/my-payment-app", it can detect the icon for "evil.com/my-payment-app" loading to know that "paypal" wasn't available.

[tommythorsen]

@jakearchibald

Of course not 😄. I said "The page" not "The browser".

😄 I seem to have misread you.

https://w3c.github.io/browser-payment-api/#show-method already rejects with a particular error if no supported payment apps are available. A site could use this as a trigger to display a list of recommendations.

Yeah, this would probably work even without any further changes. One approach that might be sufficient, at least for version 1 of the specification, could be to figure out the best way for a merchant to use the existing behavior of the payment request api to implement recommendations on his web page, and then produce some really good examples that shows the best practices.

I don't think there's a fingerprinting issue with the show method, since it potentially shows UI. I'd imagine one would prefer fingerprinting methods that weren't visible to the user. The canMakePayment method is a better candidate for fingerprinting.

[tommythorsen]

The more I think about it, the more I lean towards following @jakearchibald's advice and ditch the Recommended Payment Apps, at least from the first version of the specification.

Pros:

• Simpler to specify
• Simpler for the mediator to implement
• Avoids security issues with showing untrusted elements in trusted browser UI
• Lets merchants present recommendations in whichever way they desire

Cons

• More work for the merchants who want to implement app recommendations

This con is not insignificant, but I think it can be remedied to some extent by providing really good examples and best practices that the implementers of merchant pages can make use of. At the end of the day, it could be that merchants will be more happy with this approach, as it gives them more control.

If we choose to go in this direction, do we even need a Payment App Identifier for anything? Maybe we could just drop the whole concept. I don't think we really need a manifest file either.

[marcoscaceres]

I'm also in favor of the below.

…

On 3 Feb 2017, at 9:28 pm, Tommy Thorsen ***@***.***> wrote: The more I think about it, the more I lean towards following @jakearchibald's advice and ditch the Recommended Payment Apps, at least from the first version of the specification. Pros: Simpler to specify Simpler for the mediator to implement Avoids security issues with showing untrusted elements in trusted browser UI Lets merchants present recommendations in whichever way they desire Cons More work for the merchants who want to implement app recommendations This con is not insignificant, but I think it can be remedied to some extent by providing really good examples and best practices that the implementers of merchant pages can make use of. At the end of the day, it could be that merchants will be more happy with this approach, as it gives them more control. If we choose to go in this direction, do we even need a Payment App Identifier for anything? Maybe we could just drop the whole concept. I don't think we really need a manifest file either. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ianbjacobs]

I observe only lukewarm support for merchant-recommended payment apps in V1 of the specification.

A modified version of the proposal is this:

• To recommend payment apps (native or web), the merchant provides a list of payment app identifiers via Payment Request API. For Web-based payment apps, the identifier is an origin.
• The user agent is free to use this information in a variety of ways, including (1) Highlighting in a special way any registered payment apps that the merchant has recommended or (2) displaying information about trusted payment apps. This specification would not initially describe how the user agent establishes that a payment app is trusted.

Any thoughts on this reduced approach that still allows merchants to provide some preference information?

Ian

[tommythorsen]

@ianbjacobs if you want a reduced approach, my proposal above would fit that bill. The only thing the merchant provides to recommend an app, is a url to a web page where the user can install the payment app.

I would still vote for leaving this out of V1, since it is possible for the merchants to implement recommendations fairly easily without this. I can try some time next week to actually implement this in my test merchant page, to see how hard it is to do.

[marcoscaceres]

I'd prefer the recommendation stuff be incubated in a separate spec.

[ianbjacobs]

I am closing this issue because:

• We are no longer proposing any payment app manifest files.
• Payment apps are identified by origin.
• We are discussing how to manage "multiple things per origin" in issue Multiple payment apps per origin #98
• We are discussing recommended payment apps in issue Recommended payment apps #74

Therefore, the original question of this issue is now moot.

Ian