Security for Access to Device APIs from the Web - W3C Workshop 10-11 December 2008, London

Workshop Report

Workshop Goals and Scope

Audience

Participants in this workshop included implementers and users of widget and browser runtime environments, researchers, and others who professed an interest in technologies used to facilitate access to sensitive, but useful APIs from the web context, and the security issues raised by such a model. Participants in the workshop had to submit a position paper.

The workshop had 44 participants from over 20 organizations; 29 position papers were received.

Workshop Goals

The workshop's goal was to gather information and experiences in the space, start build community consensus about possible standardization work within W3C, and gather requirements to guide such work.

Workshop Materials

Slides and position papers related to workshop sessions are linked from the agenda. Detailed minutes are available:

During the final session of the workshop, a set of summary slides was prepared.

Executive Summary

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.

Topics of interest, and the levels of interest, are summarized in the following table.

Topic Description Interest level
Declaration of APIs The mechanisms by which a widget or web application can declare a dependency (with possible security consequences) on an API High
API Patterns What should be similar across many APIs, e.g. API design, error handling etc. High
Concrete APIs Specific APIs that should be standardized High
Policy Description An XML (or other) formalism for describing a security policy. High
Policy Management An over the air protocol for remotely managing a security policy. Low
Javascript Sandboxing An alternative approach to web based security involving active sandboxing of running code. Medium

Of the many issues discussed during the workshop, there are some strong candidates for standardization, principally policy description and concrete APIs.

Policy management and user interface concerns were not deemed to be standardization candidates at this time.

Workshop participants strongly agreed that APIs and security models used for widgets and more classical Web applications should be aligned as closely as possible. This requirement is expected to apply to current and future work in the Web Applications Working Group, and to additional work that might be chartered as a result of this workshop.

Next Steps

Charters of existing W3C Working Groups will be reviewed for the possibility to accommodate high-priority items as part of that work. Where this does not appear appropriate (most likely in the case of the policy description item), chartering of new work will be considered. Interested parties are asked to contact the Team for detailed follow-up discussions; a mailing list will be made available at [email protected] (public archive).

Policy management and Javascript sandboxing might be considered further in Incubator Groups or in the W3C Policy Languages Interest Group, if so desired.

Summary of Discussions

This section gives a more detailed summary of the areas of interest discussed at the workshop, and tries to identify common themes that were raised during discussions.

Declaration of APIs and Applications

A secure framework for device APIs access must be built on a solid foundation. One aspect of these foundations is the identity and capability of the APIs that are accessed. Code identity and the dependency of an application on a particular API is not only important from a security perspective, but is a runtime dependency issue as well.

Dharwan and Olsen's position paper contains a useful summary of the candidate areas for standardization in this field.

It should be noted that widgets and web applications may impose different constraints on the security model, in part due to the different models of declaring application identity. Hanlick provided a useful review of many of these difference that have been found.

API Patterns

There are many candidate APIs that are useful to an application developer, but would also raise security concerns.

Within the W3C work program three proposed or existing APIs can be compared to illustrate the issue:

Each grants API access to a potentially security sensitive capability via Javascript, and each represents the technical work of a somewhat different community. A consistent approach to API design would help to reduce developer learning effort, and would enable a common approach to dealing with security issues.

By example, Ranganathan's paper highlights an approach to soliciting permissions from a user using non modal dialogs. This approach is justified on the basis that it gives a better end user experience; a user is not forced to make hasty security decisions in order to proceed with their browsing experience. As a consequence of this strategy toward user interaction, device APIs need to be asynchronous.

These types of consistent programming idioms are in scope as potential standardization (or pre-standardization) activity. One of the most important areas for consideration is a standard approach to security related errors.

Attention was drawn to some existing work by the Open Ajax Alliance.

Concrete APIs

Beyond the consideration of generic API declaration methods and standard API design patterns, concrete APIs were identified as a high-priority area of work.

Examples for concrete APIs beyond those currently under consideration by the W3C include:

The conclusion of the workshop was there was sufficient interest in committing resources to justify actively progressing this work within W3C.

Policy Description

The security frameworks used by existing mobile application frameworks, such as Java and Symbian, include a policy enforcement mechanism as part of the application environment itself, and user application identity and trust models derived from certificate architectures.

At least three of the papers presented (Caceres, Lewontin, Allott) suggest security frameworks where the notion of trust (the rule that determines what a particular application can rightfully access) can be provided by an architecturally distinct component. Two of these papers include specific candidate technologies which are either implemented, or in the process of implementation (Lewontin, Allott).

There are several use cases for this type of functionality:

There is considerable prior art in the area of policy description. Workshop participants noted that the XACML specification, represents a useful starting point and framework for any standardization work that is deemed necessary in this area. While several parties noted implementation experience that started out with XACML and led to purpose-specific and possibly simpler languages, other participants strongly suggested that future work should use (a profile of) XACML, and should liaise with the XACML Technical Committee to feed back experiences and requirements.

The syntax and semantics of policy description become a natural focal point for all the activity within the secure device API access problem. Specifically, the following interactions where highlighted within the workshop:

The workshop concluded that standardizing policy description should be actively pursued within W3C. Examining the state of the art of policy description within OASIS, and continuing to liaise any changes required as part of adapting XACML to the mobile device API problem domain, were deemed sensible routes forward.

The conclusion of the workshop was there was sufficient interest in committing resources to justify actively progressing this work within W3C.

Policy Management

Where policy description is the formalism for describing a security policy, policy management deals with mechanism by which this policy may be managed by a remote entity.

There is some prior art for remote management of XML description files. Specifically, OMA's device management work was raised as a candidate technology in this area. It was noted, however, that the mobile focus of OMA activities is likely to introduce a logical break between managing such policies on mobile and fixed internet technologies. Participants at the workshop agreed that this would be an undesirable outcome.

The workshop concluded that policy management should be deemed out of scope for early W3C standardization.

Javascript Sandboxing: Caja

Laurie presented Caja, a model for policing Javascript security. The Caja approach sandboxes, and therefore contains the inherent risk, of running untrusted code by performing a Javascript to Javascript translation. This model allows the containing application to make fine grained and flexible adaptations of security policy, in a way that the contained Javascript code will not be aware.

This method of containing security risks was presented as superior to the use of iframes for embedding untrusted Javascript code in Web Applications.

The workshop did not conclude that this mechanism was an immediate candidate for standardization, but it remains an interesting implementation option that should be monitored carefully as both the technology and the security policy standardization activity matures.

Interactions with other groups

Furthering work in the area of secure access to device APIs will require interaction with a wide array of groups and organizations both inside and outside W3C.

The following bodies and working groups were identified as being integral to furthering work in this area:

W3C Groups
PLING - Policy Languages Interest Group
The Policy Languages Interest Group 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.
XML Security Working Group
The XML Security Working Group is chartered to revise the XML Signature and XML Encryption specifications. XML Signature, specifically, is expected to play an enabling role in widget security models, and is the basis of the Widgets 1.0: Digital Signature specification under development in the Web Applications Working 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 and widgets can achieve.
Web Applications Working Group
The Web Applications ("WebApps") Working Group is the locus of numerous work items, including W3C's work on widget packaging and signatures, and APIs exposed to Web Applications.
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.
Mobile Web Best Practices
The Mobile Web Best Practices Working Group develops Best Practices for Mobile Web Applications, which highlights in several occasions the specific care that need to be taken with regard to security.
External bodies
OASIS: XACML TC
The Extensible Access Control Markup Language is a likely starting point for possible work on policy description. If the language is used, relevant requirements and experiences should be fed back to the XACML technical committee.
IETF: geopriv
The IETF Geographic Location Privacy Working Group has performed significant work on protocols and authorization frameworks for the transport of geographic location privacy.
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.