RE: XML protocol security

While I agree with many of the points made below in this thread, the fact
that they are considered aspects of SOAP betrays confusion between what is
mandated by the SOAP specification versus permitted by it.  
 
The SOAP specification is not intended to be a soup-to-nuts design of every
feature that applications might find useful.  Rather, it is predicated on
the idea that specifications should be layered and composable, and so SOAP
defines just the bare essentials of an envelope and a distributed
extensibility mechanism.  That extensibility mechanism is particularly
important, since, unlike many more rigid protocol designs, it allows
features to be added to a message in a reliable way. Instead of building all
features into the base protocol, SOAP gives the sender of a message a way to
mark elements to indicate that they are required extensions to the protocol
(see the soap-env:mustUnderstand attribute).  
 
For example, the SOAP spec does not require or forbid object references.
Object references, and everything attendant to them, are compatible with
SOAP but properly should appear in separate specification.  'The discussion
of whether object references are a good or bad idea is not something that
the SOAP specification per se takes a stand on. If however, a particular
message relies on object references per a certain specification, SOAP
provides the soap-env:mustUnderstand attribute so that this fact can become
part of that message's contract.  
 
Similarly, a security model is not built into SOAP.  But, whatever security
model is chosen as valuable, it can be added to a SOAP message in a reliable
way.