The policy framework described in this document is intended to be applicable both to widgets and web applications (web site access to Device APIs).
This security model is based on a clear separation between the definition of the general framework and the creation of specific trust and access policies. This allows the configured policies of a web runtime to be adapted to the needs of different stakeholders at any time during the lifecycle of a product. This includes, but is not limited to, the embedding and configuration of web runtimes at manufacture as well as post-sales installation of web runtimes.
As a general high-level objective, it should be noted that the security framework is intended to protect the device and its user from web applications that pose a security risk from unintentional but undetected implementation flaws as well as those that are malicious.
The intention is that the framework, at the most general level, allows a very wide range of policies to be represented (although manageability and interoperability concerns require there to be a certain level of similarity and compatibility in policy structure). However, the framework must permit fine-grained security policies to be represented as well as policies based on broad groupings of APIs and assignment of web applications to a small number of trust domains. For example, a fine-grained access policy is necessary to grant or deny access to individual APIs for individual web applications.
This framework is based on a very general model that governs both trust domain access by subjects to resources based on a hierarchy of trust policies, access policies and policy sets, where each policy consists of a number of rules. A subject corresponds to an entity that may attempt security-relevant actions and represents a single identity. This identity can describe either a widget resource or a website. Resources are associated with the API features and device capabilities used to access device features or services (e.g. the location module or PIM database) that are being protected. Subjects and resources are characterised by a number of defined subject attributes and resource attributes, respectively. A range of attributes is defined so that access policies can be expressed based on a widget resource signer's identity, or an individual widget resource identity, or the widget resource signature’s root certificate, or a website's URL. Therefore, the generality of this framework derives from the range of attributes that are supported, as well as the flexible structure of policies and policy sets in the security model.
The XACML Policy Profile for Device APIs specifies a profile of XACML 2.0 [[XACML20]] for the framework described in this document [[DAP-XACML-POLICY-PROFILE]].
Content properties such as content origin and signatures can be used to map to trust domains. Trust policies may be used to specify these mappings. For example, a policy can specify the set of origin URLs corresponding to a trust domain, or map a certificate associated with a widget signature to a trust domain. Trust domains may be assigned when content is installed or at run time. In the first case, the installer determines a trust domain from the trust engine and saves this securely to the installed content registry. When content is run, the runtime can retrieve the saved trust domain from the registry. In the second case, the runtime gets the trust domain directly from the trust engine when the content is run. In both cases, the runtime must maintain a reference to the trust domain associated with the content in such a way that the trust domain can be specified when requesting an access control decision.
Trust domains can be based on origin, signatures or be "Untrusted", to list three common cases.
Access control is a two step process. First the trust domain is determined, and then based on that trust domain the appropriate access control policy is used to make a policy decision.
A feature is a set of one or more capabilities that in combination forms a logical construct that may require access control. (or shall we define a feature in terms of high level methods).
A feature is the unit of expression of dependencies by web applications. (This definition needs clarification).
Feature dependencies are
expressed as an IRI. It is the responsibility of the author of the
feature in question to define the feature and any associated API,
and to advertise the corresponding IRI. It is also possible, using
standard IRI techniques, to create a family of IRIs so that the
feature definition is "parameterised". It is up to the author of
the feature definition to specify the valid usage and meaning of
the associated IRIs in this case. For widgets, features are
identified in the configuration document by
An example of a feature IRI would be: TBD
Need to define: what constitutes a feature, how/where features IRIs are defined, feature IRI examples. See BONDI A&S document, pages 31 and 32.
A device capability is a device resource or device functionality that may require access control.
Examples of device capabilities are the ability to read a local file, or to discover nearby Bluetooth devices, or to send an SMS message. Device capabilities may be defined in a way that is independent of the specific Device APIs that an application uses to access them. Although there are simple Device APIs that provide access only to a single Device Capability, there are also more complex APIs that expose multiple Device Capabilities; examples might include a camera API that provides the ability to geotag a photo with the current location, or a messaging API that provides the ability to access documents stored locally and attach them to outgoing messages. Therefore, enabling or disabling access to a specific Device Capability may not directly correspond to enabling or disabling access to a single Device API interface.
The paragraph above repeats material in the requirements document.
The trust domain control layer controls the assignment of the appropiate trust domain to the web application via the relevant trust policy. In general, trust policies will select one trust domain or another depending on the subject attributes and environment attributes that identify the web application.
This explicit separation of features and their dependent device capabilities addresses a number of significant requirements, as follows.
The web runtime must only grant access to features that are advertised as being dependencies of the web application. The access control system must ensure that only requested features are accessible to the web application. This requires that the access control system is able to control access based on the ID of a Feature.
It must be possible to represent both trust and access policies portably. This implies that all identifiers used in a security policy (both for features and for device capabilities) must be portably defined, and not (for example) based on any platform-specific API names. This requires that the identifiers for device capabilities are defined in a platform-independent way.
Both the trust and access control systems consist of a number of logically distinct elements. This logical breakdown and associated terminology is adopted from XACML [[XACML20]] and illustrated below.
The specified functional components are as follows:
Policy Decision Point (PDP): for trust domain requests, the module that evaluates which trust domain should be assigned to a web application; for access requests, the module that evaluates whether or not a device API can be accessed by a web application, based on the current policy.
Policy Enforcement Point (PEP): for trust domain requests, the module that assigns a trust domain to a particular web application; for access requests, the module that allows or prevents access to device APIs.
Policy Information Point (PIP): the module that gathers information to be used by the PDP to evaluate a trust domain or an access control request. For trust domain requests, it collects the subject attributes (i.e. how the web application was identified and its associated security attributes), whereas for access requests, resource attributes (i.e. which device API is being requested and using which parameters) and environment attributes (i.e. status of the device) are collected.
Policy Administration Point (PAP): the authority that defines the policy. It could be a network operator, a terminal manufacturer, a web runtime developer, an enterprise or a user at runtime. Policies can be provided by the PAP in different ways, for instance using a preloaded file or data structure, or a remote management mechanism (e.g. OMA DM [[OMA-DM]]).
OMA DM reference missing?
Should we include this?: In the present phase, DAP does not define any specific external interface requirements for the PAP, although this may be in scope for later phases. The security policy itself is not defined by DAP, although a default policy may be recommended by DAP at a future stage.
The functionality required in each of these components is specified in terms of the following entities:
An entity that may attempt security-relevant actions and corresponds to a single "identity". (In practice, some web applications might have multiple identities – for example is a widget resource is signed by multiple signers – but for the purposes of this model, each access control query is considered to involve a single subject and hence a single identity.)
The website identity type applies to all operations occurring in the execution of a remotely-hosted document, whether this is the top-level document of the website or is associated with some child browsing context (such as an iframe).
Every subject is associated with a set of attributes. Subject attributes allow the identification of the web application that is attempting access to device capabilities using device APIs. The identified web application is then assigned a trust domain according to the appropriate trust policy. Subject attributes include specific attributes that represent the identity of the web application attempting access to a resource. Valid identity attributes include the widget identifier URI for widgets and the URL for websites; other identifiers may be supported. Subject attributes also include the credentials used to verify the authenticity and integrity of the subject, e.g. a TLS or code signing digital certificate. Other credentials may be supported.
All subject attributes are determined for the applicable application execution phases: widget-install, widget-instantiate.
the resources that subjects may request access to. The device features or services (e.g. the location module or PIM database) are the actual resources that are being protected, but from the point of view of the security framework these resources are associated with the API Features and device capabilities used to access them.
The widget identity type applies to all operations associated with a widget resource, or occurring in the execution of a document belonging to a widget resource.
Operations occurring in the execution of a remotely hosted document that has been loaded by a widget (for example in an iframe) use a website identity.
Every resource is associated with a set of attributes. Resource attributes include an identifier. Other attributes may be associated with a resource, and these can include specific parameters that are specified as part of the request when attempting access. Resource attributes serve as input of access control policies.
The device features or services (e.g. the location module or PIM database) are the actual resources that are being protected, but from the point of view of the security framework these resources are associated with the API features and device capabilities used to access them.
The collection of device status and context attributes that may be relevant to the circumstances of a resource access attempt, but are not directly associated with either the subject or resource. For example, environment attributes can include terminal charging, network connection status, whether roaming. Environment attributes serve as input of access control policies.
Attributes of the environment capture contextual information relating to the device or other circumstances of the access attempt.
The execution phase of a web application reflects the state of that application at the time an associated trust domain or access control query is made. The defined execution phases are listed below.
|widget-install||Applies to trust domain or access control queries made by a widget user agent during the processing of a widget resource as part of an installation or update operation.|
|widget-instantiate||Applies to trust domain or access control queries made by a widget user agent during the instantiation of a widget.|
|website-bind||Applies to access control queries made in response to a call to requestFeature() in the course of execution of a website|
Need to define "requestFeature()" ?
In BONDI, the requestFeature() API is itself a Feature. Websites have access to this API automatically and this is the sole means of expression of Feature dependencies by Websites.
Both trust domain and access control policies share the same underlying structure. The policy in effect in any given context is logically expressed as a collection of specific access control rules. The rules are organised into groups, termed policies, and these in turn are organised into groups termed policy sets. This structuring serves a number of purposes:
it helps organise the rules into groups that can be independently created and maintained, sometimes under different authority (and subject to differing degrees of control);
it provides a way of ensuring that the correct precedence is applied when processing rules. This makes some rules easier to write because their applicability is more narrowly scoped by their enclosing policy. More significantly, it ensures that security requirements determined by one authority are not wrongly overridden by rules provided by a subordinate authority.
Simplistically, each rule is specified by defining a condition, which is a set of statements which must be satisfied in order for that particular rule to apply, and an effect which represents the rule's outcome – ie the trust domain for trust domain requests and whether that rule indicates that the access request should be permitted or not for access requests.
The following steps illustrate the logical processing required when trust and access control policies are used to determine the outcome of a particular access attempt:
based on the subject attribute values presented in the trust domain query, the conditions associated with each rule and target can be evaluated, and the applicable rules, policies and trust policy sets can be determined;
based on the evaluated effect of each applicable rule, the relevant combining rules are used to determine the policies, policy sets and rules with precedence, which in turn determines the overall effect of evaluating the access control query. This effect is represented by the trust domain name that will be associated to the web application in successive device API and capability access requests.
We need to agree on what the output of a trust policy is: a string (=name of the trust domain?), how will this string be stored/managed?
From a logical perspective, a trust domain query can be evaluated when the necessary attribute values become available. For widgets, a trust domain query will be evaluated at installation time, when the subject attributes can be already determined.
the environment attributes are also captured;
the set of resource and environment attribute values captured is embodied in an access query which is evaluated in the context of the top-level access control policy set associated with the configured access control policy;
the access query also contains the name of the trust domain that has been assigned by the trust policy;
based on the trust domain name, resource and environment attribute values presented in the query, the conditions associated with each rule and target can be evaluated, and the applicable rules, access control policies and access control policy sets can be determined;
based on the evaluated effect of each applicable rule, the relevant combining rules are used to determine the policies, policy sets and rules with precedence, which in turn determines the overall effect of evaluating the access control query;
if the effect requires the user to be prompted, this is done, and the results of the user’s decision are recorded where appropriate.
The editors would like to extend special thanks to Nokia, OMTP BONDI, and PhoneGap for their contributions.