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

I have to disagree as well. As much as I admire the intent behind it, from
a merchant prospective it would be naive to assume that customers will move
completely away from 'less secure' payment methods (such as CNP) in the
near to medium term, merchants just won't adopt it and neither will
platforms that support those merchants since the goal is provide the
broadest range of consumers with the best experience, not just those that
have adopted a new payment mechanism such as Apple Pay. IMO a generic spec
around payment details would be a larger benefit with little to no
compromise on the ability for it to support that higher level of security.



On Fri, Apr 8, 2016 at 12:25 AM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

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