- From: De Boer, Martijn <martijn.de.boer@sap.com>
- Date: Wed, 30 Oct 2002 12:13:24 +0100
- To: "'dorchard@bea.com'" <dorchard@bea.com>
- Cc: "'www-ws-arch@w3.org'" <www-ws-arch@w3.org>, "'wssqop-discuss@lists.oasis-open.org'" <wssqop-discuss@lists.oasis-open.org>
Hi David, I'm participating in the WS Security TC (short WSS), and on the first F2F, I raised the same concern, which is that ws clients (and their proxy generators) currently have no sufficient information to efficiently support ws security. As a consequence, to make use of ws security, application programmers would have to configure the ws client manually to support wss. Currently we're discussing this issue in a mailing list/phone calls and are evaluating different options. 1) Make use of CPPA as it is defined by the ebXML group 2) Add it to the WSDL document, adding it to the binding section. 3) Make use of SOAP 1.2, and define a set of security features. The approach the members of the discussion group are taking, is to prepare a proposal, and submit it to the WSS TC, either forming a sub-TC or a new TC. My personal opinion is that a good support of wss by web service clients will be essential for the success of wsse (make it easy to use - and people will use it). The best place to store the security information is probably inside the WSDL document, which also contains the interface information. I'd like to see an additional security section within the WSDL, which contains information about: a) Authentication: Which security tokens are accepted (X.509, Kerberos, UsernameToken, SAML); maybe with a list of CA certs, which are accepted by the ws b) Integrity: Which parts of the document are to be signed c) Confidentiality: Which parts of the document are to by encrypted; maybe it is a good idea to include either keys which may be used for encryption (either directly or as a reference) I hope this cleared the issue, Best Regards, Martijn _______________________ Dr. Martijn de Boer SAP AG Development Security & Directory Services GBU Server Technology Neurottstraße 16 69190 Walldorf T +49/62 27/7-6 83 92 F +49/62 27/7-83 91 13 E martijn.de.boer@sap.com http://www.sap.com -----Original Message----- From: David Orchard [mailto:dorchard@bea.com] Sent: Thursday, October 24, 2002 4:00 To: www-ws-arch@w3.org Subject: RE: Potential issue around ws-security and wsdl definitions Here's my latest wording, based upon our consensus that we should say something and Hal's input. 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. As a best practice, members of the web services architecture group believe that WSDL definitions should be part of any specification of SOAP Modules. 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. We were made aware of the significant range of possible description. We don't think it appropriate to venture into your domain and make a recommendation as the extent of descriptions that should be provided - such as trusted authorities, etc. However, it is of our opinion, though we could easily be mistaken, that a simple description of the required WS Security elements in a given message is probably doable in a reasonably short time frame. We are certainly not advocating a large (year or more) delay in schedule. On behalf of the W3C Web Services Architecture Working Group, Dave Orchard > -----Original Message----- > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On > Behalf Of David Orchard > 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 > > >
Received on Wednesday, 30 October 2002 11:26:13 UTC