RE: D-AR006.11 discussion points

>"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."
>
>is actually a separate requirement from D-AR006.11 and should 
>have been labeled D-AR006.12 in the document. 

I agree tbis is a separate requirement than (effective) reqmnt
that should be included D-AR006.11:

"D-AR6011 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, 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."

Furthermore, w.r.t. 6.11 and the proposed 6.12, I'm a little
concerned what we mean by web services "security framework" in
D-AR6002.1-6006 requirements. E.g., do we have agreement that
in context of SOAP-based web services these frameworks imply
the support of commonly agreed and interoperatible security 
header extensions. I know we are talking about requirements 
here and not solutions, but I don't explicit capture of
the header extension problem anywhere in the requrements
document while we are assuming SOAP message exchanges in the
Usage Scenario document. This seems a bit conflciting.

thanks,
Zahid Ahmed




-----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."

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?

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.
>>
>>
>>
> 
>