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

I support AR006.12, as well as your proposed AR006.13.

Steve Monetti
AT&T

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Darran Rolls
Sent: Thursday, May 09, 2002 10:20 PM
To: Joseph Hui; www-ws-arch@w3.org
Subject: RE: D-AR006.12 [Was RE: D-AR006.11 discussion points]


I understand creating AR006.12 and support it.  As a vendor of Identity
Mgmt solutions we can say with clarity that our customers unquestionably
see this as part of the model.  I must also re-iterate my earlier
comment that in our experience they also very much see security
administration as being critical too.  Let me provide an example:

Say you provide me with a value oriented service that requires you
create an identity for me within your object model, from which access
and billing is driven.  I'd like to see the following (example)
characteristics of that model:

- I want you to allow me to manage (some part of) my identity.  
- You want to make sure that if a don't pay you revoke my access
- Your auditor (and my lawyer) wants you to prove what access I had when

I know these sound like application "capabilities", so where's the
architecture?  IMO, we should guide the WS architecture to support the
notions of security administration throughout the operational life-cycle
of the service.

Is there any support for a D-AR006.13 thus:

	Where a web service provides security features in line with
AR006, it 	SHOULD provide the ability to manage that security in a
meaningful 	way.

...Or something to that extent.

--------------------------------------------------------
Darran Rolls                      http://www.waveset.com
Waveset Technologies Inc          drolls@waveset.com 
--------------------------------------------------------


-----Original Message-----
From: Joseph Hui [mailto:Joseph.Hui@exodus.net] 
Sent: Thursday, May 09, 2002 2:12 PM
To: www-ws-arch@w3.org
Subject: RE: D-AR006.12 [Was RE: D-AR006.11 discussion points]

Per off-line discussion between Steven Monetti and me,
we agreed to propose to the WG that we drop the following text
that had been meant to serve as a lite intro for few "core"
sec reqs but was mistakenly bulletized during the editing process:

   * 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 deletion would save us the debate over nomenclatures,
so we can focus more on the newly introduced D-AR006.12.

Any objections?

Editors, please take note.

Thanks,

Joe Hui
Exodus, a Cable & Wireless service
===========================================================
-----Original Message-----
From: Joseph Hui 
Sent: Thursday, May 09, 2002 10:47 AM
To: Steven A. Monetti; Abbie Barbir; Dilber, Ayse, ALASO; Christopher
Ferris; www-ws-arch@w3.org
Subject: RE: D-AR006.12 [Was RE: D-AR006.11 discussion points]


The SANS model is geared toward home networks, isn't it?

The other reference defines Availability in ways that's IMO
much less discerning than what I did or would.  
I'd leave to others to judge for themselves whether that's
a "*credible* security publication/discourse."
Joe Hui
Exodus, a Cable & Wireless service 

====================================

 -----Original Message-----
From: Steven A. Monetti [mailto:smonetti@att.com]
Sent: Thursday, May 09, 2002 10:33 AM
To: Abbie Barbir; Joseph Hui; Dilber, Ayse, ALASO; Christopher Ferris;
www-ws-arch@w3.org
Subject: RE: D-AR006.12 [Was RE: D-AR006.11 discussion points]


SANS (System Administration, Networking and Security) Institute defines
the basic security
model: http://rr.sans.org/homeoffice/home_net.php as a triad
Confidentiality, Integrity and Availability.

Another reference:
http://www.yourwindow.to/information-security/gl_confidentialityintegrit
yandavailabili.htm

steve
-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Abbie Barbir
Sent: Thursday, May 09, 2002 1:07 PM
To: Joseph Hui; Dilber, Ayse, ALASO; Christopher Ferris;
www-ws-arch@w3.org
Subject: RE: D-AR006.12 [Was RE: D-AR006.11 discussion points]


Ayse, Joe, 

I think it would be cleaner if Ayse Dilber wait until the e-mail
problems are solved. 
It is getting harder to read the thread and forwording the e-mails makes
even harder to track. 

Out of this, I agree on the following (I am quoting from list below): 

we should stick to terms that are more conventionally known or used in
*credible* 
security publications/discourses, and refrain from re-inventing 
new meanings for established terminologies unnecessarily. 



abbie 




-----Original Message----- 
From: Joseph Hui [mailto:Joseph.Hui@exodus.net] 
Sent: Thursday, May 09, 2002 12:47 PM 
To: Dilber, Ayse, ALASO; Christopher Ferris; www-ws-arch@w3.org 
Subject: D-AR006.12 [Was RE: D-AR006.11 discussion points] 



> From: Dilber, Ayse, ALASO [mailto:adilber@att.com] 
> Sent: Thursday, May 09, 2002 7:32 AM 
> To: Joseph Hui; Christopher Ferris; www-ws-arch@w3.org 
> Subject: RE: D-AR006.11 discussion points 
> 
> Sorry about my e-mail problems, I think the majority of it 
> has been resolved.  
> 
> Here is another proposal: 
> 
> FROM: 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.

> 
> TO: There are three security primitives in the security 
> framework for Web 
> Services architecture: Confidentiality, Availability, and 
> Integrity. 

This is the first time I've heard "Confidentiality, 
Availability, Integrity" be referred to as security primitives. 
I've already explained the conventional meaning of 
security primitives in couple other messages, so 
won't repeat here.  I participate/tune in many security 
forums, but not all. So I could have missed it somewhere, 
though I doubt it.  Perhaps you could show me where. 

My advise to the WG is that we should stick to nomenclatures 
that are more conventionally known or used in *credible* 
security publications/discourses, and refrain from re-inventing 
new meanings for established terminologies unnecessarily. 
It follows that we stay with the "aspects/facets" terms 
when referring to Accessibility, Authc, Authz, Conf, 
Integrity, and Non-rep. 

Also, Availability is not the same as Accessibility in 
the strictest sense.  E.g. you can have a website 
available all day (by having triple backup sites 
irrespective of security), yet a consumer can't 
access it because its (the consumer's) DNS server 
has been spoofed.  The former pertains to the WS 
provider only, the latter concerns both the provider 
and consumer.  (There're corner cases one can use 
to make arguments over this characterization.  I'll 
leave them as homework for those who may want to argue.) 

> And, 
> together with Authentication (includes identification and 
> authorization), 
> Access Control (file permission, etc.), Non-repudiation, and 
> Auditing make 
> up the seven the security principles that form the foundation 
> for secure Web 
> Services. 

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 07:56:53 UTC