W3C home > Mailing lists > Public > public-payments-wg@w3.org > July 2016

Re: Encrypting basic card data

From: Shane McCarron <shane@spec-ops.io>
Date: Mon, 11 Jul 2016 12:31:33 -0500
Message-ID: <CAJdbnOD4F3O5Hw9B-_sqPwvdQAtp7SzYwt-4cFaM-57g6oKRzw@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Erik Anderson <eanders@pobox.com>, Payments WG <public-payments-wg@w3.org>
Sure.  Or 2FA or whatever.  There are a lot of ways to help "secure" the
customer-side of the transaction. I would also note that all of the
messages in this API are already encrypted over the wire.  So what we are
talking about is the content of data structures as they move among various
layers of the architecture.  I think the risk of MitM is pretty low...

On the other hand, if I were using a third party payment app on a public
computer at a library, I wouldn't want the PAN coming out of my payment app
visible at all to the user agent. My solution to that is to not use
computers at libraries - but not everyone has that luxury I imagine.


On Mon, Jul 11, 2016 at 12:15 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2016-07-11 17:24, Erik Anderson wrote:
>
>>  How is the current Basic Card mechanism any less secure than what is
>>> done today using web forms to capture card details?
>>>
>>
>> Adrian, time.... Time changes everything, Chip-n-pin is causing fraud to
>> move away from the Merchant terminal to online. Laws are changing quickly
>> to adjust.
>>
>>
> The quick route to on-line security comparable to Chip-n-pin, is
> off-loading client-side payment operations to a locally installed native
> "App" like Apple and Google do.  It is essentially the same thing as a
> payment terminal in the physical world.
>
> Some people claim that these solutions even surpass Chip-n-pin
> security-wise!
>
> Anders
>
>
>


-- 
Shane McCarron
Projects Manager, Spec-Ops
Received on Monday, 11 July 2016 17:32:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 11 July 2016 17:32:36 UTC