European market - Security concerns about webpayments

[cyberphone]

@adamroach

The merchant app runs against its own origin. The payment app runs against its own origin, in a service worker. They exchange information with each other in a tightly-controlled fashion via the Web Payments API

I can't find any information in the current draft explaining these interactions. Although I'm just guessing here it is not unimaginable that the Web Payment API could be abused.

We don't dictate to them how they collect or store credentials; we allow and expect them to use the entire rich web platform to craft this according to their requirements and preferences. We are relying on the (easily demonstrable) fact that the platform already has affordances sufficient for this purpose.

Unfortunately your fellow Mozillians do not consider the Web platform (as shipping) suitable for credential storage: https://bugzilla.mozilla.org/show_bug.cgi?id=1065729#c262

[adrianhopebailie]

1- We have only two technical solutions to provide payments : payment page redirection & Iframe.
Currently, the specification does not allow any of these solutions, which raise our concerns about its adoption . We cannot ask our customer to migrate to a non PCI compliant solution.

Does the specification intend to support existing payment solutions that follow PCI DSS rules ?

This is not true. As a PSP you can still provide your merchants with code that embeds an iframe, the content of which is hosted on your secure (and PCI DSS certified) web servers.

The Merchant can explicitly give that iframe permission to call the Payment Request API so when the user wants to pay the interaction is done directly with your systems.

For the redirect use case, nothing stops you from invoking the API when the user has been redirected to the payment page hosted on your secure servers.

2- Pay Apps are great piece of the specification, but they raise several issues

• Payee may have his favourite Pay Apps. Is the PSP supposed to deal with all these Payment Apps and handle their own payment message structure (Android Pay sends token, Basic Card sends clear data, Maybe some app will send encrypted data) ?

A PSP does not need to have any knowledge of payment apps, only payment methods. Each payment method defines its own message structure and to support a payment method the PSP must be able to generate a request and handle a response from the API that conforms to the structure defined by that payment method.

The payment app that the payee uses is not even known to the PSP.

• Regarding PCI DSS, every system where critical data transits must be certified PCI DSS in order to be compliant. Will the browser (Mediator) be certified, knowing that critical data can be stolen from a browser in a corrupted computer?

Since browsers already handle this when they provide the ability to auto-fill card forms I must assume they already meet all the requirements.

[cyberphone]

@marcoscaceres @adrianhopebailie Security reviews have been requested by the WG chairs. I don't get how you can do such for Web-based payments unless you are an absolute über expert on every possible topic (I'm not). Is there a security model description somewhere? On top of my head I can't say I understand:

• Where (and how) is SOP overridden? ServiceWorkers do that? IFRAME does the trick?
• Where (and how) are payment credentials stored?
• How do you perform cryptographic operations in payment apps?

It is (off-list) sometimes claimed that FIDO alliance products is the intended (or desired) authentication solution. If that's the case it rather brings the issuer into the scenario while payment gateways would only be dealt with in the background through merchants, right?

[Abacaxi-Nelson]

Thanks for quick answer.

This is not true. As a PSP you can still provide your merchants with code that embeds an iframe, the content of which is hosted on your secure (and PCI DSS certified) web servers.

The Merchant can explicitly give that iframe permission to call the Payment Request API so when the user wants to pay the interaction is done directly with your systems.

I agree, it's technicaly possible and compliant.
But i disagree on the UX involved;

For the redirect use case, nothing stops you from invoking the API when the user has been redirected to the payment page hosted on your secure servers.

Again, i agree; but we loose all UX, the payee is redirected from the ecommerce website to a generic page, loosing connection with the merchant.

[marcoscaceres]

Again, i agree; but we loose all UX, the payee is redirected from the ecommerce website to a generic page, loosing connection with the merchant.

Is that much different than today? The ecommerce must still provide a good UX/UI that associates the two together (see PayPal and eBay integration - which is pretty good). Is that what you mean?

[cyberphone]

It would also be interesting to know how Web (in contrast to App)-based payment applications are supposed to cope with PSD2's SCA (Strong Customer Authentication) requirement.

[Abacaxi-Nelson]

Is that much different than today? The ecommerce must still provide a good UX/UI that associates the two together (see PayPal and eBay integration - which is pretty good). Is that what you mean?`

@marcoscaceres : you are right, it's not different than today, but are we here to innovate ? Redirection and iframe based payment are secure process, but not friendly process.

I hope that W3C could change that.

Thanks,

[ianbjacobs]

Hi @tugal,

Regarding user experience, I believe we have an opportunity to improve
on the status quo. We are discussing how payment apps open windows
in our issue 73. One could imagine, for example, that instead of being
forwarded to a Web site to make a payment in the usual way, that the user
experience could remain closer to the checkout context. That may be
easier in a large screen context (e.g., desktop) than in a mobile context.

Although the WPWG will unlikely make specific UX requirements, I believe
through the API user agents will have information that enables them to
improve on today's UX.

Ian

[1] w3c/payment-handler#73

I believe we have an opportunity to improve the user experience with this API.

[adamroach]

@cyberphone --

• Where (and how) is SOP overridden? ServiceWorkers do that? IFRAME does the trick?

The merchant app runs against its own origin. The payment app runs against its own origin, in a service worker. They exchange information with each other in a tightly-controlled fashion via the Web Payments API. The model here is very similar to Web Messaging and Foreign Fetch.

• Where (and how) are payment credentials stored?

This is handled the same way as it is today: cookies, IndexedDB, or local storage. It is entirely up to the app to use one or more of these technologies in whatever way it sees fit. Storage on the back-end is entirely up to the payment provider. There are also touchpoints with things like WebAuth and the emerging Credential Management API.

Most importantly, this is out of scope for the work we're doing. The WebPayments working group is defining a new capability that allows developers to create Web Apps that can provide payments. We don't dictate to them how they collect or store credentials; we allow and expect them to use the entire rich web platform to craft this according to their requirements and preferences. We are relying on the (easily demonstrable) fact that the platform already has affordances sufficient for this purpose.

• How do you perform cryptographic operations in payment apps?

WebCrypto.

[ianbjacobs]

Closing due to lack of activity. See also SPC.