- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 27 Jul 2007 20:46:02 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv9348
Modified Files:
ws-policy-primer.html ws-policy-primer.xml
Log Message:
Implemented the resolution for issue 4857. Editors' action 350.
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -d -r1.61 -r1.62
--- ws-policy-primer.html 27 Jul 2007 20:19:02 -0000 1.61
+++ ws-policy-primer.html 27 Jul 2007 20:45:59 -0000 1.62
@@ -448,11 +448,12 @@
two alternatives; one where the assertion A exists with @wsp:Ignorable=true and the
second where the assertion A does not exist.</p></div><div class="div2">
<h3><a name="nested-policy-expressions" id="nested-policy-expressions"></a>2.9 Nested Policy Expressions</h3><p>In the previous sections, we considered two security policy assertions. In this section,
- let us look at one of the security policy assertions in little more detail.</p><p>As you would expect, securing messages is a complex usage scenario. Company-X uses the
+ let us look at one of the security policy assertions in a little more detail.</p><p>As you would expect, securing messages is a complex usage scenario. Company-X uses the
<code>sp:TransportBinding</code> policy assertion to indicate the use of transport-level
security for protecting messages. Just indicating the use of transport-level security for
protecting messages is not sufficient. To successfully interact with Company-X’s Web
- services, the developer must know what transport token to use, what secure transport to use, what
+ services, the developer must also know what transport token to use,
+ what particular secure transport to use, what specific
algorithm suite to use for performing cryptographic operations, etc. The
<code>sp:TransportBinding</code> policy assertion can represent these dependent
behaviors. In this section, let us look at how to capture these dependent behaviors in a
@@ -501,7 +502,8 @@
and sp:RequireClientCertificate. When the HttpToken is used with an empty nested policy in a
policy expression by a provider, it will indicate that none of the dependent behaviors namely
authentication or client certificate is required. A non-anonymous client who requires authentication
- or client certificate will not be able to use this provider solely on the basis of intersection algorithm alone.
+ or client certificate will not be able to use this provider solely on the basis of
+ policy intersection algorithm alone.
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 2-14. </span> Empty Nested Assertion </i></p><div class="exampleInner"><pre><sp:TransportToken>
<wsp:Policy>
@@ -804,11 +806,13 @@
an assertion. In the XML representation, the child elements and attributes of an assertion
excluding the child elements and attributes from the WS-Policy language XML namespace name,
are the assertion parameters. For example @wsp:Optional and @wsp:Ignorable are not assertion parameters.</p><p>We considered nested policy expressions in the context of a security usage scenario. Let
- us look at its shape in the policy data model. In the normal form, a nested policy is a
- policy that has at most one policy alternative and is owned by its parent policy
- assertion. The policy alternative in a nested policy represents a collection of dependent
- behaviors or requirements or conditions that qualify the behavior of its parent policy
- assertion.</p><p>A policy-aware client supports a policy assertion if the client engages the behavior or
+ us look at its shape in the policy data model. A nested policy expression is a policy expression that is
+ a child element of an
+ assertion. In the normal form, a nested policy expression has at most one
+ policy alternative. The policy alternative in a nested policy expression
+ represents a collection of associated or dependent behaviors, requirements or
+ conditions that qualify its parent policy assertion.
+ </p><p>A policy-aware client supports a policy assertion if the client engages the behavior or
requirement or condition indicated by the assertion. A policy-aware client supports a
policy alternative if the client engages the behaviors represented by all the assertions
in the alternative. A policy-aware client supports a policy if the client engages the
@@ -1639,4 +1643,7 @@
Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/331">331</a>.
</td></tr><tr><td rowspan="1" colspan="1">20070727</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Fixed a typo in Section <a href="#compatible-policies"><b>3.4 Compatible Policies</b></a>. Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/349">349</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070727</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented the resolution for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4857">4857</a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/350">350</a>.
</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-policy-primer.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.xml,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -d -r1.66 -r1.67
--- ws-policy-primer.xml 27 Jul 2007 20:19:03 -0000 1.66
+++ ws-policy-primer.xml 27 Jul 2007 20:45:59 -0000 1.67
@@ -513,12 +513,13 @@
<div2 id="nested-policy-expressions">
<head>Nested Policy Expressions</head>
<p>In the previous sections, we considered two security policy assertions. In this section,
- let us look at one of the security policy assertions in little more detail.</p>
+ let us look at one of the security policy assertions in a little more detail.</p>
<p>As you would expect, securing messages is a complex usage scenario. Company-X uses the
<code>sp:TransportBinding</code> policy assertion to indicate the use of transport-level
security for protecting messages. Just indicating the use of transport-level security for
protecting messages is not sufficient. To successfully interact with Company-X’s Web
- services, the developer must know what transport token to use, what secure transport to use, what
+ services, the developer must also know what transport token to use,
+ what particular secure transport to use, what specific
algorithm suite to use for performing cryptographic operations, etc. The
<code>sp:TransportBinding</code> policy assertion can represent these dependent
behaviors. In this section, let us look at how to capture these dependent behaviors in a
@@ -576,7 +577,8 @@
and sp:RequireClientCertificate. When the HttpToken is used with an empty nested policy in a
policy expression by a provider, it will indicate that none of the dependent behaviors namely
authentication or client certificate is required. A non-anonymous client who requires authentication
- or client certificate will not be able to use this provider solely on the basis of intersection algorithm alone.
+ or client certificate will not be able to use this provider solely on the basis of
+ policy intersection algorithm alone.
<example>
<head> Empty Nested Assertion </head>
<eg><sp:TransportToken>
@@ -1020,11 +1022,13 @@
excluding the child elements and attributes from the WS-Policy language XML namespace name,
are the assertion parameters. For example @wsp:Optional and @wsp:Ignorable are not assertion parameters.</p>
<p>We considered nested policy expressions in the context of a security usage scenario. Let
- us look at its shape in the policy data model. In the normal form, a nested policy is a
- policy that has at most one policy alternative and is owned by its parent policy
- assertion. The policy alternative in a nested policy represents a collection of dependent
- behaviors or requirements or conditions that qualify the behavior of its parent policy
- assertion.</p>
+ us look at its shape in the policy data model. A nested policy expression is a policy expression that is
+ a child element of an
+ assertion. In the normal form, a nested policy expression has at most one
+ policy alternative. The policy alternative in a nested policy expression
+ represents a collection of associated or dependent behaviors, requirements or
+ conditions that qualify its parent policy assertion.
+ </p>
<p>A policy-aware client supports a policy assertion if the client engages the behavior or
requirement or condition indicated by the assertion. A policy-aware client supports a
policy alternative if the client engages the behaviors represented by all the assertions
@@ -2536,7 +2540,15 @@
<td>Fixed a typo in Section <specref ref="compatible-policies"/>. Editors' action
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/349">349</loc>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20070727</td>
+ <td>ASV</td>
+ <td>Implemented the resolution for issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4857">4857</loc>. Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/350">350</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Friday, 27 July 2007 20:46:10 UTC