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.