ISSUE-32: Features, Device Capabilities, their identification, and their role in policy

ISSUE-32: Features, Device Capabilities, their identification, and their
role in policy.

A few notes below to begin the discussion.

*Disclaimer

*Much of the terminology in the discussion below is borrowed from BONDI.
That's not because there's a built-in assumption that what BONDI says is
right, but it makes sense to minimise confiusion, especially for those
familiar with earlier work, by re-using definitions where possible.

*Assumptions*

The definitions and discussion below are based on the following assumptions.
The assumptions are just as much open to challenge as anything else, but
they're used as the starting point because the validity of the assumptions
themselves is probably a separate issue, and you have to start somewhere.

1) APIs will be provided that enable access to sensitive resources or
capabilities of a device. "Sensitive" means that they may be open to abuse,
and unfettered access by all applications is inappropriate.

2) A User Agent will implement some access control policy, that mediates
access to those resources by applications. Any policy framework created or
adopted by DAP will not presuppose who the authority will be that defines
such a policy. Similarly, DAP will not presuppose what such a policy author
will write, in terms of the specific access control restrictions that apply
to each API (under reasonably foreseeable use cases).

3) In order for the policy to be expressed, there needs to be some means of
identifying the web applications (but that topic is outside of this issue),
and of identifying the resources.

*Definitions*

*Application*s are applications that may make use of DAP APIs, whether
widgets or web applications running in a browser.

 *Device Capabilities* are specific resources, assets, or device
functionality that can be accessed, manipulated or exploited by an
application. Examples of device capabilities are the ability to read a local
file, or to discover nearby Bluetooth devices, or to send an SMS message.

 In principle, device capabilities can be defined in a way that is
independent of the specific APIs that an application uses to access them.

*APIs *are the constructs that the programmer is provided to access
resources. APIs are typically structured as a collection of *Interfaces*,
which are in turn structured into methods and properties, and these may in
turn be associated with other interfaces. Interfaces, and modules (ie
groupings of related interfaces) may be defined using WebIDL.

Interfaces, by themselves, are not necessarily associated with a specific
device capability. For example, a Stream interface (providing serial read,
write and seek functionality) may be used to interact with a local file, or
a Bluetooth connection. Similarly, the DCCI API could be used to access a
wide range of different device capabilities through a common set of
interfaces.

A *Feature* is a defined way of  accessing certain specified device
capabilities using an associated API.

Often there will be a simple 1-1 mapping between features, APIs and device
capabilities. For example, the "vibrate" feature may make the "vibrator"
device capability accessible through a "Vibrator" API. In other cases,
different features may use the same APIs but to access different device
capabilities. To steal an example from the JavaME world,

Connector.open("file://sdcard/my_dog.jpg");

would use a "local filesystem" feature, whereas

Connector.open("btspp://<hostname>:<parameters>");

would use a "Bluetooth serial port profile" feature.

*Use cases/requirements*

1) In principle any entity can legitimately define a feature, and it should
be possible for access to any such feature to be mediated by access control
policy.

2) There may be multiple features that provide access to the same device
capability. The simplest case of this is simply where there are multiple
competing APIs to do the same thing, such as for legacy reasons (eg
manufacturer, or BONDI, or JIL APIs).

However, there may naturally also be different APIs that make use of the
same underlying device capability; examples include:

a) a messaging API that permits files to be attached to messages would use
the "read local filesystem" device capability;
b) a camera API that permits captured photos to be geotagged, would use the
"geolocation" device capability.

3) A policy author may wish to control access to a specific feature.

4) A policy author may wish to control access to a device capability,
irrespective of the API/feature used to access it. For example, there should
be a means for a policy to say that an application shall have no access to
geolocation, by any method.

5) A means must exist for an application to express a dependency on specific
features.

*Identification*

Use cases (3) and (5) tell us that there must be a means of identifying
features, in order to express a policy and in order for an application to
express a dependency on them. Based on use cases (1) and (2), it is
suggested that features should be identified using an IRI. This way, the
definition of APIs and features is decentralised, allowing multiple
organisations to define features and associated APIs.

 Device capabilities are an API-independent way of identifying resources and
device functionality. They have to be defined in a way that is:

a) as portable as possible - ie have a meaning that is independent of the
platform, or the API used to access the resource - and;

 b) as specific as is necessary or relevant to defining an access control
policy. Therefore a shared file needs to be distinguishable from an
application's private file, and a Bluetooth port needs to be distinguishable
from a USB serial port.
*
In order to satisfy use case (4), identifiers for device capabilities are
required, and there must be a way for a policy to refer directly to specific
device capabiliites. Also, motivated by use case (4), those identifiers must
be defined commonly (eg defined centrally by DAP, not defined independently
by each API author).

[For these reasons, BONDI identifies features by IRI, but defines a separate
namespace, centrally managed, for device capabilities (eg
device.io.file.read).]

Paddy*