RE: Status of D-AG006 + CSF

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 
Cc: 
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:
 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.
 
 
 Glossary:
 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.
 
 
 QoS:
 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