attending 6/23: Eric Sedlar, Geoff Clemm and Anne Hopkins attending 6/30: Geoff Clemm and Anne Hopkins 6/30 Discussion: 1. "Self" special principal identifier for ACEs. The self identifier, now in the spec, is meant to indicate the user principal associated with a resource that is itself an object representing a user (like a security principal account - the usual case, but I speculate it could also be useful for user objects like an employee record in an HR database). During access check, the "self" principal id in the ACE would be replaced by some (unspecified and system-dependent) principal id retrieved from the resource prior to evaluation of whether this ACE matches the caller. The benefit of the self identifier is that it allows a single ACE to be defined once and inherited to a whole tree of resources, providing access control (say, ability to update my password or my home address) to a different individual for each resource, without the overhead of adding a specific principal ACE to the ACL of each resource. Concerns and ideas: * We should add an optional DAV:selfprincipal property to resources. Prior to access check, if an ACE with the Self tag exists, the value in DAV:selfprincipal-id is substituted into the ACE. Although the selfprincipal is redundant for systems that already implement this behavior (eg, principal resources already contain an ID that gets substituted into the Self ACE), the selfprincipal would allow a broader set of resource types (like employee records) to take advantage of the Self ACE behavior. It would make this behavior more flexible, an allow resources that aren't necessarily User or Group objects to participate in the scalable ACL inheritance behavior. * Does "self" behavior overlap too much with "owner" behavior (I say definitely not - will articulate below). * Should we have a "selfgroup" princID for ACEs, like self but applies to Group resources, where group object ID replaces "selfgroup" in the ace for acc. check. I don't think we need this if we allow generic application of this selfprincipal behavior as described in first bullet. * should we have an "ownergroup," like owner, but contains the group that "owns" this resource Justification for Owner behavior: * Many existing systems have a well defined notion of a resource's owner. Owner is usually initialized to be the principal ID of the user that created the resource. Owner can be changed on many, but perhaps not all systems. * Owner is a useful specialized concept because it: * Identifies to other users the owner of a resource so that he may be contacted (to request access, to warn of disk space problems, etc) * Identifies who to "charge" for disk quotas, etc. * May imply special rights, such as ability to set the access control policy (since it is his resource to control). For these reasons, I suggest we maintain a strong notion of DAV:owner and don't overload it with any other behavior. We already agreed that the spec doesn't mandate any implicit owner rights. The special "owner" principal tag for the ACE allows for scalable ACE configuration to apply to owners. Justification for Self behavior: * Scalable administration of access control for resources representing Users (eg, security principal accounts, HR employee database records, LDAP directory User objects). Namely, a single ACE may be defined once and inherited to a whole tree of User resources, granting rights (say, ability to update my password or my home address) to a different individual for each resource, without the overhead of adding a specific principal ACE to the ACL of each resource. NT actually uses this special SelfPrincipalID for ACEs on both User and Group objects; the SelfPrincipalID is replaced with the principal ID associated with the user or group resource being accessed. To answer Geoff's concern about why we need both: The primary motivation for "self" ACE is scalable ACL admin on user-oriented resources. The SELF ACE must map to a principal ID that is NOT the same as the owner (users don't usually own their security accounts, their HR records, etc, but they may be able to update certain fields on these resources). Th primary motivation for "Owner" is not scalable ACL admin (though the special owner ACE is useful for this purpose), but for other purposes like disk quota accounting and identifying who has unqualified ability to assign rights. What about OwnerGroup? OwnerGroup: UNIX and NT assign the ownergroup at resource creation time to be the primary group of the user creating the resource. UNIX essentially uses this to assign rights for their one "group ACE." NT supports a special principal-ID for the "OwnerGroup" for use in ACEs; priot to access check, it is replaced with the "ownergroup" defined on the resource. I'd vote for supporting this as optional behavior in the spec. Conclusion: I propose adding two new optional properties on a resource: DAV:ownergroup Live property (same XML definition as DAV:principal) identifying the principal of the group owner of this resource. Group owners may be granted rights in inheritable ACEs by using the special DAV:ownergroup tag as the principal ID in the ACE. DAV:selfprincipal Live property (same XML definition as DAV:principal) identifying the principal to be substituted for the special DAV:self principal tag in an ACE for anaccess check operation. I propose adding one additional special principal tag for use in ACEs: DAV:ownergroup Tag indicating that the value of the DAV:ownergroup property should be substituted for this tag in an ACE for purposes of access check on this resource. For consistency, should we rename the special DAV:self principal identifier tag to DAV:selfprincipal. Is it ok for these tags to have the same names as the actual properties? 2. Property ACEs. Geoff and I agreed the notion of an ACE containing rights that controlled access to a specific property(ies) should be added since it could be defined simply, it would be very useful for webdav, and it would be optional. Here's my stab at text describing this feature: The following property is an optional element of the DAV:ace property: DAV:acepropertytypes: This property contains one or more elements, each of which is an XML tag identifying: * a property on this resource and/or * a property on a child resource that may inherit this ace. Presence of this property distinguishes this ACE as a "Property ACE." The rights associated with a "Property ACE" control access to only the property(ies) contained in DAV:acepropertytypes, and not to the resource as a whole. The set of access rights supported on Property ACEs may be all or a subset of the DAV:access-rights present on this resource. This spec does not provide a mechanism to specify a different set of access-rights for a property, than for the resource. An implementation that supports a different set of access-rights for a property than for the resource, must return an error "Unsupported Right" on an attempt to write a Property ACE with rights not supported by the server. 6/23 Agreements: 1. Spec doesn't need to mention Locking the resource prior to updating ACL. This is recommended, but not required, and is not special to the access control properties. 2. Change spec to say that ACEs contain either the Grant or the Deny, but not both elements. (change made to spec version 01.3) 3. Remove all mention of an ACE "unique key." Remove mention of only one ACE per unique key per ACL. The "one ACE per unique key" concept was no longer required since we don't allow discrete updates where an update might have to replace the ACE with the same key. We only allow updating the entire ACL. (change made to spec 01.3) 4. We agreed that the client should strip out inherited ACEs and write only the explicit ACEs. I thought longer about this after the call and reversed my opinion. Rationale for NOT stripping inherited ACEs on the client-side: * "friendly" model allows client to read ACL, tweak a single ACE, write ACL. No excess processing of untouched ACEs. * supports client-side propagation of ACL inheritance, which is an optimization supported/required by some existing systems * server can figure out the right thing to do, one of the following two options: * silently (no error) filter out inherited ACEs, then replace all existing explicit ACEs with the client-provided explicit ACEs, or * replace the entire existing ACL with the entire client-provided ACL including inherited ACEs (this supports client-side propagation of inheritance) I thought I added this to the spec, but it appears to have gotten lost in one of my internal doc merges. 5. We agreed that DAV:owner is not granted any implicit rights by this spec, since systems may differ in this behavior. Instead, server should create a read-only ACE reflecting any rights granted implicitly by the system (to owner or anyone else for that matter). This "readonly" ACE should have the DAV:inherited flag and DAV:inheritancesource should contain DAV:system-ace. (this change made to spec 01.3, although I forgot to delete the phrase saying owner is granted implicit read/writeacl) Other items to address in next draft (some of these already catalogued in Open Issues section of spec): 1. Do we need to add a section defining new error codes/messages? Or should we make a pass through the doc and ensure all possible error conditions are mapped to existing errors? 2. Should we articulate that the required DAV:principal property should be able to be used for equality checks? Equality checks were mentioned as one reason why this property should be mandatory, even if the URI is fake. 3. Add to "Using ACLs" section: Clients shouldn't strip out inherited ACEs. Add that it is a server decision whether to: * silently (no error) filter out inherited ACEs, then replace all existing explicit ACEs with the client-provided explicit ACEs, or * replace the entire existing ACL with the entire client-provided ACL including inherited ACEs (this supports client-side propagation of inheritance) Do we need to provide a flag that indicates whether the server accepts a client update of inherited ACEs (to support client-side propagation of inheritance)? And/or a flag to indicate that the client WANTs to set inherited ACEs? 4. I propose renaming DAV:rights to DAV:effectiverights. DAV:rights is a little ambiguous and could be confused with DAV:access-rights, where the supported rights are defined. In the ACL Semantics section, I define Effective Rights (all rights that would be granted to a user based on current ACL), since the concept is required in that section. 5. How are WebDAV Access Control compliant servers detected. 6. Add support for Property ACEs. Anne will need to update Semantics description to address property ACEs. 7. Do any other Semantics models need to be supported by initial spec. What is a realistic process for implementors to add a new model? Is there any problem identifying UNIX, NT, etc in the spec, whether as examples, or as tag names for the models? 8. Remove "Default ACLs" from the section 6 heading. "Default ACLs" refers to an ACL that is used (perhaps in combination with other info) to create the initial ACL for a newly created resource. This, I believe, is outside the scope of our spec. 9. Update the self, selfgroup, ownergroup stuff according to eventual agreements.