- From: Umit Yalsinap via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 19 Oct 2006 23:53:38 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv31927
Modified Files:
ws-policy-guidelines.html
Log Message:
apply Maryann's last two commits.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- ws-policy-guidelines.html 14 Oct 2006 03:25:49 -0000 1.3
+++ ws-policy-guidelines.html 19 Oct 2006 23:53:35 -0000 1.4
@@ -1,4 +1,6 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html lang="en-US"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</title><style type="text/css">
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html lang="en-US"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</title><style type="text/css">
code { font-family: monospace; }
div.constraint,
@@ -48,8 +50,11 @@
margin: 4px}
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"><link rel="contents" href="#contents"></head><body><div class="head">
<h1>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</h1>
-<h2>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd><a href="ws-policy-guidelines.html">ws-policy-guidelines.html</a></dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8</a></dd><dt>Editors:</dt><dd>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 eserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
-<h2><a name="abstract">Abstract</a></h2><p><em>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</em> is a
+<h2>Editors' copy $Date$ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
+ <a href="ws-policy-guidelines.html">ws-policy-guidelines.html</a>
+ </dd><dt>Latest version:</dt><dd><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8">http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?content-type=text/html;charset=utf-8</a></dd><dt>Editors:</dt><dd>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
@@ -58,8 +63,8 @@
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 /></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"> 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="#single-domains">Single Domains</a><br> 5.2 <a href="#new-domains">New Policy Domains</a><br> 5.3 <a href="#nested-assertions">Nested Assertions</a><br> 5.4 <a href="#parametrized-assertons">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="#subject-scoping-considerations">Subject Scoping Considerations</a><br> 5.11 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br> 5.12 <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.12.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.12.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br> 5.12.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 worked example</a><br></p>
+ 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>
<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
@@ -139,25 +144,32 @@
</p><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"></a>2.1.1 Domain Owners/WS-Policy Authors</h4><p> WS-Policy Domain owners (or WS-Policy authors) are defined
+<h4><a name="domain-owners"></a>2.1.1 WS-Policy Authors</h4><p> WS-Policy Domain owners or WS-Policy authors are defined
by the WS-Policy Framework to be 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
WS-Policy Framework is based on a declarative model, meaning
- that it is incumbent on the WS-Policy authors to define the
+ that it is incumbent on the WS-Policy authors to define both the semantics of
+ the assertions as well as the
scope of their target domain in their specification. The set
- of metadata will vary in the granularity of assertion
- specification, and it is therefore important for WS-Policy
- authors to clearly identify their scope (i.e, the variables of
- the WS-ReliableMessaging specification). It is the intent of
- this primer to help communities utilize the framework in such
+ of metadata for any particular domain will vary in the granularity of assertion
+ specification required. It is the intent of
+ this document to help communities utilize the framework in such
a way that multiple WS-Policy domains can co-exist and
consumers and providers can utilize the framework consistently
across domains.
- </p><p>An example of this can be seen in the WS-SecurityPolicy
+ </p><p>In order to take advantage of the WS-Policy Framework, any
+ domain author attempting to define new WS-Policy assertions
+ must adhere to the MUST's and SHOULD's in the specifications
+ 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><em>"This document [WS-SecurityPolicy] defines a set of
+ 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:
SOAP Message Security, WS-Trust and
@@ -170,19 +182,14 @@
information for compatibility and interoperability to be
determined by web service participants along with all
information necessary to actually enable a participant to
- engage in a secure exchange of messages." </em></p><p>In order to take advantage of the WS-Policy Framework, any
- domain author attempting to define new WS-Policy assertions
- must adhere to the MUST's and SHOULD's in the specifications
- 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 this is also provided by the WS-Security
+ 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>Consumers of WS-Policy Assertions can be any entity that is
+<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 its
- creation of a message to send to the subject that advertised
- the WS-Policy expression. The WS-Policy Attachment
+ 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.
@@ -197,8 +204,8 @@
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>Providers of WS-Policy Assertions can be any web service
- implementation that can specify its on the wire message
+<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
@@ -208,24 +215,21 @@
constraints available, it may also need to conform to
requirements of other policy specifications it utilizes (
i.e., WS-SecurityPolicy).
- </p><p>Also it is useful for providers to take into account how
- to evolve their services capabilities. If forward
+ </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
compatibility with different and potentially new clients,
- providers should refer to <a href="#lifecycle"><b>5.12 Lifecycle of Assertions</b></a> and
+ 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">
<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>When a community of WS-Policy authors decides to define
- a set of WS-Policy assertions they should understand what
- functionality the framework provides and apply the
+<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
+ functionality the WS-Policy framework provides and apply the
knowledge of framework processing when defining the set of
- assertions. This will require the WS-Policy authors to have
- some definition and/or understanding of what the goal is
- for the use of the assertions.
- </p><p>Assertions can be simple or they can be complex. A set
- of WS-Policy authors may choose to specify one or two
+ assertions.
+ </p><p>Assertions can be simple or they can be complex. WS-Policy authors may choose to specify one or two
assertions or they may choose to specify many assertion
elements that require parameters or other nested
assertions. There are advantages to simplifying the set of
@@ -237,18 +241,14 @@
to combine individual assertions may also need to be
considered.
</p><p>The number of different subjects to which an assertion
- can be associated is also a factor when defining an
- assertion. It is possible that WS-Policy assertions will be
- consumed by a wide range of client configurations, from
+ can be attached is also a factor when defining an
+ assertion. Determining the appropriate policy subjects can sometimes
+ involve understanding the requirements of wide range of client configurations, from
stand alone client applications to "active" web service
- requestors that are capable of adapting to constraints and
- capabilities modifying their own configurations
- dynamically. If the assertion is intended to be consumed
- by a broad range of clients, then the behavior should be
- simple for all of these clients to understand and
- implement.
- </p><p> Once the subjects are identified, one way of attaching
- multiple instances of a simple policy assertion is to
+ 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
@@ -258,11 +258,12 @@
creating a domain specific attachment in multiple WSDL
files, EPRs, in which the same set of policies are expected
to be applied.
- </p><p>WS-Policy domain authors should consider the following
+ </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
used by multiple subjects:
- </p><ul><li><p><em>The definition of the
+ </p><ul><li><p>
+ <em>The definition of the
assertion</em>. Does the assertion pertain to a specific
behavior that is tied to a context or is the behavior
different in each possible context? For example an
@@ -270,7 +271,8 @@
message exchange or for all message exchanges that pertain
to an endpoint would probably be represented by separate
assertions.
- </p></li><li><p><em>Scoping of the assertion</em>. Where
+ </p></li><li><p>
+ <em>Scoping of the assertion</em>. Where
does the assertion apply? Is the assertion about a
specific description in WSDL? Is the assertion about a
specific aspect of protocol? Is the assertion about a
@@ -278,7 +280,8 @@
the subject of an assertion is helpful in specifying the
different scopes and subjects that it applies to.
- </p></li><li><p><em>Composition</em>. If the assertion is
+ </p></li><li><p>
+ <em>Composition</em>. If the assertion is
used with other assertions in a context, it is necessary
to consider how the assertion may or may not affect
the composition. For example, if an assertion applies to
@@ -345,32 +348,15 @@
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p> Note that both authoring styles are equivalent, however
there may be reasons to choose one form over another
- depending on the use. The compact form is more
+ depending on the use. For example, when multiple alternatives are present
+ 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
illustrates above.
</p></div><div class="div1">
<h2><a name="modeling-guidelines"></a>5. Guidelines for Modeling New Assertions</h2><div class="div2">
-<h3><a name="single-domains"></a>5.1 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 can be well defined. A domain
- that expresses a broad set of capabilities will need to have
- community support to provide value to the consumers.
- Ultimately it is the consumers and providers that will
- determine whether a particular set of assertions correctly
- characterize the domain. A community should avoid duplicating
- assertions that have already been defined as this will create
- ambiguity not clarification and 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 is an "opt-in" model. Namely, the
- providers of services should invest to find the set of
- assertions useful to improve interoperability of services 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="new-domains"></a>5.2 New Policy Domains</h3><p>When creating a new policy domain, it is important to
+<h3><a name="new-domains"></a>5.1 New Policy Domains</h3><p>When creating a new policy domain, it is important to
understand how policy expressions are used by the
framework. Some WS-Policy domains represent infrastructure
efforts like WS-SecurityPolicy and WS-RM Policy. We also
@@ -399,6 +385,26 @@
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
@@ -454,7 +460,8 @@
</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>
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
+ assertion (<code>sp:Basic256Rsa15</code>
+ <em>in the example above</em>) and further qualifies the behavior of the
<code>sp:TransportBinding</code> policy assertion.</p><p>Setting aside the details of using transport-level
security,, a policy-aware client that recognizes this policy
assertion can engage transport-level security and its
@@ -465,7 +472,7 @@
<h3><a name="parametrized-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 to qualify an assertion. For some domains it
+ 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
@@ -487,13 +494,18 @@
delegated to the specific domain handlers that are not visible
to the WS-Policy framework. The tradeoff is the generality
vs. the flexibility and complexity of the comparison expected
- for a domain.
-
- </p></div><div class="div2">
+ for a domain. </p><p>In the example below, <code>sp:Body</code> and <code>sp:Header</code> elements are the
+ two assertion parameters of the <code>sp:SignedParts</code> policy assertion (this
+ assertion requires the parts of a message to be protected). </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 5-2. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre><Policy>
+ <sp:SignedParts>
+ <sp:Body />
+ <sp:Header />
+ </sp:SignedParts>
+</Policy></pre></div></div></div><div class="div2">
<h3><a name="self-describing"></a>5.6 Self Describing Messages </h3><p>WS-Policy is intended to communicate the requirements,
- capabilities, preferences and behaviors of nodes on the message's
- path, not specifically declare properties of the messages
- themselves. One of the advantages of Web services is that an XML
+ capabilities, preferences 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
@@ -506,24 +518,20 @@
required in a particular message; the latter are the intended
uses of the Ws-Policy framework.
</p><p>The assertion authors should take into account that there are
- two important concepts when designing assertions. Firstly, an
+ two important concepts when designing assertions and documenting the semantics of the
+ assertion types. Firstly, an
assertion type indicates a <em>runtime</em> behavior. Secondly,
an assertion should also indicate how the assertion type can be
- inferred or indicated from a message, if there is a need for the
- behavior to be represented in a persistent way by additional data
- or metadata that is present in a message. If such a relationship
- exists, it should be incorporated into an assertion design
- document that illustrates the disambiguation of the usage of the
- policy at runtime and in the message if that message is
- persisted.
+ 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.
</p><p>As a result, Policy assertions should not be used to express
- what otherwise should be part of the message. If a property is
+ the semantics of a message. If a property is
required to understand a message, it should be communicated in
- the message, or made available to in a message (e.g., being
+ the message, or be made available by some other means(e.g., being
referenced by a URI in the message) rather than communicated as a
- policy element. Thus, the assertion definition should specify how
- the presence of the property will determine the engagement of the
- behavior indicated by the assertion.
+ policy element.
</p><p>If the messages could not be made self describing by utilizing
additional properties present in the message as required by the assertion, it would be
necessary to determine the behaviors engaged at runtime by
@@ -643,13 +651,13 @@
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><div class="exampleOuter"><p>EXAMPLE</p></div></div><div class="div2">
-<h3><a name="subject-scoping-considerations"></a>5.10 Subject Scoping Considerations</h3><p> Appendix A. Which assertions </p><p>Enabled versioning. Conservative composites. </p><p> Anti patterns. Interaction between the subjects and interaction between different attachment points. How you can get into trouble. </p><p>Give wS-RX as example. </p><p>Give examples for WSDL 1.0. </p></div><div class="div2">
-<h3><a name="levels-of-abstraction"></a>5.11 Levels of Abstraction in WSDL </h3><p>A behavior identified by a policy assertion applies to the
+ subjects. More of this topic is covered in the <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
+ </p><div class="exampleOuter"><p>EXAMPLE</p></div></div><div class="div2">
+<h3><a name="levels-of-abstraction"></a>5.10 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, policy assertion authors must specify a WSDL
policy subject. The policy subject is determined with respect
- to a behavior as follows behavior?
+ to a behavior as follows:
</p><ul><li><p>If the behavior applies to any message exchange
using any of the endpoints offered by a service then the
subject is the service policy subject. </p></li><li><p>If the behavior applies to any message exchange
@@ -658,15 +666,13 @@
defined by an operation then the subject is the operation
policy subject. </p></li><li><p>If the behavior applies to an input message then
the subject is the message policy subject - similarly for
- output and fault message policy subjects.</p></li></ul><p>The authors need to understand how the assertions will be
+ output and fault message policy subjects.</p></li></ul><p>WS-Policy authors that wish to utilize WSDL policy subjects need to understand how the assertions will be
processed in intersection and merging and the implications of
the processing for considering a specific attachment point and
- policy subject. This topic is considered in detail in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite></p><p>The current set of subjects as mapped to the WSDL 1.1
- elements, can constrain the assertion constructs to a WSDL
- exchange if the authors so choose. For Example, In WS-RM,
- there was not a WSDL subject that was appropriate to some of
- the characteristics of a reliable messaging exchange and the
- domain authors chose to not support certain capabilities at
+ policy subject. This topic is considered in detail in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
+ </p><p>The current set of subjects as mapped to the WSDL 1.1
+ elements, can also constrain the assertion constructs. For Example, In WS-RM,
+ the domain authors chose to support certain capabilities at
the endpoint level. This resulted in the finer granularity of
the assertion to apply at the message policy subject, but the
assertion semantics also indicates that the if the senders
@@ -690,8 +696,7 @@
the assertion reasonably applies to any endpoint that ever
references that portType. Most of the known policy assertions
are designed for the endpoint, operation or message policy
- subject. The commonly used attachment points for these policy
- subjects are outlined in <a href="#subject-scoping-considerations"><b>5.10 Subject Scoping Considerations</b></a>. </p><p> In using WSDL attachment, it should be noted that the
+ subject. </p><p> In using WSDL attachment, it should be noted that the
service policy subject is a collection of endpoint policy
subjects. The endpoint policy subject is a collection of
operation policy subjects and etc. As a result, the WSDL
@@ -707,7 +712,8 @@
subjects then <em>the assertion author has the burden to
describe the semantics of multiple instances of the same
assertion attached to multiple policy subjects at the same
- time in order to avoid conflicting behavior. </em></p><p>One approach is to specify a policy subject, choose the
+ 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
approach only works if the policy subject is a true WSDL
@@ -721,13 +727,15 @@
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="lifecycle"></a>5.12 Lifecycle of Assertions</h3><p>There are three aspects that govern an assertions lifecycle:</p><ul><li><p> Assertion Extensibility </p></li><li><p> Policy Language Extensibility </p></li><li><p> Subject attachment Extensibility </p></li></ul><div class="div3">
-<h4><a name="Referencing_Policy_Expressions"></a>5.12.1 Referencing Policy Expressions</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> illustrates how the
- utilizing identification mechanism can be useful for exposing
- a complex policy expression as a reusable building block for
+<h3><a name="lifecycle"></a>5.11 Lifecycle of Assertions</h3><p>WS-Policy authors need to consider not just the expression of the current set of requirements but
+ how they anticipate new assertions being added to the set. There are three aspects that govern an assertions lifecycle:</p><ul><li><p> Assertion Extensibility </p></li><li><p> Policy Language Extensibility </p></li><li><p> Subject attachment Extensibility </p></li></ul><div class="div3">
+<h4><a name="Referencing_Policy_Expressions"></a>5.11.1 Referencing Policy Expressions</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> illustrates how
+ providers can
+ utilize the identification mechanism defined in the Policy specification
+ to expose a complex policy expression as a reusable building block for
other policy expressions by reference. Domain assertion
- authors, especially those utilizing complex assertions that
- include nesting or complex types should consider utilizing
+ authors, especially those defining complex assertions that
+ include nesting or complex types should consider specifying or recommending
naming conventions in order to promote reuse. Reuse through
referencing allows a policy expression to be utilized not only
within another expression but also allows specification of
@@ -736,8 +744,8 @@
managability of the expressions as they are uniquely
identified.
</p></div><div class="div3">
-<h4><a name="extending-assertions"></a>5.12.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.12.3 Evolution of Assertions (Versioning and Compatibility)</h4><p>4.4.7. Over time, there may be multiple equivalent
+<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
@@ -746,15 +754,15 @@
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-3. </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
+ 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-4. </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
+ 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
multiple equivalent behaviors. </p></div></div></div><div class="div1">
-<h2><a name="inter-policy"></a>6. Inter-domain Policy and Composition Issues</h2><p>Domain authors must be aware of the interactions between
- different domains. For example, security assertions interact
+<h2><a name="inter-policy"></a>6. Inter-domain Policy and Composition Issues</h2><p>Domain authors must be aware of the interactions between their
+ domain and other domains. For example, security assertions interact
with other protocol assertions in a composition. Although
- modeling such assertions may appear independent behaviors,
+ modeling protocol assertions may appear to be an independent behavior,
protocol assertions and security assertions affect transport
bindings and their interactions must be considered. For
example, utilization of WS-Security Policy with other
@@ -796,7 +804,7 @@
<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
might utilize the WS-Policy Framework to enable Web Service
- interoperability. In addition we provide the following matrix:</p><div class="exampleOuter"><p>ADD MATRIX</p></div><p>CompanyA has determined to utilize WS-Security,
+ interoperability. CompanyA has determined to utilize WS-Security,
WS-Addressing and WS-Reliable Messaging in all its new web
service offerings and has instructed its developers to use the
policy assertions defined by the following documents: </p><ul><li><p>Web Services Security Policy </p></li><li><p>Web Services Reliable Messaging Policy </p></li><li><p>Web Services Addressing WSDL Binding</p></li></ul><p>The application developers at CompanyA are instructed to
@@ -816,7 +824,7 @@
the use of transport-level security for protecting messages as
well as including addressing headers. Employees of CompanyA have
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-2. </span>Message with Security Headers</i></p><div class="exampleInner"><pre><soap:Envelope>
+ 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">
<wsu:Timestamp u:Id=_0">
@@ -835,7 +843,7 @@
messages. </p><p>The example below illustrates a policy expression that
CompanyA has created for its employees to use on their web
services to indicate the use of addressing and transport-level
- security for securing messages. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-3. </span> CompanyA-ProfileA </i></p><div class="exampleInner"><pre>
+ 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>
@@ -863,7 +871,7 @@
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-4. </span>CompanyA-ProfileB ( not expanded)</i></p><div class="exampleInner"><pre>
+ 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>
@@ -888,7 +896,7 @@
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-5. </span>CompanyA-ProfileB (fully expanded)</i></p><div class="exampleInner"><pre>
+ 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>
<Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing />
<ExactlyOne>
@@ -907,7 +915,8 @@
<sp:AsymmetricBinding>
</sp:AssymetricBinding>
</ExactlyOne>
-</Policy></pre></div></div><p><code>The sp:AlgorithmSuite</code> is a nested policy
+</Policy></pre></div></div><p>
+ <code>The sp:AlgorithmSuite</code> is a nested policy
assertion of the <code>sp:TransportBinding</code> assertion and
indicates that this suite is required. The
<code>sp:TransportToken</code> is a nested policy assertion that
@@ -933,14 +942,14 @@
specification and attach the policies to the web service endpoint
policy subject as recommended by the WS-SecurityPolicy
specification. For the default web services, the URI is included
- in the wsdl binding for each web service. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-6. </span></i></p><div class="exampleInner"><pre>
+ in the wsdl binding for each web service. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-5. </span></i></p><div class="exampleInner"><pre>
<wsdl:binding name="CompanyADefaultBinding" type="tns:CompanyADefault">
<wsp:PolicyReference URI="http://www.CompanyA.com/WebServicesProfileA.xml">
<wsdl:operation name="GetQuote"> </wsdl:operation>
</wsdl:binding> </pre></div></div><p>The partner specified policy is included in the beginning of
the wsdl 1.1document and referenced by the binding for the service
- as in the example below.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-7. </span></i></p><div class="exampleInner"><pre>
+ as in the example below.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-6. </span></i></p><div class="exampleInner"><pre>
<wsdl:definitions name="StokeQuote"
targetNamespace="http:..">
<wsp:Policy wsu:Id="CompanyA-ProfileB">
@@ -979,54 +988,100 @@
effective policies for WSDL 1.1 based subjects. </p></div></div><div class="back"><div class="div1">
<h2><a name="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"></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 colspan="1" rowspan="1">Prefix</th><th colspan="1" rowspan="1">XML Namespace</th><th colspan="1" rowspan="1">Specifications</th></tr></thead><tbody><tr><td colspan="1" rowspan="1"><code>soap</code></td><td colspan="1" rowspan="1"><code>http://www.w3.org/2003/05/soap-envelope</code></td><td colspan="1" rowspan="1">[<cite><a href="#SOAP12">SOAP 1.2 Messaging Framework</a></cite>]</td></tr><tr><td colspan="1" rowspan="1"><code>sp</code></td><td colspan="1" rowspan="1"><code>http://schemas.xmlsoap.org/ws/2005/07/securitypolicy</code></td><td colspan="1" rowspan="1">[<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]</td></tr><tr><td colspan="1" rowspan="1"><code>wsa</code></td><td colspan=1" rowspan="1"><code>http://www.w3.org/2005/08/addressing</code></td><td colspan="1" rowspan="1">[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]</td></tr><tr><td colspan="1" rowspan="1"><code>wsdl</code></td><td colspan="1" rowspan="1"><code>http://schemas.xmlsoap.org/wsdl/</code></td><td colspan="1" rowspan="1">[<cite><a href="#WSDL11">WSDL 1.1</a></cite>]</td></tr><tr><td colspan="1" rowspan="1"><code>wsp</code></td><td colspan="1" rowspan="1"><code>http://www.w3.org/@@@@/@@/ws-policy</code></td><td colspan="1" rowspan="1">[<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>, <cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>]</td></tr><tr><td colspan="1" rowspan="1"><code>wsrmp</code></td><td colspan="1" rowspan="1"><code>http://docs.oasis-open.org/ws-rx/wsrmp/200608</code></td><td colspan="1" rowspan="1">[<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]</td></tr><tr><td colspan="1" rowspan="1"><code>wss</code></td<td colspan="1" rowspan="1"><code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</code></td><td colspan="1" rowspan="1">[<cite><a href="#WS-Security2004">WS-Security 2004</a></cite>]</td></tr><tr><td colspan="1" rowspan="1"><code>wsu</code></td><td colspan="1" rowspan="1"><code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd</code></td><td colspan="1" rowspan="1">[<cite><a href="#WS-Security2004">WS-Security 2004</a></cite>]</td></tr></tbody></table><br></div><div class="div1">
-<h2><a name="references"></a>C. References</h2><dl><dt class="label"><a name="MTOM"></a>[MTOM] </dt><dd><cite><a href="http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">SOAP Message Transmission Optimization Mechanism</a></cite>, M. Gudgin, N.
+ 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">
+ <code>soap</code>
+ </td><td rowspan="1" colspan="1">
+ <code>http://www.w3.org/2003/05/soap-envelope</code>
+ </td><td rowspan="1" colspan="1">[<cite><a href="#SOAP12">SOAP 1.2 Messaging Framework</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
+ <code>sp</code>
+ </td><td rowspan="1" colspan="1">
+ <code>http://schemas.xmlsoap.org/ws/2005/07/securitypolicy</code>
+ </td><td rowspan="1" colspan="1">[<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
+ <code>wsa</code>
+ </td><td rowspan="1" colspan="1">
+ <code>http://www.w3.org/2005/08/addressing</code>
+ </td><td rowspan="1" colspan="1">[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
+ <code>wsdl</code>
+ </td><td rowspan="1" colspan="1">
+ <code>http://schemas.xmlsoap.org/wsdl/</code>
+ </td><td rowspan="1" colspan="1">[<cite><a href="#WSDL11">WSDL 1.1</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
+ <code>wsp</code>
+ </td><td rowspan="1" colspan="1">
+ <code>http://www.w3.org/@@@@/@@/ws-policy</code>
+ </td><td rowspan="1" colspan="1">[<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>, <cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
+ <code>wsrmp</code>
+ </td><td rowspan="1" colspan="1">
+ <code>http://docs.oasis-open.org/ws-rx/wsrmp/200608</code>
+ </td><td rowspan="1" colspan="1">[<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
+ <code>wss</code>
+ </td><td rowspan="1" colspan="1">
+ <code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</code>
+ </td><td rowspan="1" colspan="1">[<cite><a href="#WS-Security2004">WS-Security 2004</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
+ <code>wsu</code>
+ </td><td rowspan="1" colspan="1">
+ <code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd</code>
+ </td><td rowspan="1" colspan="1">[<cite><a href="#WS-Security2004">WS-Security 2004</a></cite>]</td></tr></tbody></table><br></div><div class="div1">
+<h2><a name="references"></a>C. References</h2><dl><dt class="label"><a name="MTOM"></a>[MTOM] </dt><dd>
+ <cite><a href="http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">SOAP Message Transmission Optimization Mechanism</a></cite>, M. Gudgin, N.
Mendelsohn, M. Nottingham and H. Ruellan, Editors. World Wide Web Consortium, 25 January
2005. This version of the SOAP Message Transmission Optimization Mechanism Recommendation
is http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/. The <a href="http://www.w3.org/TR/soap12-mtom/">latest version of SOAP Message Transmission
- Optimization Mechanism</a> is available at http://www.w3.org/TR/soap12-mtom/. </dd><dt class="label"><a name="SOAP11"></a>[SOAP 1.1] </dt><dd><cite><a href="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">Simple Object Access Protocol (SOAP) 1.1</a></cite>, D. Box, et al, Editors.
+ Optimization Mechanism</a> is available at http://www.w3.org/TR/soap12-mtom/. </dd><dt class="label"><a name="SOAP11"></a>[SOAP 1.1] </dt><dd>
+ <cite><a href="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">Simple Object Access Protocol (SOAP) 1.1</a></cite>, D. Box, et al, Editors.
World Wide Web Consortium, 8 May 2000. Available at
- http://www.w3.org/TR/2000/NOTE-SOAP-20000508/. </dd><dt class="label"><a name="SOAP12"></a>[SOAP 1.2 Messaging Framework] </dt><dd><cite><a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/">SOAP Version 1.2 Part 1: Messaging Framework</a></cite>, M. Gudgin, M. Hadley,
+ http://www.w3.org/TR/2000/NOTE-SOAP-20000508/. </dd><dt class="label"><a name="SOAP12"></a>[SOAP 1.2 Messaging Framework] </dt><dd>
+ <cite><a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/">SOAP Version 1.2 Part 1: Messaging Framework</a></cite>, M. Gudgin, M. Hadley,
N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, Editors. World Wide Web Consortium, 24
June 2003. This version of the SOAP Version 1.2 Part 1: Messaging Framework Recommendation
is http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. The <a href="http://www.w3.org/TR/soap12-part1/">latest version of SOAP Version 1.2 Part 1:
- Messaging Framework</a> is available at http://www.w3.org/TR/soap12-part1/. </dd><dt class="label"><a name="XOP"></a>[XOP] </dt><dd><cite><a href="http://www.w3.org/TR/2005/REC-xop10-20050125/">XML-binary Optimized Packaging</a></cite>, M. Gudgin, N. Mendelsohn, M.
+ Messaging Framework</a> is available at http://www.w3.org/TR/soap12-part1/. </dd><dt class="label"><a name="XOP"></a>[XOP] </dt><dd>
+ <cite><a href="http://www.w3.org/TR/2005/REC-xop10-20050125/">XML-binary Optimized Packaging</a></cite>, M. Gudgin, N. Mendelsohn, M.
Nottingham and H. Ruellan, Editors. World Wide Web Consortium, 25 January 2005. This
version of the XML-binary Optimized Packaging Recommendation is
http://www.w3.org/TR/2005/REC-xop10-20050125/. The <a href="http://www.w3.org/TR/xop10/">latest version of XML-binary Optimized Packaging</a> is available at
- http://www.w3.org/TR/xop10/. </dd><dt class="label"><a name="WS-Addressing"></a>[WS-Addressing Core] </dt><dd><cite><a href="http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/">Web Services Addressing 1.0 - Core</a></cite>, M. Gudgin, M. Hadley, and T.
+ http://www.w3.org/TR/xop10/. </dd><dt class="label"><a name="WS-Addressing"></a>[WS-Addressing Core] </dt><dd>
+ <cite><a href="http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/">Web Services Addressing 1.0 - Core</a></cite>, M. Gudgin, M. Hadley, and T.
Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the Web Services
Addressing 1.0 - Core Recommendation is
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <a href="http://www.w3.org/TR/ws-addr-core/">latest version of Web Services Addressing 1.0
- - 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,
+ - 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><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.
+ http://www.w3.org/TR/2001/NOTE-wsdl-20010315. </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
Web Services Policy 1.5 - Framework specification is at http://www.w3.org/TR/ws-policy/. The <a href="http://www.w3.org/TR/ws-policy/">latest version of
- Web Services Policy 1.5 - Framework</a> is available at http://www.w3.org/TR/ws-policy/. </dd><dt class="label"><a name="WS-PolicyAttachment"></a>[Web Services Policy Attachment] </dt><dd><cite><a href="http://www.w3.org/TR/ws-policy-attach/">Web Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
+ Web Services Policy 1.5 - Framework</a> is available at http://www.w3.org/TR/ws-policy/. </dd><dt class="label"><a name="WS-PolicyAttachment"></a>[Web Services Policy Attachment] </dt><dd>
+ <cite><a href="http://www.w3.org/TR/ws-policy-attach/">Web Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
Boubez and P. Yendluri, Editors. World Wide Web Consortium, @@,
@@@@ @@@@. This version of the
Web Services Policy 1.5 - Attachment specification is at http://www.w3.org/TR/ws-policy-attach. The <a href="http://www.w3.org/TR/ws-policy-attach/">latest version of
Web Services Policy 1.5 - Attachment</a> is available at
- http://www.w3.org/TR/ws-policy-attach/. </dd><dt class="label"><a name="WS-Policy-Primer"></a>[Web Services Policy Primer] </dt><dd><cite><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;%2520charset=utf-8">Web Services Policy 1.5 - Primer</a></cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
- Boubez and P. Yendluri, Editors. World Wide Web Consortium, Draft. </dd><dt class="label"><a name="WS-RM"></a>[Web Services Reliable Messaging] </dt><dd><cite><a href="http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html">Web Services Reliable Messaging (WS-ReliableMessaging)</a></cite>, Doug Davis (IBM), Anish Karmarkar (Oracle),
+ http://www.w3.org/TR/ws-policy-attach/. </dd><dt class="label"><a name="WS-Policy-Primer"></a>[Web Services Policy Primer] </dt><dd>
+ <cite><a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-primer.html?content-type=text/html;%20charset=utf-8">Web Services Policy 1.5 - Primer</a></cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
+ Boubez and P. Yendluri, Editors. World Wide Web Consortium, Draft. </dd><dt class="label"><a name="WS-RM"></a>[Web Services Reliable Messaging] </dt><dd>
+ <cite><a href="http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-rddl-200608.html">Web Services Reliable Messaging (WS-ReliableMessaging)</a></cite>, Doug Davis (IBM), Anish Karmarkar (Oracle),
Gilbert Pilz (BEA), Steve Winkler (SAP), Umit Yalcinalp
(SAP), 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),
+ </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), Umit Yalcinalp
(SAP), August 4, 2006, available at:
http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html
- </dd><dt class="label"><a name="WS-Security2004"></a>[WS-Security 2004] </dt><dd><cite><a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">Web Services Security: SOAP Message Security
+ </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
1.0</a></cite>, A. Nadalin, C. Kaler, P. Hallam-Baker and
R. Monzillo, Editors. Organization for the Advancement of
Structured Information Standards, March 2004. Available at
- http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf. </dd><dt class="label"><a name="WS-SecurityPolicy"></a>[WS-SecurityPolicy] </dt><dd><cite><a href="http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf">WS-SecurityPolicy v1.0</a></cite>, A. Nadalin,
+ http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf. </dd><dt class="label"><a name="WS-SecurityPolicy"></a>[WS-SecurityPolicy] </dt><dd>
+ <cite><a href="http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf">WS-SecurityPolicy v1.0</a></cite>, A. Nadalin,
M. Gudgin, A. Barbir, and H. Granqvist,
Editors. Organization for the Advancement of Structured
Information Standards, 8 December 2005. Available at
- http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf. </dd><dt class="label"><a name="WS-Trust"></a>[WS-Trust] </dt><dd><cite><a href="http://schemas.xmlsoap.org/ws/2005/02/trust">Web Services Trust Language (WS-Trust)</a></cite>,
+ http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf. </dd><dt class="label"><a name="WS-Trust"></a>[WS-Trust] </dt><dd>
+ <cite><a href="http://schemas.xmlsoap.org/ws/2005/02/trust">Web Services Trust Language (WS-Trust)</a></cite>,
S. Anderson, et al, Authors. Actional Corporation, BEA
Systems, Inc., Computer Associates International, Inc.,
International Business Machines Corporation, Layer 7
@@ -1047,7 +1102,7 @@
The people who have contributed to <a href="http://lists.w3.org/Archives/Public/public-ws-policy/">discussions
on public-ws-policy@w3.org</a> are also gratefully
acknowledged.
- </p></div> <div class="div1">
+ </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 colspan="1" rowspan="1">20060829</td><td colspan="1" rowspan="1">UY</td><td colspan="1" rowspan="1">Created first draft based on agreed outline and content</td></tr><tr><td colspan="1" rowspan="1">20061013</td><td colspan="1" rowspan="1">UY</td><td colspan="1" rowspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</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></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Thursday, 19 October 2006 23:53:50 UTC