- From: Umit Yalsinap via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 31 Oct 2006 04:04:58 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv17256
Modified Files:
ws-policy-guidelines.html
Log Message:
Fixes based on PC's feedback on Oct 20th
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- ws-policy-guidelines.html 19 Oct 2006 23:53:35 -0000 1.4
+++ ws-policy-guidelines.html 31 Oct 2006 04:04:56 -0000 1.5
@@ -54,17 +54,16 @@
<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>Maryann Hondo, IBM Corporation</dd><dd>Umit Yalcinalp, 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://wwww3.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">Abstract</a></h2><p>
- <em>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</em> is a
- guideline for assertion authors that will work with the
- Web Services Policy 1.5 - Framework and Web Services Policy 1.5 - Attachment specifications to
- create domain specific assertions. The focus of this document
- is to provide best practices and patterns to follow as well as
- illustrate the care needed in using WS-Policy to achieve the
- best possible results for interoperability. It is a
- complementary guide to using the specifications. </p></div><div>
+ <em>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</em> is a guideline 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
+ specific assertions. The focus of this document is to provide
+ best practices and patterns to follow as well as illustrate
+ the care needed in using WS-Policy to achieve the best
+ possible results for interoperability. It is a complementary
+ guide to using the specifications. </p></div><div>
<h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
no official standing.</strong></p><p></p></div><hr><div class="toc">
-<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">Basic Concepts: What is an Assertion</a><br> 2.1 <a href="#assertion-roles">Roles and Responsibilities in Utilizing Policy Assertions</a><br> 2.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br> 2.1.2 <a href="#consumers">Consumers</a><br> 2.1.3 <a href="#providers">Providers</a><br>3. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br> 3.1 <a href="#assertion-target">Assertions and Their Target Use</a><br>4. <a href="#compact-full">Authoring Styles </a><br>5. <a href="#modeling-guidelines">Guidelines for Modeling New Assertions</a><br> 5.1 <a href="#new-domains">New Policy Domains</a><br> 5.2 <a href="single-domains">Single Domains</a><br> 5.3 <a href="#nested-assertions">Nested Assertions</a><br> 5.4 <a href="#parametrized-assertions">Assertions with Parameters</a><br> 5.5 <a href="#comparison">Comparison of Nested and Parametrized Assertions</a><br> 5.6 <a href="#self-describing"> Self Describing Messages </a><br> 5.7 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br> 5.8 <a href="#considerations-for-intersection"> Considerations for Intersection and Merging </a><br> 5.9 <a href="#typing-assertions">Typing Assertions</a><br> 5.10 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br> 5.11 <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.11.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressios</a><br> 5.11.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br> 5.11.3 <a href="#assertion-evolution">Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#inter-policy">Inter-domain Policy and Composition Issues</a><br>7. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a><br> 7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 7.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction between Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenerio">Scenario and a orked example</a><br></p>
+<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">Basic Concepts: What is an Assertion</a><br> 2.1 <a href="#assertion-roles">Roles and Responsibilities in Utilizing Policy Assertions</a><br> 2.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br> 2.1.2 <a href="#consumers">Consumers</a><br> 2.1.3 <a href="#providers">Providers</a><br>3. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br> 3.1 <a href="#assertion-target">Assertions and Their Target Use</a><br>4. <a href="#compact-full">Authoring Styles </a><br>5. <a href="#modeling-guidelines">Guidelines for Modeling New Assertions</a><br> 5.1 <a href="#new-domains">New Policy Domains</a><br> 5.2 <a href="single-domains">Single Domains</a><br> 5.3 <a href="#nested-assertions">Nested Assertions</a><br> 5.4 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 5.5 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 5.6 <a href="#self-describing"> Self Describing Messages </a><br> 5.7 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br> 5.8 <a href="#considerations-for-intersection"> Considerations for Intersection and Merging </a><br> 5.9 <a href="#typing-assertions">Typing Assertions</a><br> 5.10 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br> 5.11 <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.11.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressons</a><br> 5.11.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br> 5.11.3 <a href="#assertion-evolution">Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#inter-policy">Inter-domain Policy and Composition Issues</a><br>7. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a><br> 7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 7.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction between Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenerio">Scenario and worked example</a><br></p>
<h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>B. <a href="#xml-namespaces">XML Namespaces</a><br>C. <a href="#references">References</a><br>D. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>E. <a href="#change-description">Changes in this Version of
the Document</a> (Non-Normative)<br>F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</a> (Non-Normative)<br></p></div><hr><div class="body"><div class="div1">
<h2><a name="introduction"></a>1. Introduction</h2><p>WS-Policy specification defines a policy to be a collection
@@ -73,20 +72,21 @@
is a resource primarily for assertion authors that provides
guidelines on the use of Web Services Policy 1.5 - Framework and
Web Services Policy 1.5 - Attachment specifications to create and use domain specific
- assertions to enable interoperability.</p><p>WS-Policy Assertions are xml expressions that communicate the
- requirements and capabilities of a web service by adhering to
- the specification, WS-PolicyFramework. It was recognized that in
- order to enable interoperability of web services, different sets
- of WS-Policy Assertions needed to be defined by different
- communities based upon the requirements of the web service.
- </p><p>Some policy assertions specify traditional requirements and
- capabilities that will ultimately manifest on the wire (e.g.,
- authentication scheme, transport protocol selection). Other
- policy assertions have no wire manifestation yet are critical to
- proper service selection and usage (e.g., privacy policy, QoS
- characteristics). WS-Policy provides a single policy grammar to
- allow both kinds of assertions to be reasoned about in a
- consistent manner.
+ assertions to enable interoperability.</p><p>WS-Policy Assertions are XML expressions
+ that communicate the requirements and capabilities of a web
+ service by adhering to the specification, WS-Policy Framework. It
+ was recognized that in order to enable interoperability of web
+ services, different sets of WS-Policy Assertions needed to be
+ defined by different communities based upon the requirements of
+ the web service.
+ </p><p>Some policy assertions specify traditional
+ requirements and capabilities that will ultimately manifest on
+ the wire (e.g., authentication scheme, transport protocol
+ selection). Other policy assertions have no wire manifestation
+ yet are critical to proper service selection and usage (e.g.,
+ privacy policy, QoS characteristics). WS-Policy provides a
+ single policy grammar to allow both kinds of assertions to be
+ reasoned about in a consistent manner.
</p><p>The focus of these guidelines is to capture best practices
and usage patterns for practitioners to follow. It is a
complementary guide to the Framework and Attachments
@@ -104,11 +104,12 @@
how to use the assertions authored by policy assertion
authors
</p></li></ul><p>This document assumes a basic understanding of XML 1.0,
- Namespaces in XML, WSDL 1.1 and SOAP.</p><p>This is a non-normative document and does not provide a
- definitive specification of the Web Services Policy
- framework. <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the that
- are used in this document. (XML elements without a namespace
- prefix are from the Web Services Policy XML Namespace.)</p></div><div class="div1">
+ Namespaces in XML, WSDL 1.1 and SOAP.</p><p>This is a non-normative document and does
+ not provide a definitive specification of the Web Services
+ Policy framework. <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all
+ the namespace prefixes that are used in this document. (XML
+ elements without a namespace prefix are from the Web Services
+ Policy XML Namespace.)</p></div><div class="div1">
<h2><a name="Assertions"></a>2. Basic Concepts: What is an Assertion</h2><p>An assertion is a piece of metadata that describes a
capability of a specific WS-Policy domain. Sets of assertions
are typically defined in a dedicated specification that describe
@@ -165,10 +166,10 @@
and should review the conformance section of the
specification. </p><p>WS-Policy Domain 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 example of a domain specificatin that includes these properties
- can be seen in the WS-SecurityPolicy
- specification. The WS-Security authors have defined their
- scope as follows: </p><p>
+ identified by the WS-PolicyAttachment specification</p><p>An example of a domain specification that
+ includes these properties can be seen in the WS-SecurityPolicy
+ specification [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]. The
+ WS-SecurityPolicy authors have defined their scope as follows:</p><p>
<em>"This document [WS-SecurityPolicy] defines a set of
security policy assertions for use with the WS-Policy
framework with respect to security features provided in WSS:
@@ -185,14 +186,16 @@
engage in a secure exchange of messages." </em>
</p><p>An example of scoping individual assertions to policy subjects is also provided by the WS-Security
Policy specification in Appendix A.</p></div><div class="div3">
-<h4><a name="consumers"></a>2.1.2 Consumers</h4><p>A consumer of WS-Policy Assertions can be any entity that is
- capable of parsing a WS-Policy xml element, and selecting one
- alternative from the policy, that it then uses to govern the
- creation of a message to send to the subject to which the policy alternative
- was attached. The WS-Policy Attachment
- specification defines a set of attachment models for use with
- common web service subjects: WSDL definitions, UDDI directory
- entries, and WS-Addressing endpoints.
+<h4><a name="consumers"></a>2.1.2 Consumers</h4><p>A consumer of WS-Policy
+ Assertions can be any entity that is capable of parsing a
+ WS-Policy xml element, and selecting one alternative from the
+ policy, that it then uses to govern the creation of a message
+ to send to the subject to which the policy alternative was
+ attached. The WS-Policy Attachment specification defines a
+ set of attachment models for use with common web service
+ subjects: WSDL definitions [<cite><a href="#WSDL11">WSDL 1.1</a></cite>, <cite><a href="#WSDL20">WSDL 2.0 Core Language</a></cite>], UDDI directory entries [<cite><a href="#UDDIAPI20">UDDI API 2.0</a></cite>, <cite><a href="#UDDIDataStructure20">UDDI Data Structure 2.0</a></cite>,
+ <cite><a href="#UDDI30">UDDI 3.0</a></cite>], and WS-Addressing Endpoint
+ References (EPR) [<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>].
</p><p>
In the degenerate case, a human could read the xml and
determine if a message could be constructed conformant to the
@@ -204,25 +207,26 @@
expressed in a WS-Policy document and modifying their own
configurations dynamically.
</p></div><div class="div3">
-<h4><a name="providers"></a>2.1.3 Providers</h4><p>A provider of WS-Policy Assertions can be any web service
- implementation that can reflect its on the wire message
- behavior as an XML expression that conforms to the
- WS-PolicyFramework and WS-PolicyAssertions
- specifications. The WS-PolicyAttachment 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, it may also need to conform to
- requirements of other policy specifications it utilizes (
- i.e., WS-SecurityPolicy).
- </p><p>Whe deploying services with policies it is uesful for providers to anticipate how
- to evolve their services capabilities over time. If forward
- compatibility is a concern in order to accommodate
+<h4><a name="providers"></a>2.1.3 Providers</h4><p>A provider of WS-Policy
+ Assertions can be any web service implementation that can
+ reflect it's on the wire message behavior as an XML
+ expression that conforms to the WS-PolicyFramework and
+ WS-Policy Attachment specifications. The
+ WS-PolicyAttachment 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,
+ it may also need to conform to requirements of other policy
+ specifications it utilizes ( i.e., WS-SecurityPolicy).
+ </p><p>When deploying services
+ with policies it is uesful for providers to anticipate how
+ to evolve their services capabilities over time. If
+ forward compatibility is a concern in order to accommodate
compatibility with different and potentially new clients,
providers should refer to <a href="#lifecycle"><b>5.11 Lifecycle of Assertions</b></a> and
<cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> that describes service and
policy assertion evolution.
- </p></div></div></div><div class="div1">
+ </p></div></div></div><div class="div1">
<h2><a name="general-guidelines"></a>3. General Guidelines for WS-Policy Assertion Authors</h2><div class="div2">
<h3><a name="assertion-target"></a>3.1 Assertions and Their Target Use</h3><p>WS-Policy authors need to have some definition of what the goal is for the assertions
they author. WS-Policy authors should also understand the
@@ -247,17 +251,20 @@
stand alone client applications to "active" web service
requestors that are capable of modifying their own configurations
dynamically.
- </p><p> Once the range of policy subjects are identified, there are choices for ways of attaching
- multiple instances of a simple policy assertion to multiple subjects. One way is to
- utilize the referencing mechanism that is present in the
- framework. By defining the assertion once and using it in
- different policies (e.g. with different alternatives) via
- reference, a policy assertion may be associated with
- different alternatives and subjects. A referencing
- mechanism is very useful in a tooling environment or when
- creating a domain specific attachment in multiple WSDL
- files, EPRs, in which the same set of policies are expected
- to be applied.
+ </p><p> Once the range of policy subjects
+ are identified, there are choices for ways of
+ attaching multiple instances of a simple policy
+ assertion to multiple subjects. One way is to utilize
+ the referencing mechanism that is present in the
+ framework. By defining the assertion once and using it
+ in different policies (e.g. with different
+ alternatives) via reference, a policy assertion may be
+ associated with different alternatives and subjects. A
+ referencing mechanism is very useful in a tooling
+ environment; when creating a domain specific
+ attachment in multiple WSDL files or Endpoint
+ References in which the same set of policies are
+ expected to be applied.
</p><p>In summary, WS-Policy domain authors should consider the following
factors when composing the set of domain assertions as it
may make sense to factor out some assertions that can be
@@ -352,7 +359,7 @@
in a policy, the normal form may express the choices more explicitly.
On the other hand, the compact form is more
readable for humans when an assertion is marked as optional
- using the <code>@optional</code>attribute as our example
+ using the <code>@optional</code> attribute as our example
illustrates above.
</p></div><div class="div1">
<h2><a name="modeling-guidelines"></a>5. Guidelines for Modeling New Assertions</h2><div class="div2">
@@ -379,54 +386,56 @@
assertions to define. Interoperability testing of new policy
domains is recommended to ensure that consumers and providers
are able to use the new domain assertions.
- </p><p>New aurthors are encouraged to look at <cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite> to see an example of a
- relatively simple domain that has defined 3 assertions. Domain
- authors are encouraged to look at <cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite> to see an example of a complex
+ </p><p>New authors are encouraged to look
+ at <cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite> to see an example of a
+ relatively simple domain that has defined 3
+ assertions. Domain authors are encouraged to look at <cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite> to see an example of a complex
domain that has been decomposed into a set of policy
expressions.
</p></div><div class="div2">
-<h3><a name="single-domains"></a>5.2 Single Domains</h3><p>When considering the creation of a new domain of policy
- assertions, it is important to identify whether or not the domain is self containted
- or at least if a subset of the domain can be well defined. A domain
- that expresses a broad set of capabilities will also need to have
- community supportin implementation to provide value to the consumers.
- Ultimately it is the consumers and providers that will
- determine whether a particular set of assertions correctly
- characterize a domain. A new community should avoid duplicating
- assertions that have already been defined as this will create
- ambiguity not clarification. New WS-Policy authors should focus on creating assertions
- for those specific constraints and capabilities that do not
- overlap with other domains but that communicate new
- functionality. </p><p>The model advocated for new assertion development is a cooperative marketplace
- [some might say its an "opt-in" model]. The
- providers of services need to find value in the set of
- assertions or
- they will not include the assertions in their service
- descriptions. </p><p>A review by a broad community is the best way to ensure
- that the granularity of a set of domain assertions is
- appropriate. </p></div><div class="div2">
-<h3><a name="nested-assertions"></a>5.3 Nested Assertions</h3><p>The framework provides the ability to "nest" policy
- assertions. For domains with a complex set of options, nesting
- provides one way to indicate dependent elements within a
- behavior. The granularity of assertions is determined by the
- authors and it is recommended that care be taken when defining
- nested policies to ensure that the options provided
- appropriately specify policy alternatives within a specific
- behavior.
- </p><p>We will use the WS-SecurityPolicy to illustrate the use of
- nested assertions.
- </p><p>Securing messages is a complex usage scenario. The
- WS-SecurityPolicy authors have defined the sp:TransportBinding
- policy assertion to indicate the use of transport-level
- security for protecting messages. Just indicating the use of
- transport-level security for protecting messages is not
- sufficient. To successfully interact with a Web service, the
- consumer must know not only that transport-level security is
- required, but also the transport token to use, the secure
- transport to use, the algorithm suite to use for performing
- cryptographic operations, etc. The
- <code>sp:TransportBinding</code> policy assertion can
- represent these dependent behaviors.
+<h3><a name="single-domains"></a>5.2 Single Domains</h3><p>When considering the creation of a
+ new domain of policy assertions, it is important to identify
+ whether or not the domain is self-contained or at least if a
+ subset of the domain can be well defined. A domain that
+ expresses a broad set of capabilities will also need to have
+ community supporting implementations to provide value to the
+ consumers. Ultimately it is the consumers and providers that
+ will determine whether a particular set of assertions
+ correctly characterize a domain. A new community should avoid
+ duplicating assertions that have already been defined as this
+ will create ambiguity not clarification. New WS-Policy authors
+ should focus on creating assertions for those specific
+ constraints and capabilities that do not overlap with other
+ domains but that communicate new functionality. </p><p>The model advocated for new
+ assertion development is a cooperative marketplace
+ [some might say its an "opt-in" model]. The providers
+ of services need to find value in the set of
+ assertions or they will not include the assertions in
+ their service descriptions. </p><p>A review by a broad community is
+ the best way to ensure that the granularity of a set of domain
+ assertions is appropriate. </p></div><div class="div2">
+<h3><a name="nested-assertions"></a>5.3 Nested Assertions</h3><p>The framework provides the ability
+ to "nest" policy assertions. For domains with a complex set of
+ options, nesting provides one way to indicate dependent
+ elements within a behavior. The granularity of assertions is
+ determined by the authors and it is recommended that care be
+ taken when defining nested policies to ensure that the options
+ provided appropriately specify policy alternatives within a
+ specific behavior.
+ </p><p>We will use the WS-SecurityPolicy
+ to illustrate the use of nested assertions.
+ </p><p>Securing messages is a complex
+ usage scenario. The WS-SecurityPolicy authors have defined the
+ <code>sp:TransportBinding</code> policy assertion to indicate
+ the use of transport-level security for protecting
+ messages. Just indicating the use of transport-level security
+ for protecting messages is not sufficient. To successfully
+ interact with a Web service, the consumer must know not only
+ that transport-level security is required, but also the
+ transport token to use, the secure transport to use, the
+ algorithm suite to use for performing cryptographic
+ operations, etc. The <code>sp:TransportBinding</code> policy
+ assertion can represent these dependent behaviors.
</p><p>A policy assertion like the <code>sp:TransportBinding</code>
identifies a visible behavior that is a requirement. A nested
policy expression can be used to enumerate the dependent
@@ -436,9 +445,9 @@
qualifies the behavior of its parent policy assertion.
</p><p>In the example below, the child Policy element is a nested
policy expression and further qualifies the behavior of the
- sp:TransportBinding policy assertion. The
+ <code>sp:TransportBinding</code> policy assertion. The
<code>sp:TransportToken</code> is a nested policy assertion of
- thesp:TransportBinding policy assertion. The
+ the <code>sp:TransportBinding</code> policy assertion. The
<code>sp:TransportToken</code> assertion requires the use of a
specific transport token and further qualifies the behavior of
the <code>sp:TransportBinding</code> policy assertion (which
@@ -458,7 +467,7 @@
</sp:AlgorithmSuite>
</Policy>
</sp:TransportBinding></pre></div></div><p>The <code>sp:AlgorithmSuite</code> is a nested policy assertion of
- the<code>sp:TransportBinding</code> policy assertion. The<code>sp:AlgorithmSuite</code>
+ the <code>sp:TransportBinding</code> policy assertion. The<code>sp:AlgorithmSuite</code>
assertion requires the use of the algorithm suite identified by its nested policy
assertion (<code>sp:Basic256Rsa15</code>
<em>in the example above</em>) and further qualifies the behavior of the
@@ -469,13 +478,13 @@
security usage is absorbed by a policy-aware client and hidden
from these Web service developers.
</p></div><div class="div2">
-<h3><a name="parametrized-assertions"></a>5.4 Assertions with Parameters</h3><p>The framework provides an alternative approach for
+<h3><a name="parameterized-assertions"></a>5.4 Assertions with Parameters</h3><p>The framework provides an alternative approach for
providing additional information for an assertion beyond its
type. The framework allows WS-Policy domain authors to define
name value pairs, for example, to qualify an assertion. For some domains it
will be appropriate to specify these parameters instead of
nesting elements. </p><p> Note that parameters of assertions include the following:</p><ul><li><p> Complex elements that have element children which can not be policy assertions. </p></li><li><p> Elements that have attributes </p></li></ul></div><div class="div2">
-<h3><a name="comparison"></a>5.5 Comparison of Nested and Parametrized Assertions</h3><p>The main consideration for selecting parameters or nesting
+<h3><a name="comparison"></a>5.5 Comparison of Nested and Parameterized Assertions</h3><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
parameters in its algorithm</em>. </p><p>Domain authors should recognize that the framework can
@@ -525,7 +534,7 @@
inferred or indicated from a message. If there is a need for the
behavior to be represented in a persistent way or if there s a need for additional data
or metadata that is present in a message to be persisted, it should be incorporated
- into the assertion design or in the message iteself.
+ into the assertion design or in the message itself.
</p><p>As a result, Policy assertions should not be used to express
the semantics of a message. If a property is
required to understand a message, it should be communicated in
@@ -587,7 +596,7 @@
targeted to the provider so that the provider can determine
that the optional behavior is engaged. In other words, the
requirement of self describing nature of messages in order
- to engage behaviors must not be forgotton with regard to
+ to engage behaviors must not be forgotten with regard to
the client's ability to detect and select the alternative if
it is to participate in the exchange. It is recommended that
authors not utilize optional assertions for outbound
@@ -715,7 +724,7 @@
time in order to avoid conflicting behavior. </em>
</p><p>One approach is to specify a policy subject, choose the
most granular policy subject that the behavior applies to and
- specify a preferred attachment point in WSDL. Howeever, this
+ specify a preferred attachment point in WSDL. However, this
approach only works if the policy subject is a true WSDL
construct other than some other protocol concept that is
layered over WSDL message exchanges. For example, the WS-RM
@@ -741,20 +750,22 @@
within another expression but also allows specification of
additional policy subjects and their association to common
policy expressions that are identified. It also promotes
- managability of the expressions as they are uniquely
+ manageability of the expressions as they are uniquely
identified.
</p></div><div class="div3">
<h4><a name="extending-assertions"></a>5.11.2 Factors in Extending Assertions within a Domain </h4><p> Extensibility affects the policy subjects and attachment semantics. </p></div><div class="div3">
-<h4><a name="assertion-evolution"></a>5.11.3 Evolution of Assertions (Versioning and Compatibility)</h4><p>4.4.7. Over time, there may be multiple equivalent
- behaviors emerging in the Web Service interaction
- space. Examples of such multiple equivalent behaviors are
- WSS: SOAP Message Security 1.0 vs. 1.1 and WS-Addressing
- August 2004 version vs. WS-Addressing W3C
- Recommendation. These equivalent behaviors are mutually
- exclusive for an interaction. Such equivalent behaviors can
- be modeled as independent assertions. The policy expression
- in the example below requires the use of WSS: SOAP Message
- Security 1.0. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 5-4. </span>Example 4-2. Message-level Security and WSS: SOAP Message Security 1.0 </i></p><p>ADD THE EXAMPLE HERE </p></div><p>The policy expression in the example below requires the
+<h4><a name="assertion-evolution"></a>5.11.3 Evolution of Assertions (Versioning and Compatibility)</h4><p>4.4.7. Over time, there may
+ be multiple equivalent behaviors emerging in the Web
+ Service interaction space. Examples of such multiple
+ equivalent behaviors are WSS: SOAP Message Security 1.0
+ vs. 1.1 and WS-Addressing
+ August 2004 version vs. WS-Addressing W3C Recommendation
+ [<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]. These equivalent behaviors
+ are mutually exclusive for an interaction. Such equivalent
+ behaviors can be modeled as independent assertions. The
+ policy expression in the example below requires the use of
+ WSS: SOAP Message Security 1.0. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 5-4. </span>Example 4-2. Message-level Security and WSS: SOAP
+ Message Security 1.0 </i></p><p>ADD THE EXAMPLE HERE </p></div><p>The policy expression in the example below requires the
use of WSS: SOAP Message Security 1.1. These are multiple
equivalent behaviors and are represented using distinct
policy assertions. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 5-5. </span>Example 4-3. Message-level Security and WSS: SOAP Message Security 1.1</i></p><p>ADD THE EXAMPLE HERE </p></div><p>Best practice: use independent assertions for modeling
@@ -802,7 +813,7 @@
as the WSDL provider) or it could be proven ( using
<cite><a href="#WS-Trust">WS-Trust</a></cite>). </p></div></div><div class="div1">
<h2><a name="scenerio"></a>8. Scenario and a worked example</h2><p>To illustrate the topics explored in this document, we
- include an example of a web service and how a fictitous company
+ include an example of a web service and how a fictitious company
might utilize the WS-Policy Framework to enable Web Service
interoperability. CompanyA has determined to utilize WS-Security,
WS-Addressing and WS-Reliable Messaging in all its new web
@@ -826,7 +837,7 @@
already incorporated <code>wss:Security</code> headers into their
messages. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-1. </span>Message with Security Headers</i></p><div class="exampleInner"><pre><soap:Envelope>
<soap:Header>
- <wss:Security sopap:mustUnderstand ="1">
+ <wss:Security soap:mustUnderstand ="1">
<wsu:Timestamp u:Id=_0">
<wsu:Created> 20006-01-19T02:49:53.914Z </u:Created>
<wsu:Expires> 20006-01-19T02:54:53.914Z </u:Expires>
@@ -846,8 +857,8 @@
security for securing messages. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-2. </span> CompanyA-ProfileA </i></p><div class="exampleInner"><pre>
<Policy URI=http://www.CompanyA.com/WebServicesProfileA.xml>
<wsa:UsingAddressing />
- <sp:TransportBinding>lt;/spTransportBinding>
-</Policy></pre></div></div><p>The <code>sp:TransportBinding</code> element is a policy assertion.The
+ <sp:TransportBinding></spTransportBinding>
+</Policy></pre></div></div><p>The <code>sp:TransportBinding</code> element is a policy assertion. The
assertion identifies the use of transport-level-security - such
as HTTPS for protecting messages at the transport
level. CompanyA's policy aware clients can now recognize this
@@ -863,25 +874,22 @@
configuration. </p><p>The developers read the WS-Policy specification and noted that
there were 3 ways to express combinations of behaviors. The three
policy operators, ( Policy, All and ExactlyOne) were considered
- and the result was the creation of two policy elements. </p><p>The first policy is shown in Figure X, CompanyA-ProfileA and
- it is the policy that is used by many web services at Company A
- that rely on https to provide transport level protection of
- messages. </p><p>The second policy is shown in Figure Y, CompanyA-ProfileB and
- it offers requestors of a service the ability to provide
- additional integrity protection by including WS-Security Headers
- to protect the message content after it is processed by the
- transport. The additional security processing is not required by
- all CompanyA web services. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-3. </span>CompanyA-ProfileB ( not expanded)</i></p><div class="exampleInner"><pre>
-<Policy wsu:Id="CompanyA-ProfileB">
- <wsa:UsingAddressing />
- <ExactlyOne>
- <sp:TransportBinding></sp:TransportBinding>
- <sp:AsymmetricBinding></sp:AssymetricBinding>
- </ExactlyOne>
-</Policy> </pre></div></div><p>In the previous section CompanyA offered a second profile that
- included two security options. The details of the Bindings,
- requires a more detailed exploration of some of the other features
- of the WS-Policy Framework. </p><p>When WS-Policy authors create sets of Policy assertions, like
+ and the result was the creation of two policy elements. </p><p>The first policy is shown in Figure
+ <em>CompanyA-ProfileA</em> and it is the policy that is used
+ by many web services at Company A that rely on https to provide
+ transport level protection of messages. </p><p>The second policy is shown in Figure
+ <em>CompanyA-ProfileB</em> and it offers requestors of a
+ service the ability to provide additional integrity protection by
+ including WS-Security Headers to protect the message content
+ after it is processed by the transport. The additional security
+ processing is not required by all CompanyA web services. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-3. </span>CompanyA-ProfileB ( not expanded)</i></p><div class="exampleInner"><pre> <Policy wsu:Id="CompanyA-ProfileB">
+ <wsa:UsingAddressing /> <ExactlyOne>
+ <sp:TransportBinding></sp:TransportBinding>
+ <sp:AsymmetricBinding></sp:AssymetricBinding>
+ </ExactlyOne> </Policy> </pre></div></div><p>We have shown above that CompanyA offered a
+ second profile that included two security options. The details of
+ the Bindings, requires a more detailed exploration of some of the
+ other features of the WS-Policy Framework. </p><p>When WS-Policy authors create sets of Policy assertions, like
WS-Security Policy they need to consider expressing the semantics
of their domain in a way that policy consumers, like Company A,
can utilize them. In this case, the WS-SecurityPolicy authors
@@ -891,12 +899,12 @@
transport-level security for protecting messages is not
sufficient. For a consumer of a web service provided by a company,
like CompanyA, to successfully interact, the consumer must also
- know what transport token, what algorithm suite, etc is
+ know what transport token, what algorithm suite, etc. is
required. The <code>sp:TransportBinding</code> assertion, can (and has)
represent (ed) these dependent behaviors as "nested" policy
assertions. </p><p>In the example below the child Policy element is a nested
policy behavior and further qualifies the behavior of the
- sp:TransportBinding policy assertion. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-4. </span>CompanyA-ProfileB (fully expanded)</i></p><div class="exampleInner"><pre>
+ <code>sp:TransportBinding</code> policy assertion. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-4. </span>CompanyA-ProfileB (fully expanded)</i></p><div class="exampleInner"><pre>
<Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing />
<ExactlyOne>
@@ -1047,7 +1055,15 @@
- Core</a> is available at http://www.w3.org/TR/ws-addr-core. </dd><dt class="label"><a name="WSDL11"></a>[WSDL 1.1] </dt><dd>
<cite><a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services Description Language (WSDL) 1.1</a></cite>, E. Christensen, et al,
Authors. World Wide Web Consortium, March 2001. Available at
- http://www.w3.org/TR/2001/NOTE-wsdl-20010315. </dd><dt class="label"><a name="WS-Policy"></a>[Web Services Policy Framework] </dt><dd>
+ http://www.w3.org/TR/2001/NOTE-wsdl-20010315. </dd><dt class="label"><a name="WSDL20"></a>[WSDL 2.0 Core Language] </dt><dd>
+ <cite><a href="http://www.w3.org/TR/2006/CR-wsdl20-20060327/">Web Services Description Language (WSDL) Version
+ 2.0 Part 1: Core Language</a></cite>, R. Chinnici,
+ J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World Wide
+ Web Consortium, 27 March 2006. This version of the WSDL 2.0
+ specification is
+ http://www.w3.org/TR/2006/CR-wsdl20-20060327. The <a href="http://www.w3.org/TR/wsdl20/">latest version of WSDL
+ 2.0</a> is available at http://www.w3.org/TR/wsdl20.
+ </dd><dt class="label"><a name="WS-Policy"></a>[Web Services Policy Framework] </dt><dd>
<cite><a href="http://www.w3.org/TR/ws-policy/">Web Services Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
Boubez and P. Yendluri, Editors. World Wide Web Consortium, @@,
@@@@ @@@@. This version of the
@@ -1089,12 +1105,37 @@
Technologies Inc., Ping Identity Corporation, Reactivity
Inc., RSA Security Inc., and VeriSign Inc., February
2005. Available at
- http://schemas.xmlsoap.org/ws/2005/02/trust. </dd></dl></div><div class="div1">
+ http://schemas.xmlsoap.org/ws/2005/02/trust. </dd><dt class="label"><a name="UDDIAPI20"></a>[UDDI API 2.0] </dt><dd>
+ <cite><a href="http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm">UDDI Version 2.04 API</a></cite>, T. Bellwood,
+ Editor. Organization for the Advancement of Structured
+ Information Standards, 19 July 2002. This version of UDDI
+ Version 2.0 API is
+ http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm. The
+ <a href="http://uddi.org/pubs/ProgrammersAPI_v2.htm">latest
+ version of the UDDI 2.0 API</a> is available at
+ http://uddi.org/pubs/ProgrammersAPI_v2.htm.
+ </dd><dt class="label"><a name="UDDIDataStructure20"></a>[UDDI Data Structure 2.0] </dt><dd>
+ <cite><a href="http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm">UDDI Version 2.03 Data Structure
+ Reference</a></cite>, C. von Riegen, Editor. Organization for
+ the Advancement of Structured Information Standards, 19 July
+ 2002. This version of UDDI Version 2.0 Data Structures is
+ http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm. The
+ <a href="http://uddi.org/pubs/DataStructure_v2.htm">latest
+ version of the UDDI 2.0 Data Structures</a> is available at
+ http://uddi.org/pubs/DataStructure_v2.htm.
+ </dd><dt class="label"><a name="UDDI30"></a>[UDDI 3.0] </dt><dd>
+ <cite><a href="http://uddi.org/pubs/uddi-v3.0.1-20031014.htm">UDDI Version 3.0.1</a></cite>, L. Clément, et
+ al, Editors. Organization for the Advancement of Structured Information Standards, 14 October 2003. This version of the
+ UDDI Version 3.0 is
+ http://uddi.org/pubs/uddi-v3.0.1-20031014.htm. The <a href="http://uddi.org/pubs/uddi_v3.htm">latest version of
+ the UDDI 3.0</a> specification is available at
+ http://uddi.org/pubs/uddi_v3.htm.
+ </dd></dl></div><div class="div1">
<h2><a name="acknowledgments"></a>D. Acknowledgements (Non-Normative)</h2><p>This document is the work of the <a href="http://www.w3.org/2002/ws/policy/">W3C Web Services Policy
Working Group</a>.</p><p>
Members of the Working Group are (at the time of writing, and by
alphabetical order):
- Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Philippe Le Hégaret (W3C/MIT), Jong Lee (BEA Systems, Inc.), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce, Inc.), Anthony Nadalin (IBM Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip Snow (Citigroup), Yakov Sverdlov (Computer Associates), Mark Tmple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
+ Dimitar Angelov (SAP AG), Abbie Barbir (Nortel Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin (IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic Boubez (Layer 7 Technologies), Paul Cotton (Microsoft Corporation), Jeffrey Crump (Sonic Software), Glen Daniels (Sonic Software), Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2), Christopher Ferris (IBM Corporation), William Henry (IONA Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM Corporation), Tom Jordahl (Adobe Systems Inc.), Philippe Le Hégaret (W3C/MIT), Jong Lee (BEA Systems, Inc.), Mark Little (JBoss Inc.), Ashok Malhotra (Oracle Corporation), Monica Martin (Sun Microsystems, Inc.), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce, Inc.), Anthony Nadalin (IBM Corporation), David Orchard (BEA Systems, Inc.), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Skip now (Citigroup), Yakov Sverdlov (Computer Associates), Mark Temple-Raston (Citigroup), Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2), Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).
</p><p>
Previous members of the Working Group were:
Bijan Parsia (University of Manchester), Seumas Soltysik (IONA Technologies, Inc.)
@@ -1105,4 +1146,4 @@
</p></div><div class="div1">
<h2><a name="change-description"></a>E. Changes in this Version of
the Document (Non-Normative)</h2><p>A list of substantive changes since the previous publication is below:</p><ul><li><p>TBD</p></li></ul></div><div class="div1">
-<h2><a name="change-log"></a>F. Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060829</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Created first draft based on agreed outline and content</td></tr><tr><td rowspan="1" colspan="1">20061013</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</td></tr><tr><td rowspan="1" colspan="1">20061018</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Editorial fixes for readability, added example for Encrypted parts</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+<h2><a name="change-log"></a>F. Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060829</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Created first draft based on agreed outline and content</td></tr><tr><td rowspan="1" colspan="1">20061013</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</td></tr><tr><td rowspan="1" colspan="1">20061018</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Editorial fixes for readability, added example for Encrypted parts</td></tr><tr><td rowspan="1" colspan="1">20061030</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspa="1">Fixes for Paul Cotton's editorial comments (20061020)</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Tuesday, 31 October 2006 04:05:14 UTC