W3C home > Mailing lists > Public > public-webpayments@w3.org > April 2015

Re: W3C Web Payments Use Cases 1.0 first public draft

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 18 Apr 2015 00:16:36 -0400
Message-ID: <5531DAA4.6040500@digitalbazaar.com>
To: public-webpayments@w3.org
On 04/16/2015 08:21 PM, Steven Rowat wrote:
> I admit my reasoning there seems a bit speculative (in fact, 
> hot-headed), and towards the conspiracy theory end of the continuum
> -- but, now Melvin's come back with some data that supports it; thank
> you. ;-)
> And even having calmed down, I'm still thinking that shunting off
> the simplest A->B payments between two people as 'Future Work' is a
> mistake (and a slightly suspicious one).

Let me try and explain why those of us that are involved in this work
are nervous about working on peer-to-peer payments.

The Web Payments IG is still working through the person-to-person
payments scenarios. The technology for p2p payments is incredibly
simple, but the regulation around it is fantastically complex and
expensive to comply with. The price for misreading the regulation is
extremely steep. You can read more about it here:


Here's why work in the area is going slowly:

It is a felony to engage in money transmission without a license in any
state that requires a license to operate.

I remember being a speaker at a conference with Charlie Shrem keynoting
a few years ago. A year later, Charlie was in jail. Granted, he also did
some other shady stuff, but one of the charges filed against him was
operating without a money transmission license (aka doing peer-to-peer
payments w/o being licensed to do so).

There are really no other technologies that W3C is working on where a
mistake can land you in jail. Accidentally inject a bug in HTML5 -
people get angry. Badly designed feature for CSS3? Developers are
annoyed. Botch a crypto implementation - millions of dollars in damages,
but not much else. Screw up the deployment of peer-to-peer payments at
your organization? *Felony and jail time*.

When you say you're going to work on "peer-to-peer payments", what
you're really saying is: "I'm going to try and work on this problem
knowing that there is a possibility of someone I'm working with (or me)
ending up in jail."

Personally, I imagine being ripped away from my wife and two young kids
for writing a spec, a couple hundred lines of code, and deploying it
into production... and all the program did was move a virtual thing from
one ledger to another.

So, that's what's in the back of some of our minds while working on the
peer-to-peer payments stuff... and that's why it's going slowly. We
don't want to make a mistake.

That said, many in the group want to see peer-to-peer payments succeed.
The Use Cases document has clearly put Bitcoin (a peer-to-peer payment
mechanism) in there as something that we want to support:


So, it's in scope and we're trying to move on it as fast as we can. The
problem is in deploying it into production. In order to do that at any
kind of significant level, you need a heavily capitalized organization
(like a bank) that's willing to deploy a new payment system and take the
regulatory heat (tens of millions of dollars in fines) when things go wrong.

Purchases are far less heavily regulated and much easier to standardize
and put into production without risking jail time or stratospheric
fines. That's one of the reasons the group is gravitating towards those.
The other reason is that purchases constitute far more economic activity
than peer-to-peer payments do.

Steven, I suggest you tell the Web Payments IG that you think that the
group is making a mistake by not taking peer-to-peer payments more
seriously. It'll be a review comment, and per W3C process, we're very
strongly urged to respond to you. That will force the Web Payments IG to
have a discussion about it, on the record, and get back to you.



-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
Received on Saturday, 18 April 2015 04:17:02 UTC

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