W3C home > Mailing lists > Public > public-webpayments@w3.org > June 2014

Re: 3D Secure++ for Push Payments

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 27 Jun 2014 06:58:29 +0200
Message-ID: <53ACF9F5.9030701@gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>, public-webpayments@w3.org
On 2014-06-27 06:16, Manu Sporny wrote:
> On 06/26/2014 11:49 PM, Anders Rundgren wrote:
>> The merits of 3D Secure haven't been discussed in this list, probably
>> because it has [rightfully] been rejected in the US. However, 3D
>> Secure is a very cool idea, it just lacks a proper platform to run
>> on.
> PaySwarm is basically 3D Secure w/o domain verifier phishing security
> risks.

I have some difficlties finding out such information from the docs.

> Have you gone through the PaySwarm demo? The process is the same
> as 3D Secure.

I have and I tried it again.  It is IMO not obvious how a payment protocol
works just by running a demo, but a demo certainly is necessary anyway :-)

>> 0. Probably the payer must select payment type (=payment
>> provider)... 1. The payer gets a digitally signed payment request
>> from the payee 2. The payment request is redirected to the payment
>> provider 3. The payer authorizes the payment request at the payment
>> provider using a payer key 4. The payment provider counter-signs the
>> payment request with its provider key 5. The resulting object is
>> returned to the payee
> +1 up to this point. I'll note that in step #4, we've been referring the
> the resulting object in #5 as the "digital receipt".

Sounds like a good name.

>> 6. The payee pulls money from the received object trough its payment
>> provider
> Don't know if this step is necessary since step #4 above wouldn't happen
> unless the clearing/settlement was successful.

That's true.  For subscriptions and bookings I believe step 5 and 6
would though be needed.

>> Note that the payer's card details wouldn't be given to the merchant
>> when you use your payment provider as the source rather than your
>> card. The payer only needs to be authenticated to the payment
>> provider.
> +1
>> Although originally designed with another objective in mind, the
>> following steps and platform ought to work for push payments as
>> well:
>> http://webpki.org/papers/payments/securing-card-not-present-transactions.pdf
> I read this when you sent it out the other day. This is more-or-less
> what PaySwarm does as well (which is good, because it means that we
> agree on the general principle of how this stuff should work).

Nice to hear!

>> I strongly believe that BaM-payments and Web-payments could/should
>> be identical.
> +1
>> There are several hurdles.  Banks are slow as h**l, Standardization
>> takes forever, and Google can do whatever they want:
>> http://www.cnet.com/news/google-spells-out-ambitious-plan-android-world-domination
> Google will use a standard if it gives them a competitive advantage
> against the incumbents. JSON-LD gave them a competitive advantage, which
> is the reason it powers portions of their Knowledge Graph and Google Now
> products. I would expect Google to do the same sort of adoption w/ the
> Web Payments work if we create something compelling for them (and I
> think we're on that path with the discussions we've been having over the
> last two or so months).

Well, I guess I don't really see it that way...their wallet still isn't
open-sourced AFAICT.


> -- manu
Received on Friday, 27 June 2014 04:58:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:32 UTC