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

W3C takes on Web+SecurityElements

From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
Date: Mon, 8 Oct 2012 20:41:06 +0200
To: Ryan Sleevi <sleevi@google.com>, Richard Barnes <rbarnes@bbn.com>
CC: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
Message-ID: <076ED1F6CB375B4BB5CAE7873691360703C7973A1804@CROEXCFWP04.gemalto.com>
Richard,

Ryan made the right point. The objective of this API is to establish a communication layer with the secure element. The proposed API in the SysApp charter is mapping with the API which has been defined by the SIMAlliance (the sim card industry group) and it has been shared as an example with SysApp potential participants to show the way it could be implemented. 
The targeted functionalities are really : auditing the available readers able to host a secure element, opening a communication with a reader, sending the actual command (APDU). As you can see we are far from the services aimed in the Web Crypto WG such as retrieve a key identifier, or perform a ciphering operation. 

This may or may not be used by browsers to access secure element when implementing the Web Crypto API, but to respect the Web Crypto charter, we have been avoiding linking the two topics. 

Regards,
Virginie

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: lundi 8 octobre 2012 19:11
To: Richard Barnes
Cc: Anders Rundgren; public-webcrypto-comments@w3.org
Subject: Re: W3C takes on Web+SecurityElements

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 http://googlewebtoolkit.blogspot.com/2010/06/todays-guest-blog-post-comes-from.html
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 18:41:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 8 October 2012 18:41:57 GMT