Should origin information (about the payment request) be shared with the payment app?

[ianbjacobs]

Hi all,

In a conversation today I was asked whether origin information would be shared from the browser to the payment app. Sharing origin information, for example, would enable a payment app to generate an origin-bound token.

Relates to this part of the spec:
https://w3c.github.io/webpayments-payment-apps-api/#payment-app-request-data

Ian

[halindrome]

I hadn't thought about this specifically before, but I feel it is essential. My payment app should be able to make recommendations (or even decisions) about the payment instrument based upon the origin. If I am on amazon.com, use my "Amazon" branded visa. If I am at target.com, use my target branded MasterCard. If I am on the delta.com site use my delta skymiles amex. I need those points!

[rsolomakhin]

I think the browser should provide the origin to the payment app. For example, Android Pay needs to verify the origin of the website against the list of registered merchants. (Android Pay requires merchant registration where merchants agree to terms of service.)

[dlongley]

The origin of the payee (or whatever identifier we use for the payee) is important to pass on to the Payment App. I would think that information would be required and present in the payment request message that gets forwarded to the app -- and, depending on our design, could actually be different from the origin of the request.

Now, if an API strongly binds those two together (i.e. you can't take a digitally-signed payment request message from one origin and submit it from another one), then the two would necessarily be the same origin. But if I could sign and put payment request messages out on the Web and people could find them and submit them however they wanted, then the Payment App would be most interested in the payee (or "merchant") origin, not where they were submitted from.

[halindrome]

@dlongley I think that in the Apple Pay implementation of the Browser Payments API there is merchant vetting that happens before they are allowed to accept Apple Pay. So in addition to the origin, the merchant is sending along their Merchant Key or whatever and Apple Pay is ensuring everything is as it should be before processing the payment.

I imagine other captive payment schemes would work similarly.

[ianbjacobs]

We discussed this issue at the 17 August task force call:
https://www.w3.org/2016/08/17-apps-minutes.html#item02

Summary of two main points:

• There may be privacy implications of sharing merchant origin information with third party payment apps. Both merchants and users may care about sharing of the information.
• Such sharing may be useful for some payment methods (e.g., that do tokenization) and unncessary for others (e.g., cards). This suggests that payment method specs might be the place to define sharing of origin information.

[halindrome]

I am sorry I was not in this discussion. I find it hard to fathom how there could be any privacy issues here... as the user, I CHOSE TO INSTALL the payment app. Therefore isn't it up to me if I then choose to tell that app where I am shopping? I mean... it's not exactly a secret.

Beyond that, I would disagree that it is only of interest to payment methods. It is CERTAINLY required that payment methods know. Otherwise they are going to have a hard time sending the funds. But my wallet needs to know so it can help suggest the right payment method to me. What we are attempting to do here is improve the end user experience when shopping. Maximum convenience and utility for the end user. Suppressing this information is not going to help with that goal.

[burdges]

I've likely missed some relevant conversations, but the payment app learning the recipient sounds fine in principle. It should not learn this until the users picks it thought the payment mediator of course.

There might be interesting payment apps where controlling this information could be a selling point, but mostly that sounds like BitCoin or Zerocoin space stuff, like maybe your private keys remain air gapped or something.

It's generally false however that users should trust their payment app, especially if it's web based. There are obviously going to be malicious web based payment apps that trick the user into installing them for various nefarious purposes.

[ianbjacobs]

Reading a bit in the Consultation Paper from the EBA [1]:

"In any case, the authentication procedure should ensure that the payer is always made aware of the amount and payee of the transaction he is authorising and should be tamper-resistant to prevent any manipulation of the amount and of the payee during the initiation of the payment transaction so that any change to the amount or payee shall result in a change of the authentication code."

This made me think that if I open a payment app to make a payment, it is likely the payment app will want (or perhaps even need to) display information about the payee (origin) as part of an authorizaiton step.

Ian

[1] https://www.eba.europa.eu/documents/10180/1548183/Consultation+Paper+on+draft+RTS+on+SCA+and+CSC+(EBA-CP-2016-11).pdf

[halindrome]

@ianbjacobs that's a good point. Actually, with digital signatures, I can envision something akin to the lock icon on my address bar right next to the payee name:

{{icon}} Secure payment request from Alice Co. for $xxx.yy

[ianbjacobs]

At its 24 August teleconf, the task force concluded that yes, origin information should be available to the payment app.
https://www.w3.org/2016/08/24-apps-minutes#item02