W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

RE: References and Access Control (was, RE: Adv. Coll. items from the 42nd IETF)

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Fri, 18 Sep 1998 16:24:07 -0400
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C6E@x-wb-0128-nt8.wrc.xerox.com>
To: "'Lisa Lippert (Dusseault) (Exchange)'" <lisadu@exchange.microsoft.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Cc: slein@wrc.xerox.com
I agree if you meant to say *even direct* references need separate access
control lists.  As long as there are any operations that affect the
reference itself (and we are proposing that DELETE, MOVE, and COPY do affect
the reference itself, even for direct references), access control makes
sense for the reference.

We distinguished references along 2 axes: direct / indirect, strong / weak.
Strong / weak has to do only with whether the server undertakes to insure
referential integrity.  I don't see how the strong / weak distinction has
any implications for access control lists.

--Judy

Judith A. Slein
CR&T/ADSTC
jslein@crt.xerox.com
8*222-5169


> -----Original Message-----
> From: Lisa Lippert (Dusseault) (Exchange)
> [mailto:lisadu@exchange.microsoft.com]
> Sent: Tuesday, September 15, 1998 3:47 PM
> To: 'Slein, Judith A'; 'Jim Amsden'; 'WebDAV'
> Cc: slein@wrc.xerox.com
> Subject: RE: References and Access Control (was, RE: Adv. Coll. items
> from the 42nd IETF)
> 
> 
> Even strong references require some kind of separate access 
> control list.
> You need to be able to specify who can delete the strong 
> reference, and it
> may not be the same list of principals that can delete the 
> resource referred
> to.
> 
> I'm not clear whether all possible operations on references, 
> strong or weak,
> need their own access control.
> 
> Lisa
> 
> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Tuesday, September 15, 1998 12:07 PM
> To: 'Jim Amsden'; 'WebDAV'
> Cc: slein@wrc.xerox.com
> Subject: References and Access Control (was, RE: Adv. Coll. items from
> the 42nd IETF)
> 
> 
> >Jim Amsden wrote: 
> > 
> > 3. Issue: Should access control of references be distinct from those
> > of target?
> > 
> > Yes. SQL views are a good example of a similar concept.
> 
> This seems right to me.  At least indirect references are resources,
> with their own URLs, to which HTTP and WebDAV can be applied, 
> which bear
> properties, etc.  So access control should certainly apply to 
> them just
> as to any other resource.
> 
> Direct references are less clear, but they get created 
> independently of
> their targets, deleted independently of their targets, and some subset
> of HTTP / WebDAV methods affect them, so it seems as if they, too,
> should have access control separate from their targets.
> 
> > 
> > 4. Issue: Should the owner of a resource should be able to 
> > prevent creation of
> > references to it via ACL?  This would affect requirements for 
> > ACL, not ACR.
> > 
> > No, creating a reference to a resource should only require 
> > read access to the
> > resource. In general, the ACL scheme needs to be simplified 
> > from ACLs on every
> > DAV method to ACLs on the effect the DAV method has on the 
> > state of the
> > resource. Basically CRUD plus Execute like in most 
> operating systems.
> >
> 
> This is not so clear.  The discussion of Strong References at Redmond
> revealed some security risks that might lead us to conclude 
> that we want
> access control on the creation of references.  For example, 
> one way for
> a server to preserve referential integrity for DELETE operations is to
> refuse to delete the target as long as there are any references to it.
> On a server that uses this approach, the owner of any resource who
> wanted to be sure he could always delete it might want to restrict
> permissions to create (strong) references to it.
> 
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
>  
> 
Received on Friday, 18 September 1998 16:26:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:47 GMT