Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the browser pass user data it has collected (email etc) to the payment app? #137

Closed
adrianhopebailie opened this issue Jun 15, 2016 · 1 comment

Comments

@adrianhopebailie
Copy link
Collaborator

Migrated from w3c/payment-request#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant