W3C

The mission of the Web Application Security Working Group is to develop security and policy mechanisms to improve the security of Web Applications, and enable secure cross-site communication.
 
Modern Web Applications are composed of many parts and technologies. They may transclude, reference or have information flows between resources at the same, related or different origins. Due to the historically coarse-grained nature of the security boundaries and principals defined for such applications, they can be very difficult to secure.
 
In particular, application authors desire uniform policy mechanisms to allow application components to drop privileges and reduce the chance they will be exploited, or that exploits will compromise other content, to isolate themselves from vulnerabilities in content that might otherwise be within the same security boundaries, and to communicate securely across security boundaries. These issues are especially relevant for the many web applications which incorporate other web application resources (mashups). That is, they comprise multiple origins (i.e., security principals).
 
Areas of scope for this working group include:
 
Vulnerability Mitigation

• Vulnerabilities are inevitable in sufficiently complex applications. The WG will work on mechanisms to reduce the scope, exploitability and impact of common vulnerabilities and vulnerability classes in web applications, especially script injection / XSS.

Attack Surface Reduction
 
The WG will design mechanisms to:

• Allow applications to restrict or forbid potentially dangerous features which they do not intend to use
• Govern information and content flows into and out of an application
• Allow applications to isolate themselves from other content which may contain unrelated vulnerabilities
• Sandbox potentially untrusted content and allow it to be interacted with more safely
• Uniquely identify application content such that unauthorized modifications may be detected and prevented
• Replace or augment injection-prone APIs in the browser with safer alternatives using strategies such as sanitization, strict contextual autoescaping, and other validation and encoding strategies currently employed by server-side code.

Secure Mashups
 
Several mechanisms for secure resource sharing and messaging across origins exist or are being specified, but several common and desirable use cases are not covered by existing work, such as:

• Allowing child IFRAMEs to protect themselves from "clickjacking"
• Providing labeled information flows and confinement properties to enable secure mashups. This is especially relevant for, e.g. applications communicating between security principals with different user-granted permissions (e.g. geolocation)

Manageability
 
Given the ad-hoc nature in which many important security features of the Web have evolved, providing uniformly secure experiences to users is difficult for developers. The WG will document and create uniform experiences for several undefined areas of major utility, including:

• Treatment of Mixed HTTPS/HTTP Content and defining Secure/Authenticated Origins for purposes of user experience, content inclusion/transclusion and other information flows, and for features which require a verifiably secure environment
• Providing hinting and direct support for credential managers, whether integrated into the user-agent or 3rd-party, to assist users in managing the complexities of secure passwords
• Application awareness of features which may require explicit user permission to enable.

The Web Security Model
 
The WG may be called on to advise other WGs or the TAG on the fundamental security model of the Web Platform and may produce Recommendations towards the advancement of, or addressing legacy issues with, the model, such as mitigating cross-origin data leaks or side channel attacks.
 
In addition to developing Recommendation Track documents in support of these goals, the Web Application Security Working Group may provide review of specifications from other Working Groups, in particular as these specifications touch on chartered deliverables of this group (in particular CSP), or the Web security model, and may also develop non-normative documents in support of Web security, such as developer and user guides for its normative specifications.

The mission of the Web Applications Working Group (WebApps WG) is to produce specifications that facilitate the development of client-side web applications.
 
The scope of the WebApps Working Group is:

• Haptic input devices and their emitted events and/or data.
• Textual input and text manipulation.
• Data sharing across remote and local web applications.
• Receiving and acting upon data from remote sources.
• Accessing the file system and persistent storage.
• Interfacing with OS capabilities.
• Integrating web applications with the OS.

The working group also maintains a specification for mapping HTML elements and attributes to platform accessibility APIs, and a separate specification that defines author conformance requirements for setting ARIA attributes. The Working Group does not expect to add any other specifications relating to this matter.
 
Specifications produced by the WebApps Working Group enable developers to create web applications that work across a wide range of platforms and devices, and for a broad diversity of users, by addressing matters of accessibility, device independence, internationalization, privacy, and security.

The mission of the Web Fonts Working Group is to develop specifications that allow the interoperable deployment of downloadable fonts on the Web.
 
The Web Fonts WG will develop Recommendation-track specifications as listed under deliverables; track emerging implementations, and maintain communications with the typography, Web design and implementor communities.

The Web of Things seeks to counter the fragmentation of the IoT through standard complementing building blocks (e.g., metadata and APIs) that enable easy integration across IoT platforms and application domains.
 
Thing Description:
 
Semantic vocabularies for describing the data and interaction models exposed to applications, the choice of communications patterns provided by protocols, and serialization formats suitable for processing on resource-constrained devices and transmission over constrained networks.
 
Scripting API:
 
Platform-independent application-facing API for Thing-to-Thing interaction and Thing lifecycle management.
 
Binding Templates:
 
Example mappings from the abstract messages to specific common platforms and protocols in collaboration with the corresponding organizations.
 
Security and Privacy:
 
Cross-cutting policies and mechanisms integrated into the other building blocks to describe and implement security and privacy policies to enable secure and safe interaction across different IoT platforms.
 
Of these, the first deliverable, the normative Thing Description standard, is central, with the other items playing supporting roles. The Scripting API is also normative but simply serves to provide a standardized and convenient way to access the functionality of the Thing Description from a programming language in order to build concrete applications. Binding Templates are informational and provide mappings to concrete protocols. This deliverable also provides templates for describing further protocol mappings through the Thing Description. The Security and Privacy deliverable is normative, but while considered separately, its implementation is integrated into the other deliverables.

The mission of the Web Payments Working Group is to make payments easier and more secure on the Web. The group seeks to:

• streamline checkout by making it easier for users to return stored credentials and other information, and by creating a consistent experience across Web sites, browsers, and operating systems. These improvements should help reduce the percentage of transactions abandoned prior to completion ("shopping cart abandonment") by improving consumer confidence in the payment experience;
• improve payment security by fostering digital payment method innovation on the Web;
• simplify and lower the cost of creating effective Web checkout experiences;

Under its charter, the Working Group defines Recommendations that allow for a payment to be initiated within a Web site or application.

The Working Group will continue to advance these existing specifications to Recommendation:

• Payment Request API, which standardizes an API to allow merchants (i.e., Web sites selling physical or digital goods) to utilize one or more payment methods with minimal integration. User agents (e.g., browsers) facilitate the payment flow between merchant and user, mediating the user experience and providing consistency between different merchants and providers.
• Payment Method Identifiers, which defines the validation and (where applicable) registration of identifiers used for matching purposes by other W3C payments specifications.
• Payment Handler API, which defines capabilities that enable Web applications to handle payment requests. The specification defines how payment apps register their capabilities with the user agent, how the user agent communicates with them, and what information is exchanged.
• Payment Method Manifest, which allows the curators of a defined payment method or owners of a proprietary payment method to authorize (via a manifest file) which payment apps may be used to fulfill the payment method. The scope of this work extends to all types of payment apps, including native mobile apps and Web apps.

The Working Group will continue to develop the following payment method specification, intended to become a Working Group Note:

• Basic Card Payment, which specifies request and response data for making simple card payments with Payment Request API.

The Working Group will also look at enabling re-use of the Payment Request API data model in out-of-browser payments. One approach may be to define the model in a binding- and encoding-neutral way. For early work on this topic, see HTTP Messages 1.0.

The mission of the Web Performance Working Group is to provide methods to measure aspects of application performance of user agent features and APIs.
 
Web developers are building sophisticated applications where application performance is a critical feature. Web developers want the ability to observe the performance characteristics of their applications, and they want the ability to write more efficient applications, using well-defined interoperable methods. Their methods must be both secure and privacy-enabling by design, using well-defined interoperable methods that conform to the current Web browser security model.
 
The Web Performance Working Group's scope of work includes user agent features and APIs to observe and improve aspects of application performance, such as measuring network and rendering performance, responsiveness and interactivity, memory and CPU use, application failures, and similar APIs and infrastructure to enable measurement and delivery of better user experience. Such deliverables will apply to desktop and mobile browsers and other non-browser environments where appropriate, and will be consistent with Web technologies designed in other working groups including HTML, CSS, Web Application Security, Web Platform, Device and Sensors, and SVG.
 
In addition to developing Recommendation Track documents, the Web Performance Working Group may provide review of specifications from other Working Groups.

The mission of the Web Platform Working Group is to continue the development of the HTML language and provide specifications that enable improved client-side application development on the Web, including application programming interfaces (APIs) for client-side development and markup vocabularies for describing and controlling client-side application behavior.
 
The group will:

• Continue the development of the HTML language, and associated APIs.
• Ensure that developers can use Web technologies to build client-side applications that rely on Web engines as application run-time environments.
• Provide generic and consistent interoperability and integration among all target formats, such as HTML, CSS, and SVG.
• Continue to define normative requirements for applications that process HTML resources, including browsers and other interactive user agents, authoring tools, content management tools, and conformance checkers.
• Ensure Web applications can work across a wide range of devices and among a broad diversity of users, in particular addressing issues of accessibility, device independence, internationalization, privacy, and security.

The mission of the Web Real-Time Communications Working Group is to define client-side APIs to enable Real-Time Communications in Web browsers. These APIs should enable building applications that can be run inside a browser, requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers.
 
Enabling real-time communications between Web browsers require the following client-side technologies to be available:

• API functions to explore device capabilities, e.g. camera, microphone, speakers,
• API functions to capture media from local devices (e.g. camera and microphone, but also output devices such as a screen),
• API functions for encoding and other processing of those media streams,
• API functions for accessing the data in these media streams,
• API functions for transferring data between peers,
• API functions for establishing direct peer-to-peer connections, including firewall/NAT traversal,
• API functions for decoding and processing (including echo canceling, stream synchronization and a number of other functions) of those streams at the incoming end,
• Delivery to the user of those media streams via local screens and audio output devices (partially covered with HTML5).

The working group will address issues related to using these functions in various contexts on the Web platform, such as:

• Traditional Web pages
• Web Workers of various types
• Iframes, with appropriate access controls
• Applications that span multiple pages
• Pages, workers and frames specifying content security policies or other security mechanisms that should impact the use of these APIs

The mission of the Second Screen Working Group is to provide specifications that enable web pages to use secondary screens to display web content.
 
The scope of this Working Group is to define an API that allows a web application to request display of web content on a connected display, with a means to communicate with and control the web content from the initiating page and other authorized pages. Pages may become authorized to control the web content by virtue of sharing an origin with the originating page, explicit user permission, or other facilities provided by the user agent. The API will hide the details of the underlying connection technologies and use familiar, common web technologies for messaging between the authorized pages and the web content shown on the secondary display. The web content may comprise HTML documents, web media types such as images, audio, video, or application-specific media, depending on the capabilities of the secondary display for rendering the media. Application-specific media includes that whose type is known to the controlling page and the connected display, but not necessarily a generic HTML user agent.
 
The API will provide a means to identify whether requesting display on second screens is likely to be successful, i.e. whether at least one secondary screen is available for display.
 
The API is agnostic with regard to the display connection used, and also works with display connections that support video only, for example, a TV connected to a laptop with an HDMI connection. In such a usage scenario, the web content displayed on a connected display must be rendered and converted to video before it is sent to a second screen. The user agent may use whatever means the operating system provides to prepare and send the video to a second screen. Any interaction between the authorized web pages and the content displayed on a secondary screen would happen within the bounds of the initiating device since both the pages and the content are rendered on that same device, and only a video representation is sent to the second screen.
 
Alternatively, if the second screen device understands some other means of transmitting content to a display and a means of two-way message passing, the web content can be rendered by the remote device. In this scenario, a URL to the content to be displayed is sent to the secondary display to be rendered there. Because the content is rendered separately from the initiating user agent, pages hosted by other user agents may be authorized to control the remotely rendered content at the same time.
 
For a requested piece of web content, how and by which device the content is rendered is an implementation detail. The user agent is responsible for determining which secondary displays are compatible with the content that is requested to be shown through the API.
 
Sending content to a connected display creates a presentation session. Applications can create multiple presentation sessions to control multiple displays, although synchronization between them is not currently supported by the API.
 
The specifications produced by this Working Group will include security and privacy considerations. Specifically, the user must always be in control of privacy-sensitive information that may be conveyed through the APIs, such as the visibility or access to secondary displays.
 
Members of the Working Group should review other Working Groups' deliverables that are identified as being relevant to the Working Group's mission.

The mission of the Publishing Working Group is to enable all publications—with all their specificities and traditions—to become first-class entities on the Web. The group will provide the necessary technologies on the Open Web Platform to make the combination of traditional publishing and the Web complete in terms of accessibility, usability, portability, distribution, archiving, offline access, and reliable cross referencing.
 
The WG will specify Web Publications and identify what they need the underlying Web platform to provide. It will build upon existing platform technologies specified by other groups, where available, seeking to fill gaps by assuring that the unique requirements of Web Publications are addressed by features (including optional features) or extension points in those specifications.
 
In particular, the WG will make normative Recommendations for Web Publications; Packaged Web Publications; EPUB 4; and DPUB-ARIA 2.0, as described in Deliverables.
 
Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes general Web Content Accessibility Guidelines (WCAG) and Web Accessiblity Initiative (WAI) requirements of the W3C as well as requirements for international readers using different scripts and document formats. Profiles of Web Publications may be defined with more stringent accessibility requirements.

The mission of the Pointer Events Working Group is to provide methods to enable simple device independent input from pointing devices such as mouse, pen, and multi-touch screen.
 
Web browsers can receive input in a variety of ways including mouse, touch, and pen input. A “pointer” is an abstract form of input that can be any point of contact on a input surface made by a mouse cursor, pen, finger, or multiple fingers.
 
Pointer Events provide support for handling mouse, touch, and pen input for web sites and web applications through DOM Events. For example, a content creator using Pointer Events would only have use a single model, rather than separate code paths for mouse events, touch events, and pen-tablet events, making authoring content much more efficient and inclusive.
 
This Working Group seeks to enhance the features delivered in the Pointer Events Level 1 Recommendation by exploring changes, such as:

• Addition of direction-specific values for finer-grained control of panning touch behaviors
• Reduction of hit-testing via implicit capture
• Additional clarifications of API behavior and performance optimizations

The mission of the Automotive Working Group is to develop Open Web Platform specifications for application developers, including but not limited to HTML5/JavaScript, enabling Web connectivity through in-vehicle infotainment systems and vehicle data access protocols. The API is agnostic with regard to the connection used.
 
This group will develop service specifications for exposing vehicle data and other information around vehicle centric functions.
 
A common pattern will be described to unify the style the different service interfaces are using.
 
The specification(s) produced by this Working Group will include security and privacy considerations.
 
Members of the Working Group should review other working groups' deliverables that are identified as being relevant to the Working Group's mission.
 
Services may include but are not limited to

• Vehicle Data
  • vehicle brand, model, year, fuel type, transmission type, steering wheel position, tire pressure, oil level, wiper position, lights, doors, windows and seat settings as well as navigation, trip computer data, climate control data, speed, RPMs, acceleration, gears, …
• media
  • media control, track lists, …
• navigation
  • route manipulation, points of interests, …