[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] WSS Focus
Hello all, I think a good support of wsse 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) When including security information, we should differentiate between static information (i.e. which parts to sign) and information that may change (certificates etc.). As a next step, we should compile a list of information, which we'd like to see included in an WSDL document, and talk with the WSDL TC (SAP also has members in the WSDL TC). Best Regards, Martijn ___________________ Dr. Martijn de Boer SAP AG Development Security & Directory Services GBU Server Technology -----Original Message----- From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com] Sent: Donnerstag, 5. September 2002 22:32 To: wss@lists.oasis-open.org Subject: RE: [wss] WSS Focus I think where we left this disussion today was: 1) that WSDL level security policy management and negotiation is not currently part of the WSS v. 1.0 scope; 2) that we have an option to create a separate e-mail list to discuss the merits of pursuing the web services security management problem; 3) that if upon further review it seems to make sense, interested parties could form a new TC to tackle the problem of web service security policy management, particularly as it relates to WSDL oriented invocation and communication to/from web service. There are critical needs to standardize the web services security policy management. However, I also agree that keeping focus on the basic "run-time" SOAP messaging aspects of Web Services Security, i.e., token passing, encryption and signature processing is fine for the v1 goals of WSS TC. Any proposals w.r.t. "policy configuration" aspects of web services security could possibly be pursued on a separate TC track. This seems to ring a bell when SAML TC got formed and soon afterwords a need for XACL group became evident and that was formed too. I would welcome any technical proposals that may lead to this. thanks, Zahid Ahmed Commerce One, Inc. -----Original Message----- From: Gene Thurston [mailto:gthurston@amberpoint.com] Sent: Thursday, September 05, 2002 6:35 PM To: wss@lists.oasis-open.org Subject: RE: [wss] WSS Focus I think we all know that "WS-Security" (short for "Web Services Security") is a bit of a misnomer, in that it only really deals with (basically) three specific security topics in the context of web services: 1. The inclusion of security tokens (of any kind). 2. Digitally signatures in SOAP messages via XML Signature. 3. Encryption in SOAP messages via XML Encryption. Essentially, only these pieces of SOAP message security, and clearly not the full spectrum of "security for web services". The charter and scope of our TC, which was published prior to our first meeting, and which we all "clarified", voted on, and accepted yesterday, stated only that we will deal only with the WS-Security specification (i.e., the above three items), along with some "profiles" for a select list of some of the more commonly used security tokens. I firmly believe that topics such as: * WSDL work for publishing what a web service can/will allow, * "in-line" negotiation of quality of security, * and all those other important aspects of security that are necessary in the broader sense of the term "Web Services Security", are important (and in some cases CRITICAL) for web services to be fully utilized by industry. That said, I have to agree with those who point out this was not in the original TC charter, and that others may have attended had they seen this in the charter. Therefore, I must conclude that we should not increase the scope of our work to include these items. I just wish our TC was not called "Web Services Security", since that undoubtedly will conjure up the image that we will solve all security issues related to web services. - Gene Thurston - AmberPoint, Inc. -----Original Message----- From: Munter, Joel D [mailto:joel.d.munter@intel.com] Sent: Thursday, September 05, 2002 4:32 PM To: wss@lists.oasis-open.org Subject: RE: [wss] WSS Focus Alex, It is my humble opinion that we should eventually create a real Web Services Security [set of] Specification[s] with the first significant deliverable being the SOAP Security Header ("core") Specification described by WS-Security and the additional profile doc's that we discussed at the FTF. We should absolutely target these 1st deliverables as soon as is feasible. If the charter and scope need to be readjusted after the closure of these first deliverables then so be it, let's adjust them; and then taking into account comments heard from Hemma and others today, we should advertise the scope/charter changes and invite new contributors. Joel -----Original Message----- From: Jan Alexander [mailto:alex@systinet.com] Sent: Thursday, September 05, 2002 4:04 PM To: wss@lists.oasis-open.org Subject: [wss] WSS Focus Hi all, I think we should answer a question, if we want to create real Web Service Security specification or just SOAP security header specification. We should do it in very short time. Because in Web Service Security specification, we should handle issues for example with in-band negotiation (for example for security token type, or the QoS and whatever else), proof of possession, WSDL extensibility elements for declarative security information (required QoS, etc.) and many other things in the core spec. We can of course do it in steps, explicitly stating what will be in the 1.0 version of the spec. On the other hand, if we want to just specify SOAP message header, we need only to cope with the attaching opaque (from the spec point of view) security tokens with the message and cryptographic binding of these tokens with the message (by means of XML Signature and XML Encryption) in the core spec. We can then say, that everything else is out of the scope of the core spec. I think the answer to this question should give us background for the requirements document. The use-cases document will be influenced very much by this answer as well. cheers, alex Jan Alexander Chief Architect, Systinet (formerly Idoox) http://www.systinet.com <http://www.systinet.com> ---------------------------------------------------------------- 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