Questions on the SE API draft 2014-04-03

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