One thing you could do is that for every signature you could output a confirmation element all the time (or perhaps depending on some (global) flag). But no, someobody, somewhere, has to have the original signature (and state) so that it can be confirmed.

The order in which they appear in the SOAP envelope.

There are several. For Java there's the Apache security library. For C/C++ there's xmlsec which is built on libxml and OpenSSL. If you want just crypto there's also Wei Dai's crypto++ library. All of this brings up the questions what you are implementing in, and why?

It depends on what your library does. If you are not doing the full soap stack, then just return an error condition back to your caller. Perhaps provide a routine that will return a formatted fault message. The recommendations you read make no sense -- they've already gotten you to do all the work, hence subjected you to DoS; what you return, if anything, doiesnt matter.

No, they are not schema-invalid. There issue is that if a sender puts unknown elements directly inside a WSSE header, there could be security implications that the receiver does not understand. It's hard to imagine a real-world example. Suppose a sender generates a message that has an "expiration" value, saying that the crednetials should be completely ignored in 20 days. The obvious way to do that is with something like wsse:Security/tns:Expiration. If the receiver doesn't understand this header and processes the header a month from now ... But do note that it's a SHOULD not a MUST.

Hope this helps.

/r$