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.

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 public-device-apis@w3.org (public archive).

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.

Disclosure and Discovery of device capabilities: a fundamental enabler for granting
access of device APIs to Web developers.

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.

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.

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:

Contact (address book) APIs

Messaging APIs

Sensors APIs

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:

Enterprise use case: a corporation wishes to apply its own security policy to deployed
phones and applications.

Delegation use case: an end user does not wish to make every security policy decision
themselves, but wishes to delegate trust decisions to a trusted third party.

Differentiation use case: a handset or service providers wishes to differentiate
applications or services by giving them privileged access to certain capabilities.

Portability use case: a user migrates between handsets or service providers, but wishes
to use the same application suite before and after.

Duplication use case: a user wishes to use the same suite of applications (with the same
security configurations) on multiple devices.

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:

Use cases and requirements: the logical model and the "expression" flexibility of the
policy model must be able to adequately model the use cases and requirements in this
space.

The policy model must be able to express "device APIs" within its vocabulary at an
appropriate level of granularity.

The permission model must include

capability semantics

permission semantics

evaluation algorithms

Application identity: the vocabulary must be able to describe the various application
identification mechanisms in use (e.g. origin domain and certificates).

Enforcement: the policy description needs to be policed and enforced by the
implementations, and restrictions (error codes) need to be propagated back to the client
applications.

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

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.

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.

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.

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.

External bodies

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.