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 Tuesday, 15 September 1998 15:05:02 UTC