RE: Payment App spec implementations

Not meaning to be a stick in the mud but I’ve been monitoring this thread from the shadows and this thread as well as a related thread from Tommy about complexity and I was wondering if anyone else has concerns about the complexity. I am a firm believer that the more complex a process, the chances of vulnerabilities increase exponentially -- this seems very complex.

Has anyone stepped back and reevaluated the problem to see if there is a simpler, less complex solution? Each query this, create listener(s) for that, handle this or that can open security holes waiting to be exploited. I’ve worked with people that believe “if it ain’t complex, it ain’t worth writing” and I try to avoid this path as much as possible.

On another note, the user can store a list of payment apps but can a payment app be/use the existing 3D secure rails that is currently in use in the industry? I know, this is counter to my complexity concern but it is currently in use and I don’t see the card brands changing anytime soon.


Steve Sommers
Senior Vice President, Applications Development

Shift4 Corporation
1491 Center Crossing Road
Las Vegas, NV  89144-7047

702.597.2480 ext. 40400
fax 702.597.2499
www.shift4.com
steve@shift4.com

facebook.com/shift4corp
twitter.com/shift4corp
linkedin.com/companies/shift4-corporation
shift4.com/blog



This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate,distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.

-----Original Message-----
From: Dave Longley [mailto:dlongley@digitalbazaar.com]
Sent: Friday, March 10, 2017 8:26 AM
To: Michiel de Jong; Manu Sporny
Cc: Adrian Hope-Bailie; Ian Jacobs; Payments WG
Subject: Re: Payment App spec implementations

On 03/10/2017 03:55 AM, Michiel de Jong wrote:
> Hi Manu,
>
> I agree with your point that the a polyfill would be useful for
> debugging payment apps, and for demos and strawman discussions, and it
> would be helpful if we try to build something like that.
>
> But I cannot think of a way to make it secure enough to use it in
> production: If a legitimate payment app can include a script that
> allows it to register itself, then a malicious website can also
> install itself as a payment app, without the user's consent. Also, if
> a legitimate webshop can include the polyfill script to launch the
> 'choose payment method' dialog and redirect the user to their
> preferred payment app, then a malicious website can also redirect the
> user to the user's installed payment app and request payment without
> getting the user's consent first.
>
> What if instead of a polyfill, we were to create a browser plugin? The
> plugin could host the dialog and store the user's list of installed
> payment apps. The downside would be that installing a payment app
> involves installing this plugin first, and then installing your
> favorite payment app using the plugin's dialog UI. But it would be a
> nice way to preview the future.
>
> WebExtensions are the new cross-browser way to create browser plugins,
> might be useful for this:
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions


Here's an approach for creating a polyfill that may address some of the above issues but would require a third-party, community run website to play the role of intermediary. This is not a complete work up of what would need to be implemented and there are various potential pitfalls with this approach, but I figured I throw it out there for those interested:

Quick Overview of a Payment Request/Payment App polyfill:

1. A third-party, community run website "payment-polyfill.io" could be run that has a frontend that stores permissions for origins and entries for payment apps via localStorage/IndexedDB. It will provide the UI for user consent and play the role of mediator, etc.

2. A user visits payment-app.com. This site calls
PaymentManager.requestPermission() which is polyfilled. It shows an iframe overlay from payment-polyfill.io that has a UI that says that "payment-app.com" wants to "Handle Payments" with Allow/Deny buttons, essentially mocking a browser permission UI. If the user grants permission, an entry for payment-app.com is stored in permissions on frontend in localStorage/Indexed DB.

3. payment-app.com registers a service worker. The service worker imports a polyfill script which exposes an API on a var `polyfill`. The service worker calls `polyfill.addEventListener('paymentRequest', ...)` and `polyfill.paymentManager.set(...)` (or whatever the appropriate Payment App APIs are). A URL for the payment app needs to be provided at registration time. More on this later.

4. When `polyfill.paymentManager.set(...)` is called, a client window gets opened or focused that opens an iframe to payments-polyfill.io. An invisible iframe receives, via `postMessage`, the details passed to the method. It stores those details in localStorage/IndexedDB.
Alternatively, this information could be POSTed to payments-polyfill.io via `fetch`, however, this would require storing the information on a backend at payments-polyfill.io instead of in localStorage/IndexedDB.

5. The user visits merchant.com which loads the polyfill. The PaymentRequest API called (which the polyfill provides) and it loads payments-polyfill.io in an iframe and shows a UI for the user to choose the payment app to pay with. Upon selection, an iframe on payments-polyfill.io is opened for payment-app.com (at the payment app URL previously registered) and the payment request is send via `postMessage` to it. Since payment-app.com has loaded the polyfill, it receives the message and forwards it to page's active service worker via `postMessage`.

6. The payment-app.com service worker receives the payment request via the event handler that was added via `polyfill.addEventListener`. It handles the payment request and responds with `paymentRequest.complete()` (or whatever the API is), which has been polyfilled to use `postMessage` to send the response to payments-polyfill.io which then responds to merchant.com via `postMessage` which the polyfill translates into the appropriate responses for the PaymentRequest API.


>
> Cheers,
> Michiel
>
> On Thu, Mar 9, 2017 at 11:32 PM, Manu Sporny
> <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
>
>     On 03/09/2017 12:25 PM, Adrian Hope-Bailie wrote:
>     > Assuming that all of the major vendors are going to implement PR API
>     >  soon what would be the value of the polyfill? Are you suggesting it
>     >  could add payment apps functionality where that is not available?
>
>     Yes, that would be one of the purposes of a polyfill. A secondary
>     purpose would be the capability to spec out and iterate on new features
>     before browser implementation happens (which is expensive to do and
>     takes lots of time to iterate on).
>
>     Also, note that implementing the PR API in a browser today still means
>     that there will be hundreds of millions of browsers that will not have
>     access to it due to the length of upgrade cycles... which puts people
>     trying to deploy it into at least one of two situations:
>
>     1) Waiting for deployment to get broad enough to deploy (which could
>        take years).
>     2) Writing complicated fallback algorithms which prevents the market
>        from experiencing the new technology/flow.
>
>     The option always exists to not use the polyfill and take one of the two
>     approaches above. However, having a polyfill would enable those of us
>     that want to push out Payment Apps and PaymentRequest to have the
>     ability to do so while the browser implementations catch up.
>
>     At the same time, I don't mean to trivialize the difficulty of writing
>     the polyfill. There are concerns around security and deployment and
>     there is no clear answer to polyfilling the native apps portion of
>     payment app selection... these are issues we'd have to look into further
>     (and the group may find that a distraction, which is why we'd try to
>     come up with a solution before presenting to the group).
>
>     -- manu
>
>     --
>     Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: Rebalancing How the Web is Built
>     http://manu.sporny.org/2016/rebalancing/

>     <http://manu.sporny.org/2016/rebalancing/>
>
>


--
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Friday, 10 March 2017 17:03:34 UTC