- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Fri, 27 Jun 2014 06:58:29 +0200
- 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. Cheers, Anders > > -- manu >
Received on Friday, 27 June 2014 04:58:59 UTC