WSRP Security subgroup minutes 6/5

Attendees: Mark Cassidy, Jeff Broberg, Adam Noland, Dave Clegg, Carsten Leue, Rich Thompson, Alejandro Abdelnur, Thomas Schaeck

Discussion of questions arising from specification details:

1. Secure transport discussion(R401)

a) WSDL provides a mechanism to describe the transport binding for web service operations; this is the mechanism that should be used to specify the transport to be used for each WSRP operation(this assumes that we’ll be using WSDL for service descriptions; if that runs out not to be the case, this would need to be revisited). This provides per-operation granularity on transport mechanism to be used.

Editor note: while the SOAP binding extensions to WSDL provide a way to specify http transport, the underlying security mechanism of SSL/TLS is not exposed in the SOAP binding extensions. It seems that WSRP will need to specify transport security extensions to WSDL as provided for by the WSDL specification(Extensibility Elements).

b) It may be possible where a producer supports both secure and non-secure connections with the consumer for a given operation. In this case both bindings will be declared in the WSDL and it is up to the consumer to decide which to use. No negotiation is required here.

2. Authentication discussion(R402)

a) For signature-based authentication, WS-Security describes how to include a signature in a SOAP envelope. There are, however, no current standards which provide a way to describe encryption/decryption/signature capabilities a service provider has and expects a client to conform to. Rich stated that the WS-Policy effort currently under way is aimed at just this need. Discussion on whether WSRP should wait until work from that group is available or whether we should provide a WSRP-specific method for describing signature capabilities of a producer. General feeling was that it is important to be able to support use of digital signatures and that we can’t wait for the results of WS-Policy.

The supporting metadata a consumer will need in order to generate a signature compliant with XML-Signature standard includes:

- canonicalization method used

- digest algorithm

- transforms used

- key information

Rich indicated that WSDL supports sibling elements to the root ‘definitions’ element of a WSDL document; this could be used to describe signature capabilities of the service.

b) Discussion around signing of elements(or the entire document) for authentication:

Carsten raised the issue of whether there is support in current SOAP stacks for encryption/decryption. If not, encryption of elements will significantly increase complexity of supporting signatures since both parties in the transaction will need to implement additional support for marshalling/unmarshalling SOAP requests containing encrypted elements. Nobody was aware of existing SOAP implementations that support encryption/decryption functionality. The alternative would be to use encryption on payload data only, and not at the element level.

MarkC will do some investigation into the availability of support for this functionality.

Thomas questioned whether WSRP should define workarounds for functionality that will eventually be available from infrastructure components, and thus risk having portions of the WSRP standard become obsolete, or whether we should defer requirements until support is provided by the infrastructure.

c) DaveC asked whether we’re going to support passing end-user signatures through the portal. Consensus was that this is an important scenario to design for, though perhaps not implemented in the first version reference implementation.