System Applications Working Group Charter

The mission of the System Applications Working Group is to define a runtime environment, security model, and associated APIs for building Web applications with comparable capabilities to native applications. This requires stronger integration with the host platform than is the case for traditional web pages. Browsers are designed to cope with the user visiting untrusted web sites, necessitating a cautious approach to security that narrowly limits what a particular website can do. The contrast between the two contexts can be illustrated by comparing a) an application with limited access to specific fields in the user's contacts, and b) an application that implements a contacts manager, where the application is entrusted with the ability to access, create, delete and update entries.

Join the System Applications Working Group.

End date	1 October 2014
Confidentiality	Proceedings are Public
Chairs	Adam Barth, Google Wonsuk Lee, Samsung
Team Contact (FTE %: 30)	Dave Raggett
Usual Meeting Schedule	Teleconferences: approximately 1 per week. Face-to-face: up to 3-4 per year as needed. IRC: active participants, particularly editors, regularly use the #sysapps W3C IRC channel

Goals

The System Applications Working Group aims to produce a runtime environment and a set of APIs that let trusted applications integrate closely with the operating system's functionality, thereby expanding the potential for a new breed of web applications.

Scope

The scope of the System Applications Working Group covers the technologies related to developing Web application that integrate closely with a host operating system, including a runtime environment (with both an execution model and a security model) as well as markup vocabularies and APIs for describing and controlling the application's interaction with the host operating system.

The Working Group will focus on those operating system interactions that cannot be exposed safely to Web applications executing in the traditional browser security model. The Working Group will consider a broad category of host operating systems, including those running on desktop computers, laptop computers, smart phones, tablets, TVs, cameras, and other connected devices.

Priority will be given to developing simple and uncontroversial APIs, leaving more complex features to future work. The Group should adopt, refine and when needed, extend existing solutions where possible. Some deliverables will only be applicable for platforms with the requisite hardware.

The Working Group is expected to deliver APIs designed for use with JavaScript. Bindings to other languages may be defined if appropriate.

In general, all APIs defined for Web applications executing in the traditional browser security model, e.g. the W3C DAP APIs, should be accessible from within the execution and security model specified by the System Applications Working Group. Any issues with duplication of security functionality, for example double security prompts, must be addressed.

This Working Group’s deliverables must address issues of accessibility, internationalization, mobility, security and privacy.

The Working Group will adopt best practice for marking up normative requirements, development of test suites, and production of implementation reports. The group will also maintain errata as required for the continued relevance and usefulness of the specifications it produces.

Success Criteria

To advance to Proposed Recommendation, each specification is expected to have two independent implementations of all features defined in the specification, including implementation on a constrained device (e.g. mobile phone, TV, or camera).

Deliverables

Recommendation-Track Deliverables

The working group will deliver the specifications listed below. In a number of cases, pointers have been provided to existing documents that address requirements similar to those of given deliverables. These are provided solely as aids to the review process and one should not presume that the cited documents will be submitted to W3C or that the deliverable developed by the group will take one of these for its starting point. Additional information can be obtained through the B2G WebAPI document, and the Apache Cordova Documentation).

The working group's deliverables are divided into two phases. In phase 1, the working group will focus on the execution and security models, and validating them through work on a small set of specific APIs. This will be used to establish the patterns and conventions that will be used for the remaining deliverables. The working group does not need to complete work on all the phase 1 deliverables before starting work on deliverables in phase 2. However, the working group should make substantial progress on some of the phase 1 deliverables before working on phase 2 deliverables, at which point it should be possible to do more work in parallel.

Phase 1

Execution Model

A description of the execution model and associated APIs for system applications, particularly how the execution model differs from the traditional browser-based execution model. Example: Strawman proposal from Google.

Security Model

A description of the security model and associated APIs for system applications, particularly how the security model differs from the traditional browser-based security model. Examples and further background:

The following are in alphabetical order and it is up to the Working Group to determine the priority attached to work on each API.

Alarm API

An API to manage the system's alarm daemon. Examples: Tizen Alarm, B2G Alarm.

Contacts API

An API that enables complete management of the device's address books. Examples: Tizen Contacts, B2G Contacts.

Messaging API

An API to send and receive messages (e.g. SMS, MMS, Email, IM) as well as manage messages stored on the device. Examples: Tizen Messaging, B2G Web SMS, Shelved DAP WG Messaging spec.

Telephony API

An API to interact with the phone system, for instance to dial a number, pick up a call, route to voicemail, access the call log, etc. Examples: B2G Web Telephony, Tizen Call.

Raw Sockets API

An API to manipulate low-level connections (e.g. TCP, UDP), including the ability to listen for incoming connections. Example: Chrome Sockets.

Phase 2

These are in alphabetical order and it is up to the Working Group to determine the priority attached to work on each API.

Bluetooth API: A low-level API to interact with the Bluetooth hardware available on some devices. Examples: Tizen Bluetooth, B2G Web Bluetooth.
Browser API: An API that provides all the necessary items to build a Web browser that aren't otherwise available. Most notably, this provides all that is needed in order to safely instantiate a viewport onto the open Web, pretend that such a viewport is the top level window even if the browser's chrome is itself written using Web technology, etc. Example: B2G BrowserAPI.
Calendar API: An API that enables complete management of the device's calendars. Examples: B2G Calendar, Tizen Calendar.
Device Capabilities API: An API that exposes the capabilities available to the device. Example: Tizen System Info.
Idle API: An API to be notified when the user is idle. Example: B2G Idle.
Media Storage API: An API to manage the device's storage of specific content types (e.g. pictures). Examples: Tizen Media Content, B2G Device Storage.
Network Interface API: An API to manipulate network interfaces (mobile, WiFi, etc.), such as listing available networks, current strength, etc., as well as configuring and enabling them. It may build atop the simpler network information API that Device APIs is working on. Potential uses include offloading connections from mobile networks to WiFi, enabling high priority mobile data connections and control of other network features. Examples: B2G Mobile Connection, B2G WiFi Information.
Secure Elements API: An API enabling the discovery, introspection, and interaction with hardware tokens (Secure Elements) that offer secure services such as tamper-proof storage, cryptographic operations, etc. Example: Gemalto Secure Elements.
System Settings API: An API to manage the system's settings (e.g. time/clock settings, and personal preferences including privacy preferences). Example: B2G Settings.

Note that where applicable, the group is free to split the above deliverables into several smaller specifications that collectively address the same space, or conversely to join some of the above into a single specification.

Where practical, the API specifications should use the Web IDL formalism.

Each specification must contain a section detailing any known security and privacy implications for implementers, authors, and end users. The Working Group will actively seek security and privacy review on all its specifications.

The Working Group may also enter into joint Task Forces with other groups (in particular with the Web Applications and Device APIs Working Groups), to collaborate on the deliverables above if specifications cross group boundaries.

Other Deliverables

A test suite for all features of a specification is necessary to ensure 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 by the end of the Last Call phase, and must be completed, with an implementation report, before transition from Candidate Recommendation to Proposed Recommendation. Additional tests may be added to the test suite at any stage of the Recommendation track, and the maintenance of a implementation report is encouraged.

The Working Group may also document in a Working Group Note the useful design patterns shared by the APIs it is developing.

Other non-normative documents may be created such as:

Primers for each specification
Requirements and use case document for specifications
Schemas for languages developed by the group (if any)
Non-normative group notes

Given sufficient resources, this Working Group should review other working groups’ deliverables that are identified as being relevant to the Working Group’s mission.

Milestones

The Working Group will maintain an updated timeline of its deliverables on its home page.

The first priority will be to reach a consensus on the Security Model and the Execution Model, and to deliver First Public Working Drafts for these within the group's first quarter. Other deliverables can be worked on without waiting for these two documents to be final and polished. However, the design of APIs will depend on the environment to which they are tailored, and it will be necessary to have consensus on each of the primary aspects of this environment that these two documents define.

Most of the API deliverables in this charter already benefit from at least one and often several existing implementations. As such, once the preceding step is executed it is expected that the production of specifications building on strong implementation experience and existing documentation can proceed at the pace of five FPWDs per quarter (until Q2 of the second year). Each of these specifications is then expected to reach CR inside of three quarters, with transition to Recommendation status supported by the adaptation of tests from existing platforms to these specifications.

Schedule summary, see above for details
Deliverables	Q1	Q2	Q3-Q6	Q7-Q8
Note: The group will document significant changes from this initial schedule on the group home page.
Execution & Security Models	FPWD		LC, CR
Alarm, Contacts, Messaging, Telephony, Raw Sockets		FPWD	LC	CR
Bluetooth, Browser, Calendar, Device Capabilites, Idle, File System, Media Storage, Network Interface, Secure Elements, System Settings			FPWD	LC, CR

Dependencies and Liaisons

W3C Groups

This Working Group’s specifications depend upon some specifications being developed by other Working Groups for example the Web Applications Working Group’s Web IDL specification and several of the Device APIs Working Group's specifications.

This Working Group expects to ask the following W3C Working Groups for reviews of deliverables in Last Call, and where appropriate to liaise on potential synergies:

Device APIs Working Group: The Device APIs Group is chartered to develop APIs that are closely related to several of those in this group's deliverables, but that function inside the browser security model. Such APIs should be closely coordinated as they are likely to feature common aspects.
HTML Working Group: The HTML Working Group’s deliverables cover the security model implemented in Web Browsers; this security model imposes limitations on what an extended model for Web Applications can achieve. Strong interaction with this Working Group is encouraged to build a shared understanding of the execution models, and potential extensions in future versions of HTML.
Internationalization Core Working Group: The Internationalization Core Working Group provides a variety of formal and informal advice to W3C Working Group, including specification reviews.
Near Field Communications Working Group: The proposed NFC Working Group would develop an API for accessing NFC devices. Liaison is needed to share expertise in API design and to ensure that the NFC API is consistent with the security models developed by the System Applications Working Group.
Privacy Interest Group: The Privacy Interest Group should be asked to review deliverables to take advantage of their general expertise in privacy by design for Web standards.
Web Accessibility Initiative Protocols and Formats Working Group: To ensure this Working Group’s deliverables support accessibility requirements, particularly with regard to interoperability with assistive technologies, and inclusion in deliverables of guidance for implementing the group’s deliverables in ways that support accessibility requirements.
Web Applications Working Group: This group defines relevant specifications including Web IDL, and File API.
Web Application Security Working Group: Since the Web security model is a core concern here, interactions with this group are strongly encouraged in respect to the relationship between system application security models and content security policies.
Web Cryptography Working Group: Interaction with this group would be valuable for the potential synergies between work on JavaScript cryptographic APIs and access to secure elements.

External Groups

The following is a tentative list of external bodies the Working Group should collaborate with:

Ecma International Technical Committee 39 (TC39): This is the group responsible for EcmaScript standardization, and related EcmaScript features like E4X. As this Working Group is developing EcmaScript APIs, it should collaborate with TC39.
IETF Web Security Working Group: This group should be asked to review the execution and security models developed by the System Applications Working Group. Strong interaction is encouraged to maximize a shared understanding of potential threats and approaches for strengthening security.

Participation

To be successful, this Working Group is expected to have 10 or more active participants for its duration, and to have the participation of the industry leaders in fields relevant to the specifications it produces.

The Chairs and specification Editors are expected to contribute one to two days per week towards the Working Group. There is no minimum requirement for other participants.

For each specification the Working Group will name a Test Facilitator whose responsibility is to ensure that a Test Suite is made available.

Based on the input from the group participants, the Chairs may also decide to create task forces that allow more focused discussions for topics that require specific expertise.

This Working Group encourages questions and comments on its public mailing list, public-sysapps@w3.org, which is publicly archived.

Communication

Most of the technical work of the group is done through discussions on the public-sysapps@w3.org, the group’s public mailing list. Editors’ drafts and their editing history is available from a public W3C Web site. The group’s action and issue tracking data is also public, as are the participants-approved minutes from all teleconferences and meetings.

In general, the Working Group holds a weekly teleconference as needed, but additional teleconferences can be scheduled occasionally at the chairs' discretion if a specific topic seems to warrant synchronous discussion.

The group uses a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and participants of the group, for Member-only discussions in special cases when a particular participant requests such a discussion.

Information about the group (for example, details about deliverables, issues, actions, status, participants) is available from the System Applications Working Group home page.

Decision Policy

As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that 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, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation—using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.

Asynchronous decisions that are attained through the mailing list, possibly using a “Call for Consensus” process are preferred, but synchronous decisions made during a teleconference or a face-to-face meeting are valid provided that the topic they address was clearly outlined in a public agenda posted one week earlier so that non-participating parties have a chance to voice their views ahead of time.

This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). 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 W3C Patent Policy Implementation.

About this Charter

This charter for this Working Group has been created according to section 6.2 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.

The draft charter reviewed by the W3C Membership is available.

The charter has been revised to fix links to the Tizen examples following a restructuring of their website.

Editors: Adam Barth, Robin Berjon, Dave Raggett.