- From: Jeffrey E. Sussna <kuanjes@beaver.slip.net>
- Date: Mon, 3 Aug 1998 12:53:13 -0700
- To: "Babich, Alan" <ABabich@filenet.com>, "'Bruce Cragun'" <BCragun.ORM2-1.OREM2@gw.novell.com>, <fielding@kiwi.ics.uci.edu>, <francis@netscape.com>
- Cc: <w3c-dist-auth@w3.org>
I originally proposed the approach under debate. Perhaps I forgot I was participating in a spec discussion and wasn't detailed enough in my statements. In any case, LDAP seems to be able to accomplish Something similar without getting its knickers in a twist. As I stated before, it is true that the implementation under the covers has to treat ACL's specially. Jeff -----Original Message----- From: Babich, Alan <ABabich@filenet.com> To: 'Bruce Cragun' <BCragun.ORM2-1.OREM2@gw.novell.com>; fielding@kiwi.ics.uci.edu <fielding@kiwi.ics.uci.edu>; francis@netscape.com <francis@netscape.com> Cc: w3c-dist-auth@w3.org <w3c-dist-auth@w3.org> Date: Monday, August 03, 1998 11:43 AM Subject: RE: Additional WebDAV Requirements? >Bruce: > >What I have to say has already been stated in this >e-mail thread, but let me try to restate it in a >way that might help. > >* Access to the resource itself (and, perhaps, to its >properties individually) is controlled by the ACL(s) >of the resource and the credentials of the client. >This is done automatically under the covers, so that >it is invisible to the operation of normal clients. > >* Normal clients do not want to see ACL's, even if >they request "allprop", i.e., return all properties >of a resource. Only security administrators want >to get at the ACL's. For everyone else, ACL's should >be invisible. > >* Aside from not wanting to bother clients with ACL's, >there is a much more serious problem with treating >ACL's as normal properties -- the problem of infinite >regression. For example, ACL's can be used to secure >properties individually. If you treated ACL's >as normal properties on a system that had security >on an individual property basis, you would need a >second ACL "property" to control access to the first ACL >"property", which in turn controls access to a normal >property (say, Author). But of course, the second ACL >for Author would have to be accessible for modification >as a normal property as well. But you have to control >access to the second ACL for Author. So then you would >have to have a third ACL property to control access >to the second ACL property, etc. ad infinitum. > >The infinite regress problem exists even if there is >only a single ACL property for the resource as a whole. > >* The most obvious solution is to have a separate >access mechanism for ACL's -- treating ACL's exactly >the same as normal properties won't work. This is >not surprising, since they don't perform the same >function as normal properties -- they control access >to normal properties, which is functionality of a >qualitatively different kind. This has nothing >to do with the size of ACL's, or the sharing (or not) >of ACL's across resources by referring to them, or >design principles (other than "the design must work"). > >Alan Babich > >> I'm not sure I understand why this would be a big mistake. >> Are you envisioning having a "set" of ACLs that are, in >> essense, registered, and each resource that has an ACL simply >> points to an ACL resource? Or do you consider ACLs to be >> potentially large and therefore you don't want to use the >> storage space to store an ACL individually for each document? >> Or is it simply a design principle that an ACL should not be >> a property? > >
Received on Monday, 3 August 1998 15:55:47 UTC