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

There was a problem, as indicated in [.1], with the previous email that I sent 
[.2]. Resending it in case more folks had the same problem. The only difference 
between the previous email [.2] and this resend is the addition of Nilo/Andreas' 
name.

-Anish
--

[.1] http://lists.w3.org/Archives/Public/public-ws-addressing/2005May/0037.html
[.2] http://lists.w3.org/Archives/Public/public-ws-addressing/2005May/0028.html

------------------------------------------------------------------------
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.; ERICSSON; Fujitsu Limited; Hitachi, Ltd.;
Oracle Corporation; SeeBeyond Technology Corporation; Sonic Software
Inc.; Sun Microsystems, Inc.; TIBCO Software, Inc. to this mapping of
arbitrary and opaque EIIs that constitute the [reference parameters],
as individual SOAP Header blocks, which 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 introduces
a serious security defect that will impact WS-Addressing adoption and
require remedial work to correct, possibly post Recommendation. Such
remedial work will extend the overall timeline for a high quality
WS-Addressing Recommendation."

Summary:

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

Details:

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 Header
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 echoing
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:
<wsa:EndpointReference>
   <wsa:Address>.../<wsa:Address>
   <wsa:ReferenceParameters>
     <ns1:DebitAccount>...</ns1:DebitAccount>
     <wsse:Security>...</wsse:Security>
     ...
   </wsa:ReferenceParameters>
</wsa:EndpointReference>

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 parameters]
introduce the equivalent of cookie-like echoing behavior to the world of Web
services. Unlike HTTP, where the cookies are limited to the HTTP headers
'Cookie' and 'Cookie2', [reference parameters] can set any SOAP header blocks.
An equivalent in the HTTP-world would be allowing 'Set-Cookie' and 'Set-Cookie2'
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 blocks
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 detected
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 [reference
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 understand
how to process this attribute. This invalidates the claim that the mapping
is constructed to not require the receiver of the messages to understand
WS-Addressing.

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 attributes
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
example:

<soap11:Envelope>
   <soap11:Header>
     <ns1:MyReferenceParameters1 soap12:role="http://example.com/role1"
                                 soap11:actor="http://example.com/role">
       ...
     </ns1:MyReferenceParameters1>
   </soap11:Header>
...
</soap11:envelope>


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, wsa:FaultTo
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:
<soap:Envelope>
   <soap:Header>
     <wsa:ReferenceParemeters>
       <ns1:MyReferenceParameters1>...</ns1:MyReferenceParameters1>
       <ns2:MyReferenceParameters2>...</ns2:MyReferenceParameters2>
     </wsa:ReferenceParameters>
   </soap:Header>
...
</soap:envelope>

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 intermediaries.
For example:

<soap:Envelope>
   <soap:Header>
     <wsa:ReferenceParemeters soap:role="http://example.org/role1">
       <ns1:MyReferenceParameters1>...</ns1:MyReferenceParameters1>
     </wsa:ReferenceParameters>
     <wsa:ReferenceParameters soap:role="http://example.org/role2">
       <ns2:MyReferenceParameters2>...</ns2:MyReferenceParameters2>
     </wsa:ReferenceParameters>
   </soap:Header>
...
</soap:envelope>


Regards.

Mark Little, Arjuna Technologies Ltd.
Rich Salz, DataPower Technology, Inc
Andreas Bjärlestam, ERICSSON
Nilo Mitra, ERICSSON
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.

[1] http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331/
[2] http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331/#bindrefp
[3]
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
[4] http://docs.oasis-open.org/wsrm/2004/06/WS-Reliability-CD1.086.pdf
[5] http://xml.coverpages.org/WS-ReliableMessaging200502.pdf
[6] http://www.oasis-open.org/committees/download.php/12416/WS-Context.zip

Received on Thursday, 19 May 2005 17:11:38 UTC