RE: Potential issue around ws-security and wsdl definitions

>There are a variety of rationale for including description in v1: 
>1) To ensure that the runtime aspects can be described in a reasonable 
>manner - it would be unfortunate if some headers were difficult to
>describe in wsdl; 2) To promote interoperability - bodies such as 
>W3C and WS-I believe that interoperable descriptions are a requirement 
>to interoperability."

Hi David,

As a participant in OASIS WS Security and also a participant in OASIS 
WSS QoP discussion group, I am in agreement that we do need to support 
web services SOAP security run-time extensions alongwith with an 
appropriate set of WSDL-centric description to support security 
policy interoperability and control.

In last week's meeting of OASIS WSS QoP group (minutes available
at:
http://lists.oasis-open.org/archives/wssqop-discuss/200210/msg00028.html)

we discussed the feasibility of defining the WSDL-centric security policy 
descriptions for transport-level security, application authentication, 
encryption, and signature features. We also decided that it would be
a good idea to invite the W3C Web Services Description group to give 
the OASIS WSS QoP group a presentation w.r.t. policy description
extensions for security features. A similar discussion with OASIS
ebXML CPP/CPA group will also be done to determine what security policy
description may be adopted from there, if any.

No decision has been made when the OASIS WSS TC will support
WSDL based security policy management. However, the OASIS WSS-QoP
discussion group did a survey fo when such capabilities are needed
as a standard, see: 
http://lists.oasis-open.org/archives/wssqop-discuss/200210/msg00000.html

I would welcome that W3C Web Service Architecture WG provide any
inputs in this direction. Obviously, the bottom line is we need
interoperability for not only security run-time description/extensions, 
but also for its configuration/policy desciption/extensions.

I think W3C Web Services Description WG could help in this
direction in terms of generic defintion of policies and policy
extensions that can be incorporated in WSDL interface and 
implementation documents.

cheers,
Zahid



-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Wednesday, October 16, 2002 8:36 AM
To: www-ws-arch@w3.org
Subject: Potential issue around ws-security and wsdl definitions



Hi all,

I wanted to potentially raise an issue around liaison with oasis
ws-security.  ws-security does not currently provide wsdl definitions for
the security elements exchanged.  There is a discussion list around
describing qualities of service.  I think it would be a good thing to ask
oasis ws-security tc if they could provide wsdl definitions as part of their
v1 output.  Obviously this is a very delicate area, and we don't want to
annoy them.  If there isn't a strong majority within our group, then I
wouldn't want to proceed either.  This certainly appears to be an
architectural area.  It appears the key issue is around timing of when to
provide description - either at the same time as the soap definitions or
later.

I think this is also a "web service spec" best practice - Descriptions
should be provided at the same time as runtime extensions.

Some potential wording suggestion

"Dear OASIS WS-Security TC,

The W3C Web Services Architecture Working Group would like to express it's
concern around the lack of WSDL definitions for WS-Security elements in the
first version of the WS-Security product.  We would like to encourage the
WS-Security group to take up this piece of work in the first version of it's
product.  It appears that the issue is not so much the "goodness" of such a
thing, rather the timing is the issue.  There are a variety of rationale for
including description in v1: 1) To ensure that the runtime aspects can be
described in a reasonable manner - it would be unfortunate if some headers
were difficult to describe in wsdl; 2) To promote interoperability - bodies
such as W3C and WS-I believe that interoperable descriptions are a
requirement to interoperability.
"

Cheers,
Dave