WSRP Security subgroup minutes 6/12
Attendees: Mark Cassidy, Carsten Leue, Rich Thompson, Mike Freedman, Alejandro Abdelnur, Jeff Broberg
Discussion around interoperability issues with digital signatures and encryption:
1. Use of XML-Signature ‘enveloped’ digital signatures results in an additional element for the signature and shouldn’t impact the ability to use current SOAP stacks. No disagreement with this regarding SOAP4J, some question about whether there are any issues with .NET. Nobody had enough experience with using .NET to say whether there would be interoperability issues there.
2. Use of XML-Encryption is limited to the encryption of element contents unless a producer and consumer choose to implement special handlers for marshalling/unmarshalling encrypted elements, or until support for XML-Encryption is provided in widely-used SOAP implementations.
3. Question raised on whether a key exchange mechanism needs to be defined. The XML Signature specification provides a mechanism for specifying key info; this mechanism is also leveraged in the XML Encryption and WS-Security specifications. Conclusion was that WSRP will recommend this standard and won’t specify any new mechanism here.
It was re-affirmed that the first version of the spec needs to address how to use digital signatures with WSRP, and that, lacking any standard for describing service capabilities/policies for signatures, WSRP would need to define metadata to facilitate the use of digital signatures and parameter data encryption.
Discussion around metadata requirements for using transport-level security:
4. Is there a need for WSRP metadata for secure transport beyond the WSDL SOAP transport binding extensions? For example, details of certificate usage with SSL/TLS is not covered in the SOAP binding extensions. However, if the SSL/TLS protocol provides a mechanism to resolve certificate usage at runtime(believe that to be the case), WSRP metadata extensions would not be required. All that would be required is for the portal administrator to deploy the certificate to the container hosting the portal application during the setup of trust relations with the portlet, and the container would handle certificate usage whenever the portal asks for a secure connection to portlet service.
Discussion around portlet requiring specific end-user authentications(R406, R407, R408): 5. SAML would be the applicable standard to apply to these requirements. However, since SAML is not widely available and adds significant complexity to a WSRP portlet deployment, it was decided to defer these requirements from the first version of the specification.
Discussion around end-user profiles:
6. Are user-profile data handled any differently from other portlet parameters? General consensus here was:
- an optional user profile data object should be defined; portal would only transfer profile elements allowed by privacy settings in the portal.
- it was suggested that standard profile elements could be defined based on VCARD, Liberty/Passport, or directory-based standards
- profile data SHOULD be transferred confidentially
About legal issues related to transferring profile data: responsibility lies with the portal to enforce any privacy requirements for transferring user profile data to the portlet.
Discussion about whether a portal can apply encryption to data that the portlet does not require to be encrypted. Conclusion was that a portal may choose to use a portlet-supported encryption mechanism to encrypt parameter data the portlet doesn’t explicitly ask for in encrypted form..
7. RichT indicated he was approached by a standards group working on a rights language and asked if they could be put on the list of standards to consider for use with WSRP. A link to their spec draft will be circulated when they make it available to Rich.