>Therefore we need an answer, what exactly we will do for V1 spec and
what will go to V2 (if any), etc.
>I think that the requirements document (normative for
the core spec document) should say exactly this.
I
agree.
>And the requirements doc should be derived from the use
cases document,
I
would agree on this too except I think we have agreed that there won't be a
standalone
requirements document rather it will be included in the core.
I'm interested in talking
about this further in the use cases sub-committee
meeting.
>where the context for
future version of the spec will be drawn.
Yes, we should discuss this possibility as part
of the scoping issue of the use cases
document.
Zahid Ahmed
Commerce One, Inc.
That's why I'm asking this question. I feel,
that the motion was to see the TC charter not as a final list of items
which will be done in this TC, but as a minimum, which must be done.
Therefore we need an answer, what exactly we will do for V1 spec and what
will go to V2 (if any), etc. I think that the requirements document
(normative for the core spec document) should say exactly this. And the
requirements doc should be derived from the use cases document, where
the context for future version of the spec will be drawn.
I agree that if we will do only the SOAP header
spec with the minimal set of features, the name of this TC is very
unfortunate one. If we are confused by it, imagine rest of the world
confusion.
alex
----- Original Message -----
Sent: Friday, September 06, 2002
9:05
Subject: RE: [wss] WSS Focus
Hi All
I would like to express my contention that a number one priority
for this TC is to get our version 1.0 specification out
quickly. At the meeting we expressed a goal to attempt a
"six months target". I believe that this time frame is
doable if and only if we constrain the scope and focus our work on
version 1.0 to the narrow scope defined by the TC at the first meeting
and expressed by some of the people on this thread.
We have a number of very smart people on this committee who
can "leap tall buildings in a single bound" and who will feel
frustated by a narrow scope. However, if we are going to get
this version out quickly all of us will have to control
our desire to specify a complete answer to the full Web
Services security "now", i.e. in version 1.0.
To repeat, I believe that it was expressed emphatically by the TC at the
first meeting that a short schedule for version 1.0 was a prime
goal. This does not mean that version 1.0 should be
anything short of excellent but that the defined scope be narrow
and well defined.
Don
=========== Don Flinn Chief Security
Architect Quadrasis, A Business Unit of Hitachi Computer
Products Tel:
781-768-5829 Cell:
781-856-7230 FAX: 781-890-4998
e-mail: Don.Flinn@quadrasis.com
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.
-----Original
Message----- From:
Gene Thurston [mailto:gthurston@amberpoint.com] Sent: Thursday, September 05,
2002 9: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
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.
-----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
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.
|