This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application. The user agent mediates access to authenticators and their public key credentials in order to preserve user privacy. Authenticators are responsible for ensuring that no operation is performed without user consent. Authenticators provide cryptographic proof of their properties to Relying Parties via attestation. This specification also describes the functional model for WebAuthn conformant authenticators, including their signature and attestation functionality.
This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application. The user agent mediates access to authenticators and their public key credentials in order to preserve user privacy. Authenticators are responsible for ensuring that no operation is performed without user consent. Authenticators provide cryptographic proof of their properties to Relying Parties via attestation. This specification also describes the functional model for WebAuthn conformant authenticators, including their signature and attestation functionality
This document defines a set of Fetch metadata request headers that aim to provide servers with enough information to make a priori decisions about whether or not to service a request based on the way it was made, and the context in which it will be used.
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.
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 Accessible Platform Architectures Working Group (APA WG) is to ensure W3C specifications provide support for accessibility to people with disabilities. The group advances this mission through review of W3C specifications, development of technical support materials, collaboration with other Working Groups, and coordination of harmonized accessibility strategies within W3C.
The scope of the working group is
Support W3C Working Groups and external organizations collaborating on web technologies to create technical specifications that provide features needed for accessibility to people with disabilities:
Provide expertise to the W3C about the needs of users with disabilities, including both serving as a resource base and providing educational in-reach to the W3C community as needed;
Review W3C requirements and specifications (accessibility horizontal reviews, AHR) as needed to identify accessibility issues and make recommendations to the appropriate Working Group, particularly at the First Public Working Draft and Last Call or Candidate Recommendation stages and when explicit milestone review readiness is signaled;
Work closely with Working Groups when needed to help them architect their specifications to support, and not unknowingly interfere with, accessibility;
Develop and publish explanatory information about accessibility of web technology:
Document concrete guidance about how to ensure technical specifications appropriately support accessibility;
Collect information about technology features, implementation, and usage patterns to institutionalize W3C knowledge about present-day accessibility problems, including for emerging technologies such as social networking, real-time communications, Web-based television viewing, etc.;
Explore new technologies and accessibility challenges and begin to develop remediation approaches:
Leverage existing W3C markup technologies to produce new specifications or additions to existing specifications which support content personalization for various identified accessibility requirements;
Determine accessibility considerations for new devices and technologies, such as artificial intelligence, authentication, automotive interfaces, digital publications, graphics and media, mobile communications devices, payments, tablets, virtual and augmented and mixed reality, Web-enabled television, Web of Things, etc.;
Identify gaps and questions from accessibility specification reviews that may need research, and articulate findings and specific questions for discussion in various additional fora;
Coordinate with other accessibility stakeholders (including other WAI groups, accessibility proponents in other groups, and external accessibility organizations) to develop harmonized accessibility guidance across W3C:
Coordinate with accessibility proponents in W3C technical groups to help ensure accessibility solutions are developed in a consistent manner across technologies and to ensure that accessibility needs are addressed at an appropriate part of the technology stack;
Involve accessibility proponents in other fora - such as the WAI Interest Group, community groups, coordination activities, and other centers of expertise - to maximize the knowledge and impact brought to the group's activities;
Advocate creation and reuse of common implementations of functions that are required by accessibility;
Review non-W3C technologies that impact the accessibility of W3C technologies;
Strategize solutions within W3C and via liaisons with external organizations.
The mission of the Accessible Rich Internet Applications Working Group (ARIA WG, formerly part of the Protocols and Formats Working Group) is to develop technologies that enhance accessibility of web content for people with disabilities. This includes continued development of the Accessible Rich Internet Applications (WAI-ARIA) suite of technologies and other technical specifications when needed to bridge known gaps.
The scope of the working group is
Continue development of existing ARIA specifications to address needs reported by authors and to achieve parity with native host languages, creating new ARIA specifications where necessary;
For each ARIA specification developed by this Working Group, create a corresponding Accessibility API Mappings specification defining the correct exposure for each platform;
For all attributes defined by this Working Group, document best practices for authors;
Collaborate with other groups to create mapping specifications for native host language semantics;
Develop testing tools which can be used to verify accessibility implementations by examining the mappings exposed via platform accessibility APIs;
Collaborate with other groups involved in defining ARIA techniques and implementing ARIA support.
The mission of the Audio Working Group is to add advanced sound and music synthesis capabilities to the Open Web Platform.
Building upon and expanding the basic functionalities brought by HTML5's and media elements and MediaStream object, the Audio Working Group defines client-side script APIs which support the features required by rich interactive applications including the ability to process and synthesize audio streams directly in script, as well as giving access to musical instruments through a bridge with existing system-level MIDI APIs.
The audio API provides methods to read audio samples, write audio data, create sounds, and perform client-side audio processing and synthesis with minimal latency. It also adds programmatic access to the PCM audio stream for low-level manipulation directly in script. This API can be used for interactive applications, games, 3D environments, musical applications, educational applications, and for the purposes of accessibility. It includes the ability to synchronize, visualize, or enhance sound information when used in conjunction with graphics APIs. Sound synthesis can be used to enhance user interfaces, or produce music. The addition of advanced audio capabilities to user agents presents new options to Web developers and designers, and has many accessibility opportunities and challenges that this working group will continue to keep in mind.
In addition to an audio processing API, this group has received feedback from the audio and music community and industry, who wish to Web-enable their MIDI-capable devices. MIDI is an electronic device interface, developed by the musical instrument industry, that includes communication protocols for two-way connection and control of a wide variety of devices, including digital musical instruments, digital audio workstations, lighting sytems, game controllers, and many other systems. The MIDI specification has wide adoption and interoperable deployment across devices and computer operating systems, and to extend this existing infrastructure, the Audio Working Group is also developing a specification to create a bridge between the browser and existing system-level MIDI APIs, to make musical instruments first-class citizens of the Web.
The scope of this working group includes:
Developing a client-side script API for processing and synthesizing PCM audio streams, including direct scripted solutions.
Access to audio devices, such as for microphones or other audio inputs, and multi-channel speakers or other audio outputs.
APIs and advanced functionality regarding audio cache management and audio capability information.
Defining a client-side script API for accessing and manipulating MIDI-capable devices available on the users' systems.
This working group will take into account common work-flows for sound creators, including considerations for common audio formats. This group will also liaise with other groups for direct connection to audio inputs, such as microphones and speakers.
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 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.
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:
Publish a Recommendation for a new Timed Text Markup Language 2 (TTML2) specification. In the process of producing this new revision, the Group SHOULD:
Address any issues found during the development of a Simple Delivery Profile for Closed Captions.
Consider for adoption features from existing formats, such as CEA608 or CEA708, or developed by groups such as SMPTE, DECE and EBU.
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.
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:
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.
This initial charter for the Verifiable Claims Working Group will focus on use cases for education, and will place a strong emphasis on security and privacy. In particular, the Working Group will make a detailed analysis of threats to privacy and how they may be mitigated. As experience is gained, it is expected that future revisions to this charter will expand the scope to a broader range of use cases.
The Working Group will:
Recommend a data model and syntax(es) for the expression of verifiable claims, including one or more core vocabularies.
Create a note specifying one or more of
how these data models should be used with existing attribute exchange protocols;
a suggestion that existing protocols be modified;
a suggestion that a new protocol is required.
Focus their efforts on the identified use cases with a particular focus on the education sector. As a secondary focus, the group may address use cases on digital offers, receipts, and loyalty programs; discussion of these topics is not exclusive to this Working Group. Use cases from other industries may be included if there is significant industry participation.
