RE: Problems with the SOAP binding


Am thinking aloud 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="">
			<xenc:DataReference URI="#enc-un"/>
	<xenc:EncryptedData wsu:Id="enc-un"


-----Original Message-----
[] On Behalf Of Rich Salz
Sent: Saturday, December 18, 2004 6:25 PM
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
XS40 XML Security Gateway
XML Security Overview

Received on Tuesday, 21 December 2004 22:01:03 UTC