W3C home > Mailing lists > Public > public-web-security@w3.org > March 2015

Re: Charter Proposal: "Trusted Code" for the Web

From: Martin Paljak <martin.paljak@ria.ee>
Date: Mon, 30 Mar 2015 17:19:24 +0300
Message-ID: <55195B6C.3060500@ria.ee>
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>

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:


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?


Martin Paljak
Chief specialist, R&D
Estonian Information System Authority
Received on Monday, 30 March 2015 14:19:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 30 March 2015 14:19:53 UTC