W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2002

RE: Status of D-AG006 + CSF

From: Joseph Hui <jhui@digisle.net>
Date: Sun, 24 Mar 2002 20:08:10 -0800
Message-ID: <C153D39717E5F444B81E7B85018A460B081B2787@ex-sj-5.digisle.com>
To: <www-ws-arch@w3.org>
Combining what I can extrapolate from the D-AG0006 threads with
common sense, here's a take of the CSF for D-AG0006, formulated
in terms of executables to accentuate the imperative need for a well
disciplined approach in the design for Web Services security.  
The executables may also serve as sub-goals.
The Critical Success Factor (CSF) of goal AG0006 is a sequence of executables
starting with (1) a thorough analysis of the Web Services Threat Model;
followed by (2) the establishment of a set of Web Services Security Policies
to counter and mitigate the foreseeable threats; followed by (3) the construction
of a Web Services Security Model that captures the policies; followed by (4) the
flesh-out of the model in the form of a Web Services Security Framework that
is an integral part of the (W3C's) Web Services Architecture.
Joe Hui
Exodus, a Cable & Wireless services
-----Original Message----- 
From: Joseph Hui 
Sent: Wed 3/13/2002 2:53 PM 
To: www-ws-arch@w3.org 
Subject: Status of D-AG006

	Status summary on D-AG006 as of March 13, 2002.
	Goal statement:
	On the goal statement itself, there was one input suggesting the
	statement was too broad and impossible to achieve, and a replacement
	was proposed.  However, (1) there is sufficient elasticity in the
	original statement in that what it can be stretched to mean broad
	may also be contracted to mean narrow, thus there it could not be
	definitively concluded that set goal was too broad.  (2) The replacement
	text, suitable as it was, did not help narrowing the original scope
	in tangible ways.  (3) Arguments could be made, and one was made,
	for the originally stated goal being achievable.  At this juncture,
	the D-AG006 goal statement stands, in its original text.
	Interesting fallouts from impromptu topics arising from discussions
	in the D-AG006 thread are summarized below.
	Privacy can mean different things in different contexts.
	We had no clue how it got into the charter to begin with.
	We tried to get a clarification from anyone who might give
	a definition of what privacy as stated next to security in
	the WG charter was supposed to mean in the context of WS
	architecture.  Nobody's come forward yet.
	An educated guess, coupled with a tabulation of some possible
	privacy scenarios where "privacy" was presumed to be synonymous
	with "anonymity," was set up to troll for responses.  No luck
	there.  So, unless someone comes forward to stake out a
	position for privacy, it may not get addressed in WS-Arch.
	As of now, it's fair to presume privacy work, if any is to
	be done at all in W3C's WS-Arch, will not be done under the
	auspices of D-AG006.
	Suresh made an excellent suggestion to adopt the contents in
	RFC 2828 (Glossary for Internet Security) as a part of our
	WSsec glossary.  Editors, please take note.
	Whether QoS is an architectural function remains debatable.
	Nonetheless, arguments for excluding it from D-AG006's scope
	were sufficiently conclusive.
	Reliable Messaging (RM):
	Suggestions were made to include reliable messaging (RM) in D-AG006.
	The upshot of ensuing discussions could be summed up as: RM itself
	cannot be in D-AR006, but it may be in a separate WS-Arch goal
	as its merit may warrant.   (Take care to not confuse securing RM
	with RM itself.  The former is of security, The latter is not.)
	In the interest of ensuring the public that the probing interest
	to include RM in D-AG006, as initially expressed by Roger, had
	its fair shot in the WG's security deliberation so far and thus
	we don't have to make unnecessary re-visits, I'm enclosing below
	an excerpt from my responses to several off-line inquiries and
	nudgings from individuals concerning RM's prospect in D-AG006.
	   It's a lost cause trying to get RM into a security charter.
	   To get it into security, you need to begin with a threat model
	   that's RM-unique.  (Recall securing RM, which is generically
	   the same as securing messaging, is security.  RM itself is
	   not.)  Then you need to think of what security primitives
	   that may fit the bill.  The known security primitives are:
	   encryption, key exchange, digital signature, message
	   digest, ...   I can't list them all here off the top of
	   my head, but I know darned sure there ain't none for RM.
	   (Recall also I said there's not one [known] security
	   primitive for guaranteeing data arrival, which is the
	   quintessence of RM.  To make up a new one, you need to
	   establish a threat model first.  I'd love to see it if
	   you can come up with one.  That would be original.)
	   That said, I should mention that I have no problem with
	   including RM in the WS-Arch, if someone chooses to champion
	   for it.
	Transaction Processing (TP):
	The RM discussion also led to the mention that we might as
	well include transaction processing as a separate goal.
	However, there's no champion for it yet.
	In any case, TP is not a part of D-AG006.
	Requirement tidbits:
	There were touched-on discussions that were very
	requirement related.  Since requirements deserve focused
	treatments of their own, their full discourse were deferred
	to some later agenda.
	That's all, folks!
	Joe Hui
	Exodus, a Cable & Wireless service
Received on Sunday, 24 March 2002 23:08:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:55 UTC