Re: Security of the solution. Re: CfC to publish documents as FPWD of the Web Payments WG

On 2016-04-07 19:22, Adrian Hope-Bailie wrote:
> I completely disagree with this.

Everything is cool unless Apple takes the somewhat less fuzzy path I'm
advocating since such a solution could provide state-of-the-art security
and UI, as well as being straightforward integrating in existing Web shops.

Anders

>
> If we produce a standard that provides no path for existing payment methods (albeit deficient) to be used and ultimately upgraded we will never get traction.
>
> There is nothing stopping someone defining an Encrypted Card Payment Specification which, if it is widely supported, should supersede the Basic Card Payments Specification.
>
> The market should drive this through merchants and payment apps that choose to not support the older less secure methods.
>
> On 7 April 2016 at 09:34, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     Non-member opinion: I don't believe that Web payments solutions that do not reach
>     a client-side security level comparable to EMV-cards in payment terminals, or Apple Pay,
>     are worth dealing with in a new standard.
>
>     That would for example exclude the Basic Card Payment (aka CNP - Card Not Present) profile:
>     https://w3c.github.io/browser-payment-api/specs/basic-card-payment
>
>     However, the strategy behind the Web Payment API (more or less) mandates that
>     even deficient payment schemes like CNP indeed transcend into W3C standards.
>     This strategy has multiple downsides including the inability giving the market
>     a firm message regarding core system features.
>
>     Naturally alternative approaches also have their share of problems; the issue
>     is rather what the payment world in general is expecting.
>
>     Anders
>
>
>
>
>
>

Received on Friday, 8 April 2016 04:22:45 UTC