- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Wed, 6 Jan 1999 10:50:52 -0800
- To: WEBDAV WG <w3c-dist-auth@w3.org>, Lisa Lippert <lisal@microsoft.com>
In preparation for the access control breakout at the Orlando IETF, I read through the Access Control Goals document, and, while we never ended up discussing the goals document during the breakout, I did want to pass along my comments on the document. In general, I thought it was a good document, which goes a long way towards capturing group consensus on access control goals for WebDAV. But, I also suspect it can be improved with some diligent review. I'd appreciate it if members of the list would read through this draft <draft-ietf-webdav-acl-reqts-00> and send out detailed comments. Detailed comments below: Section 5, definitions - The concept of a "right" needs to be defined. - It would be helpful to separate out the definitions of ACL, and ACE, and also to have an example, in English, of an ACL and an ACE. - The concept of "ownership" needs to be defined. Section 5.2, definition of Principal -- A principal is also intended to model a computational process, like a Web crawler, whose access needs to be controlled, but which doesn't map neatly onto the concept of "user", which typically impies a human. Also, it might be useful to have a brief discussion of the interaction between authentication mechanisms and the notion of a principal. Section 5.3. Scenarios -- this should be a separate, top-level section (it doesn't really fit under "definitions", the heading for section 5. Section 5.4, "Interoperability" -- This should also be its own, top-level section. It should also include the discussion from the breakout session on the issue of mapping access control protocol semantics into the access control semantics of the underlying repository, and the possible pitfalls. Section 6, "Goals" - A general comment on the entire section is that each goal needs to have at least a paragraph of rationale associated with it. This rationale serves many functions: 1) it provides a new reader the information they need to assess whether the goal makes sense, 2) it provides a check to the author on whether the goal is correct -- if the rationale is difficult to provide, it may indicate a problem, 3) it provides a starting point for discussion on the goal. Section 6.2, "Specifying Principals": It must also be possible to specify special types of principals, in particular all authorized principals, all anonymous principals, and all principals. I'm not sure what is meant by "special types of principals" here. I'd like to see some rationale. Section 6.3, "Rights": - to alter the properties of a resource -- "alter all the properties" might be slightly better wording here - None of the rights discussed in this section map to the HTTP methods "HEAD" or "OPTIONS". Does it make sense to have an access right for these too? - None of the access rights map onto HTTP POST either (an "execute" right?) - The following rights need to be added: - Read the body of a resource - Read the properties of a resource Section 6.7, "Security": "It should be acceptable to deny unprotected transactions." I don't understand what is meant by an "unprotected transaction" in this context. Section 7.1: It is recommended that users be able to add access control information to an object without having to reset all access control settings. I agree with this. This is recommended because certain systems or implementations may allow a user to add certain kinds of access rights but not others (i.e. grant "read" but not grant "delete"). Similarly, it should be possible for users to be able to remove, delete or clear access rights without having to reset all rights. However, this rationale seems to be too implementation-oriented. Why did the original stores implement the feature this way? 7.2.2. Inheritance If the underlying system uses inheritance, then users of the DAV access control mechanism should still be able to predict its behavior. This could be achieved if the type of inheritance is discoverable, or if the type(s) of inheritance is/are specified by the DAV access control protocol draft. Even if the goals don't take a stand on the inheritance issue, I think they should still lay out the decision space for which kinds of inheritance are possible. It seems like more work needs to be done to factor out the underlying goals for inheritance. For example, the goals might be something like, "a new resource should receive a default ACL, and this default ACL may depend on its URL." 7.2.3. Ownership Systems in which resources have owners also must be treated with care. Predictability can be achieved on systems with owners by including owner functionality in DAV access control. Systems which do not support owner functionality could refuse requests to change or set ownership. There may be other ways to preserve predictability with inheritance and ownership. Similarly, the goals are sidestepping the issue of ownership. For document authoring, I think having a special principal for each resource, known as the owner, can be justified. The protocol can make ownership actions a SHOULD if the repository mapping issues are too hard, but having ownership seems like a reasonable goal. Section 8.2, "Roles" Those with experience building complex document management or workflow systems on top of stores with simple ACLs know how hard it is to define roles for individuals. For example, the document management system can map the role "author" to grant the rights read/write/delete, but it is more difficult to go the other way. Is an individual with read/write/delete permissions an author, an editor, or somebody with no role and just a list of rights? Many systems employ the concept of assigning roles, more temporary than identities, to more flexibly define access. Roles are important. However, roles would appear to be difficult and not necessarily related to ACLs. The protocol draft MAY define how roles may be assigned. I'm pretty convinced we do not want roles in the protocol. However, the above paragraph doesn't do roles justice. Roles can be very helpful in helping to administer access control across a repository. Plus, roles can be orthogonal to an ACL/ACE mechanism, and hence a role based system could be built to use what we're proposing. 8.3. Certificate-based security Certificates are out of scope for the DAV ACL protocol. Why? Some rationale is needed here. 8.4. Time-based access control Time-based access control is out of scope for the DAV ACL protocol. I agree, although I feel that a brief description of time-based access control, as well as some rationale for not supporting it, is needed here. Also, what is our stance on IP-based access control? 9. SECURITY CONSIDERATIONS This section should reference the new, soon to be Draft Standard authentication document (descendant of RFC 2069). Nits: Section 4.1: These controls define what actions a particular principals is allowed to exercise on a particular resource. "principals" -> "principal" Section 6.2: It MUST be possible to use a the octet strings --> delete "a" after "use" References: [1] Y. Goland, J. Whitehead, A. Faizi, S. Carter, D. Jensen, "Extensions for Distributed Authoring on the World Wide Web", <draft-ietf-webdav-protocol-08>, April 1998. This should be updated. H. Palmer, "Requirements for Access Control within Distributed Authoring and Versioning Environments on the World Wide Web", <draft-ietf-webdav-acreq-01.txt>, November 1997 This can be deleted. P. J. Leach, Y. Y. Goland, "WebDAV ACL Protocol", <draft-ietf- webdav-acl-00.txt> November 1997 M. Satyanarayanan, "Integrating Security in a Large Distributed System", ACM transactions on computer systems 7(3), August 1989. These should actually be referenced someplace. Or, perhaps the last one could be put in a "recommended reading" section. - Jim
Received on Thursday, 7 January 1999 14:08:39 UTC