2009/dap/policy Framework.html,1.1,1.2

Update of /sources/public/2009/dap/policy
In directory hutz:/tmp/cvs-serv6963

Modified Files:
	Framework.html 
Log Message:
Changes to the policy framework

Index: Framework.html
===================================================================
RCS file: /sources/public/2009/dap/policy/Framework.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- Framework.html	2 Jun 2010 13:52:57 -0000	1.1
+++ Framework.html	3 Jun 2010 17:03:28 -0000	1.2
@@ -279,48 +279,65 @@
   <section id=rule-processing>
     <h3>Rule Processing</h3>
     <p>
-     The following steps illustrate the logical processing required when a <a href=#policy-set>policy set</a> is used to determine the outcome of a particular access attempt:
+     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>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 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>
+      <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> 
+    </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 subject, resource and environment attribute values captured is embodied in a <a href=#query>query</a> which is evaluated in the context of the top-level policy set associated with the configured security policy;</p></li>
-      <li><p>based on the subject, 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 rules, policies and policy sets can be determined;</p></li>
-      <li><p>the effect of each applicable rule 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 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>
+      <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>
+      <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 an access control policy, and a definition of the attributes of
-  each entity that are recognised and are required to be supported. This
-  specification uses [[!XACML20]]. </p>
+  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
 	  reflects the state of that application at the time an
-	  associated access control query is made. The defined
+	  associated trust domain or access control query is made. The defined
 	  execution phases are listed below. </p> <table
 	  border="1" summary=""> <caption> <dfn
 	  id="execution-phases-table">Execution Phases
 	  Table</dfn></caption> <thead> <tr> <th
 	  scope="col">Execution Phase</th> <th
 	  scope="col">Description</th> </tr> </thead> <tbody> <tr>
-	  <td>widget-install</td> <td>Applies to access control
-	  queries made by a widget user agent during the
+	  <td>widget-install</td> <td>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.</td> </tr> <tr>
-	  <td>widget-instantiate</td> <td>Applies to access
-	  control queries made by a widget user agent during the
+	  <td>widget-instantiate</td> <td>Applies to trust domain or access control queries made by a widget user agent during the
 	  instantiation of a widget.</td> </tr> <tr>
 	  <td>website-bind</td> <td>Applies to access control
 	  queries made in response to a call to requestFeature()
@@ -343,8 +360,8 @@
 	  <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 all applicable
-	  application Execution Phases. </p>
+	  <p> All <strong><em>subject attributes</em></strong> are determined for the applicable
+	  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

Received on Thursday, 3 June 2010 17:03:32 UTC