RE: D-AR006.12 [Was RE: D-AR006.11 discussion points]

Chris,

What's your point?

I can give you a billion hits if I care to pay
$49.95 a month for a website and fill it with fluff
if only hits count.

There're books written by industry recognized experts
and archives in ICSA, IETF, etc that I can bring to
the pissing contest.  But, why bother.  
This is public list.  The informed readers can judge
for themselves what nomenclatures are more proper anyway.

Joe Hui
Exodus, a Cable & Wireless service
================================================ 

> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Friday, May 10, 2002 6:54 AM
> To: www-ws-arch@w3.org
> Subject: Re: D-AR006.12 [Was RE: D-AR006.11 discussion points]
> 
> 
> Hmmm...
> 
> I did a search for "security primitives" and get only
> 666 (spooky!) hits[2].
> 
> I did a search on "security countermeasures" and get
> 3,350 hits[3]. Seems to me to be a more widely used
> term than "security primitives" (which I had never
> previously heard used, and I've been around a while:)
> 
> A search on "security principles" will get you 10,100
> hits[1], the most interesting of which is[4] (parented by
> [5]). The interesting thing there is that this body
> The International Information Security Foundation (I2SF),
> cites 3 "Pervasive" security principles (e.g. rule or standard,
> see [6]) which are:
> 	Confidentiality
> 	Integrity
> 	Availability
> 
> Cheers,
> 
> Chris
> 
> [1] http://www.google.com/search?q=%22security+primitives%22
> [2] http://www.google.com/search?q=%22security+countermeasures%22
> [3] http://www.google.com/search?q=%22security+principles%22
> [4] http://web.mit.edu/security/www/GASSP/gassp021.html
> [5] http://web.mit.edu/security/www/gassp1.html
> [6] http://www.dictionary.com/search?q=principle
> 
> Joseph Hui wrote:
> <snip/>
>   >
>   > Again, nomenclature issue: the term "principle(s)" connotes
>   > "how to do something better."  We want to convey "what
>   > constitutes the foundation" in the sentence, because the
>   > paragraph is meant to be a lite intro for the few reqs to
>   > follow.  Additionally, as I said in a previous message,
>   > "Access Control (file permission, etc.)" is an Authz means.
>  >
>  >
>  >>ADD to the requirements statements:
>  >>     - The security framework must include Auditing.
>  >>
>  >
>  > IMO, this is good -- something I can recommend to the WG
>  > and the public.  So, unless there're objections, the following
>  > is going to the WG's floor:
>  >
>  >    D-AR006.12 --
>  >        The security framework must include Auditing.
>  >
>  > Editors, please take note of the D-AR006.12 addition.
>  >
>  > Thanks,
>  >
>  > Joe Hui
>  > Exodus, a Cable & Wireless service
>  > ========================================
>  >
>  >
>  >
>  >>-----Original Message-----
>  >>From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
>  >>Sent: Wednesday, May 08, 2002 7:50 PM
>  >>To: Christopher Ferris
>  >>Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
>  >>Subject: RE: D-AR006.11 discussion points
>  >>
>  >>
>  >>
>  >>>-----Original Message-----
>  >>>From: Christopher Ferris [mailto:chris.ferris@sun.com]
>  >>>Sent: Wednesday, May 08, 2002 3:50 PM
>  >>>To: Joseph Hui
>  >>>Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
>  >>>Subject: Re: D-AR006.11 discussion points
>  >>>
>  >>>
>  >>>Joe,
>  >>>
>  >>>What is a "security primitive" per se? My understanding of
>  >>>security is based on the premise of risks and balanced
>  >>>countermeasures based on the level of risk assessed
>  >>>for each resource. I have never heard of a "security
>  >>>primitive" before so I have no idea how to respond
>  >>>to your question.
>  >>>
>  >>Off the top of my head, the established security primitives
>  >>include: encryption (for Confidentiality); message digest (for
>  >>data Integrity; Public Key Encryption (PKE, for key
>  >>establishment, which may be further broken down to
>  >>key exchange and key agreement); digital signature
>  >>(for non-repudiation), ...  I think you get gist by now.
>  >>
>  >>(Just like doing computer graphics, you have point,
>  >>draw, fill, ... as graphic primitives.)
>  >>
>  >>
>  >>>IMO, auditing as a service *might* be something we
>  >>>consider as an important aspect of web services
>  >>>security.
>  >>>
>  >>I agree it can be important, but not to the point of
>  >>being the equal of the original six.
>  >>
>  >>
>  >>>Or, we might conclude that in terms of priority
>  >>>that other countermeasure technologies should be considered
>  >>>ahead of auditing. But that's beside the point.
>  >>>
>  >>>The six "facets" you cite are in fact (IMHO) merely six
>  >>>countermeasures which comprise but a subset of the
>  >>>total arsenal of countermeasures that might be applied
>  >>>to mitigate a risk. Auditing is another, equally valid,
>  >>>countermeasure that is (or should be!) often employed
>  >>>within the fabric of a secure environment. There are
>  >>>other non-technical (and IMHO, far more important)
>  >>>countermeasures (management comes to mind, without which
>  >>>all the glitzy technicological countermeasures one
>  >>>can imagine can be rendered useless overhead) that could
>  >>>also be included in the list.
>  >>>
>  >>Are we going to roll admin/operational elements into the mix now?
>  >>I thought there was already enough grief given to D-AR006.7
>  >>through 6.8.  They are admin/operational-ish.
>  >>
>  >>
>  >>>Why is it that you are so adamantly opposed to its (Auditing)
>  >>>inclusion in this list?
>  >>>
>  >>Let's not jump to conclusions.  I haven't made up my mind yet
>  >>whether to oppose it, let alone adamantly.
>  >>For Pete's sake, what's the final wording of the req?
>  >>
>  >>I have already expressed my reservation about grouping Auditing
>  >>in as a sec aspect.  (Ayse was having mail problem and I'm
>  >>still waiting on the response that she said she'd sent me.)
>  >>And I've already responded (favorbly, mind you :-) to the
>  >>one proposed by Steven A. Monetti.
>  >>
>  >>
>  >>>A number of others have chimed in suggesting
>  >>>that its inclusion would be "a good thing(tm)".
>  >>>
>  >>No argument ever from me against Auditing being a good thing.
>  >>
>  >>
>  >>>Would you be willing to live with its inclusion?
>  >>>
>  >>Inclusion as a separate req; or inclusion as replacement to
>  >>supplant the original six?  Like implied earlier, I can
>  >>live with the simple wording proposed by Steven.
>  >>Will that be the final wording?
>  >>
>  >>Cheers
>  >>
>  >>Joe Hui
>  >>Exodus, a Cable & Wireless service
>  >>=========================================
>  >>
>  >>>Cheers,
>  >>>
>  >>>Chris
>  >>>
>  >>>
>  >>>
>  >>>Joseph Hui wrote:
>  >>>
>  >>>
>  >>>>>From: Christopher Ferris [mailto:chris.ferris@sun.com]
>  >>>>>Sent: Wednesday, May 08, 2002 2:25 PM
>  >>>>>To: Joseph Hui
>  >>>>>Cc: Dilber, Ayse, ALASO; www-ws-arch@w3.org
>  >>>>>Subject: Re: D-AR006.11 discussion points
>  >>>>>
>  >>>>>
>  >>>>>Joe,
>  >>>>>
>  >>>>>As with AuthN and AuthZ, it is a countermeasure used
>  >>>>>to mitigate a security threat(s) such as when AuthN and
>  >>>>>AuthZ have been (somehow) circumvented. It is also
>  >>>>>useful to protect against abuse of privileges that
>  >>>>>may have been granted.
>  >>>>>
>  >>>>>
>  >>>>Chris,
>  >>>>
>  >>>>I'm well aware of the benefits of auditing -- nuts and
>  >>>>bolts and trimmings; and what auditing may mean in various
>  >>>>contexts.  (Exodus is a well established vendor of Security
>  >>>>Audit services, albeit Ayse's notion of Auditing is more
>  >>>>like logging and our products cover far more than that.)
>  >>>>
>  >>>>However, I wouldn't elevate it to a "security aspect/facet"
>  >>>>equal to the original six commonly known to security experts.
>  >>>>The experts no doubt know what Auditing can mean in the
>  >>>>context of security, but wouldn't group it in the company
>  >>>>of the original six for sure.
>  >>>>
>  >>>>Can you think of a security primitive that does Auditing?
>  >>>>
>  >>>>Cheers,
>  >>>>
>  >>>>Joe Hui
>  >>>>Exodus, a Cable & Wireless service
>  >>>>=================================================
>  >>>>
>  >>>>
>  >>>>
>  >>>>
>  >>>>
>  >>>>>Cheers,
>  >>>>>
>  >>>>>Chris-sans-chapeau
>  >>>>>
>  >>>>>Joseph Hui wrote:
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>>>>-----Original Message-----
>  >>>>>>>From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
>  >>>>>>>Sent: Wednesday, May 08, 2002 2:02 PM
>  >>>>>>>To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org
>  >>>>>>>Subject: RE: D-AR006.11 discussion points
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>i don't know if you will receive this but i'm having lots of
>  >>>>>>>e-mail problems today, i thought i answered your question in
>  >>>>>>>a different message but it sounds like it wasn't delivered.
>  >>>>>>>so here it is:
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>
>  >>>>>>Well, here it is what?  Another mail problem? ;-)
>  >>>>>>Please take your time, Ayse.
>  >>>>>>Fix you mail first; the world can wait. :-)
>  >>>>>>
>  >>>>>>Joe Hui
>  >>>>>>Exodus, a Cable & Wireless service
>  >>>>>>=============================================
>  >>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>>>-----Original Message-----
>  >>>>>>>From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
>  >>>>>>>Sent: Wednesday, May 08, 2002 4:41 PM
>  >>>>>>>To: Dilber, Ayse, ALASO; Christopher Ferris; 
> www-ws-arch@w3.org
>  >>>>>>>Subject: RE: D-AR006.11 discussion points
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>Ayse,
>  >>>>>>>
>  >>>>>>>Then what's your answer to my questions in [1]
>  >>>>>>>pertaining to threat characterization?
>  >>>>>>>
>  >>>>>>>I'm copying the text of the original question over
>  >>>>>>>as follows:
>  >>>>>>>
>  >>>>>>>Auditing* as a security aspect?
>  >>>>>>>Can you explain why?  E.g. for starter, how would you
>  >>>>>>>characterize the threat (model) that's unique to Auditing?
>  >>>>>>>Note that the impetus for requiring each of the original
>  >>>>>>>six begins with a unique threat, or in some cases, threats.
>  >>>>>>>
>  >>>>>>>Joe Hui
>  >>>>>>>Exodus, a Cable & Wireless service
>  >>>>>>>
>  >>>>>>>PS: I wasn't interested in what auditing means in
>  >>>>>>>  the conventional sense.  It's obvious.
>  >>>>>>>
>  >>>>>>>[1]
>  >>>>>>>
>  >>>>>>>
>  
> >>>>>http://lists.w3.org/Archives/Member/w3c-ws-arch/2002May/0056.html
>  >>>>>
>  >>>>>
>  >>>>>>>============================================================
>  >>>>>>>
>  >>>>>>>
>  >>>>>==========
>  >>>>>
>  >>>>>
>  >>>>>>>>-----Original Message-----
>  >>>>>>>>From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
>  >>>>>>>>Sent: Wednesday, May 08, 2002 12:59 PM
>  >>>>>>>>To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org
>  >>>>>>>>Subject: RE: D-AR006.11 discussion points
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>No, I didn't back out on Auditing!  I was having serious
>  >>>>>>>>e-mail problems that's why I couldn't respond.  I believe
>  >>>>>>>>that the Auditing should be included!
>  >>>>>>>>Ayse
>  >>>>>>>>
>  >>>>>>>>-----Original Message-----
>  >>>>>>>>From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
>  >>>>>>>>Sent: Wednesday, May 08, 2002 3:55 PM
>  >>>>>>>>To: Christopher Ferris; www-ws-arch@w3.org
>  >>>>>>>>Subject: RE: D-AR006.11 discussion points
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>>-----Original Message-----
>  >>>>>>>>>From: Christopher Ferris [mailto:chris.ferris@sun.com]
>  >>>>>>>>>Sent: Wednesday, May 08, 2002 12:00 PM
>  >>>>>>>>>To: www-ws-arch@w3.org
>  >>>>>>>>>Subject: Re: D-AR006.11 discussion points
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>Joe/Ayse,
>  >>>>>>>>>
>  >>>>>>>>>1) Please keep this, and all technical discussion, on
>  >>>>>>>>>
>  >>the public
>  >>
>  >>>>>>>>>mailing list.
>  >>>>>>>>>
>  >>>>>>>>>2) It seems to me that Joe is suggesting that the bulleted
>  >>>>>>>>>item under D-AR006.11 that says:
>  >>>>>>>>>
>  >>>>>>>>>"There are six aspects in the security framework for Web
>  >>>>>>>>>Services architecture: Accessibility,
>  >>>>>>>>>Authentication, Authorization, Confidentiality, Integrity,
>  >>>>>>>>>and Non-repudiation. Together they form
>  >>>>>>>>>the foundation for secure Web Services.
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>The above text is NOT a requirement at all!!!
>  >>>>>>>>It doesn't even read like one.
>  >>>>>>>>It's a lite intro for D-AR006.1 thru D-AR006.6.
>  >>>>>>>>The editors inserted D-AR006.10 and D-AR006.11 in
>  >>>>>>>>the wrong place.  The two should have followed D-AR009;
>  >>>>>>>>and the intro should not have been bulletized.
>  >>>>>>>>What a mess.  sigh.
>  >>>>>>>>
>  >>>>>>>>D-AR006.11 text should read as follows:
>  >>>>>>>>
>  >>>>>>>>D-AR006.11 The architecture must provide an interface for
>  >>>>>>>>Web Services to directly communicate with their underlying
>  >>>>>>>>infrastructure.
>  >>>>>>>>
>  >>>>>>>>The interface is for negotiating services that an
>  >>>>>>>>
>  >>infrastructure
>  >>
>  >>>>>>>>may provide to, or perform on behalf of, requesting Web
>  >>>>>>>>
>  >>>Services.
>  >>>
>  >>>>>>>>Such value-added services may include: security, content
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>delivery,
>  >>>>>
>  >>>>>
>  >>>>>>>>QoS, etc. For instance, a Web service may instruct (via the
>  >>>>>>>>interface)
>  >>>>>>>>the security agents of its infrastructure to defend against
>  >>>>>>>>DOS/DDOS attacks on its behalf."
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>>is actually a separate requirement from D-AR006.11 
> and should
>  >>>>>>>>>have been
>  >>>>>>>>>labeled D-AR006.12 in the document. Am I reading this
>  >>>>>>>>>correctly? If so,
>  >>>>>>>>>then this needs to be fed to the editors as a comment so
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>that it is
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>>>certain to be tracked (and fixed in the next 
> editor's draft).
>  >>>>>>>>>
>  >>>>>>>>>The question I have then is whether or not Joe is accepting
>  >>>>>>>>>Ayse's request to add Auditing to this list of 6 aspects
>  >>>>>>>>>or whether he is suggesting that yet another requirement
>  >>>>>>>>>(D-AR006.13) be created to accomodate Auditing... do
>  >>>>>>>>>
>  >>any others
>  >>
>  >>>>>>>>>have an opinion on this?
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>I think Ayse has already backed out on Auditing.
>  >>>>>>>>So it's no longer an issue whether I'd accept it.
>  >>>>>>>>(I wasn't inclined to accept it because there's no
>  >>>>>>>>threat model that's uniquely associated with Auditing.
>  >>>>>>>>But I wouldn't decide one way or the other without
>  >>>>>>>>hearing the case out first.)
>  >>>>>>>>
>  >>>>>>>>Whoever wants to give it another shot is welcome to
>  >>>>>>>>present his/her *reasoning and analysis*.
>  >>>>>>>>
>  >>>>>>>>Cheers,
>  >>>>>>>>
>  >>>>>>>>Joe Hui
>  >>>>>>>>Exodus, a Cable & Wireless service
>  >>>>>>>>==================================================
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>>Thanks,
>  >>>>>>>>>
>  >>>>>>>>>Chris
>  >>>>>>>>>
>  >>>>>>>>>Joseph Hui wrote:
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>>>From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>[snip]
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>>D-AR006.11 the six aspects need to be replaced with the
>  >>>>>>>>>>>following seven aspects of the security framework:
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>Ayse, the D-AR006.11 number was taken.
>  >>>>>>>>>>You may want to re-number your proposal as 
> D-AR006.12 instead
>  >>>>>>>>>>if you're serious about it (to be voted on or debated).
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>>Auditing;
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>Auditing* as a security aspect?
>  >>>>>>>>>>Can you explain why?  E.g. for starter, how would you
>  >>>>>>>>>>characterize the threat (model) that's unique to Auditing?
>  >>>>>>>>>>Note that the impetus for requiring each of the original
>  >>>>>>>>>>six begins with a unique threat, or in some cases, threats.
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>>Authentication (includes identification and 
> authorization);
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>Authc & Authz are separate sec aspects.
>  >>>>>>>>>>
>  >>>>>>>>>>Example 1: The security policy of the very system 
> that you're
>  >>>>>>>>>>using probably includes only Authz but not Authc.  
> To login,
>  >>>>>>>>>>you simply enter user name and password, the system checks
>  >>>>>>>>>>the password file and lets you in.  You are not asked to
>  >>>>>>>>>>authenticate yourself as Ayse.  BTW, password file is known
>  >>>>>>>>>>to be one form of Access Control List (ACL).
>  >>>>>>>>>>
>  >>>>>>>>>>Example 2: Alice's security policy includes Authc & Authz.
>  >>>>>>>>>>To join Alice's party, Bob must present a certificate to
>  >>>>>>>>>>Alice to authenticate himself as Bob -- Authc, AND, after
>  >>>>>>>>>>successful authc (sometimes aka positive identification),
>  >>>>>>>>>>Alice checks whether Bob is on her guest list (i.e. ACL)
>  >>>>>>>>>>before allowing him into her party.
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>>Access Control (file permission, etc.);
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>Access Control is just a Authz means.  (See 
> example 2 above.)
>  >>>>>>>>>>
>  >>>>>>>>>>Cheers,
>  >>>>>>>>>>
>  >>>>>>>>>>Joe Hui
>  >>>>>>>>>>Exodus, a Cable & Wireless service
>  >>>>>>>>>>========================================================
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>>Confidentiality;
>  >>>>>>>>>>>Availability; Integrity; Non-repudiation.
>  >>>>>>>>>>>Thanks,
>  >>>>>>>>>>>Ayse
>  >>>>>>>>>>>
>  >>>>>>>>>>>-----Original Message-----
>  >>>>>>>>>>>From: Christopher Ferris [mailto:chris.ferris@sun.com]
>  >>>>>>>>>>>Sent: Saturday, May 04, 2002 10:00 AM
>  >>>>>>>>>>>To: wsawg public
>  >>>>>>>>>>>Subject: D-AR006.11 discussion points
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>SUNW: This requirement goes "inside" a web service
>  >>>>>>>>>>>
>  >>and places
>  >>
>  >>>>>>>>>>>requirements
>  >>>>>>>>>>>on how it is designed.  We should be focusing on 
> externally
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>observable
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>
>  >>>>>>>>>>>(through the web service interfaces) behaviour
>  >>>>>>>>>>>
>  >>>>>>>>>>>SYBS: Implementation details. Don't seem to fit in Web
>  >>>>>>>>>>>Services Architecture
>  >>>>>>>>>>>group..
>  >>>>>>>>>>>
>  >>>>>>>>>>>W3C: See
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  >>>>>>>>>>>
>  
> >>>>>>>http://lists.w3.org/Archives/Public/www-ws-arch/2002May
> /0015.html
>  >>>>>>>
>  >>>>>>>>
>  >>>>>>>>>>ORCL: I don't quite see how "an architecture" can actually
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>provide an
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>>>interface. And in this case the goal may be too ambitious
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>given the
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>>>>number of different possible "infrastructures".
>  >>>>>>>>>>
>  >>>>>>>>>>PF: I just don't see the need for this.
>  >>>>>>>>>>
>  >>>>>>>>>>TIB: not clear to me that individual Web services would
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>ever want to
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>>>>know whether they were under DOS at some lower layer
>  >>>>>>>>>>
>  >>>>>>>>>>CrossWeave: Don't understand this
>  >>>>>>>>>>
>  >>>>>>>>>>CMPQ: The interface is for negotiating services that an
>  >>>>>>>>>>infrastructure may
>  >>>>>>>>>>provide to, or perform on behalf of, a requesting
>  >>>>>>>>>>
>  >>Web Services.
>  >>
>  >>>>>>>>>>Such value-added services may include: security, content
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>delivery,
>  >>>>>
>  >>>>>
>  >>>>>>>>>>QoS, etc. For instance, a Web service may instruct (via the
>  >>>>>>>>>>interface) the security
>  >>>>>>>>>>agents of its infrastructure to defend against DOS/DDOS
>  >>>>>>>>>>attacks on its behalf.
>  >>>>>>>>>>
>  >>>>>>>>>>This seems to say that the requirement is
>  >>>>>>>>>>"The security framework must provide for negotiations
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>pertaining to
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>
>  >>>>>>>>>>security considerations."
>  >>>>>>>>>>
>  >>>>>>>>>>That is, the requirement is for negotiation 
> support;  within
>  >>>>>>>>>>security context,
>  >>>>>>>>>>it is security negotiation, within QoS context, it is QoS
>  >>>>>>>>>>negotiation, etc.
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>>>>>>
>  >>>>>
>  >>>
>  >>>
>  >
> 
> 
> 
> 

Received on Friday, 10 May 2002 14:17:10 UTC