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

Re: Concrete contribution to Web Payments

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 11 Apr 2014 11:15:17 -0400
Message-ID: <53480705.6060508@digitalbazaar.com>
To: public-webpayments@w3.org
Anders, as a precursor to this email, know that I read everything you
post to this mailing list as well as the documents you link to. I agree
with maybe half of what you say. So, it's not coming out of ignorance to
the work that you do. :)

On 04/11/2014 04:25 AM, Anders Rundgren wrote:
> To make you feel slightly happier (?), I can report that I'm in the 
> *very* early phases of implementing a browser extension in Firefox 
> which combines smart card technology and Web Crypto which have 
> multiple uses including payments: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=978867

You're overlapping with the work that the WebCrypto group is planning on
doing after the initial WebCrypto spec is done. Worse, you're just
implementing a proprietary extension in a singular browser - Mozilla is
most likely going to reject your patch and ask you to align w/ the
WebCrypto folks.

That said, a demo of what you're working on using Firefox would be very
cool. You just shouldn't expect Mozilla to ever integrate that into
their browser, unless it comes from the WebCrypto group.

> This project has to date no moral, monetary, or technical support 
> from anybody. I haven't even been able to get constructive feedback 
> on the concept itself.

You haven't received feedback yet because most are loath to tell
someone that what they doing has almost no chance of succeeding. I even
hate saying that because who's to say that I know any better than you
the chances of success with what you're attempting to do? The work will
need to be done eventually, but not before there is some sort of
specification that other browser manufacturers can follow, and I would
expect the WebCrypto group to deliver that in 2+ years time.

In addition, 2-factor authentication is outside of the scope of the
first set of specifications that a payments WG will most likely work on.
2-factor auth is something that your payment provider is going to use to
give themselves a competitive advantage. While things like U2F and
2-factor really increase the level of security for a transaction, it is
not /required/ for a first cut of a payments solution for the Web.

If you don't work at a browser company, and your focus is on anything
that browser vendors are going to have to implement for your system to
work, you've already failed. I say this after years of attempting to get
browser vendors to implement particular APIs. They will not do it unless
the count of your user base is in the hundreds of millions.

That's why the best approach, if you're trying to get a browser API
done, is to implement it as a pure JavaScript polyfill. If that's what
you're focusing on, then great. If you're not focusing on creating a
polyfill that works today across all major browsers, your efforts are
going to be largely wasted.

Just my $0.02 - trying to help you not waste your time.

> My hope is that Mozilla will include the code (when ready...)

They won't unless you can prove you have hundreds of millions of users
of your extension.

> in the shipping browser but this is one of the many hurdles we are 
> facing today: Browser vendor support. Open Source is by no means a 
> guarantee for success!

No, it's not one of the hurdles because we're choosing not to play that
game. Nothing we're working on here requires browser vendor support.
Vendor support would make the ecosystem more secure, which is why we're
focusing on polyfills for browser APIs (which are optional parts of the
payment ecosystem), but browser implementations are certainly not a hard
requirement.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/
Received on Friday, 11 April 2014 15:15:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:36 UTC