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 16:26:50 UTC