- From: Martin Paljak <martin.paljak@ria.ee>
- Date: Mon, 30 Mar 2015 17:19:24 +0300
- To: Anders Rundgren <anders.rundgren.net@gmail.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, GALINDO Virginie <Virginie.Galindo@gemalto.com>, "public-web-security@w3.org" <public-web-security@w3.org>
- CC: Mike West <mkwst@google.com>, Anne van Kesteren <annevk@annevk.nl>
Hello, I very much like what Anders has writtendown, the focus is much more clear this time and I find this the best way forward, for now, especially for "legacy" solutions that don't want to follow the "cloud" buzzword or have requirements different from "designed for web". For smart card and "hardware crypto", we could all build upon a standardized communication mechanism(s) and just define our API with necessary granularity on top of it. To draw a parallel: what we need here is a "PKCS#11 specification" supported by browsers, not "TSL specification with implementation and support for PKCS#11". But we're of course not talking ONLY about cryptography, the same interface or messaging solution could be used for whatever other purposes. On 18/03/15 16:55, Anders Rundgren wrote: > There are currently at least four (!) entirely different ways to invoke > "trusted code" so I guess > the first step would be to characterize them so that it gets easier to > select which one to go with. > > The existing schemes are: > - Custom protocol handlers. Primarily used on Android and iOS. GitHub > also uses it on Windows > - Local web services on 127.0.01. Used by lots of services, from > Spotify to digital signatures > - Browser plugins NAPAP/ActiveX. Used (for example) by 25M people in > Korea but is now being deprecated > - Chrome native messaging. Fairly recent solution which enables Native > <=> Web messaging You forgot Java, which is still an important solution in some countries, while practically a technology forgotten for good. > > There may of course be a new scheme as well. > > The end-result should be a deliverable that describes interfaces and > deployment recommendations. > The goal is that the deliverable eventually should be a standard feature > in browsers. We drafted an "API" (so small it is hard to claim it an API) that deals with the semantics of online signatures with smart cards, boringly named "hwcrypto.js". This "fixes" things for us by allowing to use with the help of a single JavaScript library different integration methods on different platforms, TODAY. For the technical implementations for this specific task (signing on the web) we gathered from the vicinity of Estonia almost all four implementations (except url handlers), which shows that not only they exist in theory, but have been created by people in (desperate) need. What is important at this stage, IMHO, is separating the goal (usage of smart cards on the web) from the machinery. It seems obvious to me that browser vendors are not interested in building some sort of APDU or transport or card-knowledge into their products, which is something I totally agree with. I think the right focus would be that how to allow native 3rd party code to interact with browser experiences in a safe and recommended way, instead of NPAPI, on all platforms. Together with recommendations for best results (security, UX, etc) this could be a nice way to fix many things that don't fall into the limits of current web browser capabilities. Here's a link to the "hardware cryptography. certificate based API" effort, again: https://github.com/open-eid/hwcrypto.js#hwcryptojs Regarding the "web to native" initiative, how could we proceed on this one? Anders, could we set up an unofficial work group to draft initial ideas? Who would be interested in joining? Best, Martin Paljak Chief specialist, R&D Estonian Information System Authority
Received on Monday, 30 March 2015 14:19:52 UTC