[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] WSS Focus
|
RE: "The charter and scope of our TC... stated only that we will deal only with the WS-Security specification" and the set of other topics "was not in the original TC charter, and that others may have attended had they seen this in the charter"...
The statement was made several times (and I presume that this will show up in the minutes) that many of us viewed the list of items in the charter as the "minimal" set of items we will work on as a TC - not the final ultimate list that narrowly constrains what we can work on. Personally, I made my decision to attend based on the fact that that this is called the WS-Security TC and I fully expect the TC to (eventually) address things beyond what is addressed in the submitted WS-Security input document. The Statement of Purpose clearly stated that the TC will "continue the work on the Web services security foundations...". This permits us to pursue more than SOAP message security.
As I and others stated during the f2f, some of us feel strongly that there are some things we know of now, and others that will probably come up as we work on V1, that are extremely important to WS-Security but don't deal with SOAP message security that we don't have time for in the V1 timeframe.
In short, I believe our charter defines us as THE Web Services Security TC and that we SHOULD (eventually) address more than SOAP message security. I can't and don't believe that folks really think that when V1 is done, that we can declare that WS-Security is done. There will need to be a V.next. And I do not read the charter as preventing us from working on these things once V1 is done.
OASIS does not require us to shut down our TC when V1 is done and defer new work to a new TC.
Rob Philpott RSA Security Inc. The Most Trusted Name in e-Security Tel: 781-515-7115 Mobile: 617-510-0893 Fax: 781-515-7020
-----Original Message-----
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:
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-----
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----- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC