- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 18 Jun 2010 23:20:22 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy
In directory hutz:/tmp/cvs-serv5663
Modified Files:
Framework.html
Log Message:
combine attribute definitions in one place.
Index: Framework.html
===================================================================
RCS file: /sources/public/2009/dap/policy/Framework.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- Framework.html 18 Jun 2010 20:52:38 -0000 1.6
+++ Framework.html 18 Jun 2010 23:20:20 -0000 1.7
@@ -80,9 +80,14 @@
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
+<dl>
+<dt>
+<dfn id="feature">feature</dfn></dt>
+<dd> <p> A <dfn id="feature">feature</dfn> is the unit of expression of
dependencies by web applications. (This definition needs clarification).
</p>
+</dd>
+</dl>
<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,
@@ -103,9 +108,17 @@
</section>
<section id="capabilities">
<h2>Capabilities</h2>
- <p> A <dfn id="device-capability">device capability</dfn> is a
+<dl>
+<dt>
+<dfn id="device-capability">device capability</dfn>
+<dd> <p> A <dfn id="device-capability">device capability</dfn> is a
device resource or device functionality
-that may require access control. Examples of device
+that may require access control.
+</p>
+</dd>
+</dl>
+<p>
+ 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
@@ -264,13 +277,29 @@
DAP at a future stage.</p></div>
</p>
<p>
- 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
+ The functionality required in each of these components is
+ specified in terms of the following <strong>entities</strong>:
+<dl>
+<dt><dfn id="subject">subject</dfn></dt>
+<dd><p>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
+ and widgets.</p>
+<p>An entity that may attempt
+ security-relevant actions and corresponds to a single
+ "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 website identity type applies to all operations
+ 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>
+</dd>
+<dt><dfn id="subject-attribute">subject attribute</dfn></dt>
+<dd><p>Every subject is associated with a set of
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
@@ -281,28 +310,51 @@
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=#resource>Resource</a>:</strong> the resources that subjects may
+ credentials may be supported.</p>
+ <p> All <strong><em>subject attributes</em></strong> are determined for the applicable
+ application execution phases: widget-install, widget-instantiate.</p>
+</dd>
+<dt><dfn id="resource">resource</dfn></dt>
+<dd> <p>the resources that subjects may
request access to. The device features or services (e.g. the location
module or PIM database) are the actual resources that are 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 access
- them.</p></li>
- <li><p><strong><a href=#resource-attributes>Resource
- attribute</a>:</strong> each resource is associated with a set of
+ them.</p>
+<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
+ 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>
+</dd>
+<dt><dfn id="resource-attribute">resource attribute</dfn></dt>
+<dd><p>Every resource is associated with a set of
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. 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
+ access. Resource attributes serve as input of access control
+ policies.</p>
+<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
+ the point of view of the security framework these resources
+ are associated with the API features and device capabilities used to
+ access them.
+</dd>
+<dt><dfn id="environment-attribute">environment attribute</dfn></dt>
+<dd><p>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>
+ charging, network connection status, whether
+ roaming. Environment attributes serve as input of access control
+ policies.</p>
+ <p>Attributes of the <em>environment</em> capture
+ contextual information relating to the device or other
+ circumstances of the access attempt. </p>
+</dd>
+</dl>
</section> <!-- logical model -->
<section id="application-execution-phases">
<h3>Application Execution Phases</h3>
@@ -339,7 +391,16 @@
<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:
+ 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-dfn">rules</dfn></em></strong>. The
+ rules are organised into groups,
+ termed <strong><em><dfn id="policy-dfn">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> -->
@@ -353,56 +414,6 @@
<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><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
- 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> 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
- 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
- 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>
- </section> <!-- widget-resource-identity -->
- <section id="website-identity">
- <h4>Website Identity</h4>
- <p> The website identity type applies to all operations
- 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> </section> <!--
- website-identity -->
- </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
- the point of view of the security framework these resources
- are associated with the API features and device capabilities used to
- access them.
- </p>
- </section> <!-- resource-attributes -->
- <section id="environment-attributes">
- <h3>Environment Attributes</h3>
- <p>Attributes of the <em>environment</em> capture
- contextual information relating to the device or other
- circumstances of the access attempt. </p>
- </section> <!-- environment-attributes -->
-</section>
<section id="rule-processing">
<h3>Processing Rules</h3>
<p>
@@ -413,27 +424,81 @@
<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>
+ <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 trust <a href=#policy-set>policy
+ set</a> associated with the
+ configured trust <a href=#policy>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=Profile.html#target>target</a> can be evaluated, and the
+ applicable <a href=#rule>rules</a>, <a href=#policy>
+ policies</a> and <a href=#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>
+ <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>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>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=Profile.html#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 set of resource and environment attribute values
+ captured is embodied in an <a href=Profile.html#query>access
+ query</a> which
+ is evaluated in the context of the
+ top-level <a href=Profile.html#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 trust domain name, resource and environment
+ attribute values presented in the query, the conditions
+ associated with each rule
+ and <a href=Profile.html#target>target</a> can be
+ evaluated, and the
+ applicable <a href=#rule>rules</a>, <a href=#access-control-policy>access
+ control policies</a> and <a href=#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>
Received on Friday, 18 June 2010 23:20:24 UTC