- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Fri, 11 Apr 2014 06:59:59 +0200
- To: POTONNIEE Olivier <Olivier.POTONNIEE@gemalto.com>
- CC: sysapps <public-sysapps@w3.org>, "psiddh@gmail.com" <psiddh@gmail.com>
On 2014-04-11 06:20, POTONNIEE Olivier wrote: > The GlobalPlatform Access Control has a deterministic algorithm to deal > with various secure elements, so there is no reason to be "middleware hell". Doesn't this presume that the SE is GP compliant? The current spec. doesn't (AFAICT) require that. How about my questions on 1) user-consents 2) potential uses in embedded libraries? Anders > > -- > Olivier > > >> -----Original Message----- >> From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com] >> Sent: Wednesday, April 09, 2014 11:01 PM >> To: POTONNIEE Olivier >> Cc: sysapps; psiddh@gmail.com >> Subject: 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 >> > > > This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus >
Received on Friday, 11 April 2014 05:00:49 UTC