Formal objection to the binding of [reference properties] in SOAP

The 'Web Services Addressing 1.0 - SOAP Binding' Last Call Working Draft
[1] binds each Element Information Item (EII) in [reference parameters]
Message Addressing Property (MAP) as a separate [2] SOAP Header blocks.
This email constitutes a formal objection from Arjuna Technologies Ltd.;
DataPower Technology, Inc.; Fujitsu Limited; Hitachi, Ltd.; Oracle 
SeeBeyond Technology Corporation; Sonic Software Inc.; Sun Microsystems, 
TIBCO Software, Inc. to this mapping of arbitrary and opaque EIIs that
constitute the [reference parameters], as individual SOAP Header blocks, 
consumers are required to echo back. We believe it is important to have 
a high
quality WS-Addressing Recommendation as soon as possible. We believe 
that the
current formulation of [reference parameters] in the SOAP binding 
a serious security defect that will impact WS-Addressing adoption and 
remedial work to correct, possibly post Recommendation. Such remedial work
will extend the overall timeline for a high quality WS-Addressing


It is our opinion that such a mapping poses problems for --

1) Safety and Security
2) Composability
3) Simplicity, Module Independence and Layering
4) Validation of SOAP Header blocks


We detail the problems (summarized above) with such a mapping along with
a potential solution that does not suffer from the same problems.

1) Safety and Security

The sender of a SOAP message is typically responsible for including SOAP 
blocks and expected to understand the implications of such inclusion. 
The sender
also decides the values of the mustUnderstand attribute, the actor/role
attribute, the relay attribute, and the reinsert attribute for those SOAP
headers and accept the consequences of these choices. SOAP headers have
well-defined semantics and perhaps contractual obligations associated 
with them.

Contrary to this understanding, the SOAP binding of [reference parameters]
REQUIRES that each of the EIIs be bound as a SOAP Header blocks and treats
these Headers blocks as opaque. This essentially provides an echoing device,
but without any restrictions on the SOAP Header blocks that can be 
required to
be echoed (unlike the HTTP-Session/Cookie mechanism). This unrestricted 
has serious security and safety consequences, which are not necessarily
circumvented by signing and using only trusted sources of
EndpointReferences (EPR).

Consider an EPR as follows:

Dereferencing the above EPR requires the consumer to include the
ns1:DebitAccount and wsse:Security SOAP header blocks in the message.

The use of [reference parameters] can be compared to the use of
Cookies/HTTP state management mechanism over the Web. [reference 
introduce the equivalent of cookie-like echoing behavior to the world of 
services. Unlike HTTP, where the cookies are limited to the HTTP headers
'Cookie' and 'Cookie2', [reference parameters] can set any SOAP header 
An equivalent in the HTTP-world would be allowing 'Set-Cookie' and 
HTTP header to determine the values of any HTTP headers ('Accept*',
'Host', 'Authorization', etc) that the user-agent sets in a HTTP-request.

2) Composability

Arbitrary SOAP header blocks that are REQUIRED to be echoed back by the
consumer may conflict with other SOAP header blocks that a sender may 
have to
send due to local policies or previously agreed upon contracts. Header 
REQUIRED by the [reference parameters] may be incompatible with such blocks
REQUIRED for other reasons, or may duplicate them, or may simply violate
existing contracts.

SOAP Header blocks are a principal extensibility mechanism in SOAP.
This binding severely impedes composability, as such errors cannot be 
by an encapsulated WS-Addressing module, but instead must occur at the SOAP
infrastructure layer.

SOAP Header blocks are typically part of a SOAP module and express
certain functionality. For example, WS-Security [3], WS-Reliability [4],
WS-ReliableMessaging [5], WS-Context [6] etc, specify SOAP Header blocks
that have a particular meaning that is conveyed from the sender to the
receiver. Specifications in the realm of Web services are designed to be
composable with other specification. For example, WS-Context can be composed
with WS-ReliableMessaging/WS-Reliability and WS-Security.

A consuming application that dereferences an EPR that contains
[reference parameters] may have some policies in place wrt to
reliability, security, coordination, transaction, privacy etc. Given
that [reference parameters] may contain any arbitrary EIIs and these
are bound as individual SOAP header blocks, this binding can potentially
interfere with composability of WS-Addressing with other WS-* specs that
the consumer may be using.

As an example, consider the use of the EPR specified in (1) above along 
with a
local policy that requires signing of the SOAP Body using WS-Security. A
WS-Security module that signs the SOAP Body but does not check for 
parameters] will emit a SOAP envelope with two wsse:Security Header blocks.

3) Simplicity, Module independence and Layering

To prevent any unintended consequences of echoing SOAP Header blocks
from [reference parameters], a SOAP infrastructure must scan all the
EIIs in [reference parameters] to make sure that they do not conflict
with other SOAP extensions (that use SOAP Header blocks) that the sender
may be using.

In many modern SOAP processing systems, independent code modules are
responsible for processing extensions. In general each of these modules
is directly responsible for a small subset of SOAP Header blocks.
Requiring a WS-Addressing module to insert an arbitrary number
of arbitrary SOAP Header blocks breaks this layering of modules. For
example, the security module may be the first module that processes the
incoming SOAP message and the last module that processes the outgoing
SOAP message, and may do so independently of the reliable messaging 
module. When
WS-Addressing is being used, every module in the system should, if
it is to be maximally robust, confirm that any SOAP header block that 
may have
been inserted in the SOAP message as a consequence of [reference parameters]
do not conflict with its own.

4) Validation of SOAP Header blocks

The binding of [reference parameters] to SOAP requires that each 
parameter when
it morphs into a SOAP Header block be tagged with a wsa:IsReferenceParameter
attribute. This imposes a requirement that every SOAP Header block that 
is used
as a [reference parameter] be extensible via attributes. This will not 
always be
the case. SOAP nodes that do not understand WS-Addressing will not 
how to process this attribute. This invalidates the claim that the mapping
is constructed to not require the receiver of the messages to understand

Additional complications are introduced as the consumer of the EPR 
includes the
parameters as they are. This means that an EPR that is expected to be 
used with
SOAP 1.1 and SOAP 1.2 has to include both the SOAP 1.1 and SOAP 1.2 
on the [reference parameters] breaking the abstractness of EPRs. This also
leads to SOAP 1.1 messages that contain SOAP 1.2 attribute and vice 
versa, for

     <ns1:MyReferenceParameters1 soap12:role=""

Providing a different binding, as mentioned below, will provide
simplicity, requiring no extra processing or consistency checks.

Potential Solutions:

Wrapping the reference parameters with a WS-Addressing specific element
with a clear and well-defined semantics would prevent the problems outlined
above. There are two approaches that would accomplish this --

1) Make wsa:To an EPR
Change the type of wsa:To to an EPR, this will allow the [reference
Properties] to be included in the wsa:To SOAP Header block and provide
the needed echoing mechanism. This would also correct the current asymmetry
in the types of 'destination' SOAP header blocks (wsa:To is a URI, 
is an EPR and wsa:ReplyTo is an EPR).

2) Define a new SOAP Header Block

a) One bag for all [reference parameters]

Include all the [reference parameters] inside a well defined SOAP Header
block with well defined semantics (opaque data that is echoed back).
For example:

b) One SOAP Header block instance for every [reference parameters]

Include an instance of a well defined SOAP Header block with well defined
semantics (opaque data that is echoed back) for each parameter.
This would allow individual parameters to be targeted to SOAP 
For example:

     <wsa:ReferenceParemeters soap:role="">
     <wsa:ReferenceParameters soap:role="">


Mark Little, Arjuna Technologies Ltd.
Rich Salz, DataPower Technology, Inc
Tom Rutt, Fujitsu Limited
Jacques Durand, Fujitsu Limited
Robert Freund, Hitachi, Ltd.
Eisaku Nishiyama, Hitachi, Ltd.
Anish Karmarkar, Oracle Corporation
Jeff Mischkinsky, Oracle Corporation
Ugo Corda, SeeBeyond Technology Corporation
Pete Wenzel, SeeBeyond Technology Corporation
Glen Daniels, Sonic Software, Inc.
Arun Gupta, Sun Microsystems, Inc.
Marc Hadley, Sun Microsystems, Inc.
David Hull, TIBCO Software, Inc.
Amelia Lewis, TIBCO Software, Inc.


Received on Monday, 16 May 2005 21:03:38 UTC