W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2004

RE: Problems with the SOAP binding

From: Srinivas, Davanum M <Davanum.Srinivas@ca.com>
Date: Tue, 21 Dec 2004 17:01:02 -0500
Message-ID: <87527035FDD42A428221FA578D4A9A5B08A8198C@usilms24.ca.com>
To: "Rich Salz" <rsalz@datapower.com>, <public-ws-addressing@w3.org>


Am thinking aloud here...so bear with me. If you see Scenario #2 in
OASIS WSS Interop [1]. I can easily see that we could send the whole
wsse:Security as a header property as shows below and the client can
just send the whole thing back as-is. If the client has to add its own
stuff then it follows the same rules as laid out in the OASIS WSS main
spec[2] Section #5 for intermediaries. Yes, we'd have to relax the rules
for opacity such that the client can modify the wsse header block. Will
this work?


    <wsse:Security soap:mustUnderstand="1"
		<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
			<xenc:DataReference URI="#enc-un"/>
	<xenc:EncryptedData wsu:Id="enc-un"

[1] http://lists.oasis-open.org/archives/wss/200306/msg00050.html 

-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Rich Salz
Sent: Saturday, December 18, 2004 6:25 PM
To: public-ws-addressing@w3.org
Subject: Problems with the SOAP binding

After some off-line discussion with Glen (sparked by my "+1"
response to Dims's proposal), I'm still concerned about the way the SOAP
binding promotes refp's to first-class SOAP headers.

Suppose a sender has a set of refp's and wants to make sure that they
come back, unmodified.  The natural way to do this would be to sign
them, with a single signature covering all the elements.
(There could be multiple signatures, but it's really not important

Where should that signature go?  Suppose the client is using
WS-Security.  The sender can't create a WS-Security header, since WSS
does not allow multiple WSS elements targeted to the same node.

Suppose the sender generates a signature element.  The current SOAP
binding says that this header must be promoted to top-level Header
element.  This conflicts with WSS which says that all security elements
should be contained within WSS.

Whenever an EPR has a signature, it seems impossible for the client to
be conformant with both WSS and WSA.  Gudge, you're also involved in
both groups -- can you prove me wrong?

The work-around -- the sender creates its own WSS header, with a unique
SOAP actor attribute that just happens to be an internal "alias" for the
server itself, is a real hack.

(I think this is a general problem whenever an EPR includes a refp that
is *part* of another header.  Folks have claimed that WS-RM could use
refps, perhaps by include a sequence ACK header.
But suppose the server just wants to identify the sequence, leaving it
up to the sender or WS-RM layer to determine whether to continue or
terminate.  But I'm on thin ice here, as I don't know how folks are
using WS-RM.  Not that I care a great deal, since it's a proprietary
spec and there's an open WS-ReliableMessaging already :).
I'm much more sure of the WSS/WSA conflict I described above.)

Unless I'm wrong, this seems to me like a fundamental flaw in the SOAP


Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview
Received on Tuesday, 21 December 2004 22:01:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:07 UTC