2009/dap/policy Framework.html,1.12,1.13

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

Modified Files:
	Framework.html 
Log Message:
add material to trust domain section based on Nokia contribution


Index: Framework.html
===================================================================
RCS file: /sources/public/2009/dap/policy/Framework.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- Framework.html	18 Jun 2010 23:36:58 -0000	1.12
+++ Framework.html	21 Jun 2010 14:24:05 -0000	1.13
@@ -33,17 +33,24 @@
       as post-sales installation of web runtimes.
     </p> <p>
       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
+      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.
     </p> <p>
-      The intention is that the framework, at the most general level, allows a very
+      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
+      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
+      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.
     </p> <p>
       This framework is based on a very general model that governs
@@ -54,10 +61,17 @@
       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.
+      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-attribute>subject attributes</a> and <a href=#resource-attribute>resource attributes</a>, respectively. A range of
-      attributes is defined so that access policies can be expressed based
+      number of defined <a href=#subject-attribute>subject
+      attributes</a> and <a href=#resource-attribute>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.
@@ -75,6 +89,30 @@
     <section id="trust-domains">
 	<h2>Trust Domains</h2>
 	  <p>
+ 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.
+</p>
+<p>
+Trust domains can be based on origin, signatures or be "Untrusted", to
+list three common cases.</p>
+<p>
+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.
 </p>
 </section>
     <section id="features">

Received on Monday, 21 June 2010 14:24:10 UTC