Payment-request: Why another API?

[tjconcept]

The goal, the idea, and the different data structures of this specification is looking really good.

However, I do not understand why this has to be a new browser API.
With browser crypto capabilities and cross-domain/cross-window communication I think it should be possible to create a "wallet" as an offline-capable web application.
I have been playing with the idea but hit some bumps in the communications layer (https://github.com/srcagency/browser-bus).

If this is something that has been already discussed, could someone link me there?

A related project: http://substack.net/offline_decentralized_single_sign_on_in_the_browser

[ianbjacobs]

@tjconcept,

We distinguish the wallet part (which we will also work on and are calling "payment apps") from the role of the browser to display the user's available payment methods (which payment apps will support).

paymentRequest() only addresses the basic function of the browser as mediator, and what's different from existing APIs is that the browser will display native chrome, which should make the experience faster and well-integrated (and secure, etc.).

Ian

[tjconcept]

@ianbjacobs, thanks for your response.

I fear this is putting unnecessary responsibilities on browsers and browser vendors (which is never good) unless some basic functionality is needed that is not currently available to web applications. And then I would rather have vendors focus on those fundamentals. Like for instance better inter communications.
Is this an invalid concern?

[ianbjacobs]

@tjconcept,

I fear this is putting unnecessary responsibilities on browsers and browser vendors (which is never good) unless some basic functionality is needed that is not currently available to web applications.

I believe that browser vendors are particularly interested in this work (judging by who has joined the Working Group). And, as I mentioned, the behavior we are working on is not currently standardized on the Web, so it is not currently available to Web applications.

And then I would rather have vendors focus on those fundamentals. Like for instance better inter communications.

Do you mean "fundamentals for payments"? What are the fundamentals you have in mind?

Of course, there's a lot of work going on at W3C (and elsewhere) to expand Web technology capabilities; this is just one effort. Browser vendors themselves prioritize what they are going to implement for their customers.

Ian

[burdges]

Imho, there is exactly one real social value provided by a browser API over payment apps using existing methods, like browser extensions.

At some point, the user must choose what payment app with which to pay. If we've no browser API, then that means payment apps must somehow notify the merchant that they are installed, which leaks one bit of identifying information per likely payment app. This is bad.

In that scenario, a browser vendor wishing to protect user privacy, like say the Tor Project, should attempt to protect user privacy by pre-installing all the good payment apps that protect user privacy, and preventing the installation of any bad ones. This sounds like a big mess.

It's true browsers leak far more information like fonts, window dimension, etc., but browser vendors who actually care about privacy can reduce this. Tor Browser does so. And some main stream ones might be improving. In any case, we do not want payment apps making this worse.

[tjconcept]

@ianbjacobs

I believe that browser vendors are particularly interested in this work

Yes, that's something which frightens me. Soon we'll have browsers fighting with payment methods, using devices as leverage and cutting deals with banks.
Providing an alternative browser experience gets ever more difficult.

Do you mean "fundamentals for payments"? What are the fundamentals you have in mind?

No, exactly not "for payments". Payments are just one thing - and it seems if we have a browser API for that, then were do we stop?

We _do_ need multiple competing attempts (formats if you will) to spec and standardise payments between merchants and customers, but I don't want to involve browser vendors (at almost any cost).

Instead we need a generic way for web applications to expose functionality to, and communicate with, other web applications on the same device/browser. Maybe a Service Worker thing? That would have endless possibilities: sharing data from a spreadsheet to a graphical tool, post a message with the users favourite chat app, saving tickets to a wallet app or authentication without having to choose from the webmaster's favourite social networks to name a few. But this is of course a whole other discussion.

@burdges
That's a valid point. On the other hand even the API itself will increase the number of browser differences available for fingerprinting.
IMO it is the responsibility of the wallet app you're using to reduce it's footprint and keep itself anonymous.
Using an incognito mode you would of course expect the browser to have additional confirmation steps in place before any inter-communication happens.

[adamroach]

@tjconcept writes:

Yes, that's something which frightens me. Soon we'll have browsers fighting with payment methods, using devices as leverage and cutting deals with banks.

Representing a browser vendor, this is something that worries me also. It is a major reason that I see the Payment Request API as fundamentally inseparable from the Payment App API. The result of this WG's effort really needs to be a level playing field for payment providers, and the best way to ensure that is to have a uniform and nondiscriminatory way for payment apps to register and interact.

The generic broker functionality you describe sounds interesting from a theoretical perspective, but it also sounds a bit like an ocean boiling exercise. That is, unless what you have in mind is simply "remove cross-origin protections." I assume that's not what you have in mind _per se_, but I encourage you to think really hard about whether what you're thinking about eventually has the same result.

[burdges]

Actually, the browser version number should not be considered a browser differences available for fingerprinting. It is of course, but it's unavoidable.

We should obviously not allow anything into this API specification that allows for fingerprinting beyond the browser version number, even if the wallet app is a hostile tracking application. It appears a some active participants were conscious of that requirement, although maybe it should be given an issue an verbiage in the spec.

I'm mentioned in a few places that payment apps must be treated as hostile to the user because merchant provided payment apps are occasionally discussed. I believe that never literally made it into the specification itself though.

In any case, it's ridiculous to imagine that payment apps will be secure, anonymous, etc., not when the financial world runs on "zero factor authentication". Now Taler actually does do things correctly, except that we leak that Taler is installed, but we're an extreme case.

[dlongley]

@adamroach,

Representing a browser vendor, this is something that worries me also. It is a major reason that I see the Payment Request API as fundamentally inseparable from the Payment App API. The result of this WG's effort really needs to be a level playing field for payment providers, and the best way to ensure that is to have a uniform and nondiscriminatory way for payment apps to register and interact.

Yes -- and I think ensuring that we have a minimal API for merchants to call to get their payment request message to the user's Payment App of choice is important. This is another reason I prefer providing low-level, scope-limited, composable, reusable APIs and UI components.

I'm fine with browsers offering their own composition of these things in a special browser UI that covers the 80% case, but I do think merchants should be able to construct their own UI offerings as well -- whilst still getting appropriate access to Payment Apps and whatever other helpful features the user agent can assist with.

[tjconcept]

@adamroach writes:

That is, unless what you have in mind is simply "remove cross-origin protections." I assume that's not what you have in mind per se, but I encourage you to think really hard about whether what you're thinking about eventually has the same result.

Yes and no. This is a concern I indeed have been thinking about. Mostly (honestly this is just a guess) cross-origin protection is about webpage A not being able to act on behalf of or impersonate you on webpage B.
What I suggest (I am just putting out an alternative idea) is merely about communication over a new channel - which does not resemble posting forms or requesting stuff with user's cookies at all.
It is not really new, is entirely doable today - bad guys could have been (is?) doing it for years - it is just cumbersome, feels like a hack, works only offline in Chrome and Firefox, the rest requires a relay server (experiment linked in original post).

Desktop applications have always had this (mostly through the file system), and I value the fundamentally better approach of the web of apps, but we need to solve this also - not just for payments.

@burdges writes:

I'm mentioned in a few places that payment apps must be treated as hostile to the user because merchant provided payment apps are occasionally discussed. I believe that never literally made it into the specification itself though.

I agree. They should be no different from any other web application and have no special privileges.

[adrianhopebailie]

@tjconcept the handling of a payment request requires three parties on the Web: the initiator (merchant/payee), the payment app (user/payer) and a mediator.

This is the case today because there is not universal or open payment protocol (like HTTP for payments) that all participants have implemented.

It's necessary therefor for the payment request to list out all of the payment methods that the payee accepts and for the payer (through the payment app) to pick one.

Why is the mediator necessary? Because the user may have multiple payment apps that handle a variety of payment methods (and these may overlap) so a component is required in this system to mediate this process.

As in many other scenarios the browser sits between these two apps (website and payment app) to also protect the privacy of the user.

The next questions is why not have a generic cross-origin pipe for communication between the website and payment app? Well, that assumes that the payment app is a web app (it may be a native app, a browser extension, a piece of hardware etc).

It also assumes that the browser will be able to make good decisions to protect the user with no understanding of the semantics of what the user is doing.

We need the browser to know that the intent of the website is "get paid", not just "talk to another app" and be able to convey sufficient semantics in that "intent" to let the browser do a good job as the mediator.

The design of the API is such that the browser should never need to know semantics of payment methods (i.e. the difference between a bitcoin payment and a credit card payment) but enough about the transaction to provide the user with a secure, accessible and generally pleasant experience.