RE: Exposing the SE API to Web Applications

Hello Anders,

I think the group understand your opposition to the introduction of an SE API.
But I'm not sure I understand the "true" reasons for such hostility on this topic (many emails listed below).

So I tried to resume the main points (my answers below your comments):

> "TrustedComputingGroup which I'm an invited expert member of haven't been able to get the web-interface-topic on the table in the 13 years they have been operating"

This is not because the idea of a web interface has not been raised in 13 years it may not be today, the 13 years ago's web has nothing to do with the today's web, it's not because nothing is done that we should do nothing

> "Microsoft has introduced a proprietary VSC...Google is working on a new kind of smart card...Intel...Trustonic (ARM offspring)...the examples above use fundamentally different security models"
> "I believe an Open Hardware/Open Software implementation and real-world testing is a *much* better idea"

I do not see how this is inconsistent with standardization at the W3C, however, it can provide an API for users without the constraints of proprietary solutions, the aim of standardization is to confront and harmonize different implementations.

> "you should be prepared for a *very* big standard in terms of documents, possibly only eclipsed by HTML5.  Harnessing such a monster as a *second-priority sub-task* in a WG having several other tasks to cater for is simply put a pretty bad idea"
> "Coordination across the divergent interests of these players is a complex affair, and one that current technical standards bodies are not well suited to handle"
> "Size of an SE API standard...10000+ lines of Java code...Estimated work to date: 5000 hours including an Android PoC"

The process (use cases, proposals, requirements, existing implementations) is not started, saying that it is complex is subjective, standardization involves coordination, let implementors comment on this complexity. The past complexity does not prejudge the future complexity, all depends on how the subject is dealt.

> "It doesn't matter if you have a proposal or not,  none of the big vendors that define some 99% of our client platforms have any intentions standardizing an SE API in W3C unless it is their already established take on that.  Since the latter haven't hardly begun yet, a guesstimate is that we are talking about a 5-10 year delay here."

With this reasoning, we turn around, it is further inconsistent with the fact that there are already existing implementations (the one you mentioned, also seek-for-android ...), hence the need to provide an API that suits the needs and bring together the right participants around the table.

> "how this is supposed to work with respect to Security, Privacy and GUIs"

This is not the only API that raises issues of privacy and security, are you aware of the solutions provided by the group itself: http://www.w3.org/TR/runtime/#permissions

> "An SE API should start with the definition of an SE that is compliant with the web"

Why it wouldn't be compliant? SE is a hardware, other APIs are based on others hardwares (camera, microphone, sensors, geolocation API ...), so saying that a layer of abstraction for this hardware is not possible is a bias, as long as no work is started.

Why an API, natively available, might not be available in web when use cases exist and when implementations are available?
I think a more constructive approach would be to follow the process when phase 2 will be launched, initially with the use cases and technical requirements, and then provide solutions when necessary. 
Your knowledge on the subject will be greatly appreciated.

Regards

Sylvain Lalande

[1] http://lists.w3.org/Archives/Public/public-sysapps/2012Oct/0022.html
[2] http://lists.w3.org/Archives/Public/public-sysapps/2012Oct/0054.html
[3] http://lists.w3.org/Archives/Public/public-sysapps/2012Nov/0048.html
[4] http://lists.w3.org/Archives/Public/public-sysapps/2013Jan/0010.html
[5] http://lists.w3.org/Archives/Public/public-sysapps/2013Mar/0087.html
[6] http://lists.w3.org/Archives/Public/public-sysapps/2013Mar/0181.html
[7] http://lists.w3.org/Archives/Public/public-sysapps/2013May/0141.html
[8] http://lists.w3.org/Archives/Public/public-sysapps/2013Jun/0038.html
[9] http://lists.w3.org/Archives/Public/public-sysapps/2013Jun/0044.html
[10] http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0001.html
[11] http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0003.html
[12] http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0031.html
[13] http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0054.html
[14] http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0056.html
[15] http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0059.html
[16] http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0063.html
[17] http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0066.html
[18] http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0067.html


-----Message d'origine-----
De : Anders Rundgren [mailto:anders.rundgren@telia.com] 
Envoyé : dimanche 28 juillet 2013 09:23
À : sysapps
Objet : Exposing the SE API to Web Applications

I hope you don't mind me continuing the SE API write-up...

The current SE API "input document" seems to presume that web applications can invoke the SE API as is.  I must confess that I do not fully understand (big understatement), how this is supposed to work with respect to Security, Privacy and GUIs.


FWIW, the SKS/KeyGen2 "not-a-standard" doesn't expose a single SE API method to web applications, *EVER*.

This sounds pretty strange for a "web solution", right?  However, this is in fact only about reusing an already firmly established web concept; the "trusted agent" which currently exists for TLS client-certificate-authentication and in HTML5's <keygen>.

A valid question arises: How could you create new exciting HTML5-based applications using the SE if you are restricted to pre-installed "trusted agents"?  Since the SKS/KeyGen2 scheme anyway drills rather deep into the platform (eventually into the CPU itself), it felt natural *refreshing the browser as well with an additional trust- and security-model explicitly designed  for keys* because keys usually express relationships which is quite different to for example "your location" according to GPS.  The current idea is using a souped-up version of W3C's Web Crypto as the foundation for new SE-oriented web applications:
http://webpki.org/papers/PKI/pki-webcrypto.pdf

thanx,
Anders

Received on Tuesday, 30 July 2013 11:51:02 UTC