- From: David Orchard <dorchard@bea.com>
- Date: Thu, 22 Mar 2007 16:13:03 -0700
- To: "Asir Vedamuthu" <asirveda@microsoft.com>, <public-ws-policy-eds@w3.org>
Much thanks! I changed you to the owner of these and closed them. Cheers, dave > -----Original Message----- > From: public-ws-policy-eds-request@w3.org > [mailto:public-ws-policy-eds-request@w3.org] On Behalf Of > Asir Vedamuthu via cvs-syncmail > Sent: Wednesday, March 21, 2007 9:26 PM > To: public-ws-policy-eds@w3.org > Subject: 2006/ws/policy ws-policy-primer.html,1.45,1.46 > ws-policy-primer.xml,1.43,1.44 > ws-policy-guidelines.html,1.35,1.36 ws-policy-guidelines.xml,1.46,1.47 > > > 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-po > licy-primer.html?content-type=text/html;charset=utf-8">http:// > dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.h > tml?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 > 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_Disc > laimer">liability</a>, <a > href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Tradem > arks">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-po > licy-primer.html?content-type=text/html;charset=utf-8">http:// > dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.h > tml?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-200612 > 21">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_Disc > laimer">liability</a>, <a > href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Tradem > arks">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">issu > e 4103</a> > <a > href="http://lists.w3.org/Archives/Public/public-ws-policy/200 > 7Feb/0033.html">as outlined.</a> > Editors' action <a > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/19 > 3">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">r > esolution</a> > + for <a > href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300">issu > e 4300</a>. > + Editors' action > + <a > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/19 > 0">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/200 > 7Feb/0033.html">as outlined.</loc> > Editors' action <loc > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/19 > 3">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">r > esolution</loc> > + for <loc > href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4300">issu > e 4300</loc>. > + Editors' action > + <loc > + > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/19 > 0">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-po > licy-guidelines.html?content-type=text/html;charset=utf-8">htt > p://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guid > elines.html?content-type=text/html;charset=utf-8</a></dd><dt>E > ditors:</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_Disc > laimer">liability</a>, <a > href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Tradem > arks">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-po > licy-guidelines.html?content-type=text/html;charset=utf-8">htt > p://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guid > elines.html?content-type=text/html;charset=utf-8</a></dd><dt>P > revious 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_Disc > laimer">liability</a>, <a > href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Tradem > arks">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-po > licy-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-rd > dl-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-rd > dl-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-2 > 00608.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/200 > 7Feb/0169.html">proposal</a>. > - > Editorial action <a > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/19 > 7">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/19 > 7">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/19 > 9">199 </a> > + as outlined in > + <a > href="http://lists.w3.org/Archives/Public/public-ws-policy/200 > 7Mar/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">r > esolution</a> > + for <a > href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319">issu > e 4319</a>. > + Editors' action > + <a > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/20 > 6">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">r > esolution</a> > + for <a > href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990">issu > e 3990</a>. > + Editors' action > + <a > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/21 > 0">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">r > esolution</a> > + for <a > href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212">issu > e 4212</a>. > + Editors' action > + <a > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/20 > 7">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-rd > dl-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-2 > 00608.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/200 > 7Mar/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">r > esolution</loc> > + for > <loc > href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319">issu > e 4319</loc>. > + Editors' action > + <loc > + > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/20 > 6">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">r > esolution</loc> > + for > <loc > href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990">issu > e 3990</loc>. > + Editors' action > + <loc > + > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/21 > 0">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">r > esolution</loc> > + for > <loc > href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212">issu > e 4212</loc>. > + Editors' action > + <loc > + > href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/20 > 7">207</loc>. > + </td> > + </tr> > </tbody> > </table> > </inform-div1> > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Received on Thursday, 22 March 2007 23:13:27 UTC