Device APIs Working Group Charter

The mission of the Device APIs Working Group is to create client-side APIs that enable the development of Web Applications that interact with device hardware, services and applications such as the camera, microphone, system sensors, native address books, calendars and native messaging applications.

Join the Device APIs Working Group.

End date 2016-03-31 [updated]
Confidentiality Proceedings are Public
Chairs Frederick Hirsch [updated]
Team Contact
(FTE %: 20)
Dominique Hazaël-Massieux
Usual Meeting Schedule Teleconferences: 1 per week
Face-to-face: 3-4 per year (only as needed)


The Device APIs Working Group aims at producing Web client-side APIs that facilitate deeper integration of Web applications into advanced capabilities of their host devices.

These capabilities include access to a camera, microphone, address book, calendar, or system information such as network connection and battery level.

Adding these advanced features to the Web environment empowers Web developers to create richer and more context-aware Web applications.

Given the sensitive nature of the data and sensors to which these APIs grant access, the Working Group also aims at crafting APIs that are both secure and privacy-enabling by design, based on the current Web browser security model. This entails reusing existing browser-based security metaphors where they apply and looking into innovative security and privacy mechanisms where they don’t.


The scope of this Working Group is this creation of API specifications for a device’s services that can be exposed to Web applications . Devices in this context include desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, TVs, cameras and other connected devices.

Priority will be given to developing simple and consensual APIs, leaving more complex features to future versions.

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

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 all features defined in the specification, including implementation on a constrained device (e.g. mobile phone, TV).

APIs that cannot be demonstrated to be implementable securely within the default browser context will not be released. This does not preclude these APIs to support use cases of installable Web applications.

Out of Scope

The definition of a policy framework that would allow using the defined APIs into a different security environment than the default browser context is out of the scope for this group.


Recommendation-Track Deliverables

The working group will deliver the following specifications:

(*)Note: the Web and TV Interest Group and the Multimodal Interaction Working Group are also working on topics related to discovery APIs. The Device APIs Working Group will liaise with them on these topics. As the discussion evolves, the groups will investigate the opportunity of creating a separate Working Group dedicated to local device discovery.

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

The Working Group may also enter into joint Task Forces with other groups (in particular with the Web Applications Working Group), 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.

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

The Working Group is also planning to work on Best Practices for Privacy-sensitive Web applications, as well as documenting Privacy Use Cases and Requirements in Working Group Notes.

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.


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


Working Group starts work under new charter and calls for proposals for new deliverables; the following documents are already on the Recommendation track:

The following documents have editors draft:

The following documents have suggested starting points proposed by participants to the group, but have yet to be submitted to the group:

  • Vibration API
  • Menu API
  • Beep API
  • Application Registration API
  • Generic Sensor API
  • Tasks API
Contacts API becomes a Candidate Recommendation
All the new deliverables have assigned editors
HTML Media Capture, Battery and Network APIs becomes Candidate Recommendations
All deliverables have reached First Public Working Draft status
All deliverables have reached Last Call status
All deliverables have reached Proposed Recommendation.


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.

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


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 Specifications, of a similar kind to the ones developed by this group.
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.
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 Notification Working Group
This group defines an API to use the device’s notification system to alert the user of applications-triggered events; this API shares many requirements of the APIs developed by the Device APIs group in terms of security and privacy.
Multimodal Interaction Working Group
The MMI Working Group is defining an architecture that allows for several components to talk to each other, and has thus relevant experience in the field of devices and services discovery.
Web and TV Interest Group
This group provides use cases and requirements for using Web technologies on TV and thus important input on some of the APIs developed by the Device APIs Working Group
The Web Real Time Communications Working Group
This group provides way to use the video stream from on-board media capture devices (camera, microphones) which needs to be compatible with what the Device APIs Working Group offers
The HTML Speech Incubator Group
This Incubator Group looks at analysing input from the user via on-board microphones and thus is a potential user of the APIs developed by the Device APIs group

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.
The IETF has created specifications that are related to some of the APIs in this WG’s scope.
The WAC (wholesale applications community) specifications aim to define key interfaces that enable the mobile web platform to access sensitive functions on the mobile, within a security framework that protects the user from malicious actions. WAC can provide input to requirements and technologies for this Working Group, as well as review and endorse deliverables.
OpenAjax Alliance
The OpenAjax Alliance has done initial work to identify guidelines for the design of mobile device APIs.


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. However, it should be noted that as defined by the Process Document, group participants need to attend most meetings, be familiar with documents and minutes of past meeting, and follow the relevant mailing lists to be considered in good standing; this is likely to require at least half a day a week.

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 (e.g. PIM APIs).

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.


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

Most of the technical work of the group is done through discussions on the public-device-apis@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.

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 Device APIs Working Group home page.

Decision Policy

As explained in the Process Document (section 3.3), this group seeks to make decisions when there is consensus. When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on.

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.

See also the previous charter for this group, and the version of this charter that was reviewed by the W3C Advisory Committee.

This charter was updated on July 10 2013 to reflect the change of Chairs for the Group (removed Robin Berjon who was chair until September 2012).

This charter was updated on July 10 2013 to reflect the extension of the charter until December 31 2014 as decided by the W3C Director.

This charter was updated on December 17 2014 to reflect the extension of the charter until December 31 2015 as decided by the W3C Director.

This charter was updated on January 6 2016 to reflect the extension of the charter until March 31 2016 as decided by the W3C Director.

Editor: Dominique Hazael-Massieux, Team Contact, based on the previous DAP Working Group’s charter