ACTION-46: Provide input of capability definition and semantics

Hi,

  In order to close ACTION-46 I would like to provide a starting point for discussing what are Device Capabilities, how could we specify them and examples on how this has been done in BONDI.

A Device Capability is a specific functionality of a device that can be accessed by application developers. Platforms usually expose Device Capabilities to developers through different APIs and through different execution environments (e.g. JavaME, EcmaScript...). Due to this, it is in anticipated that in most of the cases there is no a one to one mapping between APIs and Device Capabilities. 

For instance, in order to access the location of a device, different mechanisms in different environments (or even in the same one) might be available in the same device:

 - ECMAScript: navigator.geolocation.getCurrentPosition(successCallback, errorCallback, {maximumAge:600000});
 - ECMAScript: var id = navigator.geolocation.watchPosition(listener, errorHandler);
 - JavaME:  location = locationProvider.getLocation(20);

In all the cases above, the Device Capability used is exactly the same. Hence, the Device Capability should be defined and identified in an abstract and portable way that does not depend in the APIs availability and the implementation details. If that is achieved, a policy defined based on the Device Capabilities could apply to different execution environments and platforms with no portability problems as there will be no dependency on the availability of a particular API/Method/Interface. 

The suggestion is defining the device capabilities in a hierarchical way that allows full flexibility for policy definition and permits a comprehensive grouping of the device capabilities.

For instance, in the particular case of retrieving the device position, the capability could be named: location.position. Where the last token (position) identifies the detailed capability to be accessed and the prefix (location) identifies a namespace containing a set of related capabilities. Partial capabilities (capability prefixes) such as “messaging.*” or "location.*" are expected to be meaningful in the policy definition. Apart from the Device Capability identifier, a human readable description should be also provided in case user interaction is needed for accessing a Device Capability. 

In order to take some security decisions, apart from the device capability to be used, it is also important assessing some of the criteria under which the capability is going to be used: context, passed parameters, etc. Due to that, device capabilities may also define a set of security parameters intended to describe those conditions that may checked before taking a security decision for a particular device capability (e.g. the path of a filesystem when trying to write a file, the location provider to be used when requesting the device position....). For each security parameter, the data type, the meaning and the possible values should be specified. 

From my point of view, this group should identify all the device capabilities that may be linked to the APIs in scope and the context information that may be used for taking security decisions for each of those capabilities. The group should also define the relationship between the ECMAScript functionality (or better API Features) and Device Capabilities (e.g. the getCurrentPosition method requires the location.position capability).  Although security decisions may be taken based on the context of the API invocation, my recommendation is that the mapping APIs - Device Capabilities should be fixed and deterministic. E.g. one method should not be linked to one Device Capability or another one depending on the passed parameters. 

The suggested approach is quite similar to the one BONDI followed. The list of device capabilities identified in BONDI is available at [1[.

Best Regards

-- Daniel

[1] http://bondi.omtp.org/1.1/apis/devcaps.html