Action item "Ugo to propose text for Sections 3.15.2 and 3.15.3 on security implications for SOAP and WSDL"

In response to the action item from today's F2F meeting, please review the following text to be added to 3.15.2. (It's derived from harvesting the WS-I Security Profile Draft).

I think it is still premature to discuss security implications for WSDL, since I noticed that neither OASIS WSS nor WS-I Security Profile have addressed the subject so far.

Ugo

============================================================= 

3.15.2.1 Security Implications

Mechanisms to enforce SOAP Message Security may be applied to the transport layer, to the message layer, to the application layer (data payload), or to a combination of these layers. Here we'll only address the HTTP transport layer and the message layer.

3.15.2.1.1 Transport Layer

Integrity and confidentiality may be provided for an entire SOAP message using the transport layer. When SSL/TLS is used in conjunction with HTTP (HTTPS), the entire HTTP message is protected as well, including the SOAP message conveyed in the HTTP body. This integrity/confidentiality is only in effect for the duration of the HTTP session and provides no protection for SOAP Messages once received. Note that integrity/confidentiality is provided for all of the SOAP message - partial integrity/confidentiality is not possible with this mechanism. This mechanism is not suitable for end-end SOAP Message integrity/confidentiality in the presence of SOAP intermediaries.

The web service provider may authenticate to the web service requester using transport layer mechanisms such as SSL/TLS using a server X.509 certificate. Vice versa, the web service requester may authenticate to the web service provider using HTTPS-based X.509 client certificate authentication, or HTTP using basic or digest authentication. Mutual authentication is provided when authentication is applied in both directions.

3.15.2.1.2 Message Layer

Security services may be provided at the SOAP Messaging protocol layer using the SOAP Message Security specification from the Oasis SOAP Message Security technical committee in conjunction with token specifications developed in that committee.

Integrity may be provided to a portion or combination of SOAP Message payload, header blocks and attachments using XML Digital Signature as outlined in the SOAP Message Security specification. 

Confidentiality may be provided to portions or some number of SOAP Message body or header block element or element content using XML Encryption as outlined in the SOAP Message Security specification.

Both integrity and confidentiality provided at the message level have the advantage that they remain with the SOAP message beyond an HTTPS session, suitable for providing end-end integrity despite SOAP intermediaries.

A SOAP Sender (either an initial SOAP sender or a SOAP intermediary) may provide authentication for one or more SOAP receivers by including one or more appropriate SOAP Message security tokens in security headers targeted at the receiver roles. Such tokens may be used in combination with XML Signatures as profiled by SOAP Message Security to provide confirmation of the token claims and to bind the claims to the message.

3.15.2.1.3 Choosing the appropriate security layer

The choice often depends on application requirements, based on answers to questions such as:

1. Does the protection need to exist beyond the transport session, protecting SOAP messages when queued at a SOAP node for example?
2. Is it necessary to apply integrity and/or confidentiality at a granularity other than the entire SOAP Message. This is usually true when SOAP intermediary processing is expected.
3. Is there a need to save evidence such as authentication assertions for subsequent dispute resolution?
4. Is there a need for transport layer protocol independence?