- From: Judith Slein <slein@wrc.xerox.com>
- Date: Wed, 2 Jul 1997 10:49:14 PDT
- To: jradoff@novalink.com
- Cc: w3c-dist-auth@w3.org
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