Device API and Security Working Group Charter - DRAFT CHARTER 11-May-2009

The mission of this Working Group is to create specifications of APIs for device services such as Calendar, Contacts, Camera, etc. Additionally, the group will produce a framework for the expression of security policies that govern access of Web applications and widgets to security-critical APIs (such as the APIs listed previously). These APIs can be used by Web pages and Widgets to create useful applications.

End date	31 July 2011
Confidentiality	Proceedings are Public
Chair	TBD
Team Contact (FTE %: TBD)	TBD
Usual Meeting Schedule	Teleconferences: 1-2 per week Face-to-face: 3-4 per year (only as needed)

Goals

In December 2008, the W3C held a Security for Access to Device APIs from the Web - W3C Workshop. The goal of this workshop was to gather information and experiences in the device API space, to start building community consensus about possible standardization work within W3C, and to gather requirements to guide such work.

Workshop participants discussed the need for standardization of technologies that would be required to provide access to security sensitive APIs from a web developer's perspective, the form these technologies should take and the viability and practicalities of standardizing this work within W3C. At the end of this workshop, the participants discussed several potential topics for new standardization work (see the Workshop Report for more details). The following high priority topics are addressed in this charter:

Declaration of APIs - The mechanisms by which a widget or web application can declare a dependency (with possible security consequences) on an API
API Patterns - What should be similar across many APIs, e.g. API design, error handling etc.
Concrete APIs - Specific APIs that should be standardized
Policy Description - An XML (or other) formalism for describing a security policy.

Scope

The scope of this Working Group is this creation of API specifications for a device's services. Devices in this context include desktop computers, laptop computers, mobile internet devices (MIDs), cellular phones, etc.

The scope also includes defining a framework for the expression of security policies that govern access of Web applications and widgets to security-critical APIs. To achieve this goal, the group will need to deal with the following items: policy expression proper, identification of APIs and identification of web applications and Widgets. Among the principles that guide the policy framework are:

Before inventing a new policy expression language, existing languages (such as XACML) should be reviewed for suitability
The resulting policy model must be compatible with the existing same origin policy (as documented in the HTML5 specification)
The work should not be specific to either mobile or desktop environments, but may take differences between the environments into account

All of the API specifications will use Web IDL to describe the API.

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

Additionally, comprehensive test suites will be developed for each specification to ensure interoperability, and the group will create interoperability 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 each of feature defined in the specification.

Deliverables

Recommendation-Track Deliverables

The working group will deliver at least the following specifications:

Device API Design Patterns
a document specifying the rules governing how all the Device APIs are designed from the high-level architectural perspective to address the API consistency aspects, including the following:

API Asynchronicity Model
specification how the callbacks are handled, how to cancel pending asynchronous operations, etc.
API Naming Conventions
naming conventions for methods, attributes, modules etc.
Error and exception model
model for error and exception handling, consistenly through all the Device APIs
API versioning model
model specifying how to handle new, improved or modified versions of the Device APIs
Models for device capability, API and API features identification
model specifying how the security aspects are related to the particular Device APIs

Set of Personal Information Management (PIM) APIs including

Calendar API
an API to access a calendar service (e.g. to add an entry, to edit an entry, to delete an entry, etc.)
Tasks API
an API to access a personal task management / organizer service (e.g. to add, edit, delete a task)
Contacts API
an API to access a contacts or address book service (e.g. to add an entry, to edit an entry, to delete an entry, etc.)

Camera API
an API to manage a device's camera e.g. to take a picture
Messaging API
an API to access a message service (e.g. to create a message, to send a message, to delete a message, etc.). The API is agnostic to the underlying messaging service (e.g. e-mail, SMS, MMS, etc.).
System Information API
an API to access various system services e.g. battery level, network status, etc.
FileSystem API
an API to access the file system and perform basic operations (e.g. Create, Read, Update, Delete) and more complex operations (e.g. mount, unmount)
Application Launcher API
an API to discover/identify and launch platform's native applications
Communication Log API
an API to access information about past communication events, like sent emails, SMS, MMS, call events etc
Gallery API
an API to manage the local media file storage
Security Policy Framework
expression of security policies that govern access of Web applications and widgets to security-critical APIs

Identification of APIs
Identification of web applications and Widgets

The Working Group may also enter into joint Task Forces with other groups, to collaborate on specifications that cross group boundaries.

Other Deliverables

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

Other non-normative documents may be created such as:

Primers
Requirements and use case document for specifications
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

Notes:

The actual production of some of the deliverables may follow a different timeline. The group will document any schedule changes on the group home page.

Milestones
Specification	FPWD	LC	CR	PR	Rec
Device API Design Patterns	2009-Q4	2010-Q2	2010-Q4	2011-Q1	2011-Q2
Calendar API	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3
Tasks API	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3
Contacts API	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3
Camera API	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3
Messaging API	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3
System Information API	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3
FileSystem API	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3
Application Launcher API	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3
Communication Log API	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3
Gallery API	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3
Security Policy Framework	2010-Q1	2010-Q3	2011-Q1	2011-Q2	2011-Q3

Dependencies and Liaisons

Dependencies

This Working Group's specifications will depend upon some specifications being developed by other Working Groups for example the Web Applications Working Group's Web IDL specification.

This Working Group is not aware of any dependencies other Working Groups' specification have on this Working Group's specifications.

Liaisons

This Working Group expects to maintain contacts with at least the following groups and Activities within W3C (in alphabetical order):

Geolocation Working Group: The Geolocation Working Group is chartered to develop the Geolocation API Specification. During Workshop discussions, this specification was frequently cited as a prototypical example for the kinds of security and privacy considerations that are expected in future device APIs.
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 and widgets can achieve.
Mobile Web Initiative: To help identify use cases and requirements for Web applications on mobile devices and to help ensure that this Working Group's deliverables address those use cases and requirements
Policy Languages Interest Group (PLING): PLING is chartered as a forum for community building around policy languages, and might be able to provide useful expertise. This Interest Group might be a useful forum for further discussion of policy management strategies.
Web Accessibility Initiative: 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.

Furthermore, this Working Group expects to follow the following W3C Recommendations, Guidelines and Notes and, if necessary, to liaise with the communities behind the following documents:

External Groups

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

ECMA Technical Committee 39 (TC39): This is the group responsible for ECMAScript standardization, and related ECMAScript features like E4X. As this Working Group will be developing ECMAScript APIs, it should collaborate with TC39.
JCP: The Java Community Process has developed comparable APIs for the Java runtime.
IETF: The IETF has created RFCs that are related to some of the APIs in this WG's scope.
OASIS: OASIS' Extensible Access Control Markup Language (XACML) is a likely starting point for work on policy description. If the language is used, relevant requirements and experiences should be fed back to the XACML technical committee.
OMTP BONDI: OMTP's BONDI initiative aims to define key interfaces that enable the mobile web platform to access sensitive functions on the mobile device.
OpenAjax Alliance: The OpenAjax Alliance has done initial work to identify guidelines for the design of mobile device APIs.

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 Chair(s) 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.

This Working Group will also allocate the necessary resources for building Test Suites for each specification.

This Working Group welcomes participation from non-Members. The group encourages questions and comments on its public mailing list, public-device-apis@w3.org, which is publicly archived and for which there is no formal requirement for participation. The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.

Communication

The Working Group's Teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis. At least one teleconference per week is expected.

Most of the technical work of the group will be done through discussions on the public-device-apis@w3.org, the group's public mailing list. Editors within the group will use the W3C's public CVS repository to maintain Editor's Draft of specifications. The group's action and issue tracking data will also be public, as will the Member-approved minutes from all teleconferences and meetings.

The group will 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 particular member requests such a discussion.

Information about the group (for example, details about deliverables, issues, actions, status, participants) will be available from the Device API 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.

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.

TBD, <TBD@w3.org>, Team Contact
TBD, TBD, Chair

Art Barstow; 8-May-2009