W3C home > Mailing lists > Public > public-payments-wg@w3.org > June 2016

[w3c/webpayments] Should the browser pass user data it has collected (email etc) to the payment app? (#137)

From: Adrian Hope-Bailie <notifications@github.com>
Date: Wed, 15 Jun 2016 13:18:42 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Message-ID: <w3c/webpayments/issues/137@github.com>
Migrated from https://github.com/w3c/browser-payment-api/issues/194

@mattsaxon said:

>Now that the payment options field can include the request of the email and phone number information, we need to consider how that information might be made securely available to payment applications such that for payment applications that need this information, the experience can be optimised.

>Example payment methods that have requirements for this data are UnionPay. This method can ask for a one-time password which is delivered via SMS and hence phone number (usually mobile/cell) may be needed.

>Other examples are a large number of payment methods that use the email address as the payer unique identifier (e.g. PayPal).

>Whilst it is true that the contact information may be different from the identity information (multiple phone numbers or email addresses in use by the Payee), we should consider how when they are the same (the usual case I would assert), that the information can be shared with the appropriate consent.

>At the moment, whilst it is not actually documented in the specification text, I believe it is the WGs' expectation that the Payment Options field is only available to the Mediator, this prevents the payment apps from offering these contact details as pre-population options data that thy may need.

@rsolomakhin said:

>I don't think that the user agent should provide user's email address to the payment app. The payment app should ask for an email address when the user signs up with or logs into the payment app. This authentication step is necessary anyway, because a payment app will need to access user's payment information in some way. For example, connecting to user's bank account or entering user's credit card information.

@ianbjacobs said:

> +1 to distinguishing the data that the user will provide to different parties for different reasons:
  - The merchant for that relationship. (This could further be broken down, e.g., 
     shipping agent, but I wouldn't advocate for that in v1.)
  - The payment app for the relationship with the payment app provider.

> @mattsaxon, it seems to me that if I install a China UnionPay app, I will give it my email address when I initialize it.

@burdges said:

>Any information provided by the browser like this would violate security properties of some payment apps.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Received on Wednesday, 15 June 2016 20:19:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:17 UTC