W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > October 2012

Re: W3C takes on Web+SecurityElements

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 8 Oct 2012 10:10:34 -0700
Message-ID: <CACvaWvbNsJrOAnZjKsWVz7v4GeG6N=QifzO-3FB77ZBrzUHgEQ@mail.gmail.com>
To: Richard Barnes <rbarnes@bbn.com>
Cc: Anders Rundgren <anders.rundgren@telia.com>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On Mon, Oct 8, 2012 at 10:04 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> In particular, this part of the charter seems relevant, given the possibility of the crypto API providing access to "secure elements" [1]:
> "
> Secure Elements API
> An API enabling the discovery, introspection, and interaction with hardware tokens (Secure Elements) that offer secure services such as tamper-proof storage, cryptographic operations, etc. Example: Gemalto Secure Elements.
> "
> Virginie, could you comment on how this [2] differs from what we're working on here?  Presumably it would be desirable for the "commands" and callbacks used in the Secure Elements "channels" to have some relation to the methods exposed by the WebCrypto API?  Or are they different enough that Secure Element / hardware stuff should be handled through Secure Elements, and WebCrypto can ignore hardware issues?

A perhaps convoluted example may involve polyfilling the Web Crypto
API using Secure Elements (of course, in the context of Sys Apps). The
current draft by Gemalto is similar to previous SConnect API (
http://www.sconnect.com/ , previously discussed at
and elsewhere)

Both SConnect and Gemalto's strawman share the property that they deal
on a fundamentally even lower layer than that afforded by the current
WG draft - it deals with primitive APDUs. This allows creating smart
card drivers (which may be as 'simple' as exposing cryptographic
operations, or as complex as situations like Mifaire-style NFC apps
that can be used for mass transit or banking)

It would seem though that it exists as perhaps something
complementary, but otherwise entirely different use cases.
Received on Monday, 8 October 2012 17:13:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:48 UTC