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

I completely disagree with this.

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>
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
>
>
>
>
>
>