Re: Additional WebDAV Requirements?

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