[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp][security] agenda for 6/12 telecon
Hi this is a link to the vCard standard (user profile). ftp://ftp.isi.edu/in-notes/rfc2426.txt Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+----------------------------> | | "Cassidy, Mark" | | | <mcassidy@Netegri| | | ty.com> | | | | | | 06/12/2002 09:19 | | | AM | | | Please respond to| | | "Cassidy, Mark" | | | | |---------+----------------------------> >---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: wsrp@lists.oasis-open.org | | cc: | | Subject: [wsrp][security] agenda for 6/12 telecon | | | | | >---------------------------------------------------------------------------------------------------------------------------------------------| After last week's telecon, I've gone back through the various standards documents relating to digital signatures, and spent some time on the Apache site reviewing the latest information on the Axis project. Goal was to assess the compatibility issues with using document-based security mechanisms with WSRP. Apache also has an implementation of the XML-Signature spec. I've also been going through the various requirements related to authentication and confidentiality and would like to focus the agenda on the following points: 0. Reword R402 from: There should be means for portlet to authenticate the portal when a service request is made: a. authentication could be protocol-based(i.e. http/basic, ssl/certificate) b. authentication could be document-based(i.e. digitally signed) to a more abstract: The specification MUST define how portlet services MAY authenticate portal requests. The specification then enumerates concrete details for transport-based and document-based mechanisms. 1. WS-Security provides a mechanism to include digital signature elements within a Security element within the Header element in a SOAP request. Since a signature element does not hide any of the data which the signature is generated against, do we have SOAP marshalling/unmarshalling issues with XML-Signature elements (with appropriate constraints such as using only 'Enveloped' signatures) in WSRP? 2. Signatures alone aren't sufficient to authenticate the sender; in the case where intermediaries are involved or in a replay attack, additional methods are needed to verify identity of sender. 3. For transport-based authentication(http/basic or SSL/TLS with client certificate), do these really require any WSRP-specific metadata(since these are configured outside of the WSRP protocol during the setup of trust relationship) to support these authentication methods? 4. R406 states: A portlet should be able to require a portal to authenticate the end user, R407 states: It should be possible to describe the level of authentication required of the end user R408 states: It should be possible for the portal to describe to the portlet how it authenticated the end-user It seems that these aren't very meaningful without a means for the portlet to verify the portal's authentication of the end-user. Is this a priority requirement for the first release of the spec? SAML would be the applicable standard to apply here, but we need to decide whether to take this on with everything else on the plate at the moment. 5. For confidentiality-related requirements, XML-Encryption provides a mechanism for encrypting entire elements or element content. By focusing on element content encryption only, do we have any marshalling/unmarshalling issues with existing SOAP stacks? 6. Do end-user personal data used as portlet parameter values need to be treated any differently than any other portlet parameters that have confidentiality requirements? Time: 8:00 a.m. PST(11:00 a.m. EST, 5:00 p.m. CET) Reservationless-Plus Toll Free Dial-In Number: 877.450.3529 Reservationless-Plus International Dial-In Number: +1.706.679.6653 Conference Code: 4254674195 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC