SOAP Version 1.2 Part 1: Messaging Framework

1.1 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].

As a convention, the namespace prefix "env" used in the prose sections of this document is associated with the SOAP namespace name "http://www.w3.org/2001/12/soap-envelope". Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [10]).

Namespace names of the general form "http://example.org/..." and "http://example.com/..." represent application or context-dependent URIs [6].

With the exception of examples and sections explicitly marked as "Non-Normative", all parts of this specification are normative.

1.2 Relation to other XML Specifications

A SOAP message is specified as an XML Information Set [10]. While all SOAP message examples in this document are shown using XML 1.0 [8] syntax, this is not a requirement of SOAP (see 4. SOAP Protocol Binding Framework).

Some of the information items defined by this document are identified using XML namespace [7] names (see 5. SOAP Message Construct). In particular, this document defines the following namespace names:

• The SOAP envelope has the namespace name "http://www.w3.org/2001/12/soap-envelope" (see 5. SOAP Message Construct).

• The SOAP Misunderstood element information item has the namespace name "http://www.w3.org/2001/12/soap-faults" (see 5.4.8 Must Understand Faults).

• The SOAP Upgrade element information item has the namespace name "http://www.w3.org/2001/12/soap-upgrade" (see 5.4.7 VersionMismatch Faults).

Normative XML Schema [4], [5] documents for these namespace names can be found by dereferencing the namespace names above.

SOAP does not require any XML schema processing (assessment or validation) in order to establish the values or correctness of element and attribute information items defined by this specification. These information items must, unless stated otherwise, be carried explicitly in the transmitted SOAP message (see 5. SOAP Message Construct).

SOAP attribute information items have types described by XML Schema: Datatypes [5]. Unless otherwise stated, all lexical forms are supported for each such attribute, and lexical forms representing the same value in the XML Schema value space are considered equivalent for purposes of SOAP processing. E.g. the boolean lexical forms "1" and "true" are interchangeable. For brevity, text in this specification refers only to one lexical form for each value, e.g. "if the value of the mustUnderstand attribute information item is "true"".

Specifications for the processing of application-defined data carried in a SOAP message but not defined by this specification MAY but need not call for additional validation of the SOAP message in conjunction with application-level processing. In such cases, the choice of schema language and/or validation technology is at the discretion of the application.

SOAP uses XML Base [11] for determining a base URI for relative URI references used as values in information items defined by this specification (see 6. Use of URIs in SOAP).

1.3 Example of SOAP Message

The following example shows a sample notification message expressed in SOAP. The message contains two pieces of application-defined data not defined by this specification: a header block with a local name of alertcontrol and a body element with a local name of alert . In general, header blocks contain information which may be of use to intermediaries as well as the ultimate destination(s) of the message. In this example an intermediary might prioritise the delivery of the message based on the priority and expiry information in the header block. The body contains the actual message payload, in this case the alert message.

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Header>
  <n:alertcontrol xmlns:n="http://example.org/alertcontrol">
   <n:priority>1</n:priority>
   <n:expires>2001-06-22T14:00:00-05:00</n:expires>
  </n:alertcontrol>
 </env:Header>
 <env:Body>
  <m:alert xmlns:m="http://example.org/alert">
   <m:msg>Pick up Mary at school at 2pm</m:msg>
  </m:alert>
 </env:Body>
</env:Envelope>

1.4 SOAP Terminology

This section describes the terms and concepts introduced in Part 1 of the SOAP specification (this document).

2.1 SOAP Nodes

A SOAP node can be the initial SOAP sender, an ultimate SOAP receiver, or a SOAP intermediary, in which case it is both a SOAP sender and a SOAP receiver.

A SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing model as described in this section and in the remainder of this specification.

A SOAP node MUST be identified by a URI.

2.2 SOAP Roles and SOAP Nodes

In processing a SOAP message, a SOAP node is said to act in one or more SOAP roles, each of which is identified by a URI known as the SOAP role name. The roles assumed by a node MUST be invariant during the processing of an individual SOAP message. This specification deals only with the processing of individual SOAP messages, no statement is made regarding the possibility that a given SOAP node might or might not act in varying roles when processing more than one SOAP message.

The following SOAP roles are defined by this specification:

"http://www.w3.org/2001/12/soap-envelope/role/next"

Each SOAP intermediary and ultimate SOAP receiver MUST act in this role and MAY additionally assume zero or more other SOAP roles.

"http://www.w3.org/2001/12/soap-envelope/role/none"

SOAP nodes MUST NOT act in this role.

"http://www.w3.org/2001/12/soap-envelope/role/ultimateReceiver"

To establish itself as an ultimate SOAP receiver a SOAP node MUST act in this role. SOAP intermediaries MUST NOT act in this role.

In addition to those described above, other roles MAY be defined as necessary to meet the needs of SOAP applications.

While the purpose of a SOAP role name is to identify a SOAP node or nodes, there are no routing or message exchange semantics associated with the SOAP role name. For example, SOAP roles MAY be named with a URI useable to route SOAP messages to an appropriate SOAP node. Conversely, it is also appropriate to use SOAP roles with names that are related more indirectly to message routing (e.g. "http://example.org/banking/anyAccountMgr") or which are unrelated to routing (e.g. a URI meant to identify "all cache management software"; such a header might be used, for example, to carry an indication to any concerned software that the containing SOAP message is idempotent, and can safely be cached and replayed).

Except for "http://www.w3.org/2001/12/soap-envelope/role/next", "http://www.w3.org/2001/12/soap-envelope/role/none" and "http://www.w3.org/2001/12/soap-envelope/role/ultimateReceiver" this specification does not prescribe the criteria by which a given node determines the (possibly empty) set of roles in which it acts on a given message. For example, implementations can base this determination on factors including, but not limited to: hardcoded choices in the implementation, information provided by the underlying protocol binding (e.g. the URI to which the message was physically delivered), configuration information made by users during system installation.

2.3 Targeting SOAP Header Blocks

SOAP header blocks carry optional role attribute information items (see 5.2.2 SOAP role Attribute) that are used to target the blocks to the appropriate SOAP node(s). This specification refers to the (implicit or explicit) value of the SOAP role attribute as the SOAP role for the corresponding SOAP header block.

A SOAP header block is said to be targeted to a SOAP node if the SOAP role for the header block is the name of a role played by the SOAP node.

Header blocks targeted to the special role "http://www.w3.org/2001/12/soap-envelope/role/none" are carried with the message to the ultimate SOAP receiver(s), but are never formally processed. Such blocks MAY carry data that is required for processing of other blocks.

2.4 Understanding SOAP Headers

It is likely that specifications for a wide variety of header functions will be developed over time (see 3. SOAP Extensibility Model), and that some SOAP nodes may include the software necessary to implement one or more such extensions. A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that block.

SOAP header blocks carry optional mustUnderstand attribute information items (see 5.2.3 SOAP mustUnderstand Attribute). When the value of such an attribute information item is "true", the SOAP block is said to be mandatory.

Mandatory blocks MUST be presumed to somehow modify the semantics of other headers or body elements. Therefore, for every mandatory SOAP header block targeted to a node, that node MUST either process the block or not process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP Messages and 5.4 SOAP Fault).

Tagging SOAP blocks as mandatory thus assures that such modifications will not be silently (and, presumably, erroneously) ignored by a SOAP node to which the header block is targeted.

The mustUnderstand attribute information item is not intended as a mechanism for detecting errors in routing, misidentification of nodes, failure of a node to serve in its intended role(s), etc., any of which may result in a failure to even attempt processing of a given SOAP header block from a SOAP envelope. This specification therefore does not require any fault to be generated based on the presence or value of this attribute on a SOAP header block not targeted at the current processing node, for example when it is suspected that such a block has survived erronously due to a routing or targeting error at a preceeding intermediairy. In particular, it is not an error for an ultimate SOAP receiver to receive a message containing a mandatory header block that is targeted to a role other than the ones assumed by the ultimate SOAP receiver.

2.5 Structure and Interpretation of SOAP Bodies

An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body (see 5.3 SOAP Body). However, Part 1 of this specification (this document) mandates no particular structure or interpretation of these elements, and provides no standard means for specifying the processing to be done.

2.6 Processing SOAP Messages

This section sets out the rules by which SOAP messages are processed. Unless otherwise stated, processing MUST be semantically equivalent to performing the following steps separately, and in the order given. Note however that nothing in this specification prevents the use of optimistic concurrency, roll back, or other techniques that might provide increased flexibility in processing order as long as all generated SOAP messages, SOAP faults and application-level side effects are equivalent to those that would be obtained by direct implementation of the following rules in the order shown below.

1. Determine the set of roles in which the node is to act. The contents of the SOAP envelope, including any header blocks and the body, MAY be inspected in making such determination.

2. Identify all header blocks targeted at the node that are mandatory.

3. If one or more of the header blocks identified in the preceding step are not understood by the node then generate a single SOAP fault with a value of "env:MustUnderstand" for faultcode (see 5.4.8 Must Understand Faults). If such a fault is generated, any further processing MUST NOT be done. Faults relating to the contents of the body MUST NOT be generated in this step.

4. Process all header blocks targeted at the node and, in the case of an ultimate SOAP receiver, the SOAP body. A SOAP node MUST process all SOAP header blocks targeted at it. A SOAP node MAY choose to ignore the processing implied by non-mandatory SOAP header blocks targeted at it.

5. In the case of a SOAP intermediary, and where the message is to be forwarded further along the message path, remove all SOAP header blocks targeted at the node, and possibly insert new SOAP header blocks.

In all cases where a SOAP header block is processed, the SOAP node MUST understand the SOAP block and MUST do such processing in a manner fully conformant with the specification for that block. An ultimate SOAP receiver MUST process the SOAP body, in a manner consistent with 2.5 Structure and Interpretation of SOAP Bodies.

Failure is indicated by the generation of a fault (see 5.4 SOAP Fault). SOAP message processing MAY result in the generation of at-most one fault. Header-related faults other than than those related to understanding header blocks (see 2.4 Understanding SOAP Headers) MUST conform to the specification for the corresponding SOAP header block.

SOAP nodes MAY make reference to any information in the SOAP envelope when processing a SOAP body or SOAP header block. For example, a caching function can cache the entire SOAP message, if desired.

The processing of a particular SOAP header block MAY control or determine the order of processing for other SOAP header blocks and/or the SOAP body. For example, one could create a SOAP header block to force processing of other SOAP header blocks in lexical order. In the absence of such a controlling block, the order of header and body processing is at the discretion of the SOAP node; header blocks MAY be processed in arbitrary order, and such processing MAY precede, MAY be interleaved with, or MAY follow processing of the body. For example, a "begin transaction" header block would typically precede, a "commit transaction" header block would likely follow, and a "logging" function might run concurrently with body processing.

2.7 Relaying SOAP Messages

As mentioned earlier in this section, it is assumed that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more features and expressed as SOAP extensions or as part of the underlying protocol binding (see 3. SOAP Extensibility Model and 4. SOAP Protocol Binding Framework). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.

2.8 SOAP Versioning Model

The version of a SOAP message is identified by the qualified name of the child element information item of the document information item. A SOAP Version 1.2 message has a child element information item of the document information item with a local name of Envelope and a namespace name of "http://www.w3.org/2001/12/soap-envelope" (see 5.1 SOAP Envelope).

A SOAP node determines whether it supports the version of a SOAP message on a per message basis. In this context "support" means understanding the semantics of that version of a SOAP envelope. The versioning model is directed only at the Envelope element information item. It does NOT address versioning of blocks, encodings, protocol bindings, or anything else.

A SOAP node MAY support multiple envelope versions. However, when processing a message, a SOAP node MUST use the semantics defined by the version of that message.

If a SOAP node receives a message whose version is not supported it MUST generate a fault (see 5.4 SOAP Fault) with a value of "env:VersionMismatch" for faultcode . Any other malformation of the message construct MUST result in the generation of a fault with a value of "env:Sender" for faultcode .

Appendix A. Version Transition From SOAP/1.1 to SOAP Version 1.2 defines a mechanism for transitioning from SOAP/1.1 to SOAP Version 1.2 using the Upgrade element information item (see 5.4.7 VersionMismatch Faults).

3.1 SOAP Features

For the purpose of this specification, the term "feature" is used to identify an abstract piece of functionality typically associated with the exchange of messages between communicating SOAP nodes. Although SOAP poses no constraints on the potential scope of such features, examples include "reliability", "security", "correlation", and "routing". In addition, the communication may require a variety of message exchange patterns (MEPs) like for example one-way messages, request/response interactions, and peer-to-peer conversations. MEPs are considered to be a type of feature, and unless otherwise stated, references in this specification to the term "feature" apply also to MEPs.

The SOAP extensibility model provides two mechanisms through which features may be expressed: the SOAP Processing Model and the SOAP Protocol Binding Framework (see 2. SOAP Processing Model and 4. SOAP Protocol Binding Framework). The former describes the behavior of a single SOAP node with respect to the processing of an individual message. The latter mediates the act of sending and receiving SOAP messages by a SOAP node via an underlying protocol.

The SOAP Processing Model enables SOAP nodes that include the mechanisms necessary to implement one or more features to express such features within the SOAP envelope as header blocks (see 2.4 Understanding SOAP Headers). Such header blocks can be intended for any SOAP node or nodes along a SOAP message path (see 2.3 Targeting SOAP Header Blocks).

In contrast, a SOAP protocol binding operates between two adjacent SOAP nodes along a SOAP message path. There is no requirement that the same underlying protocol is used for all hops along a SOAP message path. In some cases, underlying protocols are equipped, either directly or through extension, with mechanisms for providing certain features. The SOAP Protocol Binding Framework provides a scheme for describing these features and how they relate to SOAP nodes through a binding specification (see 4. SOAP Protocol Binding Framework).

The combination of the SOAP Processing Model and the SOAP Protocol Binding Framework provides some flexibility in the way that particular features can be expressed: they can be expressed entirely within the SOAP envelope (as header blocks), outside the envelope (typically in a manner that is specific to the underlying protocol), or as a combination of such expressions.

Certain features may require end-to-end as opposed to hop-to-hop processing semantics. While the SOAP Protocol Binding Framework provides for the possibility that such features may be expressed outside the SOAP envelope, it does not define a specific architecture for the processing or error handling of these externally expressed features by a SOAP intermediary. A binding specification that expresses such features external to the SOAP envelope should define its own processing rules to which a SOAP node is expected to conform (for example, describing what information must be passed along with the SOAP message as it leaves the intermediary). It is recommended that, where practical, end-to-end features be expressed as SOAP header blocks, so that the rules defined by the SOAP Processing Model can be employed.

3.2 SOAP Message Exchange Patterns

A message exchange pattern (MEP) is a template for the exchange of messages between SOAP Nodes supported by one or more underlying protocol binding instances.

This section is intended to act as a logical description of the operation of a MEP. It is not intended to describe a real implementation or to imply that a real implementation should be structured.

In general the definition of a message exchange pattern:

• describes the lifecycle of a message exchange conforming to the pattern.

• describes the temporal/causal relationships of multiple messages exchanged in conformance with the pattern.

• describes the normal and abnormal termination of a message exchange conforming to the pattern.

Underlying protocol binding specifications may declare their support for one or more named message exchange patterns.

Message exchange patterns are named by URI.

A message exchange has a lifecycle governed by a message exchange pattern.

4.1 Goals of the Binding Framework

The goals of the binding framework are:

1. To set out the requirements and concepts that are common to all binding specifications.

2. To facilitate homogenous description in situations where multiple bindings support common features.

3. To facilitate consistency in the specification of optional features.

Note, that the second and third goals above are related. Two or more bindings may offer a given optional feature, such as reliable delivery, with one binding exploiting an underlying protocol that directly facilitates the feature (the protocol is reliable), and the other providing the logic (logging and retransmission) in the binding. In such case, the feature can be made available to applications in a consistent manner, regardless of which binding is used.

4.2 Binding Framework

The creation, transmission, and processing of a SOAP message, possibly through one or more intermediaries, is specified in terms of a distributed state machine. The state consists of information known to a SOAP node at a given point in time, including but not limited to the contents of messages being assembled for transmission or received for processing. The state at each node can be updated either by local processing, or by information received from an adjacent node.

Section 2. SOAP Processing Model of this specification describes the processing that is common to all SOAP nodes when receiving a message. The purpose of a binding specification is to augment those core SOAP rules with additional processing that is particular to the binding, and to specify the manner in which the underlying protocol is used to transmit information between adjacent nodes in the message path.

Thus, the distributed state machine that manages the transmission of a given SOAP message through its message path is the combination of the core SOAP processing (see 2. SOAP Processing Model) operating at each node, in conjunction with the binding specifications connecting each pair of nodes. A binding specification MUST enable one or more message exchange pattern.

In cases where multiple features are supported by a binding specification the specifications for those features MUST provide any information necessary for their successful use in combination; this binding framework does not provide any explicit mechanism for ensuring such compatibility of multiple features.

The binding framework provides no fixed means of naming or typing the information comprising the state at a given node. Individual feature and binding specifications are free to adopt their own conventions for specifying state. Note, however, that consistency across bindings and features is likely to be enhanced in situations where multiple feature specifications adopt consistent conventions for representing state. For example, multiple features may benefit from a consistent specification for an authentication credential, a transaction ID, etc. The HTTP binding in SOAP Part 2 [1] illustrates one such convention.

As described in 5. SOAP Message Construct, each SOAP message is modeled as an XML Infoset that consists of a document information item with exactly one child: the envelope element information item. Therefore, the minimum responsibility of a binding in transmitting a message is to specify the means by which the SOAP XML Infoset is transferred to and reconstituted by the binding at the receiving SOAP node and to specify the manner in which the transmission of the envelope is effected using the facilities of the underlying protocol.

The binding framework does NOT require that every binding use the XML 1.0 [8] serialization as the "on the wire" representation of the Infoset; compressed, encrypted, fragmented representations and so on can be used if appropriate. A binding, if using XML 1.0 serialization of the infoset, MAY mandate that a particular character encoding or set of encodings be used.

Bindings MAY depend on state that is modeled as being outside of the SOAP XML Infoset (e.g. retry counts), and MAY transmit such information to adjacent nodes. For example, some bindings take a message delivery address (typically URI) that is not within the envelope; the HTTP binding in Part 2 [1], section Using SOAP in HTTP, transmits an HTTP field named SOAPAction that is not contained within the SOAP XML Infoset.

5.1 SOAP Envelope

The Envelope element information item has:

• A [local name] of Envelope .

• A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".

• Zero or more namespace qualified attribute information items amongst its [attributes] property.

• One or two element information items in its [children] property in order as follows:

  1. An optional Header element information item (see 5.2 SOAP Header).

  2. A mandatory Body element information item (see 5.3 SOAP Body).

"http://www.w3.org/2001/12/soap-encoding"
"http://example.org/encoding/"
""

5.2 SOAP Header

The SOAP Header element information item provides a mechanism for extending a SOAP message in a decentralized and modular way (see 3. SOAP Extensibility Model and 2.4 Understanding SOAP Headers).

The Header element information item has:

• A [local name] of Header .

• A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".

• Zero or more namespace qualified attribute information items in its [attributes] property.

• Zero or more namespace qualified element information items in its [children] property.

Each child element information item of the SOAP Header is called a SOAP header block.

<env:Header xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <t:Transaction xmlns:t="http://example.org/2001/06/tx" 
                env:mustUnderstand="true" >
   5
 </t:Transaction>
</env:Header>

5.3 SOAP Body

A SOAP body provides a mechanism for transmitting information to an ultimate SOAP receiver (see 2.5 Structure and Interpretation of SOAP Bodies).

The Body element information item has:

• A [local name] of Body .

• A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".

• Zero or more namespace qualified attribute information items in its [attributes] property. These MAY include an encodingStyle attribute information item.

• Zero or more namespace qualified element information items in its [children] property.

5.4 SOAP Fault

A SOAP fault is used to carry error information within a SOAP message.

The Fault element information item has:

• A [local name] of Fault .

• A [namespace name] of "http://www.w3.org/2001/12/soap-envelope".

• Two or more child element information items in its [children] property in order as follows:

  1. A mandatory faultcode element information item (see 5.4.1 SOAP faultcode Element).

  2. A mandatory faultstring element information item (see 5.4.2 SOAP faultstring Element).

  3. An optional faultnode element information item (see 5.4.3 SOAP faultnode Element).

  4. An optional faultrole element information item (see 5.4.4 SOAP faultrole Element).

  5. An optional detail element information item (see 5.4.5 SOAP detail Element).

To be recognized as carrying SOAP error information, a SOAP message MUST contain exactly one SOAP Fault as the only child element of the SOAP body. A SOAP fault element information item MAY appear within a SOAP header block, or as a descendant of a child element information item of the SOAP body; but, in such cases, the element has no SOAP-defined semantics.

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/10/soap-envelope">
 <env:Header>
  <V:Upgrade xmlns:V="http://www.w3.org/2001/12/soap-upgrade">
   <envelope qname="ns1:Envelope" 
             xmlns:ns1="http://www.w3.org/2002/10/soap-envelope"/>
   <envelope qname="ns2:Envelope" 
             xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>
  </V:Upgrade>
 </env:Header>
 <env:Body>
  <env:Fault>
   <faultcode><value>env:VersionMismatch</value></faultcode>
    <faultstring>Version Mismatch</faultstring>
   </env:Fault>
 </env:Body>
</env:Envelope>

<?xml version="1.0" ?>
<env:Envelope xmlns:env='http://www.w3.org/2001/12/soap-envelope'>
  <env:Header>
    <abc:Extension1 xmlns:abc='http://example.org/2001/06/ext'
       env:mustUnderstand='true'/>
    <def:Extension2 xmlns:def='http://example.com/stuff'
       env:mustUnderstand='true' />
  </env:Header>
  <env:Body>
    . . .
  </env:Body>
</env:Envelope>

<?xml version="1.0" ?>
<env:Envelope xmlns:env='http://www.w3.org/2001/12/soap-envelope'
              xmlns:f='http://www.w3.org/2001/12/soap-faults' >
 <env:Header>
  <f:Misunderstood qname='abc:Extension1'
                   xmlns:abc='http://example.org/2001/06/ext' />
  <f:Misunderstood qname='def:Extension2'
                   xmlns:def='http://example.com/stuff' />
 </env:Header>
 <env:Body>
  <env:Fault>
   <faultcode><value>env:MustUnderstand</value></faultcode>
   <faultstring>One or more mandatory 
                headers not understood</faultstring>
  </env:Fault>
 </env:Body>
</env:Envelope>

7.1 SOAP Nodes

SOAP can carry application-defined data as SOAP header blocks or as SOAP body contents. Processing a SOAP header block may include dealing with side effects such as state changes, logging of information, or the generation of additional messages. It is strongly recommended that only well-defined header blocks with known security implications of any side effects be processed by a SOAP node.

As for SOAP header blocks, processing a SOAP body may imply the occurrence of side affects that may, if not properly understood, have severe consequences for the receiving SOAP node. As for SOAP header blocks, it is strongly recommended that only well-defined body contents with known security implications be processed.

Security considerations, however, are not just limited to recognizing the immediate child elements of the SOAP header and the SOAP body. Implementers should pay special attention to the security implications of all data carried within a SOAP message that can cause the remote execution of any actions in the receiver's environment. This includes not only data expressed in XML infoset but data that may be encoded as binary data or carried as parameters like for example URI query strings. Before accepting data of any type, an application should be aware of the particular security implications associated with that data within the context it is being used.

SOAP implementers should be careful to ensure that if processing of the various parts of a SOAP message is provided through modular software architecture, that each module is aware of the overall SOAP security context. For example, a SOAP body should not be processed without knowing the SOAP context in which it was received.

7.2 SOAP Intermediaries

SOAP inherently provides a distributed processing model that may involve a SOAP message passing through multiple SOAP nodes (see 2. SOAP Processing Model). SOAP intermediaries are by definition men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Security breaches on systems that run SOAP intermediaries can result in serious security and privacy problems. A compromised SOAP intermediary, or an intermediary implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.

In analyzing the security implications of potential SOAP related security problems, it is important to realize that the scope of security mechanisms provided by the underlying protocol may not be the same scope as the whole message path of the SOAP message. There is no requirement in SOAP that all hops between participating SOAP nodes use the same underlying protocol and even if this was the case, the very use of SOAP intermediaries is likely to reach beyond the scope of transport-level security.

7.3 Underlying Protocol Bindings

The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Binding specification authors should describe, in detail, the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification (see 4. SOAP Protocol Binding Framework).

In addition, a binding specification may not address or provide countermeasures for all aspects of the inherent security risks. The binding specification authors should identify any such risks as might remain and indicate where further countermeasures would be needed above and beyond those provided for in the binding specification.

Binding specification authors should be aware that SOAP extension modules expressed as SOAP header blocks may affect the underlying protocol in unforeseen ways. It is strongly recommended that a binding specification should describe any such interactions. For example, a SOAP message carried over a particular protocol binding may result in seemingly conflicting features such as might be the case with HTTP basic auth combined with a SOAP based authentication mechanism.

8.1 Normative References

1

W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, @@@@2002 (See soap12-part2.html.)

2

IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, January 1997. (See http://www.ietf.org/rfc/rfc2616.txt.)

3

IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)

4

W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.)

5

W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.)

6

IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (See http://www.ietf.org/rfc/rfc2396.txt.)

7

W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See http://www.w3.org/TR/1999/REC-xml-names-19990114/.)

8

W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006.)

9

W3C Recommendation "XML Linking Language (XLink) Version 1.0", Steve DeRose, Eve Maler, David Orchard, 27 June 2001. (See http://www.w3.org/TR/2000/REC-xlink-20010627/.)

10

W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.)

11

W3C Recommendation "XML Base", Johnathan Marsh, 27 June 2001. (See http://www.w3.org/TR/2001/REC-xmlbase-20010627/.)

12

IETF "RFC 2732: Format for Literal IPv6 Addresses in URL's", R. Hinden, B. Carpenter, L. Masinter, December 1999. (See http://www.ietf.org/rfc/rfc2732.txt.)

8.2 Informative References

13

XML Protocol Comments Archive (See http://lists.w3.org/Archives/Public/xmlp-comments/.)

14

XML Protocol Discussion Archive (See http://lists.w3.org/Archives/Public/xml-dist-app/.)

15

XML Protocol Charter (See http://www.w3.org/2000/09/XML-Protocol-Charter.)

16

W3C Working Draft "XML Protocol (XMLP) Requirements", Vidur Apparao, Alex Ceponkus, Paul Cotton, David Ezell, David Fallside, Martin Gudgin, Oisin Hurley, John Ibbotson, R. Alexander Milowski, Kevin Mitchell, Jean-Jacques Moreau, Eric Newcomer, Henrik Frystyk Nielsen, Mark Nottingham, Waqar Sadiq, Stuart Williams, Amr Yassin, @@@@2002. This is work in progress. (See xmlp-reqs.html.)

17

W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer, 8 May 2000. (See http://www.w3.org/TR/SOAP/.)

18

IETF "RFC 1900: Renumbering Needs Work", B. Carpenter, Y. Rekhter, February 1996. (See http://www.ietf.org/rfc/rfc1900.txt.)

19

IETF "RFC 1123: Requirements for Internet Hosts -- Application and Support", R. Braden, October 1989. (See http://www.ietf.org/rfc/rfc1123.txt.)

20

IETF "RFC 793: Transmission Control Protocol", DARPA, September 1981. (See http://www.ietf.org/rfc/rfc793.txt.)