Working group

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 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 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 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 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 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 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 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 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.

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 Timed Text Working Group is to develop W3C Recommendations for media online captioning by developing and maintaining new versions of the Timed Text Markup Language (TTML) and WebVTT (Web Video Text Tracks) based on implementation experience and interoperability feedback, and the creation of semantic mappings between those languages.
 
This group is chartered to develop formats used for the representation of text synchronized with other timed media, like audio and video. Such formats MUST be useable for online media captioning, should be useable for described video (aka video/audio description) and should address the Media Accessibility User Requirements. Such formats MAY also be useable for broadcast production and exchange and MUST be useable in the context of HTML.
 
The Group SHOULD:

1. Publish a Recommendation for a new Timed Text Markup Language 2 (TTML2) specification. In the process of producing this new revision, the Group SHOULD:
   1. Address any issues found during the development of a Simple Delivery Profile for Closed Captions.
   2. Consider for adoption features from existing formats, such as CEA608 or CEA708, or developed by groups such as SMPTE, DECE and EBU.
   3. Consider backward compatibility with TTML1 such as:
      - A conforming TTML1 content document instance is a conforming TTML2 content document instance.
      - A conforming TTML2 processor processes a conforming TTML1 content document instance such that the output produced by the TTML2 processor is within the variations allowed per TTML1; however, it may emit warnings if it encounters deprecated features.
   4. Facilitate mapping to HTML5/CSS3.
   5. Should address the Media Accessibility User Requirements.
2. Publish Recommendations of new versions of TTML Profiles for Internet Media Subtitles and Captions 1.0.1 (IMSC1.0.1) and TTML Profiles for Internet Media Subtitles and Captions 1.1 (IMSC1.1) specifications subtitle and caption delivery applications worldwide, including dialog language translation, content description, captions for the deaf and hard of hearing, based on TTML Profiles for Internet Media Subtitles and Captions 1.0 (IMSC1), W3C Recommendation 21 April 2016.
3. Publish a Recommendation for the WebVTT language, in particular the parts that cover the syntax, semantics, and rendering of subtitles, delivery of metadata, captions, chapter markers, and textual audio descriptions for speech synthesis. The Group is expected to have a maintenance process that produces new versions of WebVTT annually, potentially adding new features to the specification. In the process of producing the specification, the Group SHOULD:
   1. Address any issues found in WebVTT: The Web Video Text Tracks Format produced by the Web Media Text Tracks Community Group. Some may be deferred to future versions.
   2. Address the Media Accessibility User Requirements.
4. Maintain TTML1 and IMSC1 Recommendations as needed.
5. Produce other technical reports (Notes) on aspects of TTML processing as appropriate.
6. Liaise with other organisations including but not limited to those listed in § 3.2.
7. Investigate caption format requirements for 360 Degree, AR and VR video content.

The mission of the Scalable Vector Graphics (SVG) Working Group is to develop and maintain SVG.
 
Scalable Vector Graphics (SVG) is a language that allows authors and users to describe graphics in a way which is scalable to different device resolutions, acessible, and animatable.
 
The SVG WG develops the SVG specifications. They consist of the following, somewhat independent technologies, all of which are in scope for the SVG Working Group:

• A syntax for retained-model structured graphics. Both XML and HTML5 syntaxes are suported. Styling characteristics are CSS properties, expressed as stylesheets or as presentation attributes.
• A rendering model which describes how the elements of SVG produce a graphical representation
• An Object Model, a set of standard APIs, to which libraries can be written for manipulating dynamic and responsive graphics.

As a primary focus in this charter period, the group will concentrate on the stabilization and interoperability testing of the core SVG 2 specification. As part of that testing, features which are in the reference draft of SVG2 and which do not meet the stability and interoperability requirements for a Proposed Recommendation may be moved to separate specification modules, work on which would remain in scope, but at a lower priority.
 
As a secondary focus, the group may address modules for new graphical features for SVG, once there is broad consensus on adding each such feature to the Web Platform. The SVG Community Group (and also any other fora, such as WICG) will incubate new proposals. Once an incubated proposal is implemented and available (in nightly or testing builds) in at least one major browser, and has support from other SVG implementers, it may be adopted by the SVG Working Group. A requirements document will be used to collect together these features.