RE: D-AR006.11 discussion points

What can we do about auditability interoperability?  I don't think we can do
too much, so I don't think this should be added.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Narahari, Sateesh
> Sent: Wednesday, May 08, 2002 12:26 PM
> To: 'Christopher Ferris'; www-ws-arch@w3.org
> Subject: RE: D-AR006.11 discussion points
>
>
> I consider auditing to be an integral part of security. So,
> it makes sense
> to add it to the list of these 6 aspects.
>
> However, I am not convinced if accessibility belongs in there.
>
> Regards,
> Sateesh
>
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Wednesday, May 08, 2002 1: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.
> >>
> >>
> >>
> >
> >
>
>

Received on Wednesday, 8 May 2002 23:08:55 UTC