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

Re: Access Control Preliminary Draft

From: Judith Slein <slein@wrc.xerox.com>
Date: Mon, 7 Jul 1997 07:10:05 PDT
Message-Id: <2.2.32.19970707141005.00ff100c@pop-server.wrc.xerox.com>
To: jradoff@novalink.com, w3c-dist-auth@w3.org
Cc: Judith Slein <slein@wrc.xerox.com>
Yes, I think we need to have more discussion around locking / reservations /
access control and how they all relate to each other.

1. The interpretation of "reservation" that seemed to prevail in this
mailing list is that it is strictly informational.  The presence of a
reservation on a resource does not prevent anyone from reading or writing it
-- it just lets others know that the reservation owner may be editing the
resource.

2. I see how your requirement derives from Jim's suggestion that we may need
to be able to prevent people from reading a resource while it has a write
lock.  I would like to suggest, however, that this has nothing to do with
access control.  It may turn out that access control and locks get
implemented using the same techniques, but I think it's worth keeping the
concepts separate at least through the requirements phase.  Access rights
are persistent properties of resources, whereas locks are short-lived states
of resources.  Locks and access rights interact in complex ways that will be
difficult to capture if we treat them as a single thing.

If we think it's desirable for write locks to prevent users from reading the
resource, then that's just part of the definition of a write lock.  If we
think there need to be two flavors of write lock, one of which prevents
users from reading the resource, one of which allows reading, that is
possible, too.  In either case, the lock is a separate consideration from
access rights, and the server has to take both lock state and access rights
into account in deciding whether to allow a given user to read the resource.

--Judy

At 08:52 AM 7/3/97 PDT, Jon Radoff wrote:
>My idea may have more to do with "reservation" than the concept
>of locking.
>
>The following was proposed by Jim 5-16-97:
>
> : I'd like to throw out for discussion a "minimalist" view of access
> : control. My hypothesis is the only access control necessary in the
> : client-server WebDAV protocol is a method which temporarily changes
> : the access rights of a resource such that only (write) lock holders
> : may read the resource, and another message which reverts the access 
> : rights back to their original form once editing is complete (or 
> : perhaps this happens automatically once all locks are released). This 
> : limited access control provides document privacy during editing, so 
> : authors are assured that others will not be reading their preliminary 
> : work.
>
>[See "Re: Access Control Draft" for 5-16-97 on the WebDAV mail archive]
>
>I don't really agree with the minimalist requirement for access
>control, but I tried to extract the spirit of the concept into the
>section on locking with access control.
>
>It seems logical that reservation (call it document privacy,
>locking, or whatnot) should be managed by the access control
>component.  The reservation state of a document essentially
>controls who is allowed to access it in a given way at a given
>time.
>
>It seems like this area needs further comment...
>
>Jon
>
>
Name:			Judith A. Slein
E-Mail:			slein@wrc.xerox.com
Internal Phone:  	8*222-5169
External Phone:		(716) 422-5169
Fax:			(716) 265-7133
MailStop:		128-29E
Received on Monday, 7 July 1997 15:49:29 GMT

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