Re: Payment App spec implementations

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

Cheers,
Michiel

On Thu, Mar 9, 2017 at 11:32 PM, Manu Sporny <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/
>
>