- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 18 Jun 2010 20:52:40 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy
In directory hutz:/tmp/cvs-serv15430
Modified Files:
Framework.html
Log Message:
Moved Attribute definitions to Profile, some additional document
restructuring, added sections for concepts including trust, features
and capabilities.
Index: Framework.html
===================================================================
RCS file: /sources/public/2009/dap/policy/Framework.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- Framework.html 18 Jun 2010 15:04:40 -0000 1.5
+++ Framework.html 18 Jun 2010 20:52:38 -0000 1.6
@@ -1,4 +1,5 @@
-<!DOCTYPE html> <html>
+<!DOCTYPE html>
+<html>
<head>
<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'
@@ -16,20 +17,12 @@
</section> <!-- abstract -->
<section id='introduction'>
- <h2>Introduction</h2> <p>
- This document is an editors draft and currently does not reflect
- consensus of the WG but rather is a starting point for further work. It
- is based on input documents and list discussion.
- </p> <p>
+ <h2>Introduction</h2>
+ <p>
The policy framework described in this document is intended to be
applicable both to widgets and web applications (web site access to
Device APIs).
</p>
- </section> <!-- introduction -->
-<section id="security-framework">
- <h2>Security Framework</h2>
- <section id="framework-overview">
- <h3>Framework Overview</h3>
<p>
This security model is based on a clear
separation between the definition of the general framework and the creation
@@ -67,29 +60,72 @@
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>
- This general model is defined using concepts,
- terminology and semantics from the eXtensible Access Control Markup Language
- [[!XACML20]] framework. Trust and access policies are capable of
- representation in a compact XML format (and other formats, including a compact
- binary representation if necessary).
- </p> <p>
- It is intended that trust and access policies are also eventually capable of representation
- in XACML, using a specific dictionary of attributes and a subset of XACML
- elements; however this is not currently possible without defining a number of
- extensions to XACML. It is hoped that this becomes possible with future
- revisions of the XACML standard.
- </p>
- </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]].
+ </p>
+ <p>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]].
+ </p>
+ </section> <!-- introduction -->
+ <section id="concepts">
+ <h2>Core Concepts</h2>
+ <section id="trust-domains">
+ <h2>Trust Domains</h2>
+ <p>
+</p>
+</section>
+ <section id="features">
+ <h2>Features</h2>
+ <p>
+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).
+</p>
+ <p> A <dfn id="feature">feature</dfn> is the unit of expression of
+ dependencies by web applications. (This definition needs clarification).
+</p>
+<p>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]]. </p>
+<p>
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>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>
+</section>
+ <section id="capabilities">
+ <h2>Capabilities</h2>
+ <p> A <dfn id="device-capability">device capability</dfn> 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.</p>
+<p>The paragraph above repeats material in the requirements document.</p>
+</section>
+</section>
+<section id="architecture">
+ <h2>Framework Architecture</h2>
+ <section id="layered-model">
+ <h3>Layered Model</h3>
<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.
@@ -197,7 +233,7 @@
Both the trust and access control systems consist of a number of logically distinct
elements. <!-- Specific DAP requirements and interfaces are specified in terms of
these separate functional components. --> This logical breakdown and associated
- terminology is adopted from XACML [[!XACML20]] and illustrated below.
+ terminology is adopted from XACML [[XACML20]] and illustrated below.
</p>
<!-- ILLUSTRATION XACML DATAFLOW -->
<!-- <object type="image/svg+xml" data="dataflow.svg"> -->
@@ -268,67 +304,6 @@
</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><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> -->
- <li><p>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);</p></li>
- <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><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">
- <img src="languagemodel.png" alt="graphical representation of the XACML policy language model" title="DAP policy language model, derived from XACML Specification Schema" width="250" /> </object>
- </section> <!--policy structure -->
- <section id=rule-processing>
- <h3>Rule Processing</h3>
- <p>
- 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:
- </p>
- <section id=rule-processing-trust-policies>
- <h4>Rule processing for Trust Policies</h4>
- <ul>
- <li><p>The identity of the calling web application, <a href=#subject>subject</a>, is known and is used to determine the <a href=#subject-attributes>subject attributes</a> for that web application;</p></li>
- <li><p>these <a href=#subject-attributes>subject attributes</a> are embodied in the trust domain query which is evaluated in the context of the top-level <a href=#trust-policy-set>trust policy set</a> associated with the configured <a href=#trust-policy>trust policy</a>;</p></li>
- <li><p>based on the subject attribute values presented in the trust domain query, the <a href=#condition>conditions</a> associated with each <a href=#rule>rule</a> and <a href=#target>target</a> can be evaluated, and the applicable <a href=#rule>rules</a>, <a href=#trust-policy>trust policies</a> and <a href=#trust-policy-set>trust policy sets</a> can be determined;</p></li>
- <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>
- <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>
- <h4>Rule processing for Access Control Policies</h4>
- <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>
- <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>
- <li><p>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;</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>
-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>
- </section> <!-- rule processing -->
-</section> <!-- security framework-->
-<section id="security-model-definition">
- <h2>Security Model Definition</h2>
- <p> This section defines the formal model underlying the general security
- framework. This includes definitions of each of the entities involved in the
- definition of trust and access control policies, and a definition of the attributes of
- each entity that are recognised and are required to be supported. <!-- This
- specification uses [[!XACML20]]. --></p>
<section id="application-execution-phases">
<h3>Application Execution Phases</h3>
<p>The <em>execution</em> phase of a web application
@@ -356,96 +331,51 @@
<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>
+<section id="policy">
+ <h2>Policy</h2>
+ <p>
+</p>
+ <section id="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><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> -->
+ <li><p>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);</p></li>
+ <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><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">
+ <img src="languagemodel.png" alt="graphical representation of the XACML policy language model" title="DAP policy language model, derived from XACML Specification Schema" width="250" /> </object>
+ </section> <!--policy structure -->
+ <section id="attributes">
+ <h4>Attributes</h4>
<section id="subject-attributes">
<h3>Subject Attributes</h3>
- <p> A <strong><em><dfn id="subject">subject</dfn></em></strong> corresponds to an entity that may attempt
+ <p> A <strong><em><a id="subject">subject</a></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>
- <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>
+ single identity.) </p>
<p> All <strong><em>subject attributes</em></strong> are determined for the applicable
- application execution phases: widget-install and website-bind.</p>
+ application execution phases: widget-install, widget-instantiate.</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. 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
+ execution of a document belonging to a widget resource.
+ </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
- border="1" summary=""> <caption> <dfn
- id="widget-subject-attributes-table">Widget Subject
- Attributes Table</dfn></caption> <thead> <tr> <th
- scope="col">Attribute</th> <th scope="col">Type</th> <th
- scope="col">Value</th> </tr> </thead> <tbody> <tr>
- <td>class</td> <td>string</td> <td>This has the value
- "widget" if and only if the subject is a widget.</td>
- </tr> <tr> <td>install-uri</td> <td>URI</td> <td>The URI
- that the widget resource was originally retrieved from
- before installation, if known, otherwise the empty
- bag.</td> </tr> <tr> <td>id</td> <td>URI</td> <td>The
- identity of the widget. For a W3C widget specification [[!WIDGETS]]
- compliant widget resource, this is the value of the <code>id</code>
- attribute of the <code>widget</code> element in the widget
- configuration document converted from IRI to URI based
- on RFC3987 [[!IRI]]. In this case, it is a URI that uniquely
- identifies the widget. Empty bag if there is no <code>id</code>
- attribute.</td> </tr> <tr> <td>version</td>
- <td>string</td> <td>Version of the widget resource. For
- a W3C widget specification compliant widget resource,
- this is the <code>version</code> attribute of the <code>widget</code> element in
- the widget configuration document. Empty bag if there is
- no <code>version</code> attribute.</td> </tr> <tr>
- <td>distributor-key-cn</td> <td>string</td> <td>The
- common name of the end entity certificate for the
- applicable widget resource distributor signature. Empty
- bag if none.</td> </tr> <tr>
- <td>distributor-key-fingerprint</td> <td>string</td>
- <td>The fingerprint of the end-entity certificate for
- the applicable widget resource distributor signature.
- Empty bag if none.</td> </tr> <tr>
- <td>distributor-key-root-cn</td> <td>string</td> <td>The
- common name of the root certificate for the applicable
- widget resource distributor signature. Empty bag if
- none.</td> </tr> <tr>
- <td>distributor-key-root-fingerprint</td>
- <td>string</td> <td>The fingerprint of the root
- certificate for the applicable widget resource
- distributor signature.Empty bag if none.</td> </tr> <tr>
- <td>author-key-cn</td> <td>string</td> <td>The common
- name of the end entity certificate for the widget
- resource author signature. Empty bag if none.</td> </tr>
- <tr> <td>author-key-fingerprint</td> <td>string</td>
- <td>The fingerprint of the end entity certificate for
- the widget resource author signature in SDP syntax.
- Empty bag if none.</td> </tr> <tr>
- <td>author-key-root-cn</td> <td>string</td> <td>The
- common name of the root certificate for the widget
- resource author signature. Empty bag if none.</td> </tr>
- <tr> <td>author-key-root-fingerprint</td>
- <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>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>
+ href=#website-identity>website identity</a>. </p>
</section> <!-- widget-resource-identity -->
<section id="website-identity">
<h4>Website Identity</h4>
@@ -453,149 +383,65 @@
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). </p> <table border="1"
- summary=""> <caption> <dfn
- id="website-subject-attributes-table">Website Subject
- Attributes Table</dfn></caption> <thead> <tr> <th
- scope="col">Attribute</th> <th scope="col">Type</th> <th
- scope="col">Value</th> <th scope="col">Meaning</th>
- </tr> </thead> <tbody> <tr> <td>class</td>
- <td>string</td> <td>"website"</td> <td>Has the value
- "website" if and only if the subject is of this
- class.</td> </tr> <tr> <td rowspan="4">sign-schema</td>
- <td rowspan="4">string</td> </tr> <tr> <td>"" (empty
- string)</td> <td>Not signed.</td> </tr> <tr>
- <td>"tls"</td> <td>The page was fetched using HTTPS and
- the browser has verified that the site certificate’s
- Common Name matches the host that the page was fetched
- from, and it has already applied its own policies
- regarding whether the root certificate is in an
- acceptable trust domain.</td> </tr> <tr>
- <td>"tls-ev"</td> <td>As "tls", and, additionally, the
- site certificate has an extended validation field and
- the browser's internal policy allows that information to
- be passed to the security framework.</td> </tr> <tr>
- <td>uri</td> <td>URI</td> <td colspan="2">The URI used
- to access the document that embeds or refers to the
- JavaScript code, corresponding to the window.location
- property of the browsing context. In the case of that a
- feature is accessed from a child browsing context (for
- example from within a <iframe> within some outer
- document), this attribute provides the location of the
- child context.</td> </tr> <tr> <td>uri-top</td>
- <td>URI</td> <td colspan="2">The URI used to access the
- website that embeds or refers to the JavaScript code,
- corresponding to the top.window property of the browsing
- context. In the case that the feature is accessed from a
- child browsing context (for example from within an
- <iframe>), this attribute provides the location of
- the top-level browsing context. If the current browsing
- 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 [[!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>
- <td>key-root-fingerprint</td> <td>string</td> <td
- colspan="2">The fingerprint of the root certificate
- chained to by the site certificate. Empty bag if
- none.</td> </tr> </tbody> </table> </section> <!--
+ context (such as an iframe). </p> </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>
- 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 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
the point of view of the security framework these resources
- are associated with the API <a href=#feature>features</a> and <a href=#device-capability>device capabilities</a> used to
+ are associated with the API features and device capabilities used to
access them.
- </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
- scope="col">Attribute</th> <th scope="col">Type</th> <th
- scope="col">Value</th> <th scope="col">Comment</th>
- </tr> </thead> <tbody> <tr> <td id="api-feature">api-feature (*** ref:
- ****)</td> <td>URI</td> <td>The IRI identifier of the
- requested Feature converted to URI as per RFC3987
- [[!IRI]].</td> <td>This uses the same naming scheme as
- in a widget's <code>feature</code> element. Determined for all
- 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 (*** 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
- phases.</td> </tr> <tr> <td colspan="4">The following
- resource attributes give information on the source of
- the implementation of the API Feature.</td> </tr> <tr>
- <td>feature-install-uri</td> <td>URI</td> <td>The URI
- that the API implementation was originally retrieved
- from before installation, if known, otherwise the empty
- bag.</td> <td>Determined for all applicable application
- execution phases.</td> </tr> <tr>
- <td>feature-key-cn</td> <td>string</td> <td>The common
- name of the end entity certificate for the signature
- associated with the Feature implementation. Empty bag if
- none.</td> <td>Determined for all applicable application
- execution phases.</td> </tr> <tr>
- <td>feature-key-root-cn</td> <td>string</td> <td>The
- common name of the root certificate for the signature
- associated with the Feature implementation. Empty bag if
- none</td> <td>Determined for all applicable application
- execution phases.</td> </tr> <tr>
- <td>feature-key-root-fingerprint</td> <td>string</td>
- <td>The fingerprint of the root certificate of the
- signature associated with the Feature implementation.
- Empty bag if none.</td> <td>Determined for all
- applicable application execution phases.</td> </tr> <tr>
- </tbody> </table>
+ </p>
</section> <!-- resource-attributes -->
<section id="environment-attributes">
<h3>Environment Attributes</h3>
- <p><strong><em>Environment attributes</em></strong> capture
+ <p>Attributes of the <em>environment</em> capture
contextual information relating to the device or other
- circumstances of the access attempt. </p> <table
- border="1" summary=""> <caption> <dfn
- id="widget-subject-attributes-table">Widget Subject
- Attributes Table</dfn></caption> <thead> <tr> <th
- scope="col">Attribute</th> <th scope="col">Type</th> <th
- scope="col">Value</th> <th scope="col">Comment</th>
- </tr> </thead> <tbody> <tr> <td>roaming</td>
- <td>string</td> <td>"national", "international", or
- empty string</td> <td>Determined in the following
- execution phases:
- <ul> <li>widget-instantiate</li>
- <li>website-bind</li> <li>invoke</li> </ul>
- Undetermined in the following execution phases:
- <ul> <li>widget-install</li> </ul>
- </td> </tr> <tr> <td>bearer-type</td> <td>string</td>
- <td>The type of the current network bearer over which a
- network request will be served, either by request of the
- application or by default (per the current serving
- network or the one over which the request will be
- served, if multiple networks are available). A
- comma-separated list of one or more of the bearer types
- given as examples in W3C DCO [[DCONTOLOGY]].</td>
- <td>Determined in the following execution phases:
- <ul> <li>widget-instantiate</li>
- <li>website-bind</li> <li>invoke</li> </ul>
- Undetermined in the following execution phases:
- <ul> <li>widget-install</li> </ul>
- </td> </tr> </tbody> </table>
+ circumstances of the access attempt. </p>
</section> <!-- environment-attributes -->
-</section>
+</section>
+ <section id="rule-processing">
+ <h3>Processing Rules</h3>
+ <p>
+ 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:
+ </p>
+ <section id="rule-processing-trust-policies">
+ <h4>Trust Processing Rules</h4>
+ <ul>
+ <li><p>The identity of the calling web application, <a href=#subject>subject</a>, is known and is used to determine the <a href=#subject-attributes>subject attributes</a> for that web application;</p></li>
+ <li><p>these <a href=#subject-attributes>subject attributes</a> are embodied in the trust domain query which is evaluated in the context of the top-level <a href=#trust-policy-set>trust policy set</a> associated with the configured <a href=#trust-policy>trust policy</a>;</p></li>
+ <li><p>based on the subject attribute values presented in the trust domain query, the <a href=#condition>conditions</a> associated with each <a href=#rule>rule</a> and <a href=#target>target</a> can be evaluated, and the applicable <a href=#rule>rules</a>, <a href=#trust-policy>trust policies</a> and <a href=#trust-policy-set>trust policy sets</a> can be determined;</p></li>
+ <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>
+ <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">
+ <h4>Feature and Capability Processing Rules</h4>
+ <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>
+ <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>
+ <li><p>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;</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>
+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>
+ </section> <!-- rule processing -->
+</section> <!-- security framework-->
<section class='conformance'>
<h2>Conformance</h2>
<p>
@@ -606,8 +452,7 @@
<h2>Acknowledgements</h2>
<p>
The editors would like to extend special thanks to Nokia, OMTP BONDI,
- and PhoneGap for providing the foundation of the working group's
- requirements discussion.
+ and PhoneGap for their contributions.
</p>
</section>
</body>
Received on Friday, 18 June 2010 20:52:42 UTC