- From: Joseph Hui <jhui@digisle.net>
- Date: Wed, 13 Mar 2002 14:53:00 -0800
- To: <www-ws-arch@w3.org>
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 Wednesday, 13 March 2002 17:53:01 UTC