W3C home > Mailing lists > Public > public-sysapps@w3.org > April 2014

Questions on the SE API draft 2014-04-03

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Thu, 10 Apr 2014 08:00:35 +0200
Message-ID: <53463383.4020507@gmail.com>
To: POTONNIEE Olivier <Olivier.POTONNIEE@gemalto.com>
CC: sysapps <public-sysapps@w3.org>, psiddh@gmail.com
http://opoto.github.io/secure-element

Precondition for the questions: Hosted web-applications

There seems to be not less than three web-based access control schemes:
1. HTTPS with some extra requirements

2. Signed code with what appears to be a standard client-platform trust model
  (which to date have created more problems than it solved)

3. Signed code which is checked by an unspecified SE runtime system against
  a GlobalPlatform-specific SE-hosted access control identifier

In order for this to work, the *client platform* must be able to deduct which SE
type it is dealing with, doesn't it?  Follow-on question: Can this be done in
a universal way so that we don't end-up in the smart card middleware hell?

Which of these alternatives would in your opinion require a user consent?

IMO, alternative #3 has much more potential than the spec. elaborates on
because it could support static libraries with trusted code called by standard
(untrusted) embedding/hosting web code.  Wouldn't the scheme outlined
in http://webpki.org/papers/PKI/pki-webcrypto.pdf work although using
SE-specific commands rather than WebCrypto++? 
(Using WebCrypto++ would require SE-specific integration and middleware
and then we are not really talking portable and platform-indendent anymore)

Cheers,
Anders
Received on Thursday, 10 April 2014 06:01:21 UTC

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