- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Fri, 19 Sep 2014 06:45:53 +0200
- 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