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 Tuesday, 15 September 1998 15:47:58 UTC