W3C home > Mailing lists > Public > public-web-security@w3.org > October 2015

Card Payments on the Web. was: State of the WebCrypto API

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Tue, 13 Oct 2015 08:01:31 +0200
To: ANDREAE Philip <P.Andreae@oberthur.com>, Tony Arcieri <bascule@gmail.com>
Cc: "public-web-security@w3.org" <public-web-security@w3.org>
Message-ID: <561C9E3B.2070203@gmail.com>
On 2015-10-12 21:42, ANDREAE Philip wrote:
> Using 3D-Secure as a application mechanism allowing the Merchant and
 > Issuer to communicate and subsequently establish a link between the
 > Cardholder and the Issuer.

That's indeed a possibility.


> Allow the Issuer to discover if a Smart Card reader is present.

Now it became a bit more difficult but still within reach.


> Ultimately allow the Issuer to communicate through the 3D-Secure redirect
 > with the smart card reader thought a tunnel allowing them to issue APDUs to the card.

This is where the real pain is.

Since I have described (any number of times...) what I consider the "right" approach,
it would be more interesting hearing other folks opinion on this concept.

Shoot!


 > The smart card reader could in theory also be an NFC interface.
>
> I am not a technical guy.  All I want to suggest is we need to enable the Financial Institution
 > "The Issuer", who ultimately guarantees the payment transaction,

As a rather technical guy I agree :-)


> to be able to use existing
 > payment credentials and associated tools, to assure themselves that a genuine set of payment
 > credentials is present.

If existing credentials will be usable remains an issue, particularly the card-reader
represent a hurdle.


> Of course there are other techniques such as Amazon One Click and "Card on File"
 > solutions, where a customer has some loyalty to the merchant or recurring activity
 > or payments happen.  In these cases the merchant e.g. AT&T, Georgia Power, Amazon,
 > Uber or Delta can take responsibility for maintaining, on the customers behalf,
 > payment credentials.  In these cases FIDO becomes an effective way to provide a
 > secure multi-factor log-in experience.

Absolutely.


> The key use case that must be addressed is where an anonymous Buyer
 > visits a Seller's website and wishes to shop and pay with payment credentials
 > they frequently use e.g. a credit or debit card.

Indeed.

>
>
> Philip Andreae
> Tel: +1 (404) 680 9640
>
>
> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
> Sent: Monday, October 12, 2015 3:11 AM
> To: Tony Arcieri
> Cc: public-web-security@w3.org
> Subject: Re: State of the WebCrypto API
>
> On 2015-10-12 00:13, Tony Arcieri wrote:
> <snip>
>>
>> Why did you start this thread?
>
> The W3C is just about to launch two crypto-related WGs:
> http://www.w3.org/2015/hasec/2015-hasec-charter.html
> http://www.w3.org/2015/06/payments-wg-charter.html
>
> It seems that WebCrypto didn't satisfy a particularly large market (in terms of applications) and therefore the next steps could be worth discussing a bit, right?
>
> I'm still waiting for some kind of write-up/specification on how the payment industry intends making the 1Bn+ chip-cards in circulation usable on the Web, or at least how virtualized versions of such cards would fill that bill.
>
> Apparently you don't think that's a good idea.
>
> Personally, I wouldn't start anything in this space until this has been done.   Elimination of "technical risk" applies to all projects, regardless if they are standards or not.
>
> Anders Rundgren
>
Received on Tuesday, 13 October 2015 06:02:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 06:02:06 UTC