- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 21 Jun 2010 12:33:31 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy
In directory hutz:/tmp/cvs-serv4762
Modified Files:
Profile.html
Log Message:
fix variety of additional validation errors
Index: Profile.html
===================================================================
RCS file: /sources/public/2009/dap/policy/Profile.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- Profile.html 18 Jun 2010 23:57:40 -0000 1.7
+++ Profile.html 21 Jun 2010 12:33:29 -0000 1.8
@@ -47,7 +47,7 @@
<section id="values-and-types">
<h3>Values and Types</h3>
<p>Each value in an expression is conceptually a
- <em>bag</em> of potentially multiple simple values. The
+ <code>bag</code> of potentially multiple simple values. The
bag can be empty, containing no simple values. In
practice almost every value encountered in the model is
either an empty bag or a bag containing a single simple
@@ -135,47 +135,51 @@
</section> <!-- attribute-match -->
<section id="subject-specification">
<h3>Subject Match</h3>
- <p>A <em>subject</em> specification consists of a
- conjunctive sequence of <em>subject</em> matches. </p>
- <p> A specification is evaluated as follows:
+ <p>A <code>subject</code> specification consists of a
+ conjunctive sequence of <code>subject</code> matches.
+ A specification is evaluated as follows:</p>
<ul> <li>is determined and has value TRUE if
- each of the <em>subject</em> matches has value
+ each of the <code>subject</code> matches has value
TRUE</li> <li>otherwise, is undetermined if any
- or the <em>subject</em> matches is
+ or the <code>subject</code> matches is
undetermined</li> <li>otherwise is determined
and has value FALSE.</li> </ul>
- A <em>subject</em> match is an attribute match where the
- attribute being matched is a <em>subject</em> attribute,
+ <p>
+ A <code>subject</code> match is an attribute match where the
+ attribute being matched is a <code>subject</code> attribute,
and the match value is a literal string and does not
contain any attribute references. </p>
</section> <!-- subject-specification -->
<section id="target">
<h3>Target</h3>
- <p>The <em>target</em> of a <em>policy</em> or
- <em>policy set</em> identifies the set of
- <em>subjects</em> to which the <em>policy</em> or
- <em>policy set</em> applies. </p> <p>The <em>target</em>
- consists of a disjunctive sequence of <em>subject</em>
- specifications. </p> <p> A target specification is
- evaluated as follows:
- <ul> <li>has value TRUE if at least one of the
- subject specifications has value TRUE</li>
- <li>otherwise has value FALSE</li> <li>A
- <em>policy</em> or <em>policy-set</em> that has
- no <em>target</em> explicitly specified is
- treated as having a <em>target</em> that
- evaluates unconditionally to TRUE.</li> </ul>
- </p>
+ <p>The <code>target</code> of a <code>policy</code> or
+ <code>policy set</code> identifies the set of
+ <code>subjects</code> to which the <code>policy</code> or
+ <code>policy set</code> applies. </p>
+ <p>The <code>target</code>
+ consists of a disjunctive sequence of <code>subject</code>
+ specifications. A target specification is
+ evaluated as follows:</p>
+ <ul>
+ <li>has value TRUE if at least one of the
+ subject specifications has value TRUE</li>
+ <li>otherwise has value FALSE</li>
+ <li>A
+ <code>policy</code> or <code>policy-set</code> that has
+ no <code>target</code> explicitly specified is
+ treated as having a <code>target</code> that
+ evaluates unconditionally to TRUE.</li>
+ </ul>
</section> <!-- target -->
<section id="decision">
<h3>Decision</h3>
- <p>If determined, the result of a <em>rule</em> or
- <em>policy</em> or <em>policy set</em> is a
- <em>decision</em>, either “not applicable” or any one of
- the <a href="#effect"><em>effects</em></a> “permit”,
+ <p>If determined, the result of a <code>rule</code> or
+ <code>policy</code> or <code>policy set</code> is a
+ <code>decision</code>, either “not applicable” or any one of
+ the <a href="#effect"><code>effects</code></a> “permit”,
“prompt-blanket”, “prompt-session”, “prompt-oneshot” or
- “deny”. </p> <p> The result of a <em>rule</em> or
- <em>policy</em> or <em>policy set</em> may be
+ “deny”. </p> <p> The result of a <code>rule</code> or
+ <code>policy</code> or <code>policy set</code> may be
undetermined under conditions specified for each below.
</p>
</section> <!-- decision -->
@@ -190,10 +194,10 @@
</section> <!-- rule -->
<section id="condition">
<h3>Condition</h3>
- <p>The <em>condition</em> of a <em>rule</em> specifies
+ <p>The <code>condition</code> of a <code>rule</code> specifies
extra criteria that need to be matched before the
- <em>rule</em> becomes applicable. </p> <p> The
- <em>condition</em> consists of one or more attribute
+ <code>rule</code> becomes applicable. </p> <p> The
+ <code>condition</code> consists of one or more attribute
matches, combined with AND and OR operators into an
arbitrarily nested tree. </p> <p> The AND operator is
evaluated as follows: <ul> <li>is determined and has
@@ -208,18 +212,18 @@
</section> <!-- decision -->
<section id="policy">
<h3>Policy</h3>
- <p>A <em>policy</em> has a <em>target</em>, and a list
- of zero or more <em>rules</em> combined using a <a
- href="#combining-algorithm"><em>rule-combining
- algorithm</em></a>. Where a directive attribute query
+ <p>A <code>policy</code> has a <code>target</code>, and a list
+ of zero or more <code>rules</code> combined using a <a
+ href="#combining-algorithm"><code>rule-combining
+ algorithm</code></a>. Where a directive attribute query
finds more than one applicable directive attribute set,
- the first one is used. </p> <p>A <em>policy</em>
+ the first one is used. </p> <p>A <code>policy</code>
optionally has a textual description. </p> <p> A
- <em>policy</em> optionally has an id. If an
+ <code>policy</code> optionally has an id. If an
implementation provides a means to provision a security
policy fragment to replace an existing one, this id can
- be used to identify the <em>policy</em> or <em>policy
- set</em> to replace. No management of ids is mandated,
+ be used to identify the <code>policy</code> or <code>policy
+ set</code> to replace. No management of ids is mandated,
therefore it is recommended that a standardised textual
representation of a UUID should be used as the id. </p>
<p> The result of a policy is determined if and only if
@@ -227,18 +231,18 @@
</section> <!-- policy -->
<section id="policy-set">
<h3>Policy Set</h3>
- <p>The overall security framework is a <em>policy
- set</em>. </p> <p> A <em>policy set</em> is a target
- with a list of zero or more <em>policies</em> and
- <em>policy sets</em> combined using a <a
- href="#combining-algorithm"><em>policy-combining
- algorithm</em></a>. Where a directive attribute query
+ <p>The overall security framework is a <code>policy
+ set</code>. </p> <p> A <code>policy set</code> is a target
+ with a list of zero or more <code>policies</code> and
+ <code>policy sets</code> combined using a <a
+ href="#combining-algorithm"><code>policy-combining
+ algorithm</code></a>. Where a directive attribute query
finds more than one applicable directive attribute set,
- the first one is used. </p> <p> A <em>policy set</em>
+ the first one is used. </p> <p> A <code>policy set</code>
optionally has an id. If an implementation provides a
means to provision a security policy fragment to replace
an existing one, this id can be used to identify the
- <em>policy</em> or <em>policy set</em> to replace. No
+ <code>policy</code> or <code>policy set</code> to replace. No
management of ids is mandated, therefore it is
recommended that a standardised textual representation
of a UUID should be used as the id. </p> <p> The result
@@ -250,17 +254,17 @@
<p>Where the implementation supports deployment of a
fragment of policy to add to the existing security
policy framework or to replace a part of it, the
- <em>policy document</em> is the unit of addition or
- replacement. A <em>policy document</em> can be either a
- <em>policy</em> or a <em>policy set</em>. </p>
+ <code>policy document</code> is the unit of addition or
+ replacement. A <code>policy document</code> can be either a
+ <code>policy</code> or a <code>policy set</code>. </p>
</section> <!-- policy-document -->
<section id="signed-policy-document">
<h3>Signed Policy Document</h3>
<p>Where the implementation supports deployment of
- policy fragments as above, the <em>signed policy
- document</em> is the cryptographically signed unit of
- deployment. It contains one or more <em>policy
- documents</em> as well as a single signature. </p>
+ policy fragments as above, the <code>signed policy
+ document</code> is the cryptographically signed unit of
+ deployment. It contains one or more <code>policy
+ documents</code> as well as a single signature. </p>
</section> <!-- signed-policy-document -->
<section id="matching-function">
<h3>Matching Function</h3>
@@ -364,25 +368,25 @@
</section> <!-- modifier-function -->
<section id="combining-algorithm">
<h3>Combining Algorithm</h3>
- <p>The <em>policy-combining algorithm</em> for a
- <em>policy set</em> determines how child
- <em>policies</em> and <em>policy sets</em> are combined.
- </p> <p>The <em>rule-combining algorithm</em> for a
- <em>policy</em> determines how child <em>rules</em> are
+ <p>The <code>policy-combining algorithm</code> for a
+ <code>policy set</code> determines how child
+ <code>policies</code> and <code>policy sets</code> are combined.
+ </p> <p>The <code>rule-combining algorithm</code> for a
+ <code>policy</code> determines how child <code>rules</code> are
combined. </p> <p>The algorithms are described in the
- following subsections. The term <em>child</em> is used
- to mean the child <em>rules</em> in the <em>policy</em>
- when applying the <em>policy's rule-combining
- algorithm</em>, or the child <em>policies</em> and
- <em>policy sets</em> in the <em>policy set</em> when
- applying the <em>policy set's policy-combining
- algorithm</em>. </p>
+ following subsections. The term <code>child</code> is used
+ to mean the child <code>rules</code> in the <code>policy</code>
+ when applying the <code>policy's rule-combining
+ algorithm</code>, or the child <code>policies</code> and
+ <code>policy sets</code> in the <code>policy set</code> when
+ applying the <code>policy set's policy-combining
+ algorithm</code>. </p>
<section id="deny-overrides-combining-algorithm">
<h4>Deny-Overrides Combining Algorithm</h4>
<p>The Deny-Overrides Combining Algorithm is usable as a
policy-combining algorithm and as a rule-combining
algorithm. </p> <p>The overall result of a
- <em>query</em> is evaluated as follows: <ul> <li>if any
+ <code>query</code> is evaluated as follows: <ul> <li>if any
child evaluates to "deny", then the overall result is
"deny";</li> <li>otherwise, if any child is
undetermined, then the overall result is
@@ -401,7 +405,7 @@
<h4>Permit-Overrides Combining Algorithm</h4>
<p>The Permit-Overrides Combining Algorithm is usable as
a policy-combining algorithm and as a rule-combining
- algorithm. The overall result of a <em>query</em> is
+ algorithm. The overall result of a <code>query</code> is
evaluated as follows: <ul> <li>if any child evaluates to
"permit", then the overall result is "permit";</li>
<li>otherwise, if any child is undetermined, then the
@@ -447,43 +451,40 @@
</section> <!-- combining-algorithm -->
<section id="effect">
<h3>Effect</h3>
- <p>The <em>effect</em> of a <em>rule</em> is one of the
+ <p>The <code>effect</code> of a <code>rule</code> is one of the
following: </p>
<section id="permit">
<h4>Permit</h4>
- <p>This <em>effect</em> allows requested access without
+ <p>This <code>effect</code> allows requested access without
user interaction. </p>
</section> <!-- permit -->
<section id="deny">
<h4>Deny</h4>
- <p>This <em>effect</em> denies requested access without
+ <p>This <code>effect</code> denies requested access without
user interaction. </p>
</section> <!-- deny -->
<section id="prompt-x">
<h4>Prompt-x</h4>
<p>The prompt-oneshot, prompt-session and prompt-blanket
effects allow requested access after explicit
- confirmation by the user. The implementation <em
- title="must" class="rfc2119">must</em> prompt the user
- before allowing access. </p> <p>The implementation <em
- title="must" class="rfc2119">must</em> only provide the
+ confirmation by the user. The implementation MUST prompt the user
+ before allowing access. </p> <p>The implementation MUST only
+ provide the
user the option to grant permission up to the maximum
- allowed by the <em>effect</em>, ie: <ul>
+ allowed by the <code>effect</code>, ie: <ul>
<li>prompt-oneshot: "deny always", "deny this time",
"allow this time";</li> <li>prompt-session:
prompt-oneshot options plus "deny for this session",
"allow for this session";</li> <li>prompt-blanket:
prompt-session options plus "allow always".</li> </ul>
- The implementation <em title="must"
- class="rfc2119">must</em> provide a means to respond
+ The implementation MUST provide a means to respond
with any available option that is applicable in the
context in which the prompt is displayed. </p> <p> Any
- default action <em title="must"
- class="rfc2119">must</em> be at least as restrictive as
+ default action MUST be at least as restrictive as
"deny this time". </p> <p> If the user has the option of
deferring a response indefinitely and the user does not
- respond explicitly, the requested access <em title="must
- not" class="rfc2119">must not</em> be allowed. </p> <p>
+ respond explicitly, the requested access MUST NOT be
+ allowed. </p> <p>
For a widget, a session lasts while the application is
still running and the terminal has not been switched off
or placed in standby mode. </p> <p> For a website,
@@ -493,20 +494,20 @@
</section> <!-- effect -->
<section id="query">
<h3>Query</h3>
- <p>A <em>query</em> represents a specific instance of a
+ <p>A <code>query</code> represents a specific instance of a
security policy being evaluated in order to make an
access control decision relating to an attempted
- operation by a web application. </p> <p>A <em>query</em>
- is characterised by the collection of <em>subject
- attributes</em> associated with the web application
- instance, the collection of <em>resource attributes</em>
+ operation by a web application. </p> <p>A <code>query</code>
+ is characterised by the collection of <code>subject
+ attributes</code> associated with the web application
+ instance, the collection of <code>resource attributes</code>
associated with the attempted operation, and the
- collection of <em>environment attributes</em> associated
+ collection of <code>environment attributes</code> associated
with the circumstances of the attempt. The
determinedness of each of these attributes is in
- accordance with the <em>execution phase</em> of the
- attempt. </p> <p>A <em>query</em> is evaluated against a
- <em>policy-set</em>, resulting in a <em>decision</em> in
+ accordance with the <code>execution phase</code> of the
+ attempt. </p> <p>A <code>query</code> is evaluated against a
+ <code>policy-set</code>, resulting in a <code>decision</code> in
accordance with the evaluation rules defined in this
specification. </p>
</section> <!-- query -->
@@ -535,19 +536,16 @@
document as defined in XML Digital Signature
[[!XMLDSIG-CORE2]], with the following additional
constraints: </p> <ul>
- <li>the <code><signature></code> element <em
- title="must" class="rfc2119">must</em> contain one or
+ <li>the <code><signature></code> element MUST contain one or
more valid <Reference> elements;</li> <li>the
- URL attribute of each <Reference> element <em
- title="must" class="rfc2119">must</em> contain a
+ URL attribute of each <Reference> element MUST contain a
reference to a <code><policy></code>; or
<code><policy-set></code> element that is a
sibling of the <code><signature></code> element
in the same Signed Policy Document;</li> <li>the
- <Reference> element <em title="must"
- class="rfc2119">must not</em> have any
+ <Reference> element MUST NOT have any
<Transform> elements;</li> <li>the widget user
- agent <em title="must" class="rfc2119">must</em> treat
+ agent MUST treat
the <code><signed-policy></code> as invalid if
it has a child <code><policy></code>; or
<code><policy-set></code> element for which
@@ -561,8 +559,7 @@
<code><policy></code>;.
<code><policy-set></code> has two possible
attributes: </p> <ul>
- <li>combine, which <em title="must"
- class="rfc2119">must</em> take a value of
+ <li>combine, which MUST take a value of
"deny-overrides", "permit-overrides" or
"first-matching-target". The attribute is optional; if
it is omitted, the default value is
@@ -661,7 +658,7 @@
</section>
</section>
-<section class='attribute-definitions'>
+<section id='attribute-definitions'>
<h2>Attribute Definitions</h2>
<section class='subject-attribute-definitions'>
<h2>Subject Attribute Definitions</h2>
@@ -785,56 +782,67 @@
<h2>Resource Attribute Definitions</h2>
<p>The resource is identified by one or more of
the following attributes: </p>
-<table> <caption> <dfn
- id="widget-subject-attributes-table">Widget Resource
- Attributes Table</dfn></caption> <thead> <tr> <th
- scope="col">Attribute</th> <th scope="col">Type</th> <th
+<table>
+ <caption>
+ <dfn id="widget-subject-attributes-table">Widget Resource
+ 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:
+ </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 Appendix A (*** 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 parameter name.</td>
- <td>The specification of each Device Capabilities 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
+ 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 Appendix A (*** 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 parameter name.</td>
+ <td>The specification of each Device Capabilities 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>
+ 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>
+ 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>
+ 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>
+ 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>
+ applicable application execution phases.</td> </tr>
+ </tbody>
+</table>
</section>
-<section 'class=context-attribute-definitions'>
+<section class='context-attribute-definitions'>
<h2>Context Attribute Definitions</h2>
- <p>
<table> <caption> <dfn
id="widget-subject-attributes-table">Context
Attributes Table</dfn></caption> <thead> <tr> <th
@@ -848,7 +856,9 @@
<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>
+</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
@@ -864,7 +874,7 @@
</td> </tr> </tbody> </table>
</section>
</section>
-<section class='examples'>
+<section id='examples'>
<h2>Examples</h2>
<section id="example-abuse-policies">
<h2>Example Policies to mitigate Abuse Use Cases</h2>
@@ -877,7 +887,7 @@
application is trusted and is on the device. If the user
(or the policy provider) has stated that they don’t want
to call premium rate numbers in the UK: </p>
- <pre><code>
+ <pre>
<code><target></code>
<code><subject></code>
<subject-match attr="author-key-root-fingerprint"
@@ -891,12 +901,17 @@
param:recipients="+4409*" func="glob"/> <-- to block UK premium
rate numbers -->
</condition>
- </rule> </pre></code>
- We could extend this to other countries if we are concerned that premium rate
- numbers would not only be from the host country. Here is an example of a policy
- fragment for blocking Spanish premium rate numbers that could be added, along
- with the condition combining operator (please note: there are probably more
- elegant ways of expressing this by using regular expressions): <pre><code>
+ </rule> </pre>
+ We could extend this to other countries if we are concerned that
+ premium rate
+ numbers would not only be from the host country. Here is an
+ example of a policy
+ fragment for blocking Spanish premium rate numbers that could be
+ added, along
+ with the condition combining operator (please note: there are
+ probably more
+ elegant ways of expressing this by using regular expressions):
+ <pre>
<condition combine="or">
<resource-match attr="dev-cap" match="messaging.*.send"
param:recipients="+4409*" func="glob"/> <-- to block UK premium
@@ -904,11 +919,14 @@
match="messaging.*.send" param:recipients="+34806*" func="glob"/>
<-- to block Spanish premium rate numbers -->
</condition>
- </pre></code> If the malicious widget is out in the wild already and has been
+ </pre>
+<p>If the malicious widget is out in the wild already and has been
identified, then we want to prevent it from installing and executing on devices,
- halting the spread of the malware in its early stages of distribution. </p> <p>
+ halting the spread of the malware in its early stages of
+ distribution.
+ </p> <p>
Clearly, if the widget is prevented from installing, then it cannot call a
- device API – these functions are shown as a belt and braces example:
+ device API – these functions are shown as a belt and braces example:</p>
<pre><code> <code><target></code>
<code><subject></code>
<subject-match attr="id" match="http://maliciouswidget1.example.org">
@@ -923,7 +941,6 @@
</section> <!-- premium-rate-abuse -->
</section> <!-- example policies -->
</section>
-</section>
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>
Received on Monday, 21 June 2010 12:33:33 UTC