- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 22 Mar 2007 04:25:59 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv31786
Modified Files:
ws-policy-primer.html ws-policy-primer.xml
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Primer:
Implemented the resolution for issue 4300. Editors' action 190.
Guidelines:
Implemented the resolution for issue 4319. Editors' action 206.
Implemented the resolution for issue 4212. Editors' action 207.
Implemented the resolution for issue 3990. Editors' action 210.
WS-Policy-Scenarios-Round4
Fixed a bug in the expected outcomes for external policy attachment 4 WSDL 11 test cases. Editors’ action 219.
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -d -r1.45 -r1.46
--- ws-policy-primer.html 19 Mar 2007 17:44:46 -0000 1.45
+++ ws-policy-primer.html 22 Mar 2007 04:25:57 -0000 1.46
@@ -58,7 +58,9 @@
<h1><a name="title" id="title"></a>Web Services Policy 1.5 - Primer</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
<a href="ws-policy-primer.html">ws-policy-primer.html</a>
- </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8</a></dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © @@@@ <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematis">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
+ </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;charset=utf-8</a></dd><dt>Previous version:</dt><dd>
+ <a href="http://www.w3.org/TR/2006/WD-ws-policy-guidelines-20061221">http://www.w3.org/TR/2006/WD-ws-policy-guidelines-20061221</a>
+ </dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © @@@@ <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark/a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
<em>Web Services Policy 1.5 - Primer</em> is an introductory description of the Web Services Policy
language. This document describes the policy language features using numerous examples. The
@@ -92,10 +94,10 @@
3.8 <a href="#extensibility-and-versioning">Extensibility and Versioning</a><br>
3.8.1 <a href="#ignorable-and-versioning">Ignorable and Versioning</a><br>
3.9 <a href="#parts-of-a-policy-assertion">Parts of a Policy Assertion</a><br>
- 3.10 <a href="#versioning-policy-language">Versioning Policy Language</a><br>
- 3.10.1 <a href="#versioning-policy-framework">Policy Framework</a><br>
- 3.10.2 <a href="#versioning-policy-attachment">Policy Attachment</a><br>
-4. <a href="#conclusion">Conclusion</a><br>
+4. <a href="#versioning-policy-language">Versioning Policy Language</a><br>
+ 4.1 <a href="#versioning-policy-framework">Policy Framework</a><br>
+ 4.2 <a href="#versioning-policy-attachment">Policy Attachment</a><br>
+5. <a href="#conclusion">Conclusion</a><br>
</p>
<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>
B. <a href="#xml-namespaces">XML Namespaces</a><br>
@@ -118,7 +120,8 @@
that provides more in-depth materials for policy implementers and assertion authors. It
explains the basics of normalizing policy expressions, merging policies, determining the
compatibility (intersection) of policies, the policy data model, the policy expression and
- the extensibility points built into the Web Services Policy language.</p><p>The Web Services Policy 1.5 - Guidelines for Policy Assertion Authors
+ the extensibility points built into the Web Services Policy language.</p><p><a href="#versioning-policy-language"><b>4. Versioning Policy Language</b></a> provides examples and best practices on
+ versioning of the policy language itself, mostly intended for policy implementers.</p><p>The Web Services Policy 1.5 - Guidelines for Policy Assertion Authors
specification provides guidelines for designing policy assertions and enumerates
the minimum requirements for describing policy assertions in specifications.</p><p>This is a non-normative document and does not provide a definitive specification of the Web
Services Policy language. <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the namespaces that are used in
@@ -1123,18 +1126,18 @@
the sake of discussion, let us assume that Company-X requires the use of a SAML token issued
by a third party. Service providers, like Company-X, must convey this usage and all the
necessary information to obtain this security token for Web service developers. This is a
- key piece of metadata for a successful interaction with Company-X’s Web services.</p></div><div class="div2">
-<h3><a name="versioning-policy-language" id="versioning-policy-language"></a>3.10 Versioning Policy Language</h3><p>
+ key piece of metadata for a successful interaction with Company-X’s Web services.</p></div></div><div class="div1">
+<h2><a name="versioning-policy-language" id="versioning-policy-language"></a>4. Versioning Policy Language</h2><p>
<table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">
The WG is contemplating moving some or all of this material into a non-normative appendix of the framework or attachment document. User feedback is solicited
</td></tr></table>
</p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new or modified constructs. These constructs may be compatible or incompatible with previous versions. Some of the possible new constructs that have been mentioned previously are: new operators, operator cardinality, policy identification, compact syntax, Policy Inclusion, security, referencing, attachment points, alternative
priority, effective dating, negotiation. </p><p>WS-Policy provides extensibility points on 6 elements with a combination of attribute and/or element extensibility.
- The possible extensibility points with their current extensibility - including some outstanding issues related to extensibility - are:</p><ol class="enumar"><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>PolicyReference: any attribute and a proposal to add any element ExactlyOne, All: element from ##other namespace, no attribute extensibility</p></li><li><p>PolicyAttachment: element from ##other namespace and any attribute</p></li><li><p>AppliesTo: any element and any attribute</p></li></ol><div class="div3">
-<h4><a name="versioning-policy-framework" id="versioning-policy-framework"></a>3.10.1 Policy Framework</h4><p>WS-Policy Framework 1.5 specifies that any child element that is not known inside a Policy,
+ The possible extensibility points with their current extensibility - including some outstanding issues related to extensibility - are:</p><ol class="enumar"><li><p>Policy: element from ##other namespace and any attribute</p></li><li><p>PolicyReference: any attribute and a proposal to add any element ExactlyOne, All: element from ##other namespace, no attribute extensibility</p></li><li><p>PolicyAttachment: element from ##other namespace and any attribute</p></li><li><p>AppliesTo: any element and any attribute</p></li></ol><div class="div2">
+<h3><a name="versioning-policy-framework" id="versioning-policy-framework"></a>4.1 Policy Framework</h3><p>WS-Policy Framework 1.5 specifies that any child element that is not known inside a Policy,
ExactlyOne or All will be treated as an assertion. The default value for wsp:Optional="false".
After normalization, such an element will be inside an ExactlyOne/All operator. </p><p>Let us show an example with a hypothetical new operator that is a Choice with a minOccurs and a maxOccurs attributes, ala XSD:Choice, in a new namespace. We use the wsp16 prefix to indicate a hypothetical Policy Language 1.6 that is intended to be compatible with Policy Language 1.5:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-14. </span>Policy containing 1.5 and 1.6 Policies.</i></p><div class="exampleInner"><pre><wsp:Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-1. </span>Policy containing 1.5 and 1.6 Policies.</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
...
@@ -1144,7 +1147,7 @@
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p>The normalization rule for wsp:Optional="false" would be applied to the wsp16:Choice, yielding the following expression:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-15. </span>Normalized Policy containing 1.5 and 1.6 Policies</i></p><div class="exampleInner"><pre><wsp:Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-2. </span>Normalized Policy containing 1.5 and 1.6 Policies</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp:ExactlyOne>
<wsp:All>
@@ -1159,13 +1162,13 @@
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p>Alternatively, the wsp:Optional could be set to "true" on the choice, as
in:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-16. </span>Policy containing explicit wsp:Optional="true"</i></p><div class="exampleInner"><pre><wsp:Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-3. </span>Policy containing explicit wsp:Optional="true"</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2"
wsp:Optional="true">
...
</wsp16:Choice>
</wsp:Policy></pre></div></div><p>The normalized form will be:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-17. </span>Normalized policy</i></p><div class="exampleInner"><pre><wsp:Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-4. </span>Normalized policy</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsp16:Choice wsp16:minOccurs="1" wsp16:maxOccurs="2">
@@ -1177,7 +1180,7 @@
</wsp:Policy></pre></div></div><p>Because the wsp16:Choice alternative isn't understood in either normalized form, it will not be chosen as one of the alternatives and will effectively be ignored. Policy intersection may be more difficult with such compatible extensions. For example, the previous will "look"
like it has a wsp16:Choice typed assertion. To determine intersection with a Policy that does not have the wsp16:Choice type assertion, domain specific processing would have to be done. However, there is an alternative that does not have the wsp16:Choice, so intersection would yield the expected result.
</p><p>Note: it is possible to add new names to the existing namespace, such as: </p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-18. </span>Policy containing 1.5 and 1.6 Policies all in the 1.5 namespace</i></p><div class="exampleInner"><pre><wsp:Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-5. </span>Policy containing 1.5 and 1.6 Policies all in the 1.5 namespace</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp:ExactlyOne>
<wsp:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
@@ -1188,7 +1191,7 @@
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p>Notice that using a new namespace can result in backwards and forwards compatibility if normalization results in an optional alternative. </p><p>Best practice: insert new elements in an optional alternative or mark with wsp:Optional="true". </p><p>Incompatible versions of the Policy language may be indicated by a new namespace name for at least the new and/or incompatible elements or attributes. Imagine that the Choice operator is required by a future version of Policy, then there will be a new namespace for the Policy element. We use the wsp20 prefix to indicate a hypothetical Policy Language 2.0 that is intended to be incompatible with Policy Language
1.5:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-19. </span>Policy containing 2.0 only Policies.</i></p><div class="exampleInner"><pre><wsp20:Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-6. </span>Policy containing 2.0 only Policies.</i></p><div class="exampleInner"><pre><wsp20:Policy>
<wsp20:ExactlyOne>
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
@@ -1197,23 +1200,23 @@
</wsp20:ExactlyOne>
</wsp20:Policy> </pre></div></div><p>The new Policy operator could be embedded inside an existing Policy
element:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-20. </span>Policy containing 2.0 (incompatible with 1.5) Policies embedded in wsp 1.5 Policy.</i></p><div class="exampleInner"><pre><wsp:Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-7. </span>Policy containing 2.0 (incompatible with 1.5) Policies embedded in wsp 1.5 Policy.</i></p><div class="exampleInner"><pre><wsp:Policy>
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
</wsp20:Choice>
...
</wsp20:Policy> </pre></div></div><p>This will be treated as an Assertion for normalization and intersection computation. This will result in only one alternative that requires the wsp20:Choice, the intended behaviour for incompatible changes.</p><p>Best practice: use a new namespace for new incompatible construct and insert inside either: new Policy element OR existing All for future incompatible policy extensions.</p><p>A future version of WS-Policy could support the current operators in the existing namespace, such as:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-21. </span>Policy containing 1.5 operator in 2.0 Policy</i></p><div class="exampleInner"><pre><wsp20:Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-8. </span>Policy containing 1.5 operator in 2.0 Policy</i></p><div class="exampleInner"><pre><wsp20:Policy>
<wsp:ExactlyOne>
<wsp20:Choice wsp:minOccurs="1" wsp:maxOccurs="2">
...
</wsp20:Choice>
...
</wsp:ExactlyOne>
-</wsp20:Policy> </pre></div></div><p>It is difficult to predict whether this functionality would be useful. The future version of WS-Policy doesn't appear to be precluded from doing this.</p></div><div class="div3">
-<h4><a name="versioning-policy-attachment" id="versioning-policy-attachment"></a>3.10.2 Policy Attachment</h4><p>Policy attachment provides WSDL 1.1 and UDDI attachment points. It appears that exchange of Policy will be in the context of WSDL or UDDI.
+</wsp20:Policy> </pre></div></div><p>It is difficult to predict whether this functionality would be useful. The future version of WS-Policy doesn't appear to be precluded from doing this.</p></div><div class="div2">
+<h3><a name="versioning-policy-attachment" id="versioning-policy-attachment"></a>4.2 Policy Attachment</h3><p>Policy attachment provides WSDL 1.1 and UDDI attachment points. It appears that exchange of Policy will be in the context of WSDL or UDDI.
WRT WSDL, the policy model is an extension of the WSDL definition. As such, it is likely that future versions of Policy will be exchanged as multiple Policy expressions within a WSDL. One alternative is that there would be a separate WSDL for each version of Policy. The problem of how to specify and query for compound documents is very difficult, so it is more likely that each version of Policy will be exchanged within a WSDL. </p><p>We show an example of a new version of policy that allows QName reference to Policies in the PolicyReference:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-22. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-9. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsp:Policy>
@@ -1235,7 +1238,7 @@
<wsdl11:operation name="GetLastTradePrice" > ....
...</pre></div></div><p>The PolicyReference element is element or attribute extensible.
One example of an addition is a list of backup URIs for the PolicyReference:</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-23. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-10. </span>WSDL containing 1.5 and 2.0 (compatible with 2.0) Policy References.</i></p><div class="exampleInner"><pre><wsdl11:binding name="StockQuoteSoapBinding" type="fab:Quote" >
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsp:Policy>
@@ -1249,8 +1252,8 @@
</wsp:ExactlyOne>
</wsp:Policy>
<wsdl11:operation name="GetLastTradePrice" > ....
- ...</pre></div></div><p>The policy framework specification says that any unknown attributes are ignored. A Policy 1.5 processor will not understand the wsp16:alternateURI attribute, it will be ignored. A Policy 1.6 processor will understand the alternate URIs so it won't be ignored.</p><p>PolicyAttachment and AppliesTo also have extensibility points. We choose not to illustrate these at this time.</p></div></div></div><div class="div1">
-<h2><a name="conclusion" id="conclusion"></a>4. Conclusion</h2><p>Service providers use Web Services Policy to represent combinations of behaviors
+ ...</pre></div></div><p>The policy framework specification says that any unknown attributes are ignored. A Policy 1.5 processor will not understand the wsp16:alternateURI attribute, it will be ignored. A Policy 1.6 processor will understand the alternate URIs so it won't be ignored.</p><p>PolicyAttachment and AppliesTo also have extensibility points. We choose not to illustrate these at this time.</p></div></div><div class="div1">
+<h2><a name="conclusion" id="conclusion"></a>5. Conclusion</h2><p>Service providers use Web Services Policy to represent combinations of behaviors
(capabilities and requirements). Web service developers use policy-aware clients that
understand policy expressions and engage the behaviors represented by providers
automatically. These behaviors may include security, reliability, transaction, message
@@ -1538,4 +1541,8 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4103">issue 4103</a>
<a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0033.html">as outlined.</a>
Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/193">193</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070320</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented the <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300#c1">resolution</a>
+ for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300">issue 4300</a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/190">190</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.43
retrieving revision 1.44
diff -u -d -r1.43 -r1.44
--- ws-policy-primer.xml 22 Mar 2007 03:33:42 -0000 1.43
+++ ws-policy-primer.xml 22 Mar 2007 04:25:57 -0000 1.44
@@ -23,7 +23,7 @@
</pubdate>
<publoc>
<loc href="&w3c-designation-primer;">&w3c-designation-primer;</loc>
- </publoc> &altlocs.primer;
+ </publoc> &altlocs;
<prevlocs>
<loc href="&prevloc;">&prevloc;</loc>
</prevlocs>
@@ -107,6 +107,8 @@
explains the basics of normalizing policy expressions, merging policies, determining the
compatibility (intersection) of policies, the policy data model, the policy expression and
the extensibility points built into the Web Services Policy language.</p>
+ <p><specref ref="versioning-policy-language"/> provides examples and best practices on
+ versioning of the policy language itself, mostly intended for policy implementers.</p>
<p>The Web Services Policy 1.5 - Guidelines for Policy Assertion Authors
specification provides guidelines for designing policy assertions and enumerates
the minimum requirements for describing policy assertions in specifications.</p>
@@ -1542,7 +1544,8 @@
necessary information to obtain this security token for Web service developers. This is a
key piece of metadata for a successful interaction with Company-X’s Web services.</p>
</div2>
- <div2 id="versioning-policy-language"><head>Versioning Policy Language</head>
+ </div1>
+ <div1 id="versioning-policy-language"><head>Versioning Policy Language</head>
<p>
<ednote>
<edtext>
@@ -1561,7 +1564,7 @@
<item><p>AppliesTo: any element and any attribute</p></item>
</olist>
- <div3 id="versioning-policy-framework"><head>Policy Framework</head>
+ <div2 id="versioning-policy-framework"><head>Policy Framework</head>
<p>WS-Policy Framework 1.5 specifies that any child element that is not known inside a Policy,
ExactlyOne or All will be treated as an assertion. The default value for wsp:Optional="false".
After normalization, such an element will be inside an ExactlyOne/All operator. </p>
@@ -1682,8 +1685,8 @@
</example>
<p>It is difficult to predict whether this functionality would be useful. The future version of WS-Policy doesn't appear to be precluded from doing this.</p>
- </div3>
- <div3 id="versioning-policy-attachment"><head>Policy Attachment</head>
+ </div2>
+ <div2 id="versioning-policy-attachment"><head>Policy Attachment</head>
<p>Policy attachment provides WSDL 1.1 and UDDI attachment points. It appears that exchange of Policy will be in the context of WSDL or UDDI.
WRT WSDL, the policy model is an extension of the WSDL definition. As such, it is likely that future versions of Policy will be exchanged as multiple Policy expressions within a WSDL. One alternative is that there would be a separate WSDL for each version of Policy. The problem of how to specify and query for compound documents is very difficult, so it is more likely that each version of Policy will be exchanged within a WSDL. </p>
@@ -1736,8 +1739,7 @@
<p>The policy framework specification says that any unknown attributes are ignored. A Policy 1.5 processor will not understand the wsp16:alternateURI attribute, it will be ignored. A Policy 1.6 processor will understand the alternate URIs so it won't be ignored.</p>
<p>PolicyAttachment and AppliesTo also have extensibility points. We choose not to illustrate these at this time.</p>
- </div3>
- </div2>
+ </div2>
</div1>
<div1 id="conclusion">
@@ -2344,7 +2346,17 @@
<loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0033.html">as outlined.</loc>
Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/193">193</loc>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20070320</td>
+ <td>ASV</td>
+ <td>Implemented the <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300#c1">resolution</loc>
+ for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300">issue 4300</loc>.
+ Editors' action
+ <loc
+ href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/190">190</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -d -r1.35 -r1.36
--- ws-policy-guidelines.html 16 Mar 2007 04:14:03 -0000 1.35
+++ ws-policy-guidelines.html 22 Mar 2007 04:25:57 -0000 1.36
@@ -58,7 +58,9 @@
<h1><a name="title" id="title"></a>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
<a href="ws-policy-guidelines.html">ws-policy-guidelines.html</a>
- </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8</a></dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © @@@@ <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mthematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
+ </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8</a></dd><dt>Previous version:</dt><dd>
+ <a href="http://www.w3.org/TR/2006/WD-ws-policy-primer-20061221">http://www.w3.org/TR/2006/WD-ws-policy-primer-20061221</a>
+ </dd><dt>Editors:</dt><dd>Asir S Vedamuthu, Microsoft Corporation</dd><dd>David Orchard, BEA Systems, Inc.</dd><dd>Frederick Hirsch, Nokia</dd><dd>Maryann Hondo, IBM Corporation</dd><dd>Prasad Yendluri, webMethods, Inc.</dd><dd>Toufic Boubez, Layer 7 Technologies</dd><dd>Ümit Yalçinalp, SAP AG.</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © @@@@ <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark/a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
<em>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</em> is intended to provide guidance for assertion
authors that will work with the Web Services Policy 1.5 - Framework [<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>] and Web Services Policy 1.5 - Attachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>] specifications to create domain
@@ -71,7 +73,7 @@
no official standing.</strong></p><p></p></div><div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#introduction">Introduction</a><br>
2. <a href="#Assertions">What is an Assertion? </a><br>
-3. <a href="#d3e169">Who is involved in authoring Assertions? </a><br>
+3. <a href="#d3e173">Who is involved in authoring Assertions? </a><br>
3.1 <a href="#roles"> Roles and Responsibilities </a><br>
3.1.1 <a href="#domain-owners"> Assertion Authors</a><br>
3.1.2 <a href="#consumers">Consumers</a><br>
@@ -89,11 +91,10 @@
4.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>
4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 4.5.1 <a href="#d3e521">Optional behavior in Compact authoring</a><br>
- 4.5.2 <a href="#d3e529">Optional behavior at runtime</a><br>
- 4.6 <a href="#typing-assertions">Typing Assertions</a><br>
- 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>
- 4.8 <a href="#interrelated-domains">Interrelated domains</a><br>
+ 4.5.1 <a href="#d3e552">Optional behavior in Compact authoring</a><br>
+ 4.5.2 <a href="#d3e560">Optional behavior at runtime</a><br>
+ 4.6 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>
+ 4.7 <a href="#interrelated-domains">Interrelated domains</a><br>
5. <a href="#versioning-policy-assertions">Versioning Policy Assertions</a><br>
5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br>
5.2 <a href="#extending-assertions"> Evolution of Assertions (Versioning and Compatibility)</a><br>
@@ -217,7 +218,7 @@
best practices will be an assertion specification that describes
a contract for the consumers and providers of the capabilities and constraints of the domain.
</p></div><div class="div1">
-<h2><a name="d3e169" id="d3e169"></a>3. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
+<h2><a name="d3e173" id="d3e173"></a>3. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
express their own domain knowledge, it is necessary to provide basic
functionality that all domains could exploit and then allow
points of extension where authors of the various WS-Policy
@@ -232,8 +233,7 @@
<h3><a name="roles" id="roles"></a>3.1 Roles and Responsibilities </h3><p>Below we capture some of the characteristics of the roles
and responsibilities for the authors, consumers and providers.
</p><div class="div3">
-<h4><a name="domain-owners" id="domain-owners"></a>3.1.1 Assertion Authors</h4><p>Assertion Authors are defined
- by the WS-Policy Framework to be a community that chooses to
+<h4><a name="domain-owners" id="domain-owners"></a>3.1.1 Assertion Authors</h4><p>Assertion Authors are a community that chooses to
exploit the WS-Policy Framework by creating their own
specification to define a set of assertions that express the
capabilities and constraints of that target domain. The
@@ -249,9 +249,9 @@
Assertion Authors defining new WS-Policy assertions
must adhere to the MUST's and SHOULD's in the specification
and should review the conformance section of the specification.
- </p><p>Assertion Authors must also specify how to associate
- the assertions they have defined with the policy subjects
- identified by the WS-PolicyAttachment specification.
+ </p><p>An assertion author should also specify a policy subject. For
+ instance, if a policy assertion were to be used with WSDL, an assertion
+ description should specify a WSDL policy subject.
</p><p>An example of a domain specification that follows these practices is the WS-SecurityPolicy
specification [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]. The
WS-SecurityPolicy authors have defined their scope as follows:
@@ -298,10 +298,7 @@
and Web Services Policy 1.5 - Attachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>] specifications.
The Web Services Policy 1.5 - Attachment specification has defined a set of
subjects and an extensible mechanism for attaching policies
- to web services subjects. When a web service provider
- chooses to make its capabilities and constraints available,
- the provider may also need to conform to requirements of other policy
- assertion specifications it utilizes ( i.e., WS-SecurityPolicy).
+ to web services subjects.
</p><p>When deploying services with policies it is useful for providers to anticipate how
to evolve their services capabilities over time. If
forward compatibility is a concern in order to accommodate
@@ -337,7 +334,7 @@
</p><p>
The WS-Policy Attachment specification defines a number of different
policy subjects to which an assertion can be attached. For attaching to
- WSDL subjects see <a href="#levels-of-abstraction"><b>4.7 Levels of Abstraction in WSDL </b></a> for more detail.
+ WSDL subjects see <a href="#levels-of-abstraction"><b>4.6 Levels of Abstraction in WSDL </b></a> for more detail.
Additionally, the framework provides for the means to extend the set of
policy subjects beyond the set of subjects defined in the WS-Policy
Attachment specification.
@@ -485,7 +482,7 @@
</p><p>Best practice: Use a unique QName to identify the behavior and provide an XML outline
(plus an XML schema document) to specify the syntax of an assertion.
</p></div><div class="div3">
-<h4><a name="self-describing" id="self-describing"></a>4.3.3 Self Describing Messages </h4><p> WS-Policy is intended to communicate the requirements, capabilities, preferences and
+<h4><a name="self-describing" id="self-describing"></a>4.3.3 Self Describing Messages </h4><p> WS-Policy is intended to communicate the requirements, capabilities and
behaviors of nodes that provide the message's path, not specifically to declare properties of the message semantics. One
of the advantages of Web services is that an XML message can be stored and later examined (e.g. as a record of a business
transaction) or interpreted by an intermediary; however, if information that is necessary to understand a message is not
@@ -642,7 +639,34 @@
dependent behaviors automatically. This means the complexity of
security usage is absorbed by a policy-aware client and hidden
from Web service application developers.
- </p></div><div class="div3">
+ </p><p>Assertion authors should note the effect of nested policy expressions
+ on policy intersection in their nested policy design. The result of
+ intersecting an assertion that contains an empty nested policy
+ expression with an assertion of the same type without a nested policy
+ expression is that the assertions are not compatible. Therefore, when
+ providers require dependent behaviors these behaviors should be
+ explicitly specified as assertions in a nested policy expression. When
+ the definition of an assertion allows for nested dependent behaviors,
+ but the use of the assertion only contains an empty nested policy
+ expression, this specific use indicates the specification of no nested
+ dependent behaviors. This use must not be interpreted as being
+ compatible with "any" of the nested dependent behaviors that are
+ allowed by the assertion, unless otherwise specified by the assertion
+ definition.</p><p>As an example, WS-Security Policy defines <code>sp:HttpToken</code> assertion to
+ contain three possible nested elements, <code>sp:HttpBasicAuthentication</code>,
+ <code>sp:HttpDigestAuthentication</code> and <code>sp:RequireClientCertificate</code>. When the
+ <code>HttpToken</code> 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.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 4-5. </span>Empty Nested Policy Expression</i></p><div class="exampleInner"><pre><sp:TransportToken>
+ <wsp:Policy>
+ <sp:HttpsToken>
+ <wsp:Policy/>
+ </sp:HttpsToken>
+ </wsp:Policy>
+</sp:TransportToken></pre></div></div><p>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.</p></div><div class="div3">
<h4><a name="which-one-to-use" id="which-one-to-use"></a>4.4.3 Considerations for choosing parameters vs nesting</h4><p>The main consideration for selecting parameters or nesting
of assertions is that <em>the framework intersection
algorithm processes nested alternatives, but does not consider
@@ -668,12 +692,12 @@
avoided when they are not needed.</p><p>Best practice: If the assertion
authors want to delegate the processing to the framework,
utilizing nesting should be considered. Otherwise, domain
- specific comparison algorithms will need to be devised and be
+ specific comparison algorithms may need to be devised and be
delegated to the specific domain handlers that are not visible
to the WS-Policy framework.
</p></div></div><div class="div2">
<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>4.5 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e521" id="d3e521"></a>4.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
+<h4><a name="d3e552" id="d3e552"></a>4.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
compact authoring form for assertions, behaviors are marked by
using <code>wsp:Optional</code> attribute that has a value,
"true". During the process of normalization, the runtime
@@ -684,7 +708,7 @@
runtime behavior. In order to simplify reference to such
assertions, we just use the term optional assertions in this section.
</p></div><div class="div3">
-<h4><a name="d3e529" id="d3e529"></a>4.5.2 Optional behavior at runtime</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
+<h4><a name="d3e560" id="d3e560"></a>4.5.2 Optional behavior at runtime</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
example that proposes the use of <cite><a href="#MTOM">MTOM</a></cite> as an
optional behavior that can be engaged by a consumer. The
primer proposes that an assertion that identifies the use of
@@ -762,46 +786,7 @@
engaged when they are designing their assertion, whether by
specific headers or some other means. See also <a href="#self-describing"><b>4.3.3 Self Describing Messages </b></a>.
</p></div></div><div class="div2">
-<h3><a name="typing-assertions" id="typing-assertions"></a>4.6 Typing Assertions</h3><p>Since a <em>QName</em> is the central mechanism for
- identifying a policy assertion, Assertion Authors should be
- aware of the possible evolution of their assertions and how
- this would impact the semantics of the assertion overtime. A namespace
- associated with the assertion may be used to indicate a
- specific version of an assertion but this has its limitations.
- See section <a href="#versioning-policy-assertions"><b>5. Versioning Policy Assertions</b></a> for more detail.
- </p><p>The typing must be done in combination with the scoping
- of the semantics to a policy subject. WS-PolicyAttachment provides a means of associating an
- assertion with arbitrary subjects, regardless of their
- nature. This flexibility can lead to ambiguity in the
- interpretation of policy; for example, if one attaches an
- assertion with the semantic "must be encrypted" to a SOAP
- endpoint, it's unclear what must be encrypted.
- </p><p> One way to disambiguate the semantic is to generally determine
- if an assertion is specific to a policy attachment
- mechanism. An example could be identifying whether the
- assertion expressed is associated with behaviors
- (endpoints) or artifacts (messages) and then constraining
- the use of an assertion to one of these subjects.
- </p><p>Thus our example encryption assertion would have a
- subject of "message", and could only be attached to
- messages, where the assertion is valid. However, Assertion Authors
- need to be aware that <em>policy attachment subjects are
- not limited to the subjects defined in WSDL</em>. The
- external attachment model in WS-PolicyAttachment allows for
- the definition of other domain expressions to be policy
- subjects. More of this topic is covered in the <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
- </p><p>Best Practice- To avoid confusion, assertion definitions should be
- precise about their semantics and include information that
- restricts their set of permissible policy subjects
- appropriately and indicates which QNames are associated with
- which subjects.</p><ol class="enumar"><li><p>Description must clearly and completely specify the syntax (plus an XML Schema
- document) and semantics of a policy assertion.</p></li><li><p>If there is a nested policy expression, description must declare it and enumerate the
- nested policy assertions that are allowed. </p></li><li><p>A policy alternative may contain multiple instances of the same policy assertion.
- Description must specify the semantics of parameters and nested policy (if any) when
- there are multiple instances of a policy assertion in the same policy alternative.
- </p></li><li><p>If a policy assertion is to be used with WSDL, description must specify a WSDL policy
- subject – such as service, endpoint, operation and message.</p></li></ol></div><div class="div2">
-<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>4.7 Levels of Abstraction in WSDL </h3><p>A behavior identified by a policy assertion applies to the
+<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>4.6 Levels of Abstraction in WSDL </h3><p>A behavior identified by a policy assertion applies to the
associated policy subject. If a policy assertion is to be used
within WSDL, Assertion Authors must specify a WSDL
policy subject. The policy subject is determined with respect
@@ -871,7 +856,7 @@
policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not apply.
</p></div><div class="div2">
-<h3><a name="interrelated-domains" id="interrelated-domains"></a>4.8 Interrelated domains</h3><p>Assertion authors need to be clear about how assertions defined in
+<h3><a name="interrelated-domains" id="interrelated-domains"></a>4.7 Interrelated domains</h3><p>Assertion authors need to be clear about how assertions defined in
their domain may fit with assertions for interrelated domains. A
classic example of such an interrelated domain is security, because
security tends to
@@ -947,10 +932,7 @@
<h3><a name="context-free-policies" id="context-free-policies"></a>6.1 Appropriate Attachment: Preserving Context-Free Policies</h3><p>Policy attachment should not affect the interpretation of
Policy alternatives. If it did, each policy assertion would
need to be written with different (and possibly unknown)
- attachment mechanisms in mind. In particular, the timing of a
- policy attachment or the role that a party who attaches
- policy should have no bearing on the evaluation of the policy
- assertion </p></div><div class="div2">
+ attachment mechanisms in mind. </p></div><div class="div2">
<h3><a name="appropriate-attachment-assertion-subjects" id="appropriate-attachment-assertion-subjects"></a>6.2 Appropriate Attachment: Identifying Assertion Subjects</h3><p>Each policy attachment mechanism should unambiguously
identify the subject of the attached assertions. Generally,
this should be a specific SOAP node or a specific message
@@ -1157,8 +1139,9 @@
assertion represents but they need to consider how new assertions
will be intersected and merged with other assertions in the
calculation of an effective policy and this also indicates they need
- to consider policy subjects.</p><p>The policy framework only defines an algorithm for calculating
- effective policies for WSDL 1.1 based subjects. </p></div></div><div class="back"><div class="div1">
+ to consider policy subjects.</p><p> The WS-Policy 1.5 - Attachment specification defines algorithms for calculating the
+ effective policy for a given policy subject and effective policies for
+ WSDL 1.1, WSDL 2.0 and UDDI policy subjects.</p></div></div><div class="back"><div class="div1">
<h2><a name="security-considerations" id="security-considerations"></a>A. Security Considerations</h2><p> Security considerations are discussed in the <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> document.</p></div><div class="div1">
<h2><a name="xml-namespaces" id="xml-namespaces"></a>B. XML Namespaces</h2><p>The table below lists XML Namespaces that are used in this document. The choice of any
namespace prefix is arbitrary and not semantically significant.</p><a name="nsprefix"></a><table summary="Prefixes and XML Namespaces used in this specification" border="1" cellspacing="0" cellpadding="5"><caption>Table B-1. Prefixes and XML Namespaces used in this specification.</caption><thead><tr><th rowspan="1" colspan="1">Prefix</th><th rowspan="1" colspan="1">XML Namespace</th><th rowspan="1" colspan="1">Specifications</th></tr></thead><tbody><tr><td rowspan="1" colspan="1">
@@ -1242,14 +1225,14 @@
http://www.w3.org/TR/ws-policy-attach/. </dd><dt class="label"><a name="WS-Policy-Primer"></a>[Web Services Policy Primer] </dt><dd>
<cite><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;%20charset=utf-8">Web Services Policy 1.5 - Primer</a></cite>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, Draft. </dd><dt class="label"><a name="WS-RM"></a>[Web Services Reliable Messaging] </dt><dd>
- <cite><a href="http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html">Web Services Reliable Messaging (WS-ReliableMessaging)</a></cite>, Doug Davis (IBM), Anish Karmarkar (Oracle),
- Gilbert Pilz (BEA), Steve Winkler (SAP), Ü. Yalçinalp
- (SAP), August 7th, 2006, available at:
+ <cite><a href="http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html">Web Services Reliable Messaging (WS-ReliableMessaging)</a></cite>, D. Davis, A. Karmarkar
+ G. Pilz, S. Winkler, Ü. Yalçinalp, Editors. Organization for the Advancement of
+ Structured Information Standards, August 7th, 2006, available at:
http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html
</dd><dt class="label"><a name="WS-RM-Policy"></a>[Web Services Reliable Messaging Policy] </dt><dd>
- <cite><a href="http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html">Web Services Reliable Messaging Policy Assertion v1.1</a></cite>, Doug Davis (IBM), Anish Karmarkar (Oracle),
- Gilbert Pilz (BEA), Steve Winkler (SAP), Ü. Yalçinalp
- (SAP), August 4, 2006, available at:
+ <cite><a href="http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html">Web Services Reliable Messaging Policy Assertion v1.1</a></cite>, D. Davis,
+ A. Karmarkar, G. Pilz, S. Winkler, Ü. Yalçinalp, Editors. Organization for the Advancement of
+ Structured Information Standards, August 4, 2006, available at:
http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html
</dd><dt class="label"><a name="WS-Security2004"></a>[WS-Security 2004] </dt><dd>
<cite><a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">Web Services Security: SOAP Message Security
@@ -1388,4 +1371,22 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4035">4035</a>
as outlined in
<a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0169.html">proposal</a>.
- Editorial action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/197">197</a>. </td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+ Editorial action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/197">197</a>. </td></tr><tr><td rowspan="1" colspan="1">20070319</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1"> Implemented resolution for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4073">4073</a>
+ in response to editor's action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/199">199 </a>
+ as outlined in
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0093.html">proposal </a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070320</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented the <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319#c1">resolution</a>
+ for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319">issue 4319</a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/206">206</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070320</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented the <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990#c1">resolution</a>
+ for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990">issue 3990</a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/210">210</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070320</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented the <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212#c1">resolution</a>
+ for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212">issue 4212</a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/207">207</a>.
+ </td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -d -r1.46 -r1.47
--- ws-policy-guidelines.xml 22 Mar 2007 03:33:41 -0000 1.46
+++ ws-policy-guidelines.xml 22 Mar 2007 04:25:57 -0000 1.47
@@ -22,7 +22,7 @@
</pubdate>
<publoc>
<loc href="&w3c-designation-guidelines;">&w3c-designation-guidelines;</loc>
- </publoc> &altlocs.guidelines;
+ </publoc> &altlocs;
<prevlocs>
<loc href="&prevloc;">&prevloc;</loc>
</prevlocs>
@@ -821,6 +821,44 @@
security usage is absorbed by a policy-aware client and hidden
from Web service application developers.
</p>
+
+ <p>Assertion authors should note the effect of nested policy expressions
+ on policy intersection in their nested policy design. The result of
+ intersecting an assertion that contains an empty nested policy
+ expression with an assertion of the same type without a nested policy
+ expression is that the assertions are not compatible. Therefore, when
+ providers require dependent behaviors these behaviors should be
+ explicitly specified as assertions in a nested policy expression. When
+ the definition of an assertion allows for nested dependent behaviors,
+ but the use of the assertion only contains an empty nested policy
+ expression, this specific use indicates the specification of no nested
+ dependent behaviors. This use must not be interpreted as being
+ compatible with "any" of the nested dependent behaviors that are
+ allowed by the assertion, unless otherwise specified by the assertion
+ definition.</p>
+
+ <p>As an example, WS-Security Policy defines <code>sp:HttpToken</code> assertion to
+ contain three possible nested elements, <code>sp:HttpBasicAuthentication</code>,
+ <code>sp:HttpDigestAuthentication</code> and <code>sp:RequireClientCertificate</code>. When the
+ <code>HttpToken</code> 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.</p>
+
+ <example>
+ <head>Empty Nested Policy Expression</head>
+ <eg xml:space="preserve"><sp:TransportToken>
+ <wsp:Policy>
+ <sp:HttpsToken>
+ <wsp:Policy/>
+ </sp:HttpsToken>
+ </wsp:Policy>
+</sp:TransportToken></eg>
+ </example>
+
+ <p>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.</p>
+
</div3>
<div3 id="which-one-to-use">
@@ -990,66 +1028,7 @@
</p>
</div3>
</div2>
- <div2 id="typing-assertions">
- <head>Typing Assertions</head>
- <p>Since a <emph>QName</emph> is the central mechanism for
- identifying a policy assertion, Assertion Authors should be
- aware of the possible evolution of their assertions and how
- this would impact the semantics of the assertion overtime. A namespace
- associated with the assertion may be used to indicate a
- specific version of an assertion but this has its limitations.
- See section <specref ref="versioning-policy-assertions"/> for more detail.
- </p>
- <p>The typing must be done in combination with the scoping
- of the semantics to a policy subject. WS-PolicyAttachment provides a means of associating an
- assertion with arbitrary subjects, regardless of their
- nature. This flexibility can lead to ambiguity in the
- interpretation of policy; for example, if one attaches an
- assertion with the semantic "must be encrypted" to a SOAP
- endpoint, it's unclear what must be encrypted.
- </p>
- <p> One way to disambiguate the semantic is to generally determine
- if an assertion is specific to a policy attachment
- mechanism. An example could be identifying whether the
- assertion expressed is associated with behaviors
- (endpoints) or artifacts (messages) and then constraining
- the use of an assertion to one of these subjects.
- </p>
- <p>Thus our example encryption assertion would have a
- subject of "message", and could only be attached to
- messages, where the assertion is valid. However, Assertion Authors
- need to be aware that <emph>policy attachment subjects are
- not limited to the subjects defined in WSDL</emph>. The
- external attachment model in WS-PolicyAttachment allows for
- the definition of other domain expressions to be policy
- subjects. More of this topic is covered in the <bibref ref="WS-Policy-Primer"/>
- </p>
- <p>Best Practice- To avoid confusion, assertion definitions should be
- precise about their semantics and include information that
- restricts their set of permissible policy subjects
- appropriately and indicates which QNames are associated with
- which subjects.</p>
- <olist>
- <item>
- <p>Description must clearly and completely specify the syntax (plus an XML Schema
- document) and semantics of a policy assertion.</p>
- </item>
- <item>
- <p>If there is a nested policy expression, description must declare it and enumerate the
- nested policy assertions that are allowed. </p>
- </item>
- <item>
- <p>A policy alternative may contain multiple instances of the same policy assertion.
- Description must specify the semantics of parameters and nested policy (if any) when
- there are multiple instances of a policy assertion in the same policy alternative.
- </p>
- </item>
- <item>
- <p>If a policy assertion is to be used with WSDL, description must specify a WSDL policy
- subject – such as service, endpoint, operation and message.</p>
- </item>
- </olist>
- </div2>
+
<div2 id="levels-of-abstraction">
<head>Levels of Abstraction in WSDL </head>
@@ -1717,15 +1696,15 @@
<titleref>&primer.title;</titleref>, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo,
P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, Draft. </bibl>
<bibl id="WS-RM" key="Web Services Reliable Messaging" href="http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html">
- <titleref>Web Services Reliable Messaging (WS-ReliableMessaging)</titleref>, Doug Davis (IBM), Anish Karmarkar (Oracle),
- Gilbert Pilz (BEA), Steve Winkler (SAP), Ü. Yalçinalp
- (SAP), August 7th, 2006, available at:
+ <titleref>Web Services Reliable Messaging (WS-ReliableMessaging)</titleref>, D. Davis, A. Karmarkar
+ G. Pilz, S. Winkler, Ü. Yalçinalp, Editors. Organization for the Advancement of
+ Structured Information Standards, August 7th, 2006, available at:
http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html
</bibl>
<bibl id="WS-RM-Policy" key="Web Services Reliable Messaging Policy" href="http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html">
- <titleref>Web Services Reliable Messaging Policy Assertion v1.1</titleref>, Doug Davis (IBM), Anish Karmarkar (Oracle),
- Gilbert Pilz (BEA), Steve Winkler (SAP), Ü. Yalçinalp
- (SAP), August 4, 2006, available at:
+ <titleref>Web Services Reliable Messaging Policy Assertion v1.1</titleref>, D. Davis,
+ A. Karmarkar, G. Pilz, S. Winkler, Ü. Yalçinalp, Editors. Organization for the Advancement of
+ Structured Information Standards, August 4, 2006, available at:
http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html
</bibl>
<bibl id="WS-Security2004" key="WS-Security 2004" href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">
@@ -2067,7 +2046,37 @@
as outlined in
<loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0093.html">proposal </loc>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20070320</td>
+ <td>ASV</td>
+ <td>Implemented the <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319#c1">resolution</loc>
+ for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319">issue 4319</loc>.
+ Editors' action
+ <loc
+ href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/206">206</loc>.
+ </td>
+ </tr>
+ <tr>
+ <td>20070320</td>
+ <td>ASV</td>
+ <td>Implemented the <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990#c1">resolution</loc>
+ for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990">issue 3990</loc>.
+ Editors' action
+ <loc
+ href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/210">210</loc>.
+ </td>
+ </tr>
+ <tr>
+ <td>20070320</td>
+ <td>ASV</td>
+ <td>Implemented the <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212#c1">resolution</loc>
+ for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212">issue 4212</loc>.
+ Editors' action
+ <loc
+ href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/207">207</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Thursday, 22 March 2007 13:08:02 UTC