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

Re: WebCrypto.Next conference conclusions

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 19 Sep 2014 06:45:53 +0200
Message-ID: <541BB501.1000106@gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>, Web Payments CG <public-webpayments@w3.org>
On 2014-09-19 03:46, Manu Sporny wrote:
> On 09/12/2014 11:55 AM, Anders Rundgren wrote:
>> The conclusion was to include support for security hardware for more
>> traditional smart card applications that are already widely
>> deployed.
>
> Did the FIDO stuff factor into the discussion anywhere?

Yes, it was mentioned several times by Google.  Note: there's absolutely
nothing wrong with FIDO but it doesn't address the traditional smart card
use-case which is not bound to domains, at least not web-domains.

>
>> My personal belief is that this does not mean retrofitting the web
>> for the existing very diverse set of cards out there because this
>> would lead to "Driver Hell".  There were also moderate interest in
>> supporting smart cards at the APDU-level although that (on paper)
>> would give support for every card.
>>
>> As a Google representative  said: I don't think many web-developers
>> would be able to write a login solution based on APDUs.  So right!!!
>
> +1
>
>> So what does that lead us?  IMO, the only workable solution is
>> creating a "WebToken" along the lines of FIDO but using a different
>> access control/ mediation mechanism to get away from the SOP
>> constraint which does not match current use of smart cards.
>
> Who is "us"?

Well, "us" would be all users of the Internet.


> What would the "WebToken" be used for?

"WebToken" is my name of a smart card/secure key storage solution
designed for ubiquitous use on the web.  What Gemalto, Microsoft et. al.
have in mind for the web I have no idea of.


> What would we use instead of the same-origin policy?

That's a core issue this [potential] work item must try to get consensus on.

Several of the attendees expressed concerns about SOP constraints.


> Could you expand on this bit a little more? I'm not following what you're saying.

Since none of the W3C members have come up with a concrete solution for coping with
SOP, I can only point to my (non-member) proposal which is sort of lame, right?

I have published it several times before on this list.  It is based on a thoroughly
revamped client-platform since (IMO), current desktop OSes like Windows do not
really cut it due to a lack of binding between keys and applications which is
fundamental in a world where you download various apps all the time without always
knowing what these are up to.  That is, "fixing the browser" wouldn't (IMO) take
us very far, there are problems underneath that need fixing as well!

On the web an "application" is really a web-page so (again IMO), there should be some
kind of association between the web-page and the key.  This is what SOP offers but
effectively leave us in the hands of super-providers. However, this discussion seems
to cause massive discontent among some folks so we better drop it here...


>> If this actually succeeds it would be no less than a revolution!

Well, there are several components that in their own right would be revolutionary:
- The smart card industry and the browser vendors actually agreeing on something.
- Enabling applications that so far haven't been very practical like secure on-line banking.

>
> Since I don't follow, I don't understand why it would be a revolution.
> Specifically what part would be a revolution?

Payments on the web could be as secure *and* convenient as EMV in
a brick-and-mortar shops.

In Europe and Asia you would also be able to carry out various
e-government-related tasks on the web without having to install
highly proprietary and platform-dependent drivers and browser plugins.
The latter is a reality these days but will soon be "outlawed" which
means that suddenly a lot of people won't have any solution at all
which puts some pressure on the group coming up with a replacement.

Anders

>
> -- manu
>
Received on Friday, 19 September 2014 04:46:36 UTC

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