Please define user interests/priorities and the main question for smart cards.

Brad (and Ryan),


Please explain how your claim "It is more important that we consider the priorities (or interests) of the user" is backed with real life evidence of documented user priorities/interests? It reminds me of the Gnome 3 story, where the outcome - which was  "designed for the needs and habits of users" - was nothing many *actual users*, with their needs, habits, requirements and wishes, wanted. It was rather something designed for a thought up, wished-for, lab-created abstract user and implemented as "lets just make what we want, we know better and the user will have get used to it eventually, ".


Let me tell you an anecdote, well known in Estonia. A man visits a foreign country and sees that there are ATM style machines for shaving the beard with razors: just insert your chin and ZAP-done. Feeling surprised, he asks his host: "but how does this work, aren't the chins of all men different?" "Of course they are", answers his host. "The first time at least ..."


Doing architecture astronautics "for the web" and assuming that everybody shall want to - and have to - build their devices and systems according to "the web" is similar to the chin problem. I like my chin, I like my smart cards and I'm happy with the way those applications are built from the cryptography and privacy point of view. Please don't tell me that I must like WebCrypto or FIDO because it "caters to my needs and priorities better" than what I currently have. FIDO (or only authentication in general) can't cater to my needs. It is really useful for running cloud-services, but not enough. Legally binding non-repudiation ("signature") is a real life use case that by definition relates to privacy differently than signing in to random pet forum.


Not saying that there is no room and need for better solutions to problems dealing with high privacy, authentication, attestation/non-repudiation or identity in general, just please don't assume that it is realistic to make a "web identity" and that everybody shall build their lives around it (one reason being that  "identity" is such an ambiguous and mis-used term, it has no realistic single universal implementation)


Actual users (lets name them "persons") have actual priorities and real lives that has real life (attested identity) solutions and services, built for the web and currently delivered through the web. Users *want* to solve their real life problems (banking, school, digital paperwork, taxes, telco arrangements, whatnot) conveniently through the web, the same way they can conveniently kill their time on FB: by not leaving the couch. I don't want to judge which activity is "best for the user", I just describe the facts of the world and web.


For example, the assumption that whatever "comes from the government, in post-snowden world" equals no privacy, no consent and is generally bad stuff by all means by default, more likely draws from someone's personal experience from his/her relations to his/her government than it does from practical evidence. As an example, take the German eID that has created a technological beast taking into account near paranoid privacy assumptions and user controlled attribute releasing, so that the system is basically unusable due to complexity (and, in fact, not used significantly in real life).


While the web of course targets the planet and beyond, I must repeat a nitty comment from some identity related event more than 10 years ago: "the difference between running an online service in US and EU is that in EU your user database (and everything collected) is a liability. Whereas in US it is an asset."


IMHO there are are sensible solution proposal descriptions from vendors that are for some reason outright labelled as "not good for user, not in user interests, not a priority, utter legacy", a response that makes me wonder why should I want to achieve W3C membership and work openmindedly with the "web platform" target if it really seems to be easier to become a "legacy browser" vendor that also "knows best about user priorities and interests" and just get the stuff done.


Anyway, I wish we could get back to technical problems and technical solutions rather than close to political rhetoric and dogmatic assumptions. Lets not deal with architecture astronautics and try to re-invent everything for the web or think what the users should want or not want or what is best for them, without asking them.


----------------------------


Technical task to solve: how to bridge cryptographic material from smart cards and similar tokens to web applications via browsers, on all relevant platforms, in an open, meaningful (to users, browser vendors and web developers), effective and secure (including privacy) way.


The most important question (actually the answer) is: do browser vendors agree that this is something that should be possible and are willing to work on creating something or working with the "smart card community" to get things implemented via browsers, on most platforms?


If the answer is "YES", there are a few technical decisions to be made and W3C can have a role, read below.


If the answer is a "NO" from browser makers, there is no point in keeping up the discussion. Browser makers are currently actively moving away from previous de facto mechanism to bridge local native platforms components to web applications (NPAPI on the desktop, but mobile is the second problem source with nothing available) which the sector has happily used without working on usable standardisation efforts (something that plagues this sector unfortunately).  And there is no clear communication from browser makes about what should be used instead to get a comparable stable, supported solution. It should be made very clear if this is active resistance to any kind of efforts to achieve the necessary functionality or it is just lack of communication or lack of listening capability. Especially because any kind of standardisation effort, if at all possible through w3c, shall take years both from web software vendors as well as any real life rollouts if the only thinkable way forward for browser makers would be "web compatible hardware". The hiatus in availability of current web based services would render the web that affected users know "broken" for them and we better then turn to plan B and make adequate communication to users ASAP. But I'm sure that there exists a software solution rather than being a hardware issue.


The technical decisions would be, at least:


1. Decoupling of the problem from WebCrypto, which seems to be married to SOP and which is probably a good idea for current target. The question is discussed in webcrypto context only because it seems to be the forum where browser makers and smart card vendors/sector cross paths. A solution is needed to the soon broken use cases on desktop and hard-to-implement use cases on mobile platforms rather than something necessarily in WebCrypto. By nature it is more like geolocation/video/microphones with proper permissions and privacy considerations for implementors than SOP.


2. The question is where the support shall be implemented and from whom comes the necessary extra code to support device specific details. *Something* shall be necessary from browser makers in the first place, either generic (like NPAPI/ActiveX/NaCl) or domain specific (similar to what secure-element/openmobile/sconnect APIs or HID/Gemalto proposals assume).


3. I really like the web and most of the things I do over the internet I do with a "standard" web browser. The best would be if I could continue to use the web with a generic a browser instead of another dedicated "internet enabled" application. The same way it would be nice if the web on a mobile would work via a single browser, not jumping between apps. Anyway...


I know a few methods that can be - and in fact are - used to solve the problem *right now* but I don't like any of them. This includes: Native Client with Chrome or talking to a web servers on localhost which is done by a few countries in EU, probably could figure out a trick or two that could be used to bridge the two worlds without being affected by rent-seeking/gate-keeping by browser makers but at a considerable usability expense for the users.



Unless there is a clear understanding about the nature of the question and response from affected parties,  it would make more sense for me to stop trying to build upon the "web platform" and start a dedicated web browser project "that knows better" (EuroFox, anyone?) or just go with the flow and resort to dedicated apps. Balkanization achieved.


Thanks,

 Martin