- From: Laura Arribas via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 26 May 2010 11:53:09 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy
In directory hutz:/tmp/cvs-serv27583
Modified Files:
Overview.html
Log Message:
Update to the policy framework draft
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy/Overview.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- Overview.html 13 Apr 2010 15:01:37 -0000 1.8
+++ Overview.html 26 May 2010 11:53:07 -0000 1.9
@@ -29,10 +29,10 @@
<h2>Security Framework</h2>
<section id="framework-overview">
<h3>Framework Overview</h3>
- <p>
- The DAP security model is based on a clear
+ <p>
+ This security model is based on a clear
separation between the definition of the general framework and the creation
- of specific Security Policies. This allows the configured Security Policy of
+ 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
@@ -49,27 +49,27 @@
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 security policy is necessary to grant
+ 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>
- The DAP security framework is based on a very general model that governs access by subjects
- to resources based on a hierarchy of <a href=#policy>policies</a> and <a href=#policy-set>policy sets</a>, where each policy
+ 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
- attributes is defined so that policies can be expressed controlling access based
+ 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.
</p> <p>
- This model is defined using concepts,
+ This general model is defined using concepts,
terminology and semantics from the eXtensible Access Control Markup Language
- [[!XACML20]] framework. DAP policies are capable of
+ [[!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 DAP policies are also eventually capable of representation
+ 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
@@ -78,22 +78,32 @@
</section> <!-- framework overview-->
<section id="layer-model">
<h3>Layer Model</h3>
- <p>
- A web application uses a DAP-specified mechanism to gain access to (or bind to)
- a JavaScript API by stating one or more features exposed by the JavaScript API.
- The implementation of this API, in turn, makes use of one or more device
+ <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
specifies which feature it implements, and which device capabilities it uses.
</p> <p>
- The mechanisms provided in DAP to bind to APIs, and to control access (both to
+ The mechanisms provided in this specification to bind to APIs, and to control access (both to
the features and the device capabilities exposed by them) are generic, and are
- not themselves dependent on any particular set of JavaScript APIs. The DAP
+ not themselves dependent on any particular set of JavaScript APIs. This
model envisages that these controls apply, irrespective of whether the APIs in
use are defined by DAP or any independent entity. <!-- This “layering” of
JavaScript APIs and mediating access control is illustrated in the figure below. -->
</p>
+ <section id="trust-domain-control-layer">
+ <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
+ 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
+ identify the web application.
+ </p>
+ </section> <!-- trust domain control layer -->
<section id="api-access-control-layer">
<h4>Javascript API Access Control Layer</h4>
<p>
@@ -120,7 +130,7 @@
number of significant requirements, as follows.
</p>
<ul>
- <li><p><strong>Extensibility is an intrinsic part of the DAP model.</strong> DAP expects that APIs will be defined and implemented
+ <li><p><strong>Extensibility is an intrinsic part of the security model.</strong> It is expected that APIs will be defined and implemented
independently, and the nature of those APIs will not necessarily be known to the
author of a security policy. Therefore, if a security policy author wishes to
deny access to a specific device capability, then there must be a way of doing
@@ -140,41 +150,43 @@
enabling or disabling access to a specific device capability will not directly
correspond to enabling or disabling access to a single JavaScript API.</p></li>
<li><p><strong>Implementations of JavaScript APIs need not be as highly
- trusted as the web runtime.</strong> Authors of security policies may require the ability to
+ trusted as the web runtime.</strong> Authors of access policies may require the ability to
control access to specific JavaScript APIs, or families of APIs, based on the
identity of the API (and not just the device capabilities it exposes), according
to the trustworthiness of the author of the API.</p></li>
- <li><p><strong>It must be possible to represent security policies
+ <li><p><strong>It must be possible to represent both trust and access policies
portably.</strong> 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. <!-- BONDI defines a set of these capabilities in
- Appendix
- A.--></p></li>
+ Appendix A.--></p></li>
</ul>
- </section> <!-- considerations -->
- </section> <!-- logical model -->
+ </section> <!-- feature-caps requirements -->
+ </section> <!-- layer model -->
<section id="logical-model">
<h3>Logical Model</h3>
- <p>
- The DAP access control system, from a logical perspective, mediates any
- attempt by an executing web application to access device capabilities
- using JavaScript APIs. The access control system, implementing a specific
- access control policy, has the sole effect of making and enforcing an
- access control decision in relation to each attempted access. (In order to
- make that decision the access control system may request interactive
+ <p>
+ On the one hand, the trust domain control system explained in this
+ document, from a logical perspective, represents the system by which a web
+ application that attempts to access device capabilities using JavaScript
+ APIs, is assigned a trust or security domain. This trust domain will then
+ be used in subsequent access requests, simplifying the whole process. On
+ the other hand, the access control system, implementing a specific access
+ control policy, has the sole effect of making and enforcing an access
+ control decision in relation to each attempted access. (In order to make
+ that decision the access control system may request interactive
confirmation from the user, but this is invisible to the requesting web
application.)
</p> <p>
- The access control system itself consists of a number of logically distinct
+ 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.
</p>
<!-- ILLUSTRATION XACML DATAFLOW -->
- <object type="image/svg+xml" data="XACMLdataflow.svg">
- <img src="XACMLdataflow.png" alt="graphical representation of the XACML data flow" title="DAP security model, derived from XACML Specification Schema" width="700" height="700"/> </object>
+ <!-- <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="700" height="700"/> <!-- </object> -->
<p>
The specified functional components are as follows:
<ul>
@@ -205,19 +217,31 @@
<p>
The functionality required in each of these components is specified in terms of the following entities:
</p>
- <ul>
<li><p><strong><a href=#subject>Subject</a>:</strong> the web application
that requires access to JavaScript APIs. Examples of subjects are websites
and widgets.</p></li>
<li><p><strong><a href=#subject-attributes>Subject
attribute</a>:</strong> each subject is associated with a set of
- attributes. 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
+ 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 appropiate 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.</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
@@ -231,12 +255,6 @@
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>
- <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>
</ul>
</p>
</section> <!-- logical model -->
Received on Wednesday, 26 May 2010 11:53:10 UTC