Re: FYI: Design Team Meeting 11/20-11/21

Jim,

> Topics of discussion will be: access control, issues on the protocol draft,
> versioning.

I've made major additions and changes to the access control requirements
document and submitted it as an Internet-Draft.  It is available as:

http://people.netscape.com/hep/webdav/ac/draft-ietf-webdav-acreq-01.txt

This adds a description of the access control framework, and specifies more
detailed requirements than the previous version.  It mostly reflects my own
proposals for what the requirements should be, except for the section on
generic access rights, which is left mostly as it was for the moment.

The access control issues to be discussed at the design meeting, as I see them,
are:

1) Review access control framework and terminology.

2) What is nature of a principal description (previously called a principal
specifier)?

In particular, does it simply refer to a list of users and/or groups, or does
it (or could it) include other principal attributes such as IP address and DNS
name?  Does it allow Boolean expressions as proposed in the requirements
document?

3) How is conflict between ACEs in an ACL resolved?

The ACL protocol document uses ACE specificity as a mechanism for determining
precedence.  I claim that if general principal descriptions are going to be
required or even allowed in an ACE, specificity may become difficult or
impossible to define.  Therefore the requirements document specifies that ACEs
are ordered in an ACL, and order determines precedence in resolving conflicts.

4) Should an ACE be able to grant its access rights to one principal
description and deny them to another principal description?

It depends on how conflicts between ACEs are resolved, in my opinion.  If using
ordering to resolve conflicts, it seems unnecessary.

5) How are users (and possibly groups) referenced in a principal description?

I don't think opaque identifiers promote interoperability, so the requirements
document differs with the protocol document on this point.

6) What kind of inheritance is required or permitted?

Inheritance complicates things considerably.  The requirements document
suggests that it is optional, but proposes certain requirements for
implementations which do support inheritance.

7) If inheritance is required or allowed, how are conflicts between policies in
different ACLs resolved?

The requirements document proposes ordering ACLs.

8) How is access control to ACLs themselves managed?

The requirements document still has the "change access" access right, but I
think finer granularity is needed.  For example, you probably want to be able
to give someone the right to grant "read" access to a resource, but not to
grant "modify" access.  This is partially reflected in the requirements by
specifying operations to insert and delete individual ACEs in an ACL.  That is,
someone who was not allowed to grant "modify" access would not be allowed to
insert or delete an ACE containing the "modify" right.

9) What generic access rights should be supported?

The requirements document has the old list.  We ought to review it.

10) Merging of access rights, e.g. "list" and "read", is it really a
requirement?

The requirements document has been changed to limit access right merging to
particular cases, rather than giving server implementors carte blanche.  I
don't think that a conforming implementation should be allowed to merge "read"
and "delete", for example.  Or do some things just go without saying?

I think we'll be doing really well if we get through issues 1-5, and maybe
start on 6.

Howard

Received on Wednesday, 19 November 1997 02:07:00 UTC