OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wss] WSS Focus


Hi all,

    I don't want to stir-up any controversies - but isn't the
roadmap/architecture document supposed to guide us thru these kinds of
discussions ? We could add a couple more boxes in the arch diagram and
leave that to another group to solve !

    Another thought - if we want to rename out TC, we can - at least I
think we can (to paraphrase Bob TB) Or really take a little time to see
what it means to be a Web Services Security TC and then do the right
thing. The WS-Security is just an initial submission, we are not bound
by it to do only SOAP-Security.

cheers (and have a night flight home for those who traveled from far
away lands/states for the f2f)

-----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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC