Although you could use https instead of http to ensure SOAP messages are encrypted when they pass from A to B, this is regarded as inadequate. One of the problems with using https is that if B decides to send the SOAP message to some other machine C, A has no control over whether https gets used by B. So, can we do something different about security without using https?

IBM, Microsoft and Verisign have released a specification called 'WS-Security' [12, 22, 37] that provides a number of ways in which SOAP messages can be transferred securely.

For example, you can:

• arrange for the SOAP message to include in its header a username and a password, and the server rejects unrecognised usernames and passwords;
• arrange for the SOAP message to include in its header a digital signature formed from its body using the sender's private key;
• arrange for the body of the SOAP message to be encrypted.

In this document, we will only look at the first of these: providing a username and a password.

The WS-Security specification provides three ways in which a username/password can be communicated in a UsernameToken element of the header of a SOAP message:

• only a username is provided;
• both a username and a password are provided in plain text;
• the password is encrypted.

In this document, we will only be looking at this last possibility.

However, even if the password is encrypted, ‘an evil intermediary could [capture the information in a SOAP header and later] send the hashed password and then could be authenticated as the original sender’ [27].

So in a later proposal (called the 'WS-Security Addendum' [13]), ‘instead of sending just a hash of the password, the addendum specifies that a digest version of the password should be sent [containing] a combination of the password, a Nonce (functionally a unique string that identifies this request), and the creation time’ [27]. A server could use the Nonce and the timestamp values to ensure that replays do not take place.