Re: P2P Payments

On 5 December 2014 at 17:07, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 12/05/2014 09:48 AM, Melvin Carvalho wrote:
> > Are you saying that all key material is governed by same origin
> > policy?
>
> Yes, but that's not as big of an issue as Anders' is making it out to be
> (IMHO). In the current WebCrypto spec, the server controls your private
> key. If you trust the server, this is perfectly fine. In fact, you don't
> have a choice, you have to trust the server.
>

Im not sure this is the case in a payment spec that wants to live up to its
billing as "decentralized".

In a decentralized system you can have centralized services but also P2P
interactions.

Bitcoin was exactly invented to address this problem by not using a central
trusted third party, but rather, cryptographic proof of trust:

[[
Commerce on the Internet has come to rely almost exclusively on financial
institutions serving as trusted third parties to process electronic
payments. While the system works well enough for most transactions, it
still suffers from the inherent weaknesses of the trust based model.
Completely non-reversible transactions are not really possible, since
financial institutions cannot avoid mediating disputes. The cost of
mediation increases transaction costs, limiting the minimum practical
transaction size and cutting off the possibility for small casual
transactions, and there is a broader cost in the loss of ability to make
non-reversible payments for non-reversible services. With the possibility
of reversal, the need for trust spreads. Merchants must be wary of their
customers, hassling them for more information than they would otherwise
need.  A certain percentage of fraud is accepted as unavoidable. These
costs and payment uncertainties can be avoided in person by using physical
currency, but no mechanism exists to make payments over a communications
channel without a trusted party.


*What is needed is an electronic payment system based on cryptographic
proof instead of trust, allowing any two willing parties to transact
directly with each other without the need for a trusted third party.*]]

Decetnralized and centralized payments can live happily in one big
framework and compete for market share.


>
> What Ander's is concerned about (I think) is that you can't then use
> that same key to sign something on another site, which is not entirely
> accurate.
>
> The way the Web Payments CG specs handle this is via the use of a 3rd
> party signing site.
>
> 1. Data is sent to the 3rd party to sign.
> 2. The 3rd party has access to some private key and signs the data.
> 3. The data is transmitted to where it needs to go.
>
> This is perfectly in line w/ the current WebCrypto spec and the U2F
> specs, and it works just fine.
>
> Yes, there is no way to access a SE and ask it to sign something (yet),
> but the crypto folks at W3C are on it. They're trying to build momentum
> to make that happen and I think they will be successful at some point in
> the next 3-5 years. Until then, we have a solution that'll work.
>
> > So what's the difference between this and just using localStorage?
>
> There is effectively no difference.
>
> > Sounds like a bit of a train smash, if so, for web payments and the
> > decentralized social web in general.  Are there any ways round it?
>
> Yep, there are several ways around it. It's not a show stopper.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: High-Stakes Credentials and Web Login
> http://manu.sporny.org/2014/identity-credentials/
>
>