- From: Laura Arribas via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 18 Jun 2010 15:04:42 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy
In directory hutz:/tmp/cvs-serv32475
Modified Files:
Framework.html
Log Message:
General editoral changes (taking into account Dom's e-mail)
Index: Framework.html
===================================================================
RCS file: /sources/public/2009/dap/policy/Framework.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- Framework.html 9 Jun 2010 13:48:31 -0000 1.4
+++ Framework.html 18 Jun 2010 15:04:40 -0000 1.5
@@ -1,6 +1,6 @@
<!DOCTYPE html> <html>
<head>
- <title>Device API Policy Framework</title> <meta http-equiv='Content-Type'
+ <title>Policy Framework for Device APIs</title> <meta http-equiv='Content-Type'
content='text/html;charset=utf-8'/> <script src='../ReSpec.js/js/respec.js'
class='remove'></script> <script class='remove'>
var respecConfig = { specStatus: "ED", shortName: "policy",
@@ -53,14 +53,18 @@
trust domains. For example, a fine-grained access policy is necessary to grant
or deny access to individual APIs for individual web applications.
</p> <p>
- This framework is based on a very general model that governs both trust domain access by subjects
- to resources based on a hierarchy of <a href=#trust-policy>trust policies</a>, <a href=#access-policy>access policies</a> and <a href=#policy-set>policy sets</a>, where each policy
- consists of a number of <a href=#rule>rules</a>. Subjects and resources are characterised by a
- number of defined <a href=#subject-attributes>subject attributes</a> and <a href=#resource-attributes>resource attributes</a>. A range of
+ This framework is based on a very general model that governs both trust domain access by <a href=#subject>subjects</a>
+ to <a href=#resource>resources</a> based on a hierarchy of <a href=#trust-policy>trust policies</a>, <a href=#access-policy>access policies</a> and <a href=#policy-set>policy sets</a>, where each policy
+ consists of a number of <a href=#rule>rules</a>.
+ 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 <a href=#feature>features</a> and <a href=#device-capability>device capabilities</a> 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 <a href=#subject-attributes>subject attributes</a> and <a href=#resource-attributes>resource attributes</a>, 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
+ 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.
</p> <p>
@@ -79,13 +83,20 @@
</section> <!-- framework overview-->
<section id="layer-model">
<h3>Layer Model</h3>
+ <p> A <dfn id="feature">feature</dfn> is the unit of expression of dependencies by web applications. 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 the <code>feature</code> element's <code>name</code> attribute [[!WIDGETS]].
+ An example of a feature IRI would be: TBD </p>
+ <div class="issue">
+ <p>Features</p>
+ <p>Need to define: what constitues a feature, how/where features IRIs are defined, feature IRI examples. See BONDI A&S document, pages 31 and 32.</p></div>
+ <p> A <dfn id="device-capability">device capability</dfn> is a device resource or device functionality exploited by a web application, which 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.
+</p>
<p>
A web application uses a mechanism specified in this document to gain access to (or bind to)
a JavaScript API by stating one or more features exposed by the JavaScript API. This access is given on a basis of the trust domain that has been assigned to the web application.
The implementation of the API, in turn, makes use of one or more device
capabilities, defined in terms of facilities that might be provided by APIs at
the device, platform or OS level, but without reference to any particular API.
- Where a JavaScript API is defined within the DAP model, each function definition
+ Where a JavaScript API is defined within the this model, each function definition
specifies which feature it implements, and which device capabilities it uses.
</p> <p>
The mechanisms provided in this specification to bind to APIs, and to control access (both to
@@ -99,30 +110,33 @@
<h4>Trust Domain Control Layer</h4>
<p>
The trust domain control layer controls the assignment of the appropiate
- trust domain to the web application via the relevant trust policy. In
+ trust domain to the web application via the relevant <strong><em><dfn id="trust-policy">trust policy</dfn></em></strong>. In
general, trust policies will select one trust domain or another
- depending on the <a href=#subject-attributes>subject attributes</a> and<a href=#environment-attributes>environment attributes</a> that
+ depending on the <a href=#subject-attributes>subject attributes</a> and <a href=#environment-attributes>environment attributes</a> that
identify the web application.
</p>
</section> <!-- trust domain control layer -->
<section id="api-access-control-layer">
- <h4>Javascript API Access Control Layer</h4>
+ <h4>JavaScript API Access Control Layer</h4>
<p>
The JavaScript API access control layer controls access
- to all JavaScript APIs exposed by the web runtime. Each feature is
- identified uniquely by URI, and this security layer mediates access to
+ to JavaScript APIs exposed by the web runtime. Each <a href=#feature>feature</a> is
+ identified uniquely by IRI, and this security layer mediates access to
features on the basis of that ID, <a href=#api-feature><code>api-feature</code></a>.
</p>
</section> <!-- API access control layer -->
<section id="device-capability-access-control-layer">
<h4>Device Capability Access Control Layer</h4>
<p>
- The device capability access Control layer controls
+ The device capability access control layer controls
access to the underlying capabilities of the device when used from JavaScript
APIs. These device capabilities themselves are identified so that it is possible
to write security policies that control access to specific capabilities
independently of the JavaScript APIs used to access them.
</p>
+ <p>
+ For both JavaScript API and device capability access control layers, access permissions are guaranteed or restricted on a basis of via <strong><em><dfn id="access-control-policy">access control policies</dfn></em></strong>. In general, access control policies will select the effect of a particular access request depending on the <a href=#resource-attributes>resources attributes</a> captured when the request happened.
+ </p>
</section> <!-- device capability access control layer -->
<section id=feature-capability-reqs>
<h4>Considerations</h4>
@@ -189,22 +203,20 @@
<!-- <object type="image/svg+xml" data="dataflow.svg"> -->
<img src="dataflow.png" alt="graphical representation of the data flow" title="Security model, derived from XACML Specification Schema" width="595" height="454"/> <!-- </object> -->
<p>
- The specified functional components are as follows:
+ The specified <strong>functional components</strong> are as follows:
<ul>
- <li><p><strong>Policy Decision Point (PDP):</strong> the module that
- evaluates whether or not a device API can be accessed by a web
+ <li><p><strong>Policy Decision Point (PDP):</strong> 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.</p></li>
- <li><p><strong>Policy Enforcement Point (PEP):</strong> the module that
- allows or prevents access to device APIs.</p></li>
+ <li><p><strong>Policy Enforcement Point (PEP):</strong> 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.</p></li>
<li><p><strong>Policy Information Point (PIP):</strong> the module that gathers information to
- be used by the PDP to evaluate an access control request. In particular it
+ 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), the resource attributes (i.e. which device
- API is being requested and using which parameters) and the environment (i.e.
- status of the device).</p></li>
+ 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.</p></li>
<li><p><strong>Policy Administration Point (PAP):</strong> 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 run-time. Policies can be
+ 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).</p></li>
</ul>
@@ -216,7 +228,7 @@
DAP at a future stage.</p></div>
</p>
<p>
- The functionality required in each of these components is specified in terms of the following entities:
+ The functionality required in each of these components is specified in terms of the following <strong>entities</strong>:
<ul>
<li><p><strong><a href=#subject>Subject</a>:</strong> the web application
that requires access to JavaScript APIs. Examples of subjects are websites
@@ -234,15 +246,6 @@
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.</p></li>
- <li><p><strong><a href=#environment-attributes>Environment
- attribute</a>:</strong> 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.</p></li>
- <div class="issue">
- <p>environment attributes</p>
- <p>in this new model, aren't env attrs directly related to subject and trust policies?</p></div>
<li><p><strong><a
href=#resource>Resource</a>:</strong> the resources that subjects may
request access to. The device features or services (e.g. the location
@@ -255,14 +258,20 @@
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.</p></li>
+ access. Resource attributes serve as input of access control policies.</p></li>
+ <li><p><strong><a href=#environment-attributes>Environment
+ attribute</a>:</strong> 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.</p></li>
</ul>
</p>
</section> <!-- logical model -->
<section id="trust-domain-policy-structure">
<h3>Policy Structure</h3>
<p>
- 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 <strong><em><a href=#rule>rules</a></em></strong>. The rules are organised into groups, termed <strong><em><a href=#policy>policies</a></em></strong>, and these in turn are organised into groups termed <strong><em><a href=#policy-set>policy sets</a></em></strong>. This structuring serves a number of purposes:
+ 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 <strong><em><dfn id="rule">rules</dfn></em></strong>. The rules are organised into groups, termed <strong><em><dfn id="policy">policies</dfn></em></strong>, and these in turn are organised into groups termed <strong><em><dfn id="policy-set">policy sets</dfn></em></strong>. This structuring serves a number of purposes:
</p>
<ul>
<!-- <li><p>the rules that apply to a specific web application, or group of web applications, can be grouped together, which simplifies writing and maintaining the policy;</p></li> -->
@@ -270,7 +279,7 @@
<li><p>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.</p></li>
</ul>
<p>
- Simplistically, each rule is specified by defining a <strong><em><a href=#condition>condition</a></em></strong>, which is a set of statements which must be satisfied in order for that particular rule to apply, and an <strong><em><a href=#effect>effect</a></em></strong> which represents the rule's outcome – ie whether that rule indicates that the access request should be permitted or not.
+ Simplistically, each rule is specified by defining a <strong><em><dfn id="condition">condition</dfn></em></strong>, which is a set of statements which must be satisfied in order for that particular rule to apply, and an <strong><em><dfn id="effect">effect</dfn></em></strong> 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.
</p>
<!-- ILLUSTRATION POLICY LANGUAGE MODEL -->
<object type="image/svg+xml" data="languagemodel.svg">
@@ -290,10 +299,10 @@
<li><p>as a result of the evaluation of the trust policy the <a href=#effect>effect</a> of each applicable <a href=#rule>rule</a> is determined;</p></li>
<li><p>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 <a href=#effect>effect</a> is represented by the trust domain name that will be associated to the web application in successive device API and capability access requests.</p></li>
</ul>
- <p>From a logical perspective, an trust domain query can be evaluated at any time between the point that the necessary attribute values become available and when the attempted operation is performed. Generally trust policies will be applied at installation time when the subject attributes can be already be determined.
- <div class="issue">
- <p>Enforcement of trust policies</p>
- <p>when should trust policies be enforced? at installation? instantiation?</p></div>
+ <div class="issue">
+ <p>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?</p>
+ </div>
+ <p>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.
</p>
</section>
<section id=rule-processing-access-policies>
@@ -301,9 +310,6 @@
<ul>
<li><p>When the application in question attempts an action (attempts to invoke a JavaScript API, say). This identifies the <a href=#resource>resource</a> and all associated <a href=#resource-attributes>resource attributes</a> including <a href=#api-feature><code>api-feature</code></a> and, where applicable, <a href=#device-cap><code>device-cap</code></a> resource attribute if the action entails use of a device capability. Any parameters used by any such device capability use, where designated as being security-relevant, are also captured within a <a href=#parameter><code>param:name</code></a> resource attribute;</p></li>
<li><p>the <a href=#environment-attributes>environment attributes</a> are also captured;</p></li>
- <div class="issue">
- <p>Environment attributes</p>
- <p>To which policy should "environment attributes" apply? as input for trust policies or for access control policies? or both?</p></div>
<li><p>the set of resource and environment attribute values captured is embodied in an <a href=#query>access query</a> which is evaluated in the context of the top-level <a href=#access-control-policy-set>access control policy set</a> associated with the configured <a href=#access-control-policy>access control policy</a>;</p></li>
<li><p>the access query also contains the name of the trust domain that has been assigned by the trust policy;</p></li>
<li><p>based on the trust domain name, resource and environment attribute values presented in the query, the conditions associated with each rule and <a href=#target>target</a> can be evaluated, and the applicable <a href=#rule>rules</a>, <a href=#access-contro-policy>access control policies</a> and <a href=#access-control-policy-set>access control policy sets</a> can be determined;</p></li>
@@ -311,9 +317,9 @@
<li><p>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;</p></li>
<li><p>if the effect requires the user to be prompted, this is done, and the results of the user’s decision are recorded where appropriate.</p></li></ul>
</section>
- <p>
+<p>
From a logical perspective, an access control query can be evaluated at any time between the point that the necessary attribute values become available and when the attempted operation is performed. In the case of a JavaScript API call for which arguments supplied to the call are designated resource attributes, the relevant attributes are only known once the API call has been made by the calling web application. However, in other cases the information may be known earlier. For example, if all feature requirements are stated in a widget configuration document, and none of the API access operations have conditions depending on API call parameters, then all access control queries may be evaluated fully at widget resource installation time.
- </p>
+</p>
</section> <!-- rule processing -->
</section> <!-- security framework-->
<section id="security-model-definition">
@@ -346,28 +352,35 @@
made in response to invocation of a JavaScript API in
the course of execution of a web application</td> </tr>
</tbody> </table>
+ <div class="issue">
+ <p>Need to define "requestFeature()" ?</p>
+ <p>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.</p></div>
</section>
<section id="subject-attributes">
<h3>Subject Attributes</h3>
- <p> A <strong><em><a id="subject">subject</a></em></strong> corresponds to an entity that may attempt
+ <p> A <strong><em><dfn id="subject">subject</dfn></em></strong> corresponds to an entity that may attempt
security-relevant actions and corresponds to a single
- "identity". (In practice, some web applications might
+ 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.) </p>
+ single identity.</p>
<p> The identity of a subject is in one of the following classes. The
class determines which attributes are available; other
attributes have the undefined value. </p>
<p> All <strong><em>subject attributes</em></strong> are determined for the applicable
- application execution phases: widget-install, widget-instantiate.</p>
+ application execution phases: widget-install and website-bind.</p>
<section id="widget-resource-identity">
<h4>Widget Resource Identity</h4>
<p> 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.
- </p> <p> Operations occurring in the execution of a
+ execution of a document belonging to a widget resource. Attributes related to digital signatures have been derived from [[DIGSIG]]
+ <div class="issue">
+ <p>Reference to http://www.w3.org/TR/widgets-digsig/ missing</p>
+ </div>
+ </p>
+ <p> Operations occurring in the execution of a
remotely hosted document that has been loaded by a
widget (for example in an iframe) use a <a
href=#website-identity>website identity</a>. </p> <table
@@ -424,12 +437,15 @@
<td>string</td> <td>The fingerprint of the root
certificate for the widget resource author signature.
Empty bag if none.</td> </tr> <tr>
- <td>widget-attr:name</td> <td></td> <td>The value of the
+ <td>widget-attr:name</td> <td></td> <td>For a W3C widget specification compliant widget resource, this is the value of the
named attribute of the <code>widget</code> element whose type
and value are set up in the widget configuration
document for use in the security framework. Empty
bag if no such named attribute is defined.</td> </tr>
</tbody> </table>
+ <div class="issue">
+ <p>Proposal: to remove the "widget-attr" namespace prefix. Just leave "name".</p>
+ </div>
</section> <!-- widget-resource-identity -->
<section id="website-identity">
<h4>Website Identity</h4>
@@ -477,7 +493,7 @@
context is a child of a widget top-level browsing
context, this attribute contains an IRI with the widget:
scheme that corresponds to the top-level containing
- document from the widget resource.</td> </tr> <tr>
+ document from the widget resource [[!WIDGETS-URI]].</td> </tr> <tr>
<td>key-root-cn</td> <td>string</td> <td colspan="2">The
common name of the root certificate chained to by the
site certificate. Empty bag if none.</td> </tr> <tr>
@@ -486,17 +502,19 @@
chained to by the site certificate. Empty bag if
none.</td> </tr> </tbody> </table> </section> <!--
website-identity -->
+ <div class="issue"><p>Reference to http://www.w3.org/TR/widgets-uri/ missing</p></div>
</section> <!-- subject-attributes -->
<section id="resource-attributes">
<h3>Resource Attributes</h3>
<p>
- The device features or services (e.g. the location module or PIM
- database) are the actual <strong><em><a id="resource">resources</a></em></strong> that are being protected, but from
+ A <strong><em><a id="resource">resource</a></em></strong> is the actual device feature or service (e.g. the location module or PIM
+ database) that is 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
+ are associated with the API <a href=#feature>features</a> and <a href=#device-capability>device capabilities</a> used to
access them.
- </p> <p>The resource is identified by one or more of
- the following attributes: </p> <table border="1"
+ </p>
+ <p>The resource is identified by one or more of
+ the following <strong><em>resource attributes</em></strong>: </p> <table border="1"
summary=""> <caption> <dfn
id="widget-subject-attributes-table">Widget Subject
Attributes Table</dfn></caption> <thead> <tr> <th
@@ -510,12 +528,12 @@
applicable application execution phases.</td> </tr> <tr>
<td id="device-cap">device-cap</td> <td>string</td> <td>Device
capability being accessed, if any. Empty bag if
- none</td> <td>See Appendix A (*** change this ref ***).
- Determined for all applicable application Execution
- Phases.</td> </tr> <tr> <td id=parameter>param:name</td> <td>See
- comment</td> <td>The value of parameter name.</td>
- <td>The specification of each Device Capabilities lists
- the parameters associated with that Device Capability
+ none</td> <td>See (*** change this ref ***).
+ Determined for all applicable application execution
+ phases.</td> </tr> <tr> <td id=parameter>param:name</td> <td>See
+ comment</td> <td>The value of named parameter.</td>
+ <td>The specification of each device capability lists
+ the parameters associated with that device capability
and the type and semantics of each. Empty bag if the
parameter is not defined. Determined in the invoke
execution phase. Undetermined in all other execution
@@ -546,7 +564,7 @@
</section> <!-- resource-attributes -->
<section id="environment-attributes">
<h3>Environment Attributes</h3>
- <p>Attributes of the <em>environment</em> capture
+ <p><strong><em>Environment attributes</em></strong> capture
contextual information relating to the device or other
circumstances of the access attempt. </p> <table
border="1" summary=""> <caption> <dfn
@@ -578,6 +596,12 @@
</td> </tr> </tbody> </table>
</section> <!-- environment-attributes -->
</section>
+<section class='conformance'>
+ <h2>Conformance</h2>
+ <p>
+ TBD
+ </p>
+</section>
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>
Received on Friday, 18 June 2010 15:04:44 UTC