W3C home > Mailing lists > Public > public-webpayments@w3.org > August 2013

Re: WebPayments through WebCrypto

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Tue, 06 Aug 2013 09:24:04 +0200
Message-ID: <5200A494.4030500@gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: public-webpayments@w3.org
On 2013-08-06 03:34, Manu Sporny wrote:

Hi Manu,

> On 08/02/2013 03:49 PM, Anders Rundgren wrote:
>> I'm a "seasoned" developer in the PKI field with specific interests
>> in the consumer space.  Ages ago I started with a thing I have seen
>> debated in this and other list; the abysmal state of client-PKI
>> support in browsers.
> 
> Dave Longley, who is one of the primary architects of PaySwarm, is also
> the creator of the Forge JavaScript library and is on this mailing list.
> He might have something to say about your proposal. For those unfamiliar
> with Forge, it implements many of the most common crypto stack
> algorithms (AES, RSA, PKCS, DES, SHA, ASN.1, TLS, etc.) in pure
> Javascript (for the browser and node.js):
> 
> https://github.com/digitalbazaar/forge/

Client-PKI support in browsers is unfortunately a very politicized issue.
Probably none of the hundreds of mobile bank "apps" exist out there use
Android's built-in scheme for key storage and management.  The same goes
for most if not all eID-projects in the EU and Asia (the USG doesn't have
such projects) running on Windows.  The latter has been known by Microsoft
since more than a decade back but has not spurred any changes in Windows.

This was the original motivation/rationale for my project; creating a ubiquitous
platform for keys and browsers.


>> Unfortunately I found that my scheme (as well as all its predecessors
>> including HTML5's  <keygen>) is INCOMPATIBLE with the emerging W3C
>> WebCrypto standard!
> 
> Have you checked the latest Web Crypto spec? The June 23rd one? It's
> fixed a number of issues that existed before (we were just as baffled as
> you a few months ago, but things seem to be improving wrt. the spec).

Sure, I follow this work as a "public commenter".  Web Crypto is based
on using SOP as the key access control method but SOP doesn't have any
links to the platform keystore ("Your Certificates" in Firefox) which
creates a very "disintegrated" platform.  A number of people have suggested
various workarounds but these have been dismissed by Google.

Google has (in another forum...) introduced a scheme called U2F/Gnubby
(Universal Two Factor authentication) which looks very "WebCrypto-ish":
https://sites.google.com/site/oauthgoog/gnubby

The WebCrypto folks haven't commented on this although I have asked:
http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Jun/0002.html
(which is yet another example of how infected the key-storage thing is)


>> That dynamically loaded "Trusted Chrome" is bound to specific keys
>> may seem odd but it gives payment-networks the ability to optimize
>> the GUI for the actual protocol as well as supporting branding
>> options.
> 
> Would you be interested in joining us on a Web Payments call and
> elaborating on this a bit more? I read your paper and still don't feel
> like I have a good grasp of how the June 23rd Web Crypto spec would be
> improved upon as a result of what you're proposing. Have you approached
> the Web Crypto API folks about this? Perhaps if you were to join us on a
> call and we record the audio and minute what you're saying, we can then
> use that as an introduction to something that the Web Crypto API folks
> might want to change?

I would be happy to join the call and give a short presentation.  When it
comes to WebCrypto however, it is clear that changes of the kind that I'm
working with are way out of scope.  Anything that touches the "sacred platform"
is a BIG NO NO :-)

I don't expect that my proposal will even be reviewed!  Other contributions
(by W3C members) were rejected practically without any analysis.

Regards,
Anders

> 
> -- manu
> 
Received on Tuesday, 6 August 2013 07:24:36 UTC

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