OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [wsrp][security] Agenda for 6/5 telecon

I've begun to take the security requirements we have documented to date and
map to current standards.  Using the numbering scheme assigned by Carsten,
I've started with the first couple requirements and updated the language
used as well as begun to capture content that would go into the spec
chapter.  In the process, I've identified a number of issues/questions that
I'd like to focus tomrrow's telecon on.  Below is outline and discussion
points behind the first two 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


Chapter 5   Security
Preamble key points:

- WSRP is exposed to many of the same security issues that today's web
services-based systems are susceptible to.  It is the goal within WSRP to
leverage existing standards efforts focusing on web services security as
much as possible, and to identify solutions that provide the broadest
possible interoperability based on widely used infrastructure components.

- Reference to existing documents discussing  of security issues/threats

- WSRP context for security issues:
  o Trust between portal and portlet(authentication)
  o Handling of end user identity and personal information(authentication
and confidentiality)
  o Secure transmission of data(confidentiality)
  o Access control(policy)

- Discussion of transport-based and document-based approaches to addressing
security issues

- Pointers to relevant standards which WSRP will aim to leverage

Spec details behind requirements:

Number	Type	Description	Comment	
R401	MUST	The specification MUST support the use of secure transport
for communications between portal and portlet		
Use of transport-level security is optional.    

Applicable standards widely in use:   SSL/TLS.  This mechanism supports both
confidentiality and authentication requirements.
(reference to standards documentation)

Supporting Metadata:  
  - Transport security(none, HTTP over SSL/TLS; others as identified)
 	o SSL/TLS has an additional attribute:
		  - SSL/TLS (no certificate), or
		 	  - SSL/TLS with client certificate

- SSL/TLS sits a couple layers below WSRP in the protocol stack.  Maximum
interoperability will be achieved by using SOAP/HTTP/(SSL/TLS).   What
protocol binding is required in the service metadata to indicate the use of
HTTP/(SSL/TLS) stack beneath the SOAP layer?

Question:  should both parties(portal and portlet) have a say in the
transport mechanism used?  Or does the service simply declare how the portal
should talk to it and from there the portal is required to conform to that

- Should metadata support an 'supported but optional' scenario(versus
supported/required)  for secure transport?  

- Should transport security be scoped to all portal/portlet exchanges(from
bind step through remaining registration lifecycle), or does WSRP need to
support more fine-grained selection of transport security? 


Number	Type	Description	Comment	
R402	MUST	The specification must support the ability for a portlet to
authenticate a portal.		
A portlet service may authenticate service requests from portals, but is not
required to do so.   Transport or document-based approaches may be used for

Applicable standards for transport-based authentication that are widely in
use are:
  - http/basic 
  - client certificate  in conjunction with SSL/TLS. 
 (reference standards documentation for these)

XML-Signature is the primary document-based mechanism to consider for
authenticating a service request.  
(reference to the w3c xmldsig documentation)

Supporting metadata:
  - Authentication method(none, http/basic, SSL/TLS certificate, signature;
add others as required)

Issue:  there are no metadata standards for describing signature mechanisms;
signatures themselves as defined by XML-Signature carry a number of elements
describing how they are computed/validated(canonicalization method, digest
method, transforms, key information).  Should we replicate these elements
from XML-Signature in the portlet's metadata in order to describe how a
portal should sign a service request?

Issue:  what are the elements in the service request that should be signed?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC