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

Re: W3C takes on Web+SecurityElements

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Tue, 09 Oct 2012 05:57:57 +0200
Message-ID: <5073A0C5.7070807@telia.com>
To: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
CC: Ryan Sleevi <sleevi@google.com>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On 2012-10-08 20:41, GALINDO Virginie wrote:
> 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.
Indeed.  The question is then what end-user services you actually aim for?  The Charter doesn't give any clues to that.

To me it looks more like a business plan for an industry sector struggling for market relevance in a very changed IT-landscape:


Note: Member access only.

Since I'm working with a similar project, I'm obviously biased :-)
However, this effort directly targets Web Crypto albeit using methods which so far haven't been discussed:



> 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 Tuesday, 9 October 2012 03:58:40 UTC

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