On 2015-03-30 16:19, Martin Paljak wrote:
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".
Thanx Martin,
I think there are parallel universes interacting here...
There's a bunch of folks who insist that DUPLICATING all the goodies of the
native OSes into the "Open Web" is the way ahead despite the fact that it has
proved to be virtually impossible.
Then there's Google who claims the following regarding extensions based on
interactions with "localhost":
https://code.google.com/p/chromium/issues/detail?id=378566#c78
"we are committed to finding a long-term solution that is viable for valid use
cases"
This work is not performed (or even discussed), in any SDO and the definition of
valid use cases is up to anybody's interpretation.
I'm personally in favor of building on Chrome's Native Messaging although Google
want to cut off that as well.
Therefore we just have to wait......................................
Well, forking Chrome is of course another possibility.
Cheers,
Anders
Native Messaging using NFC/Bluetooth:
https://cyberphone.github.io/openkeystore/resources/docs/webnfc--web2device-bridge.pdf
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
