[PROPOSED] Second Screen Working Group Charter
Warning: This document has no official status. It is a draft charter for discussion within the Second Screen WG and the W3C Advisory Committee.
The mission of the Second Screen Working Group is to provide specifications that enable web pages to use secondary screens and presentation displays to display web content.
| Start date | @@ 2024 |
|---|---|
| End date | 31 January 2026 |
| Charter extension | See Change History |
| Chairs | Louay Bassbouss (Fraunhofer Gesellschaft), Anssi Kostiainen (Intel) |
| Team Contacts | François Daoust (0.1 FTE) |
| Meeting Schedule |
Teleconferences: topic-specific calls may be held Face-to-face: we will meet during the W3C's annual Technical Plenary week; other additional F2F meetings may be scheduled (up to 2 per year) IRC: active participants use the #webscreens W3C IRC channel during F2F meetings and teleconferences. |
Background
Web applications are available on an ever expanding array of devices including e-book readers, phones, tablets, laptops, auto displays, and electronic signs. A variety of mechanisms allow these devices to use secondary audio and video presentation devices available in the local environment, attached by wired connections or remotely with wireless, peer-to-peer media.
Common attachment methods include video ports like VGA, DisplayPort or HDMI, or via wireless protocols such as Miracast, WiDi, AirPlay, Bluetooth, and Google Cast. Networked presentation displays may be available on a local area network or over the Internet. In addition to displays like monitors and TVs, wireless speakers can serve as secondary devices for rendering Web content. (For the purposes of this charter, "presentation displays" includes wireless speakers as well.) General purpose PCs and laptops can also serve as secondary presentation displays.
For many of these displays, the operating system hides how the display is attached and provides ways for native applications to render media on them. Native applications can easily use additional presentation displays without having to know the details of the connection technology.
The Second Screen Working Group aims at defining simple APIs for presenting content on presentation displays, and an open suite of network protocols (specified as an application of existing IETF protocols) that allow web applications to present and control web content on networked presentation displays and speakers.
Scope
The scope of this Working Group is to define:
- APIs that allow a web application to request display of web content on presentation displays, with a means to communicate with and control the web content from the initiating page and other authorized pages;
- A suite of network protocols that allow user agents to implement the APIs in an interoperable fashion for browsers and presentation displays connected via the same local area network.
Pages may be authorized to use a presentation display and control the displayed web content through explicit user permission, a token provided by the API, or other facilities provided by the user agent. The APIs will hide the details of the underlying connection technologies and use familiar, common APIs for communication among authorized pages and the web content shown on the presentation display. Web content may comprise an HTML document; parts of an HTML document; web media types such as images, audio, video; or application-specific media. The presentation of application-specific media is known to the controlling user agent and the presentation display, but not necessarily to a generic HTML user agent.
For a requested piece of web content, the user agent will provide the means for the web application to identify whether rendering the web content on a networked presentation display is likely to be successful, i.e. whether a presentation display is available that is capable of rendering the web content.
The APIs are agnostic with regard to the display technology used. The user agent may ask the presentation display itself to render the web content, or the user agent may render the web content itself and send the resulting audio and video to the presentation display using whatever means the operating system provides. From the web application's point of view, the connection technology used to convey the results of rendering the web content is an implementation detail.
Presenting web content on a networked presentation display creates a presentation connection between the web application and the web content. Web applications should be able to create multiple presentation connections to control web content shown on multiple networked presentation displays. Some web content, such as HTML documents, can be controlled from multiple web applications simultaneously. Synchronization of web content among multiple connections may be possible, but is not defined by the specifications in this group.
To allow the interoperable use of networked presentation displays, the suite of network protocols will cover required steps for two user agents to implement APIs to use networked displays: discovery, authentication, transport, and messaging (including API control messages and messages for streaming media between agents). The suite will reuse and configure existing IETF protocols for each of these steps. This Working Group will work with the IETF to assess whether parts of the protocol suite may apply to broader scenarios than the ones envisioned for the APIs. If that is the case, those parts may be further developed in the IETF.
This Working Group will not mandate network protocols for sharing web content between user agents and presentation displays. The APIs will informatively reference the protocol suite.
The specifications produced by this Working Group will include security and privacy considerations. In particular, 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 presentation displays, or the URLs of the web content to be presented.
The scope of this Working Group is to also define APIs that allow scripts to query the device for information about connected displays and to position windows relative to those displays.
Operating systems generally allow users to connect multiple displays to a single device and arrange them virtually to extend the overall visual workspace. A variety of applications use platform tools to place windows in such multi-display environments, but web application developers are limited by existing APIs, which were generally designed around the use of a single display.
The APIs in scope will allow web applications to:
- detect if the device has more than one connected display,
- detect when connected displays are added, removed, or reconfigured,
- request display information required to facilitate window placement across displays,
- show elements fullscreen on a specific display, and place windows on a specific display.
Members of the Working Group should review other Working Groups' deliverables that are identified as being relevant to the Working Group's mission.
Out of Scope
The specifications defined by this Working Group abstract away the means of connecting and different connection technologies. For example, the following are out of scope:
- Lower level APIs that expose features of existing connection technologies;
- How presentation displays are connected to the primary device (e.g. Video Port, HDMI, WiDi, Miracast, AirPlay);
- How the user agent prepares and sends the screen contents to the presentation display.
This Working Group will reuse and configure existing network protocols to create an open suite of network protocols suitable for the APIs. As such, the following are out of scope for the Working Group:
- Any new feature in existing IETF protocols normatively referenced by the suite of network protocols;
- Any new protocol for discovery, authentication, transport and messaging;
- Any protocol not required to implement the APIs developed by this Working Group.
Input methods, such as using a TV remote as a pointer or clicker, are out of scope of the Working Group.
This Working Group will not define or mandate any video or audio codecs.
Deliverables
Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.
The Working Group may decide to group the APIs and protocol suite in one or more specifications.
Normative Specifications
The Working Group will deliver at least the following specifications:
- Presentation API
-
An API that allows a web application to request display of web content on a presentation display, with a means to communicate with and control the web content from the initiating page and other authorized pages.
Draft state: CRD
Expected completion: Q4 2025 — The Working Group is awaiting satisfaction of the Success Criteria, which require two interoperable implementations of the Presentation API. The Working Group will also await demonstration of interoperability among multiple browsers and multiple presentation displays before moving the specification to Proposed Recommendation.
Adopted Draft: https://www.w3.org/TR/2023/CRD-presentation-api-20231016/, published on 16 October 2023.
Exclusion Draft: https://www.w3.org/TR/2017/CR-presentation-api-20170601/
Associated Call for Exclusion on 2017-06-01 ended on 2017-10-29
Produced under Working Group Charter: https://www.w3.org/2014/secondscreen/charter-2016.htmlThe Open Screen Protocol will be the basis for demonstrating interoperability between browsers and devices. Two implementations based on it would satisfy those criteria. The charter timeline provides additional time for Open Screen Protocol implementations to be completed and the Success Criteria to be met.
A second version of the Presentation API that integrates features the Working Group resolved not to include in the first version in the interest of time, and also feedback from Web developers on the first version, will first be incubated and matured in an appropriate Community Group. This Working Group expects to bring such features out of incubation through rechartering, when the criteria for moving the current Presentation API to Proposed Recommendation have been met.
Additional features will be considered for the Presentation API to align it with the work on the Open Screen Protocol, based on implementation experience with that protocol.
Additional features will also be considered to improve compatibility with the Remote Playback API and presentation of additional media types that are supported by the Open Screen Protocol.
All API changes will be incubated in the Second Screen Community Group before being considered in the Working Group.
- Window Management (previously known as Multi-Screen Window Placement)
-
An API that allows a web application to query its device for information about directly connected displays, and additional APIs to position windows relative to those displays. Networked presentation displays are out of scope for this API.
Draft state: Working Draft
Expected completion: Candidate Recommendation by Q2 2025
Adopted Draft: https://www.w3.org/TR/2023/WD-window-management-20230906/, published on 6 September 2023.
Exclusion Draft: https://www.w3.org/TR/2022/WD-window-placement-20220630/
Associated Call for Exclusion on 2022-06-30 ended on 2022-11-27
Produced under Working Group Charter: https://www.w3.org/2022/03/charter-secondscreen-wg.html - Remote Playback API
-
An API that allows a web application to request display of media content on a presentation display, with a means to control the remote playback from the initiating page.
Draft state: CRD
Expected completion: Q1 2025 — The Working Group plans to publish the Remote Playback API as a final Recommendation when the Success Criteria are met.
Adopted Draft: https://www.w3.org/TR/2022/CRD-remote-playback-20220929/, published on 29 September 2022.
Exclusion Draft: https://www.w3.org/TR/2017/CR-remote-playback-20171019/
Associated Call for Exclusion on 19 October 2017 ended on 18 December 2017
Produced under Working Group Charter: https://www.w3.org/2014/secondscreen/charter-2016.htmlAdditional features will be considered for the Remote Playback API to align it with the work on the Open Screen Protocol, based on implementation experience with that protocol.
Additional features will also be considered to improve compatibility with the Presentation API and remote playback of additional media types that are supported by the Open Screen Protocol.
All API changes will be incubated in the Second Screen Community Group before being considered in the Working Group.
- Open Screen Protocol
-
A suite of network protocols that allow user agents to implement the Presentation API and the Remote Playback API in an interoperable fashion for browsers and presentation displays connected via the same local area network.
Draft state: Working Draft
Expected completion: Q4 2025
Adopted Draft: https://www.w3.org/TR/2023/WD-openscreenprotocol-20231016/, published on 16 October 2023.
Exclusion Draft: https://www.w3.org/TR/2021/WD-openscreenprotocol-20210318/
Associated Call for Exclusion on 2021-03-18 ended on 2021-08-15
Produced under Working Group Charter: https://www.w3.org/2020/12/second-screen-wg-charter.htmlTo allow browsers to support more solutions for finding, connecting, and authenticating presentation displays (including solutions based on Matter), as well as to allow reuse of the control protocol (the part of the Open Screen Protocol that defines the messages required to implement the APIs developed by this Working Group) in other contexts (e.g., WebTransport or
RTCDataChannel), the Working Group plans to split the Open Screen Protocol specification during this charter period to separate discovery and authentication from the actual control protocol.
Other Deliverables
- Test suite
-
A comprehensive test suite for all features of a specification is necessary to assess the specification's robustness, consistency, and implementability, and to promote interoperability between user agents. Therefore, each specification must have a companion test suite, which should be completed before transition to Candidate Recommendation, and which must be completed with an implementation report before transition to Proposed Recommendation. Additional tests may be added to the test suite at any stage of the Recommendation track, and the maintenance of an implementation report is encouraged.
Additionally, this Working Group will improve test automation for the Presentation API and Remote Playback API test suites. This will be done through the adoption of a Testing API, incubated in an appropriate Community Group. The Testing API will also allow developers to use automation to test their own Web applications that make use of the above-mentioned APIs.
- Use cases and requirements
-
The Working Group is strongly encouraging the participants to create and maintain a use cases and requirements document for each specification.
- Implementation guidelines
-
To facilitate interoperability among user agents and display devices and encourage adoption of the API, the group may provide informative guidelines for implementors, either directly as informative notes within the Presentation API or in a separate non-normative group Note.
Other non-normative documents may be created for each specification, for example:
- Primers
- Non-normative schemas for language formats
- Non-normative group notes
Timeline
| Note: See changes from this initial schedule on the group home page. | ||||
| Specification | FPWD | CR | PR | Rec |
|---|---|---|---|---|
| Presentation API | - | - | Q4 2025 | Q4 2025 |
| Remote Playback API | - | - | Q4 2024 | Q1 2025 |
| Window Management | - | Q2 2025 | - | - |
| Open Screen Protocol | - | Q4 2024 | Q4 2025 | Q4 2025 |
Success Criteria
In order to advance to Proposed Recommendation, each normative specification is expected to have at least two independent implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites, and two or more implementations interoperating with each other. In order to advance to Proposed Recommendation, each normative specification must have an open test suite of every feature defined in the specification. Interoperable user agents hosting the same Presentation API web application should be able to render the same content with the same functionality on supported presentation displays that are compatible with the content to render.
There should be testing plans for each specification, starting from the earliest drafts.
To promote interoperability, all changes made to specifications should have tests. Testing efforts should be conducted via the Web Platform Tests project.
Each specification should contain sections detailing all known security and privacy implications for implementers, Web authors, and end users. 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 presentation displays, or the URLs of the web content to be presented. Specifications should minimize and mitigate their fingerprinting surfaces. For specifications that enable access to third party systems, security considerations must also include a threat model with threats, attacks, mitigations and residual risks.
Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.
This Working Group expects to follow the TAG Web Platform Design Principles.
Coordination
The initial drafts of the Presentation API, the Open Screen Protocol, and Multi-Screen Window Placement were prepared by the Second Screen Community Group. Upon approval of the Working Group, the Community Group ceased its work on the Presentation API, Open Screen Protocol, and Multi-Screen Window Placement specifications.
The Community Group may work on other related deliverables where it is not clear enough how to proceed for it to be a work item for a Working Group, including on extensions to the Open Screen Protocol. The Community Group is only one possible source for work under future Working Group charters, but can serve to do initial exploration for some future work items.
The specifications produced by this Working Group adhere to the web's origin-based security model.
Common web technologies that this Working Group could refer to for messaging include Web Messaging and the Web Socket API.
No external dependencies against the specifications of this Working Group have been identified.
For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.
Additional technical coordination with the following Groups will be made, per the W3C Process Document:
W3C Groups
- Second Screen Community Group
- This group developed the initial version of the Presentation API, the Open Screen Protocol, and Multi-Screen Window Placement. The Community Group focuses on enabling interoperability among implementations of the second screen APIs, encouraging implementation of the the APIs by browser vendors and establishing complementary specifications for the APIs.
- Accessible Platform Architectures (APA) Working Group
- To help ensure deliverables support accessibility requirements, particularly with regard to interoperability with assistive technologies, and inclusion in the deliverable of guidance for implementing the group’s deliverables in ways that support accessibility requirements.
- Media and Entertainment Interest Group
- This group provides use cases and requirements for second screen scenarios and thus important input on the deliverables developed by the Second Screen Working Group.
- Media Working Group
- This group develops Media Capabilities to expose information about the output capabilities for media, which the Open Screen Protocol may align with to expose the capabilities of presentation displays.
- Web Real-Time Communications Working Group
- This group defines relevant or potentially relevant specifications for establishing peer-to-peer communication channels between web applications.
- CSS Working Group
- This group maintains the CSSOM View Module which defines extensions to the Window interface that expose screen information to web applications. Window Management proposes new extensions to this interface.
External Organizations
While the Presentation API does not have a direct dependency on any given set of protocols, the following is a tentative list of external bodies the Working Group should collaborate with to develop the Open Screen Protocol and allow the Presentation API and Remote Playback API to be implemented on top of widely deployed attachment methods for networked presentation displays:
- Connectivity Standards Alliance
- The Connectivity Standards Alliance (CSA) develops Matter, an industry–unifying standard for reliable and secure connectivity across smart home devices, mobile app and cloud services. The Second Screen Working Group will evaluate features of Matter such as IP-based networking technologies for discovery, authentication, transport and media streaming. The Working Group will discuss updates to the Open Screen Protocol to align with or reuse these features where appropriate.
- IETF
- The IETF develops network protocols that presentation displays may support, and that form the core of the Open Screen Protocol. The Second Screen Working Group will liaise with relevant groups at IETF to assure proper and secure application of IETF protocols within the Open Screen Protocol. These groups include Extensions for Scalable DNS Service Discovery, QUIC, Transport Layer Security (TLS), Crypto Forum Research Group, and Concise Binary Object Representation Maintenance and Extensions. The Second Screen Working Group will also liaise with IETF to assess whether parts of the Open Screen Protocol apply to broader scenarios than the ones envisioned for the APIs. Those parts may be developed further in the IETF.
- Web Hypertext Application Technology Working Group (WHATWG)
-
WHATWG develops the HTML specification
that contains the definition of the
HTMLMediaElementinterface that the Remote Playback API specification extends. This group also maintains the Fullscreen API specification; Window Management proposes an extension to the Fullscreen API.
Participation
To be successful, the Second Screen Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.
The group encourages questions, comments and issues on its document repositories, as described in Communication.
The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.
Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct.
Communication
Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.
Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Second Screen Working Group home page.
Most Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
This group primarily conducts its technical work on GitHub issues. The public is invited to review, discuss and contribute to this work. The public mailing list public-secondscreen@w3.org is used for calls for consensus.
The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.
Decision Policy
This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.
However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.
To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.
All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs.
This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote), and includes no voting procedures beyond what the Process Document requires.
Patent Policy
This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.
For more information about disclosure obligations for this group, please see the licensing information
Licensing
This Working Group will use the W3C Software and Document license for all its deliverables.
About this Charter
This charter for the Second Screen Working Group has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
Charter History
The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):
| Charter Period | Start Date | End Date | Changes |
|---|---|---|---|
| Initial Charter | 13 October 2014 | 31 October 2016 | none |
| Rechartered | 3 November 2016 | 31 October 2017 |
|
| Extended | 17 October 2017 | 31 December 2017 | End date adjusted |
| Extended | 1 December 2017 | 31 January 2018 | End date adjusted |
| Rechartered | 2 February 2018 | 11 December 2019 |
|
| Rechartered | 11 December 2019 | 31 December 2021 |
|
| Rechartered | 15 December 2020 | 31 December 2021 | New Patent Policy |
| New co-chair | 21 January 2021 | 31 December 2021 | Louay Bassbouss appointed as co-chair |
| Extended | 23 December 2021 | 30 June 2022 | End date adjusted |
| Rechartered | 24 March 2022 | 31 January 2024 |
|
| Extended | 22 January 2024 | 30 April 2024 | Current charter is extended to allow the group to work on a new charter. See the draft charter and raise comments via GitHub issues. |
| Rechartered | @@ 2024 | 31 January 2026 |
|