Re: Access Control Preliminary Draft

I'm back from vacation, moved to a new office, got my computer working, and
am finally getting caught up on mail, so here are some comments:

I agree with Jim that we should try to keep design decisions out of the
requirements paper.  Both the "policies as resources" and "access
attributes" are design decisions.  The suggestion that access control will
be implemented by HTTP methods is also a design constraint.

The requirements that I see in this draft, abstracted from any design, are:

1. It must be possible to set access control permissions on a resource.

2. It must be possible to set access control permissions on a collection
(such as a directory).  By default, resources contained in a collection
must inherit access control permissions from their parent resource.

3. [Notification to applications -- I share Jim's skepticism about this.]

4. It must be possible to set access control permissions on the setting of
access control permissions.

5. At a minimum, WebDAV should provide for access control over listing the
contents of a collection, reading resources [read locked / read unlocked --
I don't think we should make this distinction], modifying resources,
deleting resources, and changing access control permissions on a resource.

In addition, I think we should require:

6. Access control mechanisms should be extensible to allow servers and
applications to support additional categories of access control.  For
example, print permission, create resource, create collection, access to
certain renditions / variants of a resource, time constraints on permissions.

7. It must be possible to discover what categories of access control
permissions can be set for a given resource.

-------------

Section 3: Even with the help of your terminology section, I don't
understand what a security policy is.  Maybe it's not a concept that we need
to express requirements (as opposed to design) anyway.

I don't really like Jim's suggestion of "data producing process" for "Web
Application".  These applications do typically return data to browsers,
sometimes dynamically created, but they might just be interfaces to document
management systems with their own access control policies or workflow
management systems (groupware) that help users define access control over
the life cycle of a document.  Maybe "server-based application".

Section 5.5: It sounds as if you want to require every WebdAV-compliant
server to support all the categories of access control in this section.  In
the general requirements draft, we agreed to avoid talking about compliance,
leaving compliance issues to the WebDAV spec. In any case, I'm not sure we
should require WebDAV servers to provide access control at all, much less
this particular list of categories.  I guess I think of a set of categories
like the one you propose as similar to metadata schemas.  There could be
lots of different access control schemas, each defined in a resource
somewhere, and servers could make it known which schema(s) they support.

Jim raises the question whether to categorize access control by HTTP method.
This would be clean, and may be one of the things we should support.  But
generally, I don't think the things people want to control map nicely to
HTTP methods, or even to abstractions of HTTP methods.  Controlling who can
PUT doesn't let you distinguish between who can create and who can modify,
for example.  Who can modify metadata vs. who can modify content.  Who can
modify which metadata.  In a database application, who can modify which
fields in a record.

I agree with Jim's suggestion to separate locking from access control.  The
server should apply locking constraints and access control constraints
independently.

--Judy
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 Wednesday, 2 July 1997 13:48:26 UTC