Key management, trust bootstrapping, federation and agreement on the technical details (ciphers, formats, algorithms) is outside the scope of WS-Security.
This might be the case of an application-level proxy at a network perimeter that will terminate TCP (transmission control protocol) connections.
One method for non-repudiation is to write transactions to an audit trail that is subject to specific security safeguards.
An evaluation in 2005[2] measured 25 types of SOAP messages of different size and complexity processed by WSS4J with both WS-Security and WS-SecureConversation on a Pentium 4/2.8 GHz CPU.
Some findings were: Another benchmark in 2006[3] resulted in this comparison: Web services initially relied on the underlying transport security.
As SOAP allows for multiple transport bindings, such as HTTP and SMTP, a SOAP-level security mechanism was needed.
In point-to-point situations confidentiality and data integrity can also be enforced on Web services through the use of Transport Layer Security (TLS), for example, by sending messages over HTTPS.
Applying TLS can significantly reduce the overhead involved by removing the need to encode keys and message signatures into XML before sending.