[Web Crypto Next] Security Hardware Integration levels: Was: Status and next steps

AFAIK, integration of security hardware in the web can be performed
in (at least) three entirely different ways:

- ISO-7816/APDU access.  This solution applies to existing smart cards.
   It doesn't have any ties to the WebCrypto API.
   Gemalto/W3C draft specification: http://opoto.github.io/secure-element

- PKCS #11 and "cousins".  This solution is primarily about supporting
   PKI cards like PIV/eID and presumably supporting the WebCrypto API.
   http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/Using_the_W3C_WebCrypto_API_for_Document_Signing.html
   It is worth noting that FIDO's U2F cannot be supported by PKCS #11.

- FIDO/U2F and forward.  New form-factor-independent security hardware
   designed for the web and presumably supporting the WebCrypto API.

IMO, these solutions have little or nothing in common from a standardization
and web application developer point of view.  They can of course co-exist.

It is obvious that the FIDO approach has the current "mind-share":
http://fidoalliance.org/membership/members

However, it is not equally obvious how the W3C could deal with the
enhanced security hardware which (IMO) is required for transforming
a diverse set of legacy smart card applications relying on
soon-to-be-outlawed "plugins", into first class citizens on the web.

The current solution is rather converting these application to run as
native applications outside of the browser.

Regarding Secure AND Convenient Web-payments ("the killer application"?),
there's not an abundance of material out there telling how the FIDO bunch or the
APDU connoisseurs envision such except on a very high level ("yes, we can pay"),
which clearly is insufficient for deciding which horse you should bet on.

Cheers,
Anders

Received on Wednesday, 15 October 2014 04:52:33 UTC