Applications of information technology

The mission of the Media Working Group is to develop and improve client-side media processing and playback features on the Web.
 
Standardization efforts to develop media foundations for the Web, such as the HTMLMediaElement interface and Media Source Extensions, have helped turn the Web into a major platform for media streaming and media consumption. Building on the experience gained through implementation, deployment and usage of these technologies, and on incubation discussions within the Web Platform Incubator Community Group, the Media Working Group will extend media foundations with new standardized technologies to improve the overall media playback experience on the Web.
 
The scope of the Media Working Group is:

• Detection of media capabilities
• Detection of the autoplay policy
• Statistics on perceived playback quality
• Generation of media streams for playback
• Playback of encrypted content
• Exposure of media features at the system level to Web applications (e.g. access to platform media keys, display of media metadata at the system level, creation of an always-on-top video window) to Web applications
• Exposure of metadata event tracks synchronized to audio or video media

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 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 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 Service Workers Working Group is to enable Web applications to take advantage of persistent background processing, including hooks to enable bootstrapping of web applications while offline.
 
Web Applications traditionally assume that the network is reachable, which is not always the case. The Working Group will specify event-driven services between the network layer and the application, allowing it to handle network requests gracefully even while offline.

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

It is currently difficult to express banking account information, education qualifications, healthcare data, and other sorts of machine-readable personal information that has been verified by a 3rd party on the Web. These sorts of data are often referred to as verifiable claims. The mission of the Verifiable Claims Working Group is to make expressing, exchanging, and verifying claims easier and more secure on the Web. This charter focuses on use cases for education.
 

The mission of the Web Authentication Working Group, in the Security Activity is to define a client-side API providing strong authentication functionality to Web Applications.
 
The Working Group will determine use cases that the API needs to support and use these to derive requirements. Success will be determined by the implementation of API features as defined in this section of the charter.
 
API Features in scope are: (1) Requesting generation of an asymmetric key pair within a specific scope (e.g., an origin); (2) Proving that the browser has possession of a specific private key, where the proof can only be done within the scope of the key pair. In other words, authentication should obey the same origin policy.
 
Dependencies exist on the Credential Management API in the W3C Web Application Security Working Group along with the Client To Authenticator Protocol specification in FIDO.
 
Note that the details of any user experience (such as prompts) will not be normatively specified, although they may be informatively specified for certain function calls.
 
The Web Authentication Working Group should aim to produce specifications that have wide deployment and should adopt, refine and when needed, extend, existing practices and community-driven draft specifications when possible. The APIs should integrate well with Web Applications and so should be developed in concert with Web Application developers and reviewed by the Web Application Security and Web Applications Working Groups.
 
Comprehensive test suites should be developed for the specification to ensure interoperability. User-centric privacy considerations of device management and credentials should be taken into account. The Working Group may produce protocol standards as needed by the API.

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 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 WebAssembly Working Group is to standardize a size- and load-time-efficient format and execution environment, allowing compilation to the web with consistent behavior across a variety of implementations.
 
The scope of the WebAssembly Working Group comprises addressing the need for native-performance code on the Web in applications ranging from 3D games to speech recognition to codecs—and in any other contexts in which a common mechanism for enabling high-performance code is relevant—by providing a standardized portable, size-, and load-time-efficient format and execution environment that attempts to maximize performance and interoperate gracefully with JavaScript and the Web, while ensuring security and consistent behavior across a variety of implementations.
 
Since the inception of the Web, various technologies have been developed to allow “native” applications on the Web. Techniques such as user consent with digital signatures and Virtual Machines with different capabilities than JavaScript failed to be robust in the face of increasingly high security requirements. Later efforts like Native Client, which featured robust security, failed to achieve cross-browser adoption. Cross-compilation to JavaScript using Emscripten, especially using the machine-optimization subset called asm.js, achieved some degree of success. However, consistent cross-browser performance, shared memory threads, and other machine features have proved elusive.
 
The WebAssembly format and execution environment address the shortcomings of those previous efforts.

The mission of the Device and Sensors Working Group is to create client-side APIs that enable the development of Web Applications that interact with device hardware, sensors, services and applications such as the camera, microphone, proximity sensors, native address books, calendars and native messaging applications.
 
The scope of this Working Group is the creation of API specifications for a device’s services that can be exposed to Web applications. Services include sensors, media capture, network information and discovery. Devices in this context include desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, TVs, cameras and other connected devices.
 
Hardware security services are out of scope for this group.
 
Priority will be given to developing simple and consensual APIs, leaving more complex features to future versions.