Should the browser API support the concept of "messages"?

[adrianhopebailie]

This has been asked and referred to implicitly in a number of issues: #15, #146, #50, #45, #39, #133
Getting a concrete answer to this may help us make progress on those issues.

In this context a message is an object, either encoded as JSON or instantiated in a JavaScript execution environment.

A payment request message is an object with some specific members that are required in all payment requests like amount, and the set of supported payment methods and some optional members like the payment method specific data. i.e. it follows a predefined, but extensible data model.

Likewise a payment response message is an object with a predefined, but extensible data model.

The question is, should a website be able to pass a complete payment request message to the API and expect that message to be passed (unchanged) to the payment app. Also, should the payment app be able to return a payment response message and be certain that it will be passed unchanged to the calling website.

[dlongley]

The question is, should a website be able to pass a complete payment request message to the API and expect that message to be passed (unchanged) to the payment app. Also, should the payment app be able to return a payment response message and be certain that it will be passed unchanged to the calling website.

Yes, and yes.

[dlongley]

I'm fine if we need to pull parts of that message out to pass to the browser API because of Web IDL restrictions, ie:

var paymentRequestMessage = {
  acceptablePaymentMethods: [...],
  otherThing: ...
};

var pr = new PaymentRequest(
  paymentRequestMessage.acceptablePaymentMethods,
  {items: ...}, // user-agent only "details"
  {...}, // user-agent only "options"
  paymentRequestMessage); // passed to Payment App unchanged

[halindrome]

I guess I am surprised there is any debate about this. Yes. There MUST be a path that gives the payee and the payment app / PSP confidence that their communication is happening in an unadulterated manner. Otherwise... why would I as a merchant or you as a bank trust this system?

[adrianhopebailie]

@halindrome said:

I guess I am surprised there is any debate about this

Well if you look at the current browser API spec there is actually no mention anywhere of passing the full payment request on to a payment app. Only the data member, which contains only payment method data is proposed to be passed to the payment app.

[adrianhopebailie]

should a website be able to pass a complete payment request message to the API and expect that message to be passed (unchanged) to the payment app

Yes

should the payment app be able to return a payment response message and be certain that it will be passed unchanged to the calling website.

Yes

This is important in establishing the role of the browser API within a broader payments ecosystem.

The browser API is intended to be a way to facilitate exchange of payments related data between parties on either side of the interface. By preventing the complete payment message from being constructed outside the API the browser puts itself in the path of the flow of payment data in a way that is obstructive and unnecessarily makes the browser a gatekeeper in this flow.

The function of the browser in its role as payment mediator is to simply inspect the payment request and determine where to route it (possibly taking input from the user where required).

Unless it is possible to pass a complete and atomic payment request into the browser API the browser will need to construct this complete request dynamically in order to pass it to a payment app. The result is that the website has no certainty about the format of the payment request message that is passed on to the payment app.

[dlongley]

@adrianhopebailie,

Well if you look at the current browser API spec there is actually no mention anywhere of passing the full payment request on to a payment app.

Yes. One option is to just change data to be the full payment request message. The user agent could simply ignore that parameter entirely and pass it to the Payment App. Specific parts of that full message can be pulled out and passed in as the other parameters that the user agent needs, if we need to deal with cumbersome Web IDL restrictions.

[ianbjacobs]

@adrianhopebailie,

Unless it is possible to pass a complete and atomic payment request into the browser API the browser will need to construct this complete request dynamically in order to pass it to a payment app.

What is a "complete and atomic payment request"? Do you mean the PaymentDetails part
of the paymentRequestAPI?

As you said, the browser/mediator is acting as a router. It takes as input payment method
identifiers and some payment-method-specific data. Once the user has chosen an app,
the browser/mediator MUST NOT send more information than is necessary to the
payment app for processing. The browser/mediator MUST NOT send the merchant's
full list of supported payment methods, or the optional data for irrelevant payment
methods. Furthermore, the flags of PaymentOptions are irrelevant to the selected payment
app; what is important is the resulting data from the user interaction.

I agree we need to define how the browser/mediator gets relevant data to the
payment app. Handing "the entire blob of data from the merchant" does not seem
appropriate (indeed, could be harmful by sharing too much data, will take up
bandwidth, etc.)

Hence my question: what do you mean by "complete and atomic payment request"?

Ian

[burdges]

Isn't that what fields level encryption, and implicitly signatures, would be for @halindrome ? If it must be passed unaltered, then you need to binary encode and sign it. Anything unsigned cannot be trusted anyways.

[halindrome]

@burdges FIeld level encryption and signatures are exactly for this. However, we are not currently specifying their use. But I agree that unsigned things cannot be trusted.

[adrianhopebailie]

What is a "complete and atomic payment request"? Do you mean the PaymentDetails part
of the paymentRequestAPI?

No, that's the problem. Right now it's split among a few parameters. I mean the essential fields for a payment request: currency, amount, supported methods and their custom data.

Once the user has chosen an app, the browser/mediator MUST NOT send more information than is necessary to the payment app for processing. The browser/mediator MUST NOT send the merchant's
full list of supported payment methods, or the optional data for irrelevant payment
methods.

This is really interesting, thanks for raising it! It has been touched on in previous discussions but never deeply explored. I think it warrants it's own thread. I can see arguments for the mediator trimming down the request (protect privacy of the payee) but also arguments against (mediator must understand too much about the request and therefor limits extensibility of the message).

[msporny]

@adrianhopebailie wrote:

I can see arguments for the mediator trimming down the request (protect privacy of the payee) but also arguments against (mediator must understand too much about the request and therefor limits extensibility of the message).

Also keep in mind that merchants may want to digitally sign payment requests in the future, and anything that changes the payment request (including the mediator) would invalidate that digital signature.

Really, the payment mediator re-writing the payment request intended for the payment app should be off limits. If we don't put it off limits, we're forcing a few decisions around security and digital signatures which may paint us into a corner wrt. security.

[dlongley]

@ianbjacobs,

The browser/mediator MUST NOT send the merchant's
full list of supported payment methods, or the optional data for irrelevant payment
methods.

I disagree. For example, people may want to configure their browser to always use one particular Payment App, regardless of payment method. Then, that one Payment App may, itself, act as a mediator for other Payment Apps.

[ianbjacobs]

I propose we close this issue which I believe is mostly redundant with issue #157.

Ian

[adrianhopebailie]

I agree that the crux of what is here is dealt with in #157