Comments on ACL Protocol

Here are my comments on the WebDAV ACL Protocol,
draft-ietf-webdav-acl-00.txt.

Like the access control goals document, I found this document to be a good
starting point for discussions on creating an access control protocol for
WebDAV.  It too could benefit from review by the mailing list, but it is in
very good shape for an initial draft.

Comments:

Contents:
 - There are several "standard" sections which are missing from this draft,
such as:
   * Notational conventions
   * Terminology (the definitions should be the same as in the goals
document)
   * Security considerations
   * Internationalization considerations

General:

- Somewhere, this document needs to have a section describing the problem of
mapping the rights in the access control protocol into rights supported by
the underlying repository.

Title:
 - Since this document is really a Web access control protocol, the title
should reflect this.  I prefer the title, "Web Access Control Protocol"

Introduction:

 - The introduction should, before leaping into a discussion of mechanism,
give a brief overview of the problem, and the need for a protocol.

 - The introduction states that "individual properties can be given their
own ACL", yet this is different from my reading of the goals document.

Principal Identifiers:

 - The goals document states that groups are out of scope, yet a compound
principal sounds very much like a group.  Furthermore, compound principals
are underspecified -- this document has a brief definition, and no associate
protocol elements.

 - Human readability of principal identifiers is going to be a problem,
since presumably they will be exposed in the user interface at some point in
time.

Granting and Denying Rights:

- The first paragraph needs some work.  First, my understanding is that it
is an ACE, not an ACL which does the actual granting and denying of rights.
An ACL is just a collection of ACEs.  Second, the need for having both grant
and deny capability comes from many sources, not just from compound
principals.  In particular, I had thought that groups could be modeled by
sets of ACEs, and hence the compound principal notion isn't strictly needed.
Plus, if the protocol is going to have compound principals, then the goals
need to allow them, rather than disallowing them.

- In the third paragraph it states, "Rights MAY only be granted to a
principal by an explicit listing of that principal in a 'grant' section of
an ACL."  First, I think the "ACL" should be an "ACE".  Second, the MAY
isn't really right -- this is really a MUST requirement phrased in a odd
way.

- The rules for resolution of access control conflicts have a few
definitional problems:
  * The conflict resolution rules use the term "parent" and "child", which
need to be defined.
  * This definition could be difficult, since a resource may be accessible
via multiple collections.  I'm assuming that ACLs are associated with a
resource, rather than associated with a URL, in which case "parent" and
"child" relationships aren't 1:1.  It also raises tough questions like, how
should inheritance occur when a resource is accessible via multiple URIs
which exist in mutiple collections. Having ACLs associated with URLs might
not be a bad approach here.

Section 3.1, "Examples"

 - The examples need to carefully use the defined terms in the protocol.
So, for example, Section 3.1.1 should read:

"An ACE in the ACL defined on a resource specifies that the principal whose
opaque identifier as provided by the authentication service is 'A'..."

Section 4, "ACL Inheritance"

 - The inheritance model needs to consider non 1:1 containment relationships

 - There is some discussion here about the "owner value" being set upon
resource creation.  Ownership is important enough that it deserves its own
section, which discusses how the owner is set, read, etc.

 - "Inheritance can either be static or dynamic." -- The specification needs
to be a little more detailed here.  If inheritance can go either way, can a
client specify this when they MKCOL?  Or is this an inherent characteristic
of the repository?  Is it discoverable?  Personally, I think mandating
static inheritance, and having no dynamic inheritance is the best choice
here.

Section 5, Properties and ACLs

 - Do we want properties to have per-property access rights?

Section 6, Rights definitions

 - All the namespaces need to be "DAV:"

Section 6.5, createchild

 - The "ADDREF" reference should be changed to "MKREF"
 - MKCOL needs to be added

Section 6.6

 - The reference to "DELREF" goes away.

Section 6.9

 - The definition should be restated in terms of the ACL method, not
modifying the ACL property

There also nede to be some new rights:

 - read body
 - read properties
 - a right that controls POST (?)
 - a right that controls LOCK/UNLOCK (?)
 - a right that controls HEAD, OPTIONS (?)

Section 7.2 - "allauthprincipals XML element"

 - what is the scope of "all authenticated principals"?  Per connection? Per
server?

Section 8.2

 - I think it would be appropriate to start specifying the error reporting.

End of section 8:

 - There needs to be a DTD section which captures all of the properties and
elements into one DTD.

Nits:

In the "Status of this Memo" section, ds.internic.net is no longer active.
This section should also add the standard WebDAV draft boilerplate on the
DAV mailing list, and DAV archives location.

In the header for all pages except the first, WebDAV is miscapitalized as
"WEBDav" rather than "WebDAV".  Although, this should really just be the
"Web Access Control Protocol".

The section "Principals Identifiers" should either be "Principal's
Identifiers" or better yet, "Principal Identifiers"

6.2, "read Right"

- There is a reference to the INDEX method in here.

Section 9:

- need to use new XML namespaces syntax


- Jim

Received on Thursday, 7 January 1999 19:16:45 UTC