View source for IG/W3C security roadmap

'''In 2013 and 2014 several discussions related to security happened in W3C area and in IETF. Here are the major features that were mentioned by different contributors, based on direct contribution, or on security report workshop, such as [https://www.w3.org/2014/strint/report.html STRINT] and [http://www.w3.org/2013/10/payments/final_report.html W3C Web Payment] that the Web Security IG recommends to develop.'''

== Protocol Security Enablers ==
* The platforms hosting the open web platform is offering some security features that are not made available yet to the web developers or to the user. It may be worth bringing to the open web platform the following features : Usage of DANE (DNS-Based Authentication of Named Entities) implies more security in the communication. Read [http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec article]
* A minimum set of security properties in the communication protocol could be defined. 
Read [https://tools.ietf.org/html/draft-iab-strint-report-00 STRINT report] mentioning that IETF and W3C can do more so that default ("out-of-the-box") settings for protocols better protect security and privacy.

== Device Trusted Enablers ==
Device platform may embed some trusted elements offering functionality such as trusted storage, trusted execution... Those trusted elements can have different form such as embedded chip (TPM, embedded Secure Element), pluggable chip (SIM card, Smart Card, µSD), integrated Trusted Execution Environment. 
Note : Read the strawman proposal of 'secure token and other secure services' workshop discussed in web crypto, to be confirmed by W3C [https://www.w3.org/2012/webcrypto/wiki/WG_Future_Work_hardware_token_workshop_2014 here]

== Securing ressources ==
* Secure iFrame: add some protection layers from compromised client environment. keep the javascript integrity, handle signed/encrypted javascript. 

* Secure Delete: as the privacy browsing mode, allow secure delete after DOM operations finished. clean-up memory even at persistent virtual memory like windows pagefile.sys

== User Security Indicators ==
The user gets sometimes lost when trying to audit and understand the security of the communication a web app is having. User interface and information made available to him varies largely from one browser to another. On the other hand, some sensitive services are now deployed over the web (communication via Web RTC, payment ...), for which more control is required. One possible feature to develop could be the standardization of the user interface in order to view or control the security level of the communication a web app is using, including certificate management.
This item should also take into account the mobile environment where the display resources are scarce.
It could also be extended to the idea of a Trusted user Interface as required in the security sensitive application domain, such as payment. 

== Security implication of WebRTC ==

Globally, can we step back and ask what users will be wanting to secure in a WebRTC usage, and what additional primitives are needed to give them that ability -- or to make much clearer *whom* they will have to be trusting when they can't get technical assurances of security. Can WebRTC prompt us to look more closely at the Web security model and scope the trust domains more closely to the activities. The problems of trust scoping are myriad, including:

* CAs: once in the root CA store, CAs have the authority to issue certificates for any domain, and there's no way to limit that (e.g., to say that MIT's CA can sign certs only for mit.edu and subdomains). DNSSEC could offer better granularity. Browsers are taking site-specific measures, such as cert-pinning.
* "Origin": The Same Origin Policy depends on the concept of "origin", and on its consistent implementation; both of which are challenged (see expansion of the public suffix list with new domains and new delegation models). All students, faculty, and alums serving content under mit.edu are part of the same origin.
* Duration: Permissions may be scoped to site, application, or session duration, yet none of these may match what a user intends to authorize.
* Key management: Key management is hard, and we still haven't given users a good way to participate meaningfully in it. Can we help them build better mental models for secure authentication?

Can we use WebRTC as an occasion for thinking about what a robust and user-accessible Web Security Model would look like, and what new components we'd need to build for it?