What gets registered - apps, wallets, or payment instruments? about webpayments

[msporny]

On second thought, this isn't as much of a concern as I had originally thought. You could easily get rid of the payment app selection dialogue by just querying all of the apps and asking which instruments/methods they support. So, the number of steps necessary in both cases are still two.

It's still something we should talk about - it feels like there is more complexity in the register payment apps + payment methods vs. just payment methods case.

[adrianhopebailie]

The intention is that user's register payment apps. The way this is done will differ from platform to platform but a minimum requirement of this is that the payment mediator is aware of the new payment app and which payment methods this app supports.

It is also recommended that payment apps be able to notify the payment mediator of updates to the set of payment methods they support.

I anticipate that there will not be many payment apps that support multiple payment instruments and those that do will do so because they have intelligent ways to help users pick the best instrument for each payment (or even do this for them). This kind of user-centered functionality will be one of the ways that payment apps differentiate themselves.

In terms of sharing across platforms I expect this to follow a similar pattern to something like a password manager. User's that wish to share their passwords across platforms install the same password manager on all platforms and then authenticate themselves with that password manager. The password manager's publisher ensures that passwords are synchronized across platforms on the basis of the same user authenticating on each platform.

[webpayments]

This explanation is consistent with what I was thinking.

On Wed, Dec 9, 2015 at 2:56 AM, Adrian Hope-Bailie <[email protected]

wrote:

The intention is that user's register payment apps. The way this is done
will differ from platform to platform but a minimum requirement of this is
that the payment mediator is aware of the new payment app and which payment
methods this app supports.

It is also recommended that payment apps be able to notify the payment
mediator of updates to the set of payment methods they support.

I anticipate that there will not be many payment apps that support
multiple payment instruments and those that do will do so because they have
intelligent ways to help users pick the best instrument for each payment
(or even do this for them). This kind of user-centered functionality will
be one of the ways that payment apps differentiate themselves.

In terms of sharing across platforms I expect this to follow a similar
pattern to something like a password manager. User's that wish to share
their passwords across platforms install the same password manager on all
platforms and then authenticate themselves with that password manager. The
password manager's publisher ensures that passwords are synchronized across
platforms on the basis of the same user authenticating on each platform.

—
Reply to this email directly or view it on GitHub
#28 (comment).

-Shane

[dlongley]

+1 to registering only Payment Apps.

[msporny]

+1 to registering only Payment Apps

[msporny]

The password manager's publisher ensures that passwords are synchronized across platforms on the basis of the same user authenticating on each platform.

So, we could have a more generalized solution w/ the Credentials work. You can be issued payment instrument credentials and you could be issued payment app credentials. Your various Payment apps could query your payment instrument credentials to 'sync' between payment apps. Your Payment Mediators (browsers) could request your payment app credentials to sync them between various browsers and applications.

[burdges]

I'd agree with registering only payment applications. I'm concerned with what the payment applications reveal to the pages the user visits though, which I suppose goes here since the comment by @msporny impacts it.

Ideally, payment applications should not even be able to reveal that they're installed until the user selects them. In particular, the payment applications should never learn that the user has visited a page selecting payment until the user selects that particular payment applications, as payment applications might have network access themselves.

We'll thus need some form of "payment application mediator" through which the user selects which payment application to use. We cannot realistically ask the browser makers to provide this user-interface because merchants want to control the look and feel of their payment page, and browser makers dislike controlling the look and feel too much.

We could create a secure context in which the merchant may run javascript that:

• may only modify a small portion of the page on which it runs, and
• cannot communicate with the larger page it runs on, or the network, but
• has exclusive rights to read the registration data of payment applications and launch them.

There is an important side benefit of keeping the payment applications in the dark as long as possible: If the payment applications cannot spy on the user, then they cannot annoy the user with ads, etc. either, making security software, ad blockers, users, etc. less likely to disable everything.

I have not yet read the existing secure contexts stuff, but it's hopefully relevant: https://w3c.github.io/webappsec-secure-contexts/

[adrianhopebailie]

The job of the payment mediator is to create a distinct separation between the website and payment app so that all comms between them is passed through the mediator who is able to do what is best for the user both in terms of privacy protection and security.

Ideally, payment applications should not even be able to reveal that they're installed until the user selects them.

👍 - I'd go one further and say there is no reason that a payment app ever has to reveal that it is installed to the calling website. The response that the website gets to a payment request is formatted according to the specifications of the payment method in use. If this is a generic method that is supported by many apps the website shouldn't be able to infer which app is being used at all.

What follows is a copy of my response to your comment at: https://github.com/WICG/paymentrequest/issues/30#issuecomment-163905421

This is all with one caveat. It will be very valuable for a website to check if its own payment app is installed. This would be enforced by the UA which knows the origin of the app publisher and only supports the use of this API function if the origin of the current browsing context is the same. Merchants and PSPs that publish apps to facilitate custom payment methods that incorporate features such as loyalty programs or coupons will need a way to tailor the user experience prior to issuing the payment request so they can encourage customers to login (so they can customize the payment request) or install the merchant's payment app.

@burdges:

In particular, the payment applications should never learn that the user has visited a page selecting payment until the user selects that particular payment applications, as payment applications might have network access themselves.

👍 - Invoking the payment application is up to the payment mediator and should only be done after the user has selected the app they wish to use. I'd go further and say that the mediator should trim the payment request of any data that is not relevant for the payment methods that the app supports.

Unless a payment method specifies a way that this is passed in a payment request it's unlikely that the payment will ever know what the calling website is.

[burdges]

Sounds good. Who provides payment mediator user-interface though? It's platform dependent I suppose, but..

In the browser, it's possible to design a payment mediator secure context so that the merchant controls that flow, look and feel, etc. but cannot do anything too harmful. There are real advantages to this like a news paper could run a payment bar that handled micro-payments if suitable payment applications were installed, but otherwise offered a link to a subscription page. There are also more ways for us, the w3c, browser makers, merchants, and users to screw up though too.

I had not considered the need to trim data there because in my little world the merchant never receives any data about the customer, except for whatever the merchant put into a purchase contract, and a bunch of anonymous digital signatures. I donno if the need to trim sensitive data in the payment mediator is fatal to the idea that the merchant can provide the payment mediator logic, maybe they could still provide some part of its user interface.

[dlongley]

I'd go further and say that the mediator should trim the payment request of any data that is not relevant for the payment methods that the app supports.

-1

The Payment Mediator should not mess with any of the information that the merchant is trying to send. Furthermore, Payment Apps could use that information to understand what other types of payment methods are worth supporting in the future. This could also be a problem for digitally-signed payment requests.

[burdges]

I'd agree that the customer's wallet must verify the merchant signatures. Is there a problem with the merchant providing the payment data pre-trimmed for all payment applications they support? It should not be that much data compared with modern web pages, even as the payment applications multiply.

[dlongley]

Is there a problem with the merchant providing the payment data pre-trimmed for all payment applications they support?

Well, they'd probably need N signatures (one for each method) or some complex CL-Signature and trusted mapping information. In short, it could get very messy and frighten off developers.

Before even considering anything like that, I'd rather see the threat model for exposing all of the payment request data to the user's payment app of choice. What are the real dangers/concerns as concrete examples?

[dlongley]

Is there a problem with the merchant providing the payment data pre-trimmed for all payment applications they support?

Just a point of clarification: the design calls for merchants to simply specify supported payment methods, not particular payment applications. By standardizing around methods, payment apps can freely evolve and merchants needn't be explicitly aware of which apps a person is necessarily using to make payments. Payment apps may also support multiple payment methods and help the user make better choices regarding which one to use to complete a payment.

[webpayments]

You are correct. However, let's be careful here. In the updated
Architecture Document "payment method" is not Visa or Macy's Charge. Or
rather it is not JUST that. I think what you mean here isn't "Payment
Method" as defined in the Architecture. You are referring to the things
that a merchant talks about accepting (e.g., VIsa, Mastercard, Paypal).
Correct?

We need to have an easy way for a merchant to say that in a vocabulary that
all Payment Mediators will understand. That's why I wanted a registry for
these Payment Methods. There has to be some sort of mapping from "I accept
bob's charge" to "on this device bob's charge is supported by these 3
different payment apps" so that the payment mediator knows how to pass the
messages through to the right thing after presenting those options to the
user. Right?

On Fri, Dec 11, 2015 at 11:16 AM, Dave Longley [email protected]
wrote:

Is there a problem with the merchant providing the payment data
pre-trimmed for all payment applications they support?

Just a point of clarification: the design calls for merchants to simply
specify supported payment methods, not particular payment applications. By
standardizing around methods, payment apps can freely evolve and merchants
needn't be explicitly aware of which apps a person is necessarily using to
make payments. Payment apps may also support multiple payment methods and
help the user make better choices regarding which one to use to complete a
payment.

—
Reply to this email directly or view it on GitHub
#28 (comment).

-Shane

[dlongley]

We need to have an easy way for a merchant to say that in a vocabulary that
all Payment Mediators will understand.

My understanding is that payment requests would include the identifiers (potentially URLs) for the Payment Methods the merchant supports (along with any payment-method specific information). A Payment Method would not just be "Visa" (or this identified via a URL), it would be something more specific than that. @adrianhopebailie suggested some Payment Method examples: "Legacy Visa Credit", "Tokenised Visa Credit", "Encrypted Visa Credit v2" in another issue.

In any event, the Payment Mediator would take the identifiers (potentially URLs) from the set of supported Payment Methods in the payment request and compare them against the identifiers from the set of supported Payment Methods for each Payment App. Every Payment App that has a matching Payment Method would be made available to the user as a possible choice. Of course, the Payment Mediator could also potentially give the user the ability to pick defaults or preferences to simplify future selections.

[burdges]

Well, they'd probably need N signatures (one for each method)

I'd expect they'll need those anyways since the signature algorithms for different methods may differ, perhaps radically.

I'd rather see the threat model for exposing all of the payment request data to the user's payment app of choice. What are the real dangers/concerns as concrete examples?

At minimum it widens the attack surface for obtaining identifying information. A wallet application is potentially designed, or even insured, with the idea that it typically protects around $1000 in token, not information that'd expose the user to identity theft.

Aren't discount/loyalty programs being discussed for payment methods? Those should be considered malicious adversaries whose interests are actively hostile to the user's interests, so they really should not learn anything not specifically meant for them.

There are various new payment methods trying to support micro-payments by offering lower transaction costs. And merchants might wish to promote these. Yet, merchants doing so might face retaliation by legacy payment method providers.

[dlongley]

@burdges,

I'd expect they'll need those anyways since the signature algorithms for different methods may differ, perhaps radically.

I think we're talking about multiple layers of digital signatures. What you're describing would probably be a payment-method-specific digital signature. Which should be just fine (I believe we want to be able to include any arbitrary, necessary payment-method-specific data in the payment request). What I'm talking about is a higher-level digital signature on the payment request itself, such that when the request is forwarded to a Payment App, that app, if it so chooses, can verify that the payment request was not modified. However, depending on the format we settle on for these messages, that may not end up being a requirement.

Aren't discount/loyalty programs being discussed for payment methods? Those should be considered malicious adversaries whose interests are actively hostile to the user's interests, so they really should not learn anything not specifically meant for them.

One approach would be to tokenize or encrypt this kind of information.

There are various new payment methods trying to support micro-payments by offering lower transaction costs. And merchants might wish to promote these. Yet, merchants doing so might face retaliation by legacy payment method providers.

I'm not so sure we can easily protect against that (or it's our place to) -- and that sounds like an anti-compete lawsuit waiting to happen.

[adrianhopebailie]

Closing as this seems to have been largely agreed upon and has had no input for some time.