W3C home > Mailing lists > Public > public-ws-addressing-eds@w3.org > October to December 2005

2004/ws/addressing ws-addr-soap.xml,1.104,1.105

From: Marc Hadley via cvs-syncmail <cvsmail@w3.org>
Date: Tue, 22 Nov 2005 20:41:18 +0000
To: public-ws-addressing-eds@w3.org
Message-Id: <E1Eeex4-0005kv-Gs@lionel-hutz.w3.org>

Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv22083

Modified Files:
	ws-addr-soap.xml 
Log Message:
Added issue cr11 resolution, minor editorial teaks to SOAPAction to [action] relationship text

Index: ws-addr-soap.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-soap.xml,v
retrieving revision 1.104
retrieving revision 1.105
diff -C2 -d -r1.104 -r1.105
*** ws-addr-soap.xml	8 Nov 2005 05:21:03 -0000	1.104
--- ws-addr-soap.xml	22 Nov 2005 20:41:16 -0000	1.105
***************
*** 43,47 ****
          <name>Tony Rogers</name>
          <affiliation>Computer Associates International, Inc</affiliation>
!       </author>     
      </authlist>
      <abstract>
--- 43,47 ----
          <name>Tony Rogers</name>
          <affiliation>Computer Associates International, Inc</affiliation>
!       </author>
      </authlist>
      <abstract>
***************
*** 142,148 ****
            </tbody>
          </table>
!         <p>The Working Group intends to maintain the value of the &wsa-core.title; namespace
!           URI that was assigned in the Candidate Recommendation unless significant changes are made
!           that impact the implementation of the specification.</p>
          <p>WS-Addressing is defined in terms of the XML Information Set [<bibref ref="XMLInfoSet"
            />]. WS-Addressing is conformant to the SOAP 1.2 [<bibref ref="SOAP12-PART1"/>] processing
--- 142,148 ----
            </tbody>
          </table>
!         <p>The Working Group intends to maintain the value of the &wsa-core.title; namespace URI
!           that was assigned in the Candidate Recommendation unless significant changes are made that
!           impact the implementation of the specification.</p>
          <p>WS-Addressing is defined in terms of the XML Information Set [<bibref ref="XMLInfoSet"
            />]. WS-Addressing is conformant to the SOAP 1.2 [<bibref ref="SOAP12-PART1"/>] processing
***************
*** 391,395 ****
              binding[<bibref ref="SOAP12-PART2"/>] puts the reply message in the HTTP response.</p>
        </div2>
-       
      </div1>
      <div1 id="s11ext">
--- 391,394 ----
***************
*** 420,429 ****
              <label>SOAP Action</label>
              <def>
!               <p>Use of the SOAPAction HTTP header is required when using the SOAP 1.1 HTTP binding.
!                 The value of the SOAPAction HTTP header MUST either be the value of the wsa:Action
!                 header enclosed in quotation marks, or the empty value "". The latter case supports
!                 the ability to obscure the wsa:Action header through SOAP-level security mechanisms,
!                 without requiring otherwise unnecessary transport-level security. Any other value
!                 for SOAPAction results in an Invalid Message Addressing Property fault (see <specref
                    ref="invalidmapfault"/>).</p>
              </def>
--- 419,429 ----
              <label>SOAP Action</label>
              <def>
!               <p>Use of the SOAPAction HTTP request header field is required when using the SOAP 1.1
!                 HTTP binding. The field-value of the SOAPAction HTTP request header MUST either be
!                 the value of the [action] property enclosed in quotation marks, or the empty value
!                 "". The latter case supports the ability to obscure the [action] property through
!                 SOAP-level security mechanisms, without requiring otherwise unnecessary
!                 transport-level security. Any other value for SOAPAction results in an Invalid
!                 Message Addressing Property fault (see <specref
                    ref="invalidmapfault"/>).</p>
              </def>
***************
*** 434,439 ****
      <div1 id="faults">
        <head>Faults</head>
!       <p>The faults defined in this section are generated if the condition stated in the 
!         preamble in each subsection is met.</p>
        <p>Endpoints compliant with this specification MUST include the required message addressing
          properties serialized as SOAP headers in generated fault messages. Fault messages are
--- 434,439 ----
      <div1 id="faults">
        <head>Faults</head>
!       <p>The faults defined in this section are generated if the condition stated in the preamble in
!         each subsection is met.</p>
        <p>Endpoints compliant with this specification MUST include the required message addressing
          properties serialized as SOAP headers in generated fault messages. Fault messages are
***************
*** 448,460 ****
  &nsuri;/fault
  </eg>
!       <p>SOAP modules and extensions MAY define custom [action] values for the faults they
!         describe or MAY designate use of the following [action] value instead:</p>
        <eg xml:space="preserve">
  &nsuri;/soap/fault
  </eg>
!       <p>The above [action] value SHOULD be used for generic SOAP faults including 
!         version mismatch, must understand, and data encoding unknown.</p>
!       <p>Each of the predefined faults listed below is defined by specifying values 
!         for the following abstract properties:</p>
        <p> [Code] The fault code, use of the specified fault code is REQUIRED.</p>
        <p> [Subcode] The fault subcode, use of the specified fault subcode is REQUIRED.</p>
--- 448,460 ----
  &nsuri;/fault
  </eg>
!       <p>SOAP modules and extensions MAY define custom [action] values for the faults they describe
!         or MAY designate use of the following [action] value instead:</p>
        <eg xml:space="preserve">
  &nsuri;/soap/fault
  </eg>
!       <p>The above [action] value SHOULD be used for generic SOAP faults including version mismatch,
!         must understand, and data encoding unknown.</p>
!       <p>Each of the predefined faults listed below is defined by specifying values for the
!         following abstract properties:</p>
        <p> [Code] The fault code, use of the specified fault code is REQUIRED.</p>
        <p> [Subcode] The fault subcode, use of the specified fault subcode is REQUIRED.</p>
***************
*** 463,468 ****
        <p> [Reason] The English language reason element, use of the specified fault code is
          RECOMMENDED but alternate text MAY be used.</p>
!       <p> [Details] The detail elements, use of the specified detail elements is REQUIRED. If absent, 
!         no detail elements are defined for the fault.</p>
        <div2>
          <head>SOAP 1.2 Fault Binding</head>
--- 463,468 ----
        <p> [Reason] The English language reason element, use of the specified fault code is
          RECOMMENDED but alternate text MAY be used.</p>
!       <p> [Details] The detail elements, use of the specified detail elements is REQUIRED. If
!         absent, no detail elements are defined for the fault.</p>
        <div2>
          <head>SOAP 1.2 Fault Binding</head>
***************
*** 538,550 ****
        <div2>
          <head>SOAP 1.1 Fault Binding</head>
!         <p>The SOAP 1.1 fault is slightly less expressive than the SOAP 1.2 fault and maps only [Subcode], [Reason] and
!           [Detail]. These the properties bind to a SOAP 1.1 fault as follows:</p>
          <glist>
            <gitem>
              <label>[Subcode] or [Subsubcode]</label>
              <def>
!               <p>The value of the [Subsubcode] or, if that is not specified, the value of the [Subcode] 
!                 property is bound as the value of the SOAP faults
!                 S11:Fault/faultcode element.</p>
              </def>
            </gitem>
--- 538,551 ----
        <div2>
          <head>SOAP 1.1 Fault Binding</head>
!         <p>The SOAP 1.1 fault is slightly less expressive than the SOAP 1.2 fault and maps only
!           [Subcode], [Reason] and [Detail]. These the properties bind to a SOAP 1.1 fault as
!           follows:</p>
          <glist>
            <gitem>
              <label>[Subcode] or [Subsubcode]</label>
              <def>
!               <p>The value of the [Subsubcode] or, if that is not specified, the value of the
!                 [Subcode] property is bound as the value of the SOAP faults S11:Fault/faultcode
!                 element.</p>
              </def>
            </gitem>
***************
*** 561,566 ****
                <p>The SOAP 1.1 fault detail is only for use with faults related to the body of a
                  message and is therefore not used for SOAP 1.1 faults related to processing of
!                 addressing headers. Instead the value of the [Details] property is bound as the value
!                 of a new wsa:FaultDetail SOAP header block. The following describes the
                  wsa:FaultDetail element:</p>
                <glist>
--- 562,567 ----
                <p>The SOAP 1.1 fault detail is only for use with faults related to the body of a
                  message and is therefore not used for SOAP 1.1 faults related to processing of
!                 addressing headers. Instead the value of the [Details] property is bound as the
!                 value of a new wsa:FaultDetail SOAP header block. The following describes the
                  wsa:FaultDetail element:</p>
                <glist>
***************
*** 568,572 ****
                    <label>/wsa:FaultDetail</label>
                    <def>
!                     <p>Zero or more of the elements defined in <specref ref="faultdetailelements"/>.</p>
                    </def>
                  </gitem>
--- 569,574 ----
                    <label>/wsa:FaultDetail</label>
                    <def>
!                     <p>Zero or more of the elements defined in <specref ref="faultdetailelements"
!                     />.</p>
                    </def>
                  </gitem>
***************
*** 600,613 ****
          </example>
        </div2>
-       
        <div2 id="faultdetailelements">
          <head>Fault Detail Elements</head>
          <p>The following subsections define a set of elements used to convey additional information
!         in the faults described in <specref ref="soapfaults"/>.</p>
          <ednote>
            <edtext>Additional detail elements may be defined if feedback during CR indicates that
              this would be useful.</edtext>
          </ednote>
-         
          <div3>
            <head>Problem Header</head>
--- 602,613 ----
          </example>
        </div2>
        <div2 id="faultdetailelements">
          <head>Fault Detail Elements</head>
          <p>The following subsections define a set of elements used to convey additional information
!           in the faults described in <specref ref="soapfaults"/>.</p>
          <ednote>
            <edtext>Additional detail elements may be defined if feedback during CR indicates that
              this would be useful.</edtext>
          </ednote>
          <div3>
            <head>Problem Header</head>
***************
*** 618,622 ****
                <def>
                  <p>The root element of the invalid header block, all descendants of the root element
!                 are also included.</p>
                </def>
              </gitem>
--- 618,622 ----
                <def>
                  <p>The root element of the invalid header block, all descendants of the root element
!                   are also included.</p>
                </def>
              </gitem>
***************
*** 636,640 ****
                <label>/wsa:ProblemHeaderQName</label>
                <def>
!                 <p>A QName representing the name of the root element of the problem header block.</p>
                </def>
              </gitem>
--- 636,641 ----
                <label>/wsa:ProblemHeaderQName</label>
                <def>
!                 <p>A QName representing the name of the root element of the problem header
!                 block.</p>
                </def>
              </gitem>
***************
*** 703,708 ****
                <def>
                  <p>This element (whose content is of type xs:unsignedLong) is a suggested minimum
!                   duration in milliseconds to wait before retransmitting the message. Omission of this
!                   element indicates that a retry is never likely to succeed.</p>
                </def>
              </gitem>
--- 704,709 ----
                <def>
                  <p>This element (whose content is of type xs:unsignedLong) is a suggested minimum
!                   duration in milliseconds to wait before retransmitting the message. Omission of
!                   this element indicates that a retry is never likely to succeed.</p>
                </def>
              </gitem>
***************
*** 715,728 ****
            </glist>
          </div3>
-         
        </div2>
-       
        <div2 id="soapfaults">
          <head>Predefined Faults</head>
          <ednote>
!           <edtext>Additional faults may be defined if feedback during CR indicates that
!             this would be useful.</edtext>
          </ednote>
-         
          <div3 id="invalidmapfault">
            <head> Invalid Addressing Header</head>
--- 716,726 ----
            </glist>
          </div3>
        </div2>
        <div2 id="soapfaults">
          <head>Predefined Faults</head>
          <ednote>
!           <edtext>Additional faults may be defined if feedback during CR indicates that this would
!             be useful.</edtext>
          </ednote>
          <div3 id="invalidmapfault">
            <head> Invalid Addressing Header</head>
***************
*** 735,743 ****
            <p> [Reason] the string: "A header representing a Message Addressing Property is not valid
              and the message cannot be processed" </p>
!           <p> [Details] either a &lt;wsa:ProblemHeader&gt; element  that conveys a copy of the
!             offending header or a
!             &lt;wsa:ProblemHeaderQName&gt; element that conveys the QName of the root element of the
!             offending header.</p>
!           <p>The invalid addressing header fault can be further narrowed in scope by use of the 
              additional [Subsubcode]s specified in the following subsections. Use of these
              [Subsubcode] values is OPTIONAL.</p>
--- 733,740 ----
            <p> [Reason] the string: "A header representing a Message Addressing Property is not valid
              and the message cannot be processed" </p>
!           <p> [Details] either a &lt;wsa:ProblemHeader&gt; element that conveys a copy of
!             the offending header or a &lt;wsa:ProblemHeaderQName&gt; element that conveys
!             the QName of the root element of the offending header.</p>
!           <p>The invalid addressing header fault can be further narrowed in scope by use of the
              additional [Subsubcode]s specified in the following subsections. Use of these
              [Subsubcode] values is OPTIONAL.</p>
***************
*** 762,775 ****
              <head>wsa:DuplicateMessageID</head>
              <p>Specifies that the invalid header conveyed a [message id] that was a duplicate of one
!             already received.</p>
            </div4>
            <div4>
              <head>wsa:ActionMismatch</head>
              <p>Specifies that the [action] and SOAPAction for the message did not match, [Details]
!               MAY contain a &lt;wsa:ProblemAction&gt;
!               element in addition to the &lt;wsa:ProblemHeader&gt; element or
!               &lt;wsa:ProblemHeaderQName&gt; element.</p>
            </div4>
-           
          </div3>
          <div3 id="missingmapfault">
--- 759,771 ----
              <head>wsa:DuplicateMessageID</head>
              <p>Specifies that the invalid header conveyed a [message id] that was a duplicate of one
!               already received.</p>
            </div4>
            <div4>
              <head>wsa:ActionMismatch</head>
              <p>Specifies that the [action] and SOAPAction for the message did not match, [Details]
!               MAY contain a &lt;wsa:ProblemAction&gt; element in addition to the
!               &lt;wsa:ProblemHeader&gt; element or &lt;wsa:ProblemHeaderQName&gt;
!               element.</p>
            </div4>
          </div3>
          <div3 id="missingmapfault">
***************
*** 780,785 ****
            <p> [Reason] the string: "A required header representing a Message Addressing Property is
              not present"</p>
!           <p> [Details] a &lt;wsa:ProblemHeaderQName&gt; element that conveys the QName of the
!             message addressing header that was missing.</p>
          </div3>
          <div3 id="destinationfault">
--- 776,781 ----
            <p> [Reason] the string: "A required header representing a Message Addressing Property is
              not present"</p>
!           <p> [Details] a &lt;wsa:ProblemHeaderQName&gt; element that conveys the QName of
!             the message addressing header that was missing.</p>
          </div3>
          <div3 id="destinationfault">
***************
*** 789,794 ****
            <p> [Subcode] a QName representing the value wsa:DestinationUnreachable</p>
            <p> [Reason] the string: "No route can be determined to reach [destination]"</p>
!           <p> [Details] an optional &lt;wsa:ProblemIRI&gt; element that conveys the [address] of the
!             [destination].</p>
          </div3>
          <div3 id="actionfault">
--- 785,790 ----
            <p> [Subcode] a QName representing the value wsa:DestinationUnreachable</p>
            <p> [Reason] the string: "No route can be determined to reach [destination]"</p>
!           <p> [Details] an optional &lt;wsa:ProblemIRI&gt; element that conveys the
!             [address] of the [destination].</p>
          </div3>
          <div3 id="actionfault">
***************
*** 798,803 ****
            <p> [Subcode] a QName representing the value wsa:ActionNotSupported</p>
            <p> [Reason] the string: "The [action] cannot be processed at the receiver"</p>
!           <p> [Details] a &lt;wsa:ProblemAction&gt; element with a REQUIRED &lt;wsa:Action&gt; child
!             element</p>
          </div3>
          <div3 id="unavailablefault">
--- 794,799 ----
            <p> [Subcode] a QName representing the value wsa:ActionNotSupported</p>
            <p> [Reason] the string: "The [action] cannot be processed at the receiver"</p>
!           <p> [Details] a &lt;wsa:ProblemAction&gt; element with a REQUIRED
!             &lt;wsa:Action&gt; child element</p>
          </div3>
          <div3 id="unavailablefault">
***************
*** 810,916 ****
            <p> [Subcode] a QName representing the value wsa:EndpointUnavailable</p>
            <p> [Reason] the string "The endpoint is unable to process the message at this time"</p>
!           <p> [Details] an optional &lt;wsa:RetryAfter&gt; element and an optional &lt;wsa:ProblemIRI&gt; element that conveys the [address] of the
!             [destination].</p>
          </div3>
        </div2>
-       
      </div1>
      <div1 id="securityconsiderations">
        <head>Security Considerations</head>
!       
!       <note><p>No assumptions are made herein of the application level security
!         requirement, the organization of the application, implementation of senders
!         or receivers, or of the ways that other protocols may make use of
!         WS-Addressing, and what security mechanisms they may employ.  A holistic
!         approach to security which considers all components of the application,
!         other protocols utilized, the way that these protocols compose with
!         WS-Security, and the use of other methods or additional techniques is highly
!         recommended.</p></note>
!       
!       <p>As discussed in &wsa-core.title;[<bibref ref="WSADDR-CORE"/>],
!         WS-Addressing supports capabilities that allow a message sender to
!         instruct a message receiver to send additional unsolicited messages to
!         other receivers of their choice and to control the contents of those
!         messages to an extent using reference parameters. The SOAP binding of
!         WS-Addressing transforms EPR reference parameters into SOAP headers and
!         this allows a message sender to request a message receiver to send
!         additional unsolicited SOAP messages to other receivers of their choice
!         and to specify a set of SOAP headers that must be included in such
!         messages.</p>
!       
!       <p>SOAP headers are a powerful extension mechanism and therefore great care
!         should be taken before honoring a [reply endpoint] or [fault endpoint]
!         to avoid inadvertent participation in the activities of malicious SOAP
!         message senders.</p>
!       
!       <p>WS-Addressing message addressing properties serialized as SOAP headers
!         (wsa:To, wsa:Action et al.) including those headers present as a result
!         of the [reference parameters] property should be integrity protected as
!         explained in &wsa-core.title;[<bibref ref="WSADDR-CORE"/>].</p>
!       
!       <p>Messages that use wsa:ReplyTo or wsa:FaultTo headers whose [address] is
!         not the predefined anonymous URI should include claims that allow a
!         receiver to confirm that the EPR was issued by a principle with
!         authority to represent the [address] of the EPR.</p>
!       
!       <p>When receiving a SOAP message, certain SOAP headers may have resulted
!         from the serialization of an EPR's [reference parameters] property. A
!         SOAP message receiver should perform additional security and sanity
!         checks to prevent unintended actions.</p>
!       
        <div2>
          <head>Establishing EPR Trust</head>
!         
!         <p>There are many mechanisms that could be used to supply proof that a
!           message sender has authority to represent the [address] of EPRs supplied
!           within the message. Typically such mechanisms require the inclusion of a
!           WS-Security[<bibref ref="WS-Security"/>] header that contains XML digital signatures
!           binding the wsa:ReplyTo and wsa:FaultTo elements to the SOAP message
!           using a security token issued by an authority trusted by the receiver of
!           the message for the domain of the [address] of the EPR. Possession of a
!           security token issued by a trusted  authority for the domain of the
!           [address] of the EPR provides a level of confidence that the message
!           sender has authority to represent the [address].</p>
!         
          <p>For example, a message could include a WS-Security[<bibref ref="WS-Security"/>] header
!           that contains XML digital signatures binding the wsa:ReplyTo and
!           wsa:FaultTo elements to the SOAP message using an X.509 certificate for
!           the domain addressed by the [address] of the EPR. If the certificate is
!           issued by a certificate authority trusted by the receiver of the message
!           then the receiver can can have some level of confidence that the message
            sender has authority to represent the [address] of the EPR.</p>
-         
        </div2>
-       
        <div2>
          <head>Additional Security Considerations</head>
!         
!         <p>The wsa:isReferenceParameter attribute is only meaningful on SOAP
!           headers. Message processors should consider its appearance elsewhere in
!           a SOAP message as a possible attack.</p>
!         
!         <p>Message processors should consider elements from the soap11, soap12 and
!           wsa namespaces appearing as reference parameters in an EPR as a possible
            attack.</p>
!         
!         <p>There are known XML ID and re-structuring attacks which should be
!           considered by message processors, see [<bibref ref="WS-Security"/>] - Security
!           Conciderations: Removal and modification of XML elements.</p>
        </div2>
-       
        <div2>
          <head>Additional Considerations for SOAP Intermediaries</head>
!         
!         <p>To avoid breaking signatures, intermediaries MUST NOT change the XML
!           representation of WS-Addressing headers when relaying those headers.
!           Specifically, intermediaries MUST NOT remove XML content that explicitly
!           indicates otherwise-implied content, and intermediaries MUST NOT insert
!           XML content to make implied values explicit. For instance, if a
!           RelationshipType attribute is present with a value of
!           <attval>&nsuri;/reply</attval>, an intermediary MUST NOT
!           remove it; similarly, if there is no RelationshipType attribute, an
!           intermediary MUST NOT add one.</p>
        </div2>
-       
      </div1>
      <div1 id="conformance">
--- 806,883 ----
            <p> [Subcode] a QName representing the value wsa:EndpointUnavailable</p>
            <p> [Reason] the string "The endpoint is unable to process the message at this time"</p>
!           <p> [Details] an optional &lt;wsa:RetryAfter&gt; element and an optional
!             &lt;wsa:ProblemIRI&gt; element that conveys the [address] of the
!           [destination].</p>
          </div3>
        </div2>
      </div1>
      <div1 id="securityconsiderations">
        <head>Security Considerations</head>
!       <note>
!         <p>No assumptions are made herein of the application level security requirement, the
!           organization of the application, implementation of senders or receivers, or of the ways
!           that other protocols may make use of WS-Addressing, and what security mechanisms they may
!           employ. A holistic approach to security which considers all components of the application,
!           other protocols utilized, the way that these protocols compose with WS-Security, and the
!           use of other methods or additional techniques is highly recommended.</p>
!       </note>
!       <p>As discussed in &wsa-core.title;[<bibref ref="WSADDR-CORE"/>], WS-Addressing supports
!         capabilities that allow a message sender to instruct a message receiver to send additional
!         unsolicited messages to other receivers of their choice and to control the contents of those
!         messages to an extent using reference parameters. The SOAP binding of WS-Addressing
!         transforms EPR reference parameters into SOAP headers and this allows a message sender to
!         request a message receiver to send additional unsolicited SOAP messages to other receivers
!         of their choice and to specify a set of SOAP headers that must be included in such messages.</p>
!       <p>SOAP headers are a powerful extension mechanism and therefore great care should be taken
!         before honoring a [reply endpoint] or [fault endpoint] to avoid inadvertent participation in
!         the activities of malicious SOAP message senders.</p>
!       <p>WS-Addressing message addressing properties serialized as SOAP headers (wsa:To, wsa:Action
!         et al.) including those headers present as a result of the [reference parameters] property
!         should be integrity protected as explained in &wsa-core.title;[<bibref ref="WSADDR-CORE"
!         />].</p>
!       <p>Messages that use wsa:ReplyTo or wsa:FaultTo headers whose [address] is not the predefined
!         anonymous URI should include claims that allow a receiver to confirm that the EPR was issued
!         by a principle with authority to represent the [address] of the EPR.</p>
!       <p>When receiving a SOAP message, certain SOAP headers may have resulted from the
!         serialization of an EPR's [reference parameters] property. A SOAP message receiver should
!         perform additional security and sanity checks to prevent unintended actions.</p>
        <div2>
          <head>Establishing EPR Trust</head>
!         <p>There are many mechanisms that could be used to supply proof that a message sender has
!           authority to represent the [address] of EPRs supplied within the message. Typically such
!           mechanisms require the inclusion of a WS-Security[<bibref ref="WS-Security"/>] header that
!           contains XML digital signatures binding the wsa:ReplyTo and wsa:FaultTo elements to the
!           SOAP message using a security token issued by an authority trusted by the receiver of the
!           message for the domain of the [address] of the EPR. Possession of a security token issued
!           by a trusted authority for the domain of the [address] of the EPR provides a level of
!           confidence that the message sender has authority to represent the [address].</p>
          <p>For example, a message could include a WS-Security[<bibref ref="WS-Security"/>] header
!           that contains XML digital signatures binding the wsa:ReplyTo and wsa:FaultTo elements to
!           the SOAP message using an X.509 certificate for the domain addressed by the [address] of
!           the EPR. If the certificate is issued by a certificate authority trusted by the receiver
!           of the message then the receiver can can have some level of confidence that the message
            sender has authority to represent the [address] of the EPR.</p>
        </div2>
        <div2>
          <head>Additional Security Considerations</head>
!         <p>The wsa:isReferenceParameter attribute is only meaningful on SOAP headers. Message
!           processors should consider its appearance elsewhere in a SOAP message as a possible
            attack.</p>
!         <p>Message processors should consider elements from the soap11, soap12 and wsa namespaces
!           appearing as reference parameters in an EPR as a possible attack.</p>
!         <p>There are known XML ID and re-structuring attacks which should be considered by message
!           processors, see [<bibref ref="WS-Security"/>] - Security Conciderations: Removal and
!           modification of XML elements.</p>
        </div2>
        <div2>
          <head>Additional Considerations for SOAP Intermediaries</head>
!         <p>To avoid breaking signatures, intermediaries MUST NOT change the XML representation of
!           WS-Addressing headers when relaying those headers. Specifically, intermediaries MUST NOT
!           remove XML content that explicitly indicates otherwise-implied content, and intermediaries
!           MUST NOT insert XML content to make implied values explicit. For instance, if a
!           RelationshipType attribute is present with a value of <attval>&nsuri;/reply</attval>,
!           an intermediary MUST NOT remove it; similarly, if there is no RelationshipType attribute,
!           an intermediary MUST NOT add one.</p>
        </div2>
      </div1>
      <div1 id="conformance">
***************
*** 935,941 ****
          <p>Endpoints MAY accept and respond to messages which contain no WSA headers.</p>
        </note>
!            <p>If a receiver processes a message containing a wsa:Action header,  
!           this SOAP binding is engaged, and the rules of this specification are in force.</p>
!       </div1>
      <div1 id="references">
        <head> References</head>
--- 902,908 ----
          <p>Endpoints MAY accept and respond to messages which contain no WSA headers.</p>
        </note>
!       <p>If a receiver processes a message containing a wsa:Action header, this SOAP binding is
!         engaged, and the rules of this specification are in force.</p>
!     </div1>
      <div1 id="references">
        <head> References</head>
***************
*** 943,957 ****
          <bibl key="WS-Addressing-Core" id="WSADDR-CORE" href="&w3c-designation-wsa-core;">
            <titleref>&wsa-core.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
!         <bibl key="WS-Addressing-WSDL" id="WSADDR-WSDL"
!           href="&w3c-designation-wsa-wsdl;">
            <titleref>&wsa-wsdl.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
!                 <bibl key="WSDL 2.0" id="WSDL20" href="&w3c-designation-wsa-wsdl;">
!                     <titleref>Web Services Description Language (WSDL)
! 		    Version 2.0 Part 1: Core Language</titleref>,
! 		    R. Chinnici, J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World Wide Web
!                     Consortium, 3 August 2005. This version of the WSDL 2.0 specification is
!                     http://www.w3.org/TR/2005/WD-wsdl20-20050803. The <loc
!                         href="http://www.w3.org/TR/wsdl20">latest version of WSDL 2.0</loc> is
!                     available at http://www.w3.org/TR/wsdl20.</bibl>
          <bibl key="IETF RFC 2119" href="http://www.ietf.org/rfc/rfc2119.txt" id="RFC2119">
            <titleref>Key words for use in RFCs to Indicate Requirement Levels</titleref>, S. Bradner,
--- 910,921 ----
          <bibl key="WS-Addressing-Core" id="WSADDR-CORE" href="&w3c-designation-wsa-core;">
            <titleref>&wsa-core.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
!         <bibl key="WS-Addressing-WSDL" id="WSADDR-WSDL" href="&w3c-designation-wsa-wsdl;">
            <titleref>&wsa-wsdl.title;</titleref>, M. Gudgin, M. Hadley, Editors.</bibl>
!         <bibl key="WSDL 2.0" id="WSDL20" href="&w3c-designation-wsa-wsdl;">
!           <titleref>Web Services Description Language (WSDL) Version 2.0 Part 1: Core
!           Language</titleref>, R. Chinnici, J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World
!           Wide Web Consortium, 3 August 2005. This version of the WSDL 2.0 specification is
!           http://www.w3.org/TR/2005/WD-wsdl20-20050803. The <loc href="http://www.w3.org/TR/wsdl20"
!             >latest version of WSDL 2.0</loc> is available at http://www.w3.org/TR/wsdl20.</bibl>
          <bibl key="IETF RFC 2119" href="http://www.ietf.org/rfc/rfc2119.txt" id="RFC2119">
            <titleref>Key words for use in RFCs to Indicate Requirement Levels</titleref>, S. Bradner,
***************
*** 1015,1019 ****
            Box, et al, <titleref>Simple Object Access Protocol (SOAP) 1.1</titleref>, May 2000.</bibl>
          <bibl id="WS-Security" key="WS-Security"
!           href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf"> OASIS, <titleref>Web Services Security: SOAP Message Security</titleref>, March
          2004.</bibl>
        </blist>
--- 979,984 ----
            Box, et al, <titleref>Simple Object Access Protocol (SOAP) 1.1</titleref>, May 2000.</bibl>
          <bibl id="WS-Security" key="WS-Security"
!           href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf"
!           > OASIS, <titleref>Web Services Security: SOAP Message Security</titleref>, March
          2004.</bibl>
        </blist>
Received on Tuesday, 22 November 2005 20:41:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:19:41 GMT