FW: D-AR006.11 discussion points

To the public list.
(The thread came to me with private list cc.)

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

-----Original Message-----
From: Joseph Hui 
Sent: Wednesday, May 08, 2002 9:05 AM
To: 'Dilber, Ayse, ALASO'; w3c-ws-arch@w3.org
Subject: RE: D-AR006.11 discussion points


> -----Original Message-----
> From: Dilber, Ayse, ALASO [mailto:adilber@att.com]
> Sent: Wednesday, May 08, 2002 5:47 AM
> To: Joseph Hui; w3c-ws-arch@w3.org
> Subject: RE: D-AR006.11 discussion points
> 
> Auditing includes logging important events, backups, etc. 
> these are very important security attributes for service 
> providers. Your comments about authentication and 
> authorization is just a different definition, so i'm ok with 
> that. 

Interesting.  I'd have guessed you might be trying to make
a case for intrusion detection.

> I am sorry for mixing up the numbering scheme for the 
> goal 12 with 11.  

No problem at all. 

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

> Ayse
> 
> -----Original Message-----
> From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
> Sent: Tuesday, May 07, 2002 2:44 PM
> To: Dilber, Ayse, ALASO; w3c-ws-arch@w3.org
> Subject: RE: D-AR006.11 discussion points
> 
> 
> > 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 Wednesday, 8 May 2002 16:33:49 UTC