--- 1/draft-ietf-webdav-acl-05.txt 2006-02-05 02:10:09.000000000 +0100 +++ 2/draft-ietf-webdav-acl-06.txt 2006-02-05 02:10:09.000000000 +0100 @@ -1,781 +1,1323 @@ INTERNET-DRAFT Geoffrey Clemm, Rational Software -draft-ietf-webdav-acl-05 Anne Hopkins, Microsoft Corporation + draft-ietf-webdav-acl-06 Anne Hopkins, Microsoft Corporation Eric Sedlar, Oracle Corporation Jim Whitehead, U.C. Santa Cruz -Expires July 21, 2001 April 23, 2001 + Expires December 21, 2001 June 21, 2001 WebDAV Access Control Protocol Status of this Memo -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other groups -may also distribute working documents as Internet-Drafts. + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet- Drafts as reference material -or to cite them other than as "work in progress." + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet- Drafts as + reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract -This document specifies a set of methods, headers, and message bodies -that define the WebDAV Access Control extensions to the HTTP/1.1 -protocol. This protocol permits a client to remotely read and modify -access control lists that instruct a server whether to grant or deny -operations upon a resource (such as HTTP method invocations) by a given -principal. + This document specifies a set of methods, headers, and message + bodies that define Access Control extensions to the WebDAV + Distributed Authoring Protocol. This protocol permits a client to + remotely read and modify access control lists that instruct a server + whether to grant or deny operations upon a resource (such as HTTP + method invocations) by a given principal. This document is a product of the Web Distributed Authoring and Versioning (WebDAV) working group of the Internet Engineering Task -Force. Comments on this draft are welcomed, and should be addressed to -the acl@webdav.org mailing list. Other related documents can be found at -http://www.webdav.org/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/. + Force. Comments on this draft are welcomed, and should be addressed + to the acl@webdav.org mailing list. Other related documents can be + found at http://www.webdav.org/acl/, and + http://www.ics.uci.edu/pub/ietf/webdav/. Clemm, Hopkins, Sedlar, Whitehead [Page 1] - Table of Contents -1 INTRODUCTION......................................................4 -1.1 Terms...........................................................5 -1.2 Notational Conventions..........................................6 + 1 INTRODUCTION...................................................4 + 1.1 Terms.......................................................5 + 1.2 Notational Conventions......................................6 -2 PRINCIPALS........................................................6 + 2 PRINCIPALS.....................................................6 -3 PRIVILEGES........................................................6 -3.1 DAV:read Privilege..............................................7 -3.2 DAV:write Privilege.............................................7 -3.3 DAV:read-acl Privilege..........................................8 -3.4 DAV:read-cuprivset Privilege....................................8 -3.5 DAV:write-acl Privilege.........................................8 -3.6 DAV:all Privilege...............................................8 + 3 PRIVILEGES.....................................................7 + 3.1 DAV:read Privilege..........................................8 + 3.2 DAV:write Privilege.........................................8 + 3.3 DAV:read-acl Privilege......................................9 + 3.4 DAV:read-current-user-privilege-set Privilege...............9 + 3.5 DAV:write-acl Privilege.....................................9 + 3.6 DAV:all Privilege...........................................9 + 3.7 Aggregation of Predefined Privileges........................9 -4 PRINCIPAL PROPERTIES..............................................8 -4.1 DAV:is-principal................................................9 -4.2 DAV:alternate-URL...............................................9 + 4 PRINCIPAL PROPERTIES..........................................10 + 4.1 DAV:alternate-URL..........................................10 -5 ACCESS CONTROL PROPERTIES.........................................9 -5.1 DAV:owner.......................................................9 -5.2 DAV:supported-privilege-set....................................10 -5.3 DAV:current-user-privilege-set.................................11 -5.4 DAV:acl........................................................11 - 5.4.1 ACE Principal...............................................11 - 5.4.2 ACE Grant and Deny..........................................13 - 5.4.3 ACE Protection..............................................13 - 5.4.4 ACE Inheritance.............................................13 -5.5 DAV:acl-semantics..............................................13 -5.6 DAV:principal-collection-set...................................14 -5.7 Example: PROPFIND to retrieve access control properties........14 + 5 ACCESS CONTROL PROPERTIES.....................................10 + 5.1 DAV:owner..................................................11 + 5.1.1 Example: Retrieving DAV:owner............................11 + 5.1.2 Example: An Attempt to Set DAV:owner.....................12 + 5.2 DAV:supported-privilege-set................................13 + 5.2.1 Example: Retrieving a List of Privileges Supported on a + Resource.................................................14 + 5.3 DAV:current-user-privilege-set.............................15 + 5.3.1 Example: Retrieving the User's Current Set of Assigned + Privileges...............................................16 + 5.4 DAV:acl....................................................17 + 5.4.1 ACE Principal............................................17 + 5.4.2 ACE Grant and Deny.......................................18 + 5.4.3 ACE Protection...........................................18 + 5.4.4 ACE Inheritance..........................................18 + 5.4.5 Example: Retrieving a Resource's Access Control List.....19 + 5.5 DAV:acl-semantics..........................................20 + 5.5.1 Example: Retrieving DAV:acl-semantics....................21 + 5.6 DAV:principal-collection-set...............................22 + 5.6.1 Example: Retrieving DAV:principal-collection-set.........22 + 5.7 Example: PROPFIND to retrieve access control properties....23 -6 ACL SEMANTICS....................................................17 -6.1 ACE Combination................................................17 - 6.1.1 DAV:first-match ACE Combination.............................18 - 6.1.2 DAV:all-grant-before-any-deny ACE Combination...............18 - 6.1.3 DAV:specific-deny-overrides-grant ACE Combination...........18 -6.2 ACE Ordering...................................................18 - 6.2.1 DAV:deny-before-grant ACE Ordering..........................18 -6.3 Required Principals............................................18 + 6 ACL SEMANTICS.................................................27 + 6.1 ACE Combination............................................27 + 6.1.1 DAV:first-match ACE Combination..........................27 + 6.1.2 DAV:all-grant-before-any-deny ACE Combination............27 + 6.1.3 DAV:specific-deny-overrides-grant ACE Combination........27 + 6.2 ACE Ordering...............................................28 + 6.2.1 DAV:deny-before-grant ACE Ordering.......................28 + 6.3 Allowed ACE................................................28 + 6.3.1 DAV:principal-only-one-ace ACE Constraint................28 + 6.3.2 DAV:grant-only ACE Constraint............................28 + 6.4 Required Principals........................................28 -7 ACCESS CONTROL AND EXISTING METHODS..............................19 -7.1 OPTIONS........................................................19 - 7.1.1 Example - OPTIONS...........................................19 + Clemm, Hopkins, Sedlar, Whitehead [Page 2] + 7 ACCESS CONTROL AND EXISTING METHODS...........................29 + 7.1 OPTIONS....................................................29 + 7.1.1 Example - OPTIONS........................................29 + 7.2 MOVE.......................................................29 + 7.3 COPY.......................................................29 -8 ACCESS CONTROL METHODS...........................................19 -8.1 ACL............................................................19 - 8.1.1 ACL Preconditions...........................................20 - 8.1.2 Example: the ACL method.....................................20 - 8.1.3 Example: ACL method failure due to omission of protected ACE21 - 8.1.4 Example: ACL method failure due to inherited ACEs preceding - non-inherited ACEs................................................22 + 8 ACCESS CONTROL METHODS........................................29 + 8.1 ACL........................................................29 + 8.1.1 ACL Preconditions........................................30 + 8.1.2 Example: the ACL method..................................31 + 8.1.3 Example: ACL method failure due to protected ACE + conflict ................................................32 + 8.1.4 Example: ACL method failure due to an inherited ACE + conflict ................................................33 + 8.1.5 Example: ACL method failure due to an attempt to set + grant and deny in a single ACE ..........................34 -Clemm, Hopkins, Sedlar, Whitehead [Page 2] - 8.1.5 Example: ACL method failure due to an attempt to set grant and - deny in a single ACE..............................................23 + 9 ACCESS CONTROL REPORTS........................................35 + 9.1 REPORT Method..............................................35 + 9.2 DAV:acl-principal-props Report.............................36 + 9.2.1 Example: DAV:acl-principal-props Report..................36 + 9.3 DAV:principal-match REPORT.................................37 + 9.3.1 Example: DAV:principal-match REPORT......................38 -9 INTERNATIONALIZATION CONSIDERATIONS..............................24 + 10 XML PROCESSING..............................................39 -10 SECURITY CONSIDERATIONS........................................25 -10.1 Increased Risk of Compromised Users...........................25 -10.2 Risks of the read-acl and cuprivset Privileges................25 + 11 INTERNATIONALIZATION CONSIDERATIONS.........................39 -11 AUTHENTICATION.................................................26 + 12 SECURITY CONSIDERATIONS.....................................40 + 12.1 Increased Risk of Compromised Users........................40 + 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set + Privileges.................................................40 + 12.3 No Foreknowledge of Initial ACL............................41 -12 IANA CONSIDERATIONS............................................26 + 13 AUTHENTICATION..............................................41 -13 INTELLECTUAL PROPERTY..........................................26 + 14 IANA CONSIDERATIONS.........................................42 -14 ACKNOWLEDGEMENTS...............................................26 + 15 INTELLECTUAL PROPERTY.......................................42 -15 REFERENCES.....................................................27 -15.1 Normative References..........................................27 -15.2 Informational References......................................28 + 16 ACKNOWLEDGEMENTS............................................42 -16 AUTHORS' ADDRESSES.............................................28 + 17 REFERENCES..................................................43 + 17.1 Normative References.......................................43 + 17.2 Informational References...................................43 -17 APPENDICIES....................................................28 -17.1 XML Document Type Definition..................................28 + 18 AUTHORS' ADDRESSES..........................................43 -Clemm, Hopkins, Sedlar, Whitehead [Page 3] + 19 APPENDICIES.................................................44 + 19.1 XML Document Type Definition...............................44 + + 20 NOTE TO RFC EDITOR..........................................46 + Clemm, Hopkins, Sedlar, Whitehead [Page 3] 1 INTRODUCTION - The goal of the WebDAV access control extensions is to provide an - interoperable mechanism for handling discretionary access control - for content in WebDAV servers. WebDAV access control can be - implemented on content repositories with security as simple as that - of a UNIX file system, as well as more sophisticated models. The - underlying principle of access control is that who you are - determines how you can access a resource. The "who you are" is - defined by a "principal" identifier; users, client software, - servers, and groups of the previous have principal identifiers. The - "how" is determined by a single "access control list" (ACL) - associated with a resource. An ACL contains a set of "access - control entries" (ACEs), where each ACE specifies a principal and a - set of privileges that are either granted or denied to that - principal. When a principal submits an operation (such as an HTTP - or WebDAV method) to a resource for execution, the server evaluates - the ACEs in the ACL to determine if the principal has permission - for that operation. + The goal of the WebDAV access control extensions is to provide + an interoperable mechanism for handling discretionary access + control for content in WebDAV servers. WebDAV access control + can be implemented on content repositories with security as + simple as that of a UNIX file system, as well as more + sophisticated models. The underlying principle of access + control is that who you are determines how you can access a + resource. The "who you are" is defined by a "principal" + identifier; users, client software, servers, and groups of the + previous have principal identifiers. The "how" is determined by + a single "access control list" (ACL) associated with a + resource. An ACL contains a set of "access control entries" + (ACEs), where each ACE specifies a principal and a set of + privileges that are either granted or denied to that principal. + When a principal submits an operation (such as an HTTP or + WebDAV method) to a resource for execution, the server + evaluates the ACEs in the ACL to determine if the principal has + permission for that operation. This specification intentionally omits discussion of authentication, as the HTTP protocol already has a number of - authentication mechanisms [RFC2617]. Some authentication mechanism - (such as HTTP Digest Authentication, which all WebDAV compliant - implementations are required to support) must be available to - validate the identity of a principal. + authentication mechanisms [RFC2617]. Some authentication + mechanism (such as HTTP Digest Authentication, which all WebDAV + compliant implementations are required to support) must be + available to validate the identity of a principal. - In the interests of timeliness, the following set of security - mechanisms are not addressed by this document: + The following issues are out of scope for this document: - * Access control that applies only to a particular property on a - resource (excepting the access control properties DAV:acl and - DAV:current-user-privilege-set), rather than the entire - resource, + * Access control that applies only to a particular property + on a resource (excepting the access control properties + DAV:acl and DAV:current-user-privilege-set), rather than + the entire resource, - * Role-based security (where a role can be seen as a dynamically - defined collection of principals), + * Role-based security (where a role can be seen as a + dynamically defined collection of principals), - * Specification of the ways an ACL on a resource is initialized, + * Specification of the ways an ACL on a resource is + initialized, - * Specification of an ACL that applies globally to a method, - rather than to a particular resource. + * Specification of an ACL that applies globally to all + resources , rather than to a particular resource. - This specification is organized as follows. Section 1.1 defines key - concepts used throughout the specification, and is followed by more - in-depth discussion of principals (Section 2), and privileges - (Section 3). Properties defined on principals are specified in - Section 4, and access control properties for content resources are - specified in Section 5. The semantics of access control lists are - described in Section 6, including sections on ACE combination - (Section 6.1), ACE ordering (Section 6.2), and principals required - to be present in an ACE (Section 6.3). Client discovery of access - control capability using OPTIONS is described in Section 7.1, and - the access control setting method, ACL, is specified in Section 8. + * Creation and maintenance of resources representing people + or computational agents (principals), and groups of these. + + This specification is organized as follows. Section 1.1 defines + key concepts used throughout the specification, and is followed + by more in-depth discussion of principals (Section 2), and + privileges (Section 3). Properties defined on principals are + specified in Section 4, and access control properties for + content resources are specified in Section 5. The semantics of + access control lists are described in Section 6, including + sections on ACE combination (Section 6.1), ACE ordering Clemm, Hopkins, Sedlar, Whitehead [Page 4] - Internationalization considerations (Section 9) and security - considerations (Section 10) round out the specification. An - appendix (Section 17.1) provides an XML Document Type Definition - (DTD) for the XML elements defined in the specification. + (Section 6.2), and principals required to be present in an ACE + (Section 6.4). Client discovery of access control capability + using OPTIONS is described in Section 7.1, and the access + control setting method, ACL, is specified in Section 8. + Internationalization considerations (Section 11) and security + considerations (Section 12) round out the specification. An + appendix (Section 19.1) provides an XML Document Type + Definition (DTD) for the XML elements defined in the + specification. 1.1 Terms This draft uses the terms defined in HTTP [RFC2616] and WebDAV [RFC2518]. In addition, the following terms are defined: principal A "principal" is a distinct human or computational actor that initiates access to network resources. In this protocol, a principal is an HTTP resource that represents such an actor. principal collection A "principal collection" is a group of principals, and is - represented in this protocol by a WebDAV collection containing HTTP - resources that represent principals, and principal collections. + represented in this protocol by a WebDAV collection containing + HTTP resources that represent principals, and principal + collections. privilege A "privilege" controls access to a particular set of HTTP operations on a resource. aggregate privilege An "aggregate privilege" is a privilege that contains a set of other privileges. abstract privilege - The modifier "abstract", when applied to an atomic or aggregate - privilege, means the privilege cannot be set in an access control - element (ace). + The modifier "abstract", when applied to a privilege, means the + privilege cannot be set in an access control element (ace). - access control list (acl) + access control list (ACL) - An "acl" is a list of access control elements that define access - control to a particular resource. + An "ACL" is a list of access control elements that define + access control to a particular resource. access control element (ace) - An "ace" either grants or denies a particular set of (non-abstract) - privileges for a particular principal. + An "ace" either grants or denies a particular set of (non- + abstract) privileges for a particular principal. + Clemm, Hopkins, Sedlar, Whitehead [Page 5] inherited ace - An "inherited ace" is an ace that is shared from the acl of another - resource. + An "inherited ace" is an ace that is dynamically shared from + the ACL of another resource. When a shared ACE changes on the + primary resource, it is also changed on inheriting resources. -Clemm, Hopkins, Sedlar, Whitehead [Page 5] + protected property + + A "protected property" is one whose value cannot be updated + except by a method explicitly defined as updating that specific + property. In particular, a protected property cannot be + updated with a PROPPATCH request. 1.2 Notational Conventions The augmented BNF used by this document to describe protocol elements is described in Section 2.1 of [RFC2616]. Because this - augmented BNF uses the basic production rules provided in Section - 2.2 of [RFC2616], those rules apply to this document as well. + augmented BNF uses the basic production rules provided in + Section 2.2 of [RFC2616], those rules apply to this document as + well. - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in - this document are to be interpreted as described in [RFC2119]. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described + in [RFC2119]. + + Definitions of XML elements in this document use XML element + type declarations (as found in XML Document Type Declarations), + described in Section 3.2 of [REC-XML]. 2 PRINCIPALS - A principal is a network resource that represents a distinct human - or computational actor that initiates access to network resources. - On many implementations, users and groups are represented as - principals; other types of principals are also possible. A URL of - any scheme MAY be used to identify a principal resource. However, - servers implementing this specification SHOULD expose principal - resources at an http(s) URL, which is a privileged scheme that - points to resources that have additional properties, as described - in Section 4. Although an implementation SHOULD support PROPFIND - and PROPPATCH to access and modify information about a principal, + A principal is a network resource that represents a distinct + human or computational actor that initiates access to network + resources. On many implementations, users and groups are + represented as principals; other types of principals are also + possible. A URI of any scheme MAY be used to identify a + principal resource. However, servers implementing this + specification MUST expose principal resources at an http(s) + URL, which is a privileged scheme that points to resources that + have additional properties, as described in Section 4. So, a + principal resource can have multiple URI identifiers, one of + which has to be an http(s) scheme URL. Although an + implementation SHOULD support PROPFIND and MAY support + PROPPATCH to access and modify information about a principal, it is not required to do so. - A principal resource may or may not be a collection. A collection - principal may only contain other principals (not other types of - resources). Servers that support aggregation of principals (e.g. - groups of users or other groups) MUST manifest them as collection - principals. The WebDAV methods for examining and maintaining - collections (e.g. DELETE, PROPFIND) MAY be used to maintain - collection principals. Membership in a collection principal is - recursive, so a principal in a collection principal GRPA contained - by collection principal GRPB is a member of both GRPA and GRPB. - Implementations not supporting recursive membership in principal - collections can return an error if the client attempts to bind - collection principals into other collection principals. + A principal resource may or may not be a collection. If a + person or computational agent matches a principal resource that + is contained by a collection principal, they also match the + collection principal. This definition is recursive, and hence + if a person or computational agent matches a collection + principal that is the child of another collection principal, + they also match the parent collection principal. Membership in + a collection principal is also recursive, so a principal in a + collection principal GRPA contained by collection principal + + Clemm, Hopkins, Sedlar, Whitehead [Page 6] + GRPB is a member of both GRPA and GRPB. Implementations not + supporting recursive membership in principal collections can + return an error if the client attempts to bind collection + principals into other collection principals. + + Servers that support aggregation of principals (e.g. groups of + users or other groups) MUST manifest them as collection + principals. At minimum, principals and collection principals + MUST support the OPTIONS and PROPFIND methods. + + Implementer's Note: Collection principals are first and + foremost WebDAV collections. Therefore they contain + resources as members. Since there is no requirement that all + members of a collection principal need be principals, it is + possible for a collection principal to have non-principals + as members. When enumerating the principals-only membership + of a collection principal, it is necessary to retrieve the + DAV:resourcetype property and check it for the DAV:principal + XML element (described in Section 4). If the DAV:principal + XML element is not present, the resource is not a principal + and may be ignored for the purposes of determining the + principals-only membership of the collection principal. + + For example, the collection principal /FOO/ has two members, + Bar and Baz. Bar is a principal but Baz is not. Therefore + when determining which principals belong to the collection + principal /FOO/, a client would enumerate the membership + using PROPFIND while asking for the DAV:resourcetype + property, and see that only Bar has the DAV:principal XML + element. Therefore, only Bar is the only principal that is a + member of the collection principal /FOO/. 3 PRIVILEGES Ability to perform a given method on a resource SHOULD be controlled by one or more privileges. Authors of protocol extensions that define new HTTP methods SHOULD specify which - privileges (by defining new privileges, or mapping to ones below) - are required to perform the method. A principal with no privileges - to a resource SHOULD be denied any HTTP access to that resource. + privileges (by defining new privileges, or mapping to ones + below) are required to perform the method. A principal with no + privileges to a resource SHOULD be denied any HTTP access to + that resource. Privileges may be containers of other privileges, in which case - they are termed aggregate privileges. If a principal is granted or - denied an aggregate privilege, it is semantically equivalent to - granting or denying each of the aggregated privileges individually. - For example, an implementation may define add-member and remove- - member privileges that control the ability to add and remove an - internal member of a collection. Since these privileges control - -Clemm, Hopkins, Sedlar, Whitehead [Page 6] - the ability to update the state of a collection, these privileges - would be aggregated by the DAV:write privilege on a collection, and - granting the DAV:write privilege on a collection would also grant - the add-member and remove-member privileges. + they are termed aggregate privileges. If a principal is + granted or denied an aggregate privilege, it is semantically + equivalent to granting or denying each of the aggregated + privileges individually. For example, an implementation may + define add-member and remove-member privileges that control the + ability to add and remove an internal member of a collection. + Since these privileges control the ability to update the state + of a collection, these privileges would be aggregated by the + DAV:write privilege on a collection, and granting the DAV:write + privilege on a collection would also grant the add-member and + remove-member privileges. - Privileges may have the quality of being abstract, in which case - they cannot be set in an ACE. Aggregate and atomic privileges are - both capable of being abstract. Abstract privileges are useful for - modeling privileges that otherwise would not be exposed via the - protocol. Abstract privileges also provide server implementations - with flexibility in implementing the privileges defined in this - specification. For example, if a server is incapable of separating - the read resource capability from the read ACL capability, it can - still model the DAV:read and DAV:read-acl privileges defined in - this specification by declaring them abstract, and containing them + Clemm, Hopkins, Sedlar, Whitehead [Page 7] + Privileges may have the quality of being abstract, in which + case they cannot be set in an ACE. Aggregate and non-aggregate + privileges are both capable of being abstract. Abstract + privileges are useful for modeling privileges that otherwise + would not be exposed via the protocol. Abstract privileges also + provide server implementations with flexibility in implementing + the privileges defined in this specification. For example, if + a server is incapable of separating the read resource + capability from the read ACL capability, it can still model the + DAV:read and DAV:read-acl privileges defined in this + specification by declaring them abstract, and containing them within a non-abstract aggregate privilege (say, read-all) that - holds DAV:read, and DAV:read-acl. In this way, it is possible to - set the aggregate privilege, read-all, thus coupling the setting of - DAV:read and DAV:read-acl, but it is not possible to set DAV:read, - or DAV:read-acl individually. Since aggregate privileges can be - abstract, it is also possible to use abstract privileges to group - and classify non-abstract privileges. + holds DAV:read, and DAV:read-acl. In this way, it is possible + to set the aggregate privilege, read-all, thus coupling the + setting of DAV:read and DAV:read-acl, but it is not possible to + set DAV:read, or DAV:read-acl individually. Since aggregate + privileges can be abstract, it is also possible to use abstract + privileges to group or organize non-abstract privileges. + Privilege containment loops are not allowed, hence a privilege + MUST NOT contain itself. For example, DAV:read cannot contain + DAV:read. - The set of privileges that apply to a particular resource may vary - with the DAV:resourcetype of the resource, as well as between - different server implementations. To promote interoperability, - however, WebDAV defines a set of well-known privileges (e.g. - DAV:read and DAV:write), which can at least be used to classify the - other privileges defined on a particular resource. The access - permissions on null and lock-null resources are solely those they - inherit (if any), and they are not discoverable (i.e., the ACL - properties specified in Section 5 are not defined on null and lock- - null resources). On the transition from null or lock-null to a - stateful resource, the initial access control list is set by the - server's default ACL value policy (if any). + The set of privileges that apply to a particular resource may + vary with the DAV:resourcetype of the resource, as well as + between different server implementations. To promote + interoperability, however, this specification defines a set of + well-known privileges (e.g. DAV:read,DAV:write, DAV:read-acl, + DAV:write-acl, DAV:read-current-user-privilege-set, and + DAV:all), which can at least be used to classify the other + privileges defined on a particular resource. The access + permissions on null and lock-null resources (defined in + [RFC2518], Sections 3 and 7.4) are solely those they inherit + (if any), and they are not discoverable (i.e., the access + control properties specified in Section 5 are not defined on + null and lock-null resources). On the transition from null or + lock-null to a stateful resource, the initial access control + list is set by the server's default ACL value policy (if any). 3.1 DAV:read Privilege - The read privilege controls methods that return information about - the state of the resource, including the resource's properties. - Affected methods include GET and PROPFIND. Additionally, the read - privilege MAY control the OPTIONS method. + The read privilege controls methods that return information + about the state of the resource, including the resource's + properties. Affected methods include GET and PROPFIND. + Additionally, the read privilege MAY control the OPTIONS + method. 3.2 DAV:write Privilege - The write privilege controls methods that modify the state of the - resource, such as PUT and PROPPATCH. Note that state modification - is also controlled via locking (see section 5.3 of [WEBDAV]), so - effective write access requires that both write privileges and - write locking requirements are satisfied. + The write privilege controls methods that modify the content, + dead properties, or (in the case of a collection) membership of + the resource, such as PUT and PROPPATCH. Note that state + modification is also controlled via locking (see section 5.3 of - + Clemm, Hopkins, Sedlar, Whitehead [Page 8] + [WEBDAV]), so effective write access requires that both write + privileges and write locking requirements are satisfied. -Clemm, Hopkins, Sedlar, Whitehead [Page 7] + 3.3 DAV:read-acl Privilege - The DAV:read-acl privilege controls the use of PROPFIND to retrieve - the DAV:acl property of the resource. + The DAV:read-acl privilege controls the use of PROPFIND to + retrieve the DAV:acl property of the resource. -3.4 DAV:read-cuprivset Privilege + 3.4 DAV:read-current-user-privilege-set Privilege - The DAV:read-cuprivset privilege controls the use of PROPFIND to - retrieve the DAV:current-user-privilege-set property of the - resource. + The DAV:read-current-user-privilege-set privilege controls the + use of PROPFIND to retrieve the DAV:current-user-privilege-set + property of the resource. - Clients are intended to use this property to visually indicate in - their UI items that are dependent on the permissions of a resource, - for example, by graying out resources that are not writeable. + Clients are intended to use this property to visually indicate + in their UI items that are dependent on the permissions of a + resource, for example, by graying out resources that are not + writeable. This privilege is separate from DAV:read-acl because there is a need to allow most users access to the privileges permitted the - current user (due to its use in creating the UI), while the full - ACL contains information that may not be appropriate for the - current authenticated user. As a result, the set of users who can - view the full ACL is expected to be much smaller than those who can - read the current user privilege set, and hence distinct privileges - are needed for each + current user (due to its use in creating the UI), while the + full ACL contains information that may not be appropriate for + the current authenticated user. As a result, the set of users + who can view the full ACL is expected to be much smaller than + those who can read the current user privilege set, and hence + distinct privileges are needed for each. - + 3.5 DAV:write-acl Privilege The DAV:write-acl privilege controls use of the ACL method to modify the DAV:acl property of the resource. 3.6 DAV:all Privilege - DAV:all is an aggregate privilege that contains all privileges on - the resource. + DAV:all is an aggregate privilege that contains the entire set + of privileges that apply to the resource. + 3.7 Aggregation of Predefined Privileges + + Server implementations are free to aggregate the predefined + privileges (defined above in Sections 3.1-3.6) subject to the + following limitations: + + Clemm, Hopkins, Sedlar, Whitehead [Page 9] + DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write- + acl, or DAV:read-current-user-privilege-set. + + DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read- + acl, or DAV:read-current-user-privilege-set. + + DAV:read-current-user-privilege-set MUST NOT contain DAV:write, + DAV:read, DAV:read-acl, or DAV:write-acl. + + DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read- + current-user-privilege-set. + + DAV:read MUST NOT contain DAV:write, or DAV:write-acl. + 4 PRINCIPAL PROPERTIES Principals are manifested to clients as an HTTP resource, identified by a URL. A principal MUST have a DAV:displayname - property. This protocol defines the following additional - properties for a principal. The name and value of these properties - SHOULD NOT be returned by PROPFIND allprop request (as defined in - Section 12.14.1 of [RFC2518]). In the descriptions below, a read- - only property is defined as a property that MUST NOT be writeable - using PROPPATCH. - -Clemm, Hopkins, Sedlar, Whitehead [Page 8] - -4.1 DAV:is-principal + property (defined in Section 13.2 of [RFC2518]), and a + DAV:resourcetype property (defined in Section 13.9 of + [RFC2518]). Additionally, a principal MUST report the + DAV:principal empty XML element in the value of the + DAV:resourcetype property in addition to all other reported + elements. For example, a collection principal would report + DAV:collection and DAV:principal elements. The element type + declaration for DAV:principal is: - This is a read-only property that indicates whether this resource - is a principal. A resource MUST have a non-empty DAV:is-principal - property if and only if it is a principal resource. + - - PCDATA value: "true" - resource is a principal, "false" - resource - is not a principal (note that in cases where the "F" value might be - used, this specification requires the property not be present at - all). + This protocol defines the following additional property for a + principal. Since it is expensive, for many servers, to retrieve + access control information, the name and value of this property + SHOULD NOT be returned by a PROPFIND allprop request (as + defined in Section 12.14.1 of [RFC2518]). -4.2 DAV:alternate-URL + 4.1 DAV:alternate-URL - This read-only property, if present, contains the URL of a network - resource with additional descriptive information about the - principal. This property identifies one or more additional network - resources (i.e., it contains one or more URLs) that may be - consulted by a client to gain additional knowledge concerning a - principal. Two potential uses for this property are to store an - ldap [RFC2255] or mailto [RFC2368] scheme URL. Support for this - property is OPTIONAL. + This protected property, if non-empty, contains the URIs of + network resources with additional descriptive information about + the principal. This property identifies one or more additional + network resources (i.e., it contains one or more URIs) that may + be consulted by a client to gain additional knowledge + concerning a principal. Two potential uses for this property + are to store an ldap [RFC2255] or mailto [RFC2368] scheme URL. + Support for this property is REQUIRED, and the value is empty + if no alternate URL exists for the principal. . 5 ACCESS CONTROL PROPERTIES - This specification defines a number of new properties for WebDAV - resources. Access control properties may be retrieved just like - other WebDAV properties, using the PROPFIND method. Some access - control properties (such as DAV:owner) MAY be updated with the - PROPPATCH method. In the descriptions below, a read-only property - is defined as a property that MUST NOT be writeable using - PROPPATCH. Since it is expensive, for many servers, to retrieve - access control information, a PROPFIND allprop request (as defined - in Section 12.14.1 of [RFC2518]) SHOULD NOT return the names and + This specification defines a number of new properties for + WebDAV resources. Access control properties may be retrieved + just like other WebDAV properties, using the PROPFIND method. + Since it is expensive, for many servers, to retrieve access + + Clemm, Hopkins, Sedlar, Whitehead [Page 10] + control information, a PROPFIND allprop request (as defined in + Section 12.14.1 of [RFC2518]) SHOULD NOT return the names and values of the properties defined in this section. - HTTP resources that support the WebDAV Access Control Protocol MUST - contain the following properties. Null, and lock-null resources - (described in Section 7.4 of [RFC2518]) MUST NOT contain the - following properties: + HTTP resources that support the WebDAV Access Control Protocol + MUST contain the following properties. Null, and lock-null + resources (described in Section 7.4 of [RFC2518]) MUST NOT + contain the following properties: 5.1 DAV:owner - This property identifies a particular principal as being the - "owner" of the resource. Since the owner of a resource often has - special access control capabilities (e.g., the owner frequently has - permanent write-ACL privilege), clients might display the resource - owner in their user interface. + This protected property identifies a particular principal as + being the "owner" of the resource. Since the owner of a + resource often has special access control capabilities (e.g., + the owner frequently has permanent DAV:write-acl privilege), + clients might display the resource owner in their user + interface. - - + -Clemm, Hopkins, Sedlar, Whitehead [Page 9] - An implementation MAY include a list of selected properties of that - principal resource. Which properties (if any) are included is - implementation defined, but might reasonably include properties - such as DAV:displayname, which is useful for the construction of - access control user interfaces on the client. A server might - support this capability if it wished to save the client the - additional network round-trip delay required to retrieve this - information using a PROPFIND request on the principal URL in the - href element. Servers that do not directly support PROPFIND on - principal resources might also support this feature, since it - allows them to return a server-controlled subset of the properties - on the principal resource. + 5.1.1 Example: Retrieving DAV:owner - An implementation MAY allow the use of PROPPATCH to update the - DAV:owner field. If the DAV:owner property is writeable, clients - MUST NOT submit the prop element; only the href element can be - modified by the client. The purpose of this restriction is to limit - the scope of effect of a PROPPATCH to just the owner property's - resource; setting the prop element would additionally require - modification to properties of the principal resource identified by - the href element. + This example shows a client request for the value of the + DAV:owner property from a collection resource with URL + http://www.webdav.org/papers/. The principal making the request + is authenticated using Digest authentication. The value of + DAV:owner is the URL http://www.webdav.org/_acl/users/gstein, + wrapped in the DAV:href XML element. + + >> Request << + + PROPFIND /papers/ HTTP/1.1 + Host: www.webdav.org + Content-type: text/xml; charset="utf-8" + Content-Length: xxx + Depth: 0 + Authorization: Digest username="jim", + realm="jim@webdav.org", nonce="...", + uri="/papers/", response="...", opaque="..." + + + + + + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml; charset="utf-8" + Content-Length: xxx + + + + + Clemm, Hopkins, Sedlar, Whitehead [Page 11] + + http://www.webdav.org/papers/ + + HTTP/1.1 200 OK + + + + http://www.webdav.org/_acl/users/gstein + + + + + + + + 5.1.2 Example: An Attempt to Set DAV:owner + + The following example shows a client request to modify the + value of the DAV:owner property on the resource with URL + http://www.webdav.org/papers/. Since DAV:owner is a protected + property, the server responds with a 207 (Multi-Status) + response that contains a 403 (Forbidden) status code for the + act of setting DAV:owner. [RFC2518], Section 8.2.1 describes + PROPPATCH status code information, and Section 11 describes the + Multi-Status response. + + >> Request << + + PROPPATCH /papers/ HTTP/1.1 + Host: www.webdav.org + Content-type: text/xml; charset="utf-8" + Content-Length: xxx + Depth: 0 + Authorization: Digest username="jim", + realm="jim@webdav.org", nonce="...", + uri="/papers/", response="...", opaque="..." + + + + + + + + http://www.webdav.org/_acl/users/jim + + + + + + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml; charset="utf-8" + Content-Length: xxx + + Clemm, Hopkins, Sedlar, Whitehead [Page 12] + + + + http://www.webdav.org/papers/ + + HTTP/1.1 403 Forbidden + + + Failure to set protected property + (DAV:owner) + + + 5.2 DAV:supported-privilege-set - This is a read-only property that identifies the privileges defined - for the resource. + This is a protected property that identifies the privileges + defined for the resource. Each privilege appears as an XML element, where aggregate privileges list as sub-elements all of the privileges that they aggregate. - An abstract privilege of a resource MUST NOT be used in an ACE for - that resource. Servers MUST fail an attempt to set an abstract - privilege. + An abstract privilege of a resource MUST NOT be used in an ACE + for that resource. Servers MUST fail an attempt to set an + abstract privilege. A description is a human-readable description of what this privilege controls access to. It is envisioned that a WebDAV ACL-aware administrative client - would list the supported privileges in a dialog box, and allow the - user to choose non-abstract privileges to apply in an ACE. The - privileges tree is useful programmatically to map well-known - privileges (defined by WebDAV or other standards groups) into + would list the supported privileges in a dialog box, and allow + the user to choose non-abstract privileges to apply in an ACE. + The privileges tree is useful programmatically to map well- + known privileges (defined by WebDAV or other standards groups) + into privileges that are supported by any particular server + implementation. The privilege tree also serves to hide + complexity in implementations allowing large number of + privileges to be defined by displaying aggregates to the user. -Clemm, Hopkins, Sedlar, Whitehead [Page 10] - privileges that are supported by any particular server - implementation. The privilege tree also serves to hide complexity - in implementations allowing large number of privileges to be - defined by displaying aggregates to the user. + Clemm, Hopkins, Sedlar, Whitehead [Page 13] + 5.2.1 Example: Retrieving a List of Privileges Supported on a + Resource + + This example shows a client request for the DAV:supported- + privilege-set property on the resource + http://www.webdav.org/papers/. The value of the DAV:supported- + privilege-set property is a tree of supported privileges: + + DAV:all (aggregate, abstract) + | + +-- DAV:read (aggregate) + | + +-- DAV:read-acl (abstract) + +-- DAV:read-current-user-privilege-set (abstract) + +-- DAV:write (aggregate) + | + +-- DAV:write-acl (abstract) + + This privilege tree is not normative, and many possible + privilege trees are possible. + + >> Request << + + PROPFIND /papers/ HTTP/1.1 + Host: www.webdav.org + Content-type: text/xml; charset="utf-8" + Content-Length: xxx + Depth: 0 + Authorization: Digest username="gclemm", + realm="gclemm@webdav.org", nonce="...", + uri="/papers/", response="...", opaque="..." + + + + + + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml; charset="utf-8" + Content-Length: xxx + + + + + http://www.webdav.org/papers/ + + HTTP/1.1 200 OK + + + + Clemm, Hopkins, Sedlar, Whitehead [Page 14] + + + + Any operation + + + Read any object + + + + Read ACL + + + + + + + + Read current user privilege set + property + + + + Write any object + + + Write ACL + + + + + + + + + 5.3 DAV:current-user-privilege-set - DAV:current-user-privilege-set is a read-only property containing - the exact set of privileges (as computed by the server) granted to - the currently authenticated HTTP user. Aggregate privileges and - their contained privileges are listed. A user-agent can use the - value of this property to adjust its user interface to make actions - inaccessible (e.g., by graying out a menu item or button) for which - the current principal does not have permission. This is - particularly useful for an access control user interface, which can - be constructed without knowing the ACE combining semantics of the - server. This property is also useful for determining what - operations the current principal can perform, without having to - actually execute an operation. + DAV:current-user-privilege-set is a protected property + containing the exact set of privileges (as computed by the + server) granted to the currently authenticated HTTP user. + Aggregate privileges and their contained privileges are listed. + A user-agent can use the value of this property to adjust its + user interface to make actions inaccessible (e.g., by graying + out a menu item or button) for which the current principal does + not have permission. This is particularly useful for an access + control user interface, which can be constructed without + knowing the ACE combining semantics of the server. This + property is also useful for determining what operations the + current principal can perform, without having to actually + execute an operation. + + Clemm, Hopkins, Sedlar, Whitehead [Page 15] - If the current user is granted a specific privilege, that privilege - must belong to the set of privileges that may be set on this - resource. Therefore, each element in the DAV:current-user- - privilege-set property MUST identify a non-abstract privilege from - the DAV:supported-privilege-set property. + If the current user is granted a specific privilege, that + privilege must belong to the set of privileges that may be set + on this resource. Therefore, each element in the DAV:current- + user-privilege-set property MUST identify a non-abstract + privilege from the DAV:supported-privilege-set property. + + 5.3.1 Example: Retrieving the User's Current Set of Assigned + Privileges + + Continuing the example from Section 5.2.1, this example shows a + client requesting the DAV:current-user-privilege-set property + from the resource with URL http://www.webdav.org/papers/. The + username of the principal making the request is ôkhareö, and + Digest authentication is used in the request. The principal + with username ôkhareö has been granted the DAV:read privilege. + Since the DAV:read privilege contains the DAV:read-acl and + DAV:read-current-user-privilege-set privileges (see Section + 5.2.1), the principal with username ôkhareö can read the ACL + property, and the DAV:current-user-privilege-set property. + However, the DAV:all, DAV:read-acl, DAV:write-acl and DAV:read- + current-user-privilege-set privileges are not listed in the + value of DAV:current-user-privilege-set, since (for this + example) they are abstract privileges. DAV:write is not listed + since the principal with username ôkhareö is not listed in an + ACE granting that principal write permission. + + >> Request << + + PROPFIND /papers/ HTTP/1.1 + Host: www.webdav.org + Content-type: text/xml; charset="utf-8" + Content-Length: xxx + Depth: 0 + Authorization: Digest username="khare", + realm="khare@webdav.org", nonce="...", + uri="/papers/", response="...", opaque="..." + + + + + + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml; charset="utf-8" + Content-Length: xxx + + + + + + Clemm, Hopkins, Sedlar, Whitehead [Page 16] + http://www.webdav.org/papers/ + + HTTP/1.1 200 OK + + + + + + + + 5.4 DAV:acl - This is a read-only property that specifies the list of access + This is a protected property that specifies the list of access control entries (ACEs), which define what principals are to get what privileges for this resource. - Each DAV:ace element specifies the set of privileges to be either - granted or denied to a single principal. If the DAV:acl property - is empty, no principal is granted any privilege. + Each DAV:ace element specifies the set of privileges to be + either granted or denied to a single principal. If the DAV:acl + property is empty, no principal is granted any privilege. - + 5.4.1 ACE Principal - The DAV:principal element identifies the principal to which this - ACE applies. + The DAV:principal element identifies the principal to which + this ACE applies. - -Clemm, Hopkins, Sedlar, Whitehead [Page 11] The current user matches DAV:href only if that user is authenticated as being (or being a member of) the principal - identified by the URL contained by that DAV:href. An implementation - MAY include a DAV:prop element after the DAV:href element, - containing a list of selected properties of that principal - resource. Which properties (if any) are included in the DAV:prop - element is implementation defined. The DAV:prop element can be used - by servers that do not support PROPFIND requests on principal - resources to return principal-related information (such as the - value of the DAV:displayname property) that a client would find - useful in the creation of an access control user interface. A - server might also support this capability if it wished to save the - client the additional network round-trip delays required to - retrieve this information via a series of PROPFIND requests on each - principal URL in the ACL. In the worst case, this is one additional - PROPFIND per ACE. - - + identified by the URL contained by that DAV:href. The current user always matches DAV:all. - The current user matches DAV:authenticated only if authenticated. + The current user matches DAV:authenticated only if + authenticated. The current user matches DAV:unauthenticated only if not authenticated. + Clemm, Hopkins, Sedlar, Whitehead [Page 17] - DAV:all is the union of DAV:authenticated, and DAV:unauthenticated. - For a given request, the user matches either DAV:authenticated, or - DAV:unauthenticated, but not both. + DAV:all is the union of DAV:authenticated, and + DAV:unauthenticated. For a given request, the user matches + either DAV:authenticated, or DAV:unauthenticated, but not both + (that is, DAV:authenticated and DAV:unauthenticated are + disjoint sets). The current user matches a DAV:property principal in a DAV:acl - property of a resource only if the identified property of that - resource contains a DAV:href that identifies a principal, and the - current user is authenticated as being (or being a member of) that - principal. For example, if the DAV:property element contained - , the current user would match the DAV:property - principal only if the current user is authenticated as matching the - principal identified by the DAV:owner property of the resource. + property of a resource only if the value of the identified + property of that resource contains at most one DAV:href XML + element, the URI value of DAV:href identifies a principal, and + the current user is authenticated as being (or being a member + of) that principal. For example, if the DAV:property element + contained , the current user would match the + DAV:property principal only if the current user is + authenticated as matching the principal identified by the + DAV:owner property of the resource. The current user matches DAV:self in a DAV:acl property of the resource only if that resource is a principal object and the - current user is authenticated as being that principal. + current user is authenticated as being that principal or a + member of that principal collection. -Clemm, Hopkins, Sedlar, Whitehead [Page 12] - 5.4.2 ACE Grant and Deny - Each DAV:grant or DAV:deny element specifies the set of privileges - to be either granted or denied to the specified principal. A - DAV:grant or DAV:deny element of the DAV:acl of a resource MUST - only contain non-abstract elements specified in the DAV:supported- - privilege-set of that resource. + Each DAV:grant or DAV:deny element specifies the set of + privileges to be either granted or denied to the specified + principal. A DAV:grant or DAV:deny element of the DAV:acl of a + resource MUST only contain non-abstract elements specified in + the DAV:supported-privilege-set of that resource. 5.4.3 ACE Protection - If an ACE contains a DAV:protected element, an ACL request without - that ACE MUST fail. + If an ACE contains a DAV:protected element, an ACL request + without that ACE MUST fail. 5.4.4 ACE Inheritance - The presence of a DAV:inherited element indicates that this ACE is - inherited from another resource that is identified by the URL - contained in a DAV:href element. An inherited ACE cannot be - modified directly, but instead the ACL on the resource from which - it is inherited must be modified. + The presence of a DAV:inherited element indicates that this ACE + is inherited from another resource that is identified by the + URL contained in a DAV:href element. An inherited ACE cannot + be modified directly, but instead the ACL on the resource from + which it is inherited must be modified. - Note that ACE inheritance is not the same as ACL initialization. - ACL initialization defines the ACL that a newly created resource - will use (if not specified). ACE inheritance refers to an ACE that - is logically shared - where an update to the resource containing an - ACE will affect the ACE of each resource that inherits that ACE. - The method by which ACLs are initialized or by which ACEs are - inherited is not defined by this document. + Clemm, Hopkins, Sedlar, Whitehead [Page 18] + Note that ACE inheritance is not the same as ACL + initialization. ACL initialization defines the ACL that a + newly created resource will use (if not specified). ACE + inheritance refers to an ACE that is logically shared - where + an update to the resource containing an ACE will affect the ACE + of each resource that inherits that ACE. The method by which + ACLs are initialized or by which ACEs are inherited is not + defined by this document. + 5.4.5 Example: Retrieving a Resource's Access Control List + + Continuing the example from Sections 5.2.1 and 5.3.1, this + example shows a client requesting the DAV:acl property from the + resource with URL http://www.webdav.org/papers/. There are two + ACEs defined in this ACL: + + ACE #1: The principal collection identified by URL + http://www.webdav.org/_acl/groups/maintainers/ (the group of + site maintainers) is granted DAV:write privilege. Since (for + this example) DAV:write contains the DAV:write-acl privilege + (see Section 5.2.1), this means the ômaintainersö group can + also modify the access control list. + + ACE #2: All principals (DAV:all) are granted the DAV:read + privilege. Since (for this example) DAV:read contains DAV:read- + acl and DAV:read-current-user-privilege-set, this means all + users (including all members of the ômaintainersö group) can + read the DAV:acl property and the DAV:current-user-privilege- + set property. + + >> Request << + + PROPFIND /papers/ HTTP/1.1 + Host: www.webdav.org + Content-type: text/xml; charset="utf-8" + Content-Length: xxx + Depth: 0 + Authorization: Digest username="masinter", + realm="masinter@webdav.org", nonce="...", + uri="/papers/", response="...", opaque="..." + + + + + + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml; charset="utf-8" + + Clemm, Hopkins, Sedlar, Whitehead [Page 19] + Content-Length: xxx + + + + + http://www.webdav.org/papers/ + + HTTP/1.1 200 OK + + + + + + http://www.webdav.org/_acl/groups/maintainers/ + + + + + + + + + + + + + + + + + + + + 5.5 DAV:acl-semantics - This is a read-only property that defines the ACL semantics. These - semantics define how multiple ACEs that match the current user are - combined, what are the constraints on how ACEs can be ordered, and - which principals must have an ACE. A client user interface could - use the value of this property to provide feedback to a human - operator concerning the impact of proposed changes to an ACL. - Alternately, a client could use this property to determine exactly, - before submitting an ACL method invocation, what ACL changes it - needs to make to accomplish a specific goal (or whether that goal - is even achievable on this server). + This is a protected property that defines the ACL semantics. + These semantics define how multiple ACEs that match the current + user are combined, what are the constraints on how ACEs can be + ordered, and which principals must have an ACE. A client user + interface could use the value of this property to provide + feedback to a human operator concerning the impact of proposed + changes to an ACL. Alternately, a client can use this property + to help it determine, before submitting an ACL method + invocation, what ACL changes it needs to make to accomplish a + specific goal (or whether that goal is even achievable on this + server). - Since it is not practical to require all implementations to use the - same ACL semantics, the DAV:acl-semantics property is used to - identify the ACL semantics for a particular resource. The DAV:acl- - semantics element is defined in section 6. + Since it is not practical to require all implementations to use + the same ACL semantics, the DAV:acl-semantics property is used + to identify the ACL semantics for a particular resource. The + DAV:acl-semantics element is defined in Section 6. -Clemm, Hopkins, Sedlar, Whitehead [Page 13] + Clemm, Hopkins, Sedlar, Whitehead [Page 20] + 5.5.1 Example: Retrieving DAV:acl-semantics + + In this example, the client requests the value of the DAV:acl- + semantics property. Digest authentication provides credentials + for the principal operating the client. In this example, the + ACE combination semantics are DAV:first-match, described in + Section 6.1.1, the ACE ordering semantics are not specified + (some value other than DAV:deny-before-grant, described in + Section 6.2.1), the DAV:allowed-ace element states that only + one ACE is permitted for each principal, and an ACE describing + the privileges granted the DAV:all principal must exist in + every ACL. + + >> Request << + + PROPFIND /papers/ HTTP/1.1 + Host: www.webdav.org + Content-type: text/xml; charset="utf-8" + Content-Length: xxx + Depth: 0 + Authorization: Digest username="srcarter", + realm="srcarter@webdav.org", nonce="...", + uri="/papers/", response="...", opaque="..." + + + + + + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml; charset="utf-8" + Content-Length: xxx + + + + + http://www.webdav.org/papers/ + + HTTP/1.1 200 OK + + + + + + + + + + + + Clemm, Hopkins, Sedlar, Whitehead [Page 21] + + + + + + + 5.6 DAV:principal-collection-set - This read-only property contains zero, one, or more URLs that + This protected property contains zero, one, or more URLs that identify a collection principal. It is expected that - implementations of this protocol will typically employ a relatively - small number of locations in the URL namespace for principal, and - collection principals. In cases where this assumption holds, the - DAV:principal-collection-set property will contain a small set of - URLs identifying the top of collection hierarchy containing - multiple principals and collection principals. An access control - protocol user agent could use the contents of DAV:principal- - collection-set to query the DAV:displayname property (specified in - Section 13.2 of [RFC2518]) of all principals on that server, - thereby yielding human-readable names for each principal that could - be displayed in a user interface. + implementations of this protocol will typically use a + relatively small number of locations in the URL namespace for + principal, and collection principals. In cases where this + assumption holds, the DAV:principal-collection-set property + will contain a small set of URLs identifying the top of a + collection hierarchy containing multiple principals and + collection principals. An access control protocol user agent + could use the contents of DAV:principal-collection-set to query + the DAV:displayname property (specified in Section 13.2 of + [RFC2518]) of all principals on that server, thereby yielding + human-readable names for each principal that could be displayed + in a user interface. + Since different servers can control different parts of the URL - namespace, different resources on the same host MAY have different - DAV:principal-collection-set values. The collections specified in - the DAV:principal-collection-set MAY be located on different hosts - from the resource. The URLs in DAV:principal-collection-set SHOULD - be http or https scheme URLs. For security and scalability reasons, - a server MAY report only a subset of the entire set of known - collection principals, and therefore clients should not assume they - have retrieved an exhaustive listing. Additionally, a server MAY - elect to report none of the collection principals it knows about. + namespace, different resources on the same host MAY have + different DAV:principal-collection-set values. The collections + specified in the DAV:principal-collection-set MAY be located on + different hosts from the resource. The URLs in DAV:principal- + collection-set SHOULD be http or https scheme URLs. For + security and scalability reasons, a server MAY report only a + subset of the entire set of known collection principals, and + therefore clients should not assume they have retrieved an + exhaustive listing. Additionally, a server MAY elect to report + none of the collection principals it knows about, in which case + the property value would be empty. + + 5.6.1 Example: Retrieving DAV:principal-collection-set + + In this example, the client requests the value of the + DAV:principal-collection-set property on the collection + resource identified by URL http://www.webdav.org/papers/. The + property contains the two URLs, + http://www.webdav.org/_acl/users/ and + http://www.webdav.org/_acl/groups/, both wrapped in + XML elements. Digest authentication provides credentials for + the principal operating the client. + + The client might reasonably follow this request with two + separate PROPFIND requests to retrieve the DAV:displayname + + Clemm, Hopkins, Sedlar, Whitehead [Page 22] + property of the members of the two collections (/_acl/users/ + and /_acl_groups/). This information could be used when + displaying a user interface for creating access control + entries. + + >> Request << + + PROPFIND /papers/ HTTP/1.1 + Host: www.webdav.org + Content-type: text/xml; charset="utf-8" + Content-Length: xxx + Depth: 0 + Authorization: Digest username="yarong", + realm="yarong@webdav.org", nonce="...", + uri="/papers/", response="...", opaque="..." + + + + + + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml; charset="utf-8" + Content-Length: xxx + + + + + http://www.webdav.org/papers/ + + HTTP/1.1 200 OK + + + + http://www.webdav.org/_acl/users/ + + + http://www.webdav.org/_acl/groups/ + + + + + + 5.7 Example: PROPFIND to retrieve access control properties - The following example shows how access control information can be - retrieved by using the PROPFIND method to fetch the values of the - DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege- - set, and DAV:acl properties. + The following example shows how access control information can + be retrieved by using the PROPFIND method to fetch the values + of the DAV:owner, DAV:supported-privilege-set, DAV:current- + user-privilege-set, and DAV:acl properties. + Clemm, Hopkins, Sedlar, Whitehead [Page 23] >> Request << PROPFIND /top/container/ HTTP/1.1 Host: www.foo.org Content-type: text/xml; charset="utf-8" Content-Length: xxx Depth: 0 Authorization: Digest username="ejw", realm="users@foo.org", nonce="...", uri="/top/container/", response="...", opaque="..." -Clemm, Hopkins, Sedlar, Whitehead [Page 14] >> Response << HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx + xmlns:A="http://www.webdav.org/acl/"> + http://www.foo.org/top/container/ + HTTP/1.1 200 OK - http://www.foo.org/users/gclemm + http://www.foo.org/users/gclemm + Any operation Read any object Write any object Create an object + + Clemm, Hopkins, Sedlar, Whitehead [Page 24] Update an object Delete an object @@ -783,199 +1325,221 @@ Write the ACL - -Clemm, Hopkins, Sedlar, Whitehead [Page 15] http://www.foo.org/users/esedlar - - Eric Sedlar - + http://www.foo.org/groups/marketing/ - + + - http://www.foo.org/top/ + http://www.foo.org/top/ + + + Clemm, Hopkins, Sedlar, Whitehead [Page 25] The value of the DAV:owner property is a single DAV:href XML element containing the URL of the principal that owns this resource. - The value of the DAV:supported-privilege-set property is a tree of - supported privileges: + The value of the DAV:supported-privilege-set property is a tree + of supported privileges: DAV:all (aggregate, abstract) | +-- DAV:read +-- DAV:write (aggregate, abstract) | +-- http://www.webdav.org/acl/create +-- http://www.webdav.org/acl/update +-- http://www.webdav.org/acl/delete - -Clemm, Hopkins, Sedlar, Whitehead [Page 16] +-- DAV:read-acl +-- DAV:write-acl The DAV:current-user-privilege-set property contains two privileges, DAV:read, and DAV:read-acl. This indicates that the current authenticated user only has the ability to read the resource, and read the DAV:acl property on the resource. The DAV:acl property contains a set of four ACEs: ACE #1: The principal identified by the URL http://www.foo.org/users/esedlar is granted the DAV:read, DAV:write, and DAV:read-acl privileges. ACE #2: The principals identified by the URL http://www.foo.org/groups/marketing/ are denied the DAV:read - privilege. In this example, the principal URL identifies a group, - which is represented by a collection principal. + privilege. In this example, the principal URL identifies a + group, which is represented by a collection principal. ACE #3: In this ACE, the principal is a property principal, - specifically the DAV:owner property. When evaluating this ACE, the - value of the DAV:owner property is retrieved, and is examined to - see if it contains a DAV:href XML element. If so, the URL within - the DAV:href element is read, and identifies a principal. In this - ACE, the owner is granted DAV:read-acl, and DAV:write-acl - privileges. + specifically the DAV:owner property. When evaluating this ACE, + the value of the DAV:owner property is retrieved, and is + examined to see if it contains a DAV:href XML element. If so, + the URL within the DAV:href element is read, and identifies a + principal. In this ACE, the owner is granted DAV:read-acl, and + DAV:write-acl privileges. ACE #4: This ACE grants the DAV:all principal (all users) the DAV:read privilege. This ACE is inherited from the resource - http://www.foo.org/top/, the parent collection of this resource. + http://www.foo.org/top/, the parent collection of this + resource. + Clemm, Hopkins, Sedlar, Whitehead [Page 26] 6 ACL SEMANTICS - The ACL semantics define how multiple ACEs that match the current - user are combined, what are the constraints on how ACEs can be - ordered, and which principals must have an ACE. + The ACL semantics define how multiple ACEs that match the + current user are combined, what are the constraints on how ACEs + can be ordered, and which principals must have an ACE. - + 6.1 ACE Combination The DAV:ace-combination element defines how privileges from multiple ACEs that match the current user will be combined to - determine the access privileges for that user. Multiple ACEs may - match the same user because the same principal can appear in - multiple ACEs, because multiple principals can identify the same - user, and because one principal can be a member of another + determine the access privileges for that user. Multiple ACEs + may match the same user because the same principal can appear + in multiple ACEs, because multiple principals can identify the + same user, and because one principal can be a member of another principal. 6.1.1 DAV:first-match ACE Combination The ACEs are evaluated in the order in which they appear in the - ACL. If the first ACE that matches the current user does not grant - all the privileges needed for the request, the request MUST fail. + ACL. If the first ACE that matches the current user does not + grant all the privileges needed for the request, the request + MUST fail. 6.1.2 DAV:all-grant-before-any-deny ACE Combination The ACEs are evaluated in the order in which they appear in the ACL. If an evaluated ACE denies a privilege needed for the - request, the request MUST fail. If all ACEs have been evaluated - without the user being granted all privileges needed for the - request, the request MUST fail. + request, the request MUST fail. If all ACEs have been + evaluated without the user being granted all privileges needed + for the request, the request MUST fail. 6.1.3 DAV:specific-deny-overrides-grant ACE Combination All ACEs in the ACL are evaluated. An "individual ACE" is one - whose principal identifies the current user. A "group ACE" is one - whose principal is a collection that contains a principal that - identifies the current user. A privilege is granted if it is - granted by an individual ACE and not denied by an individual ACE, - or if it is granted by a group ACE and not denied by an individual - or group ACE. A request MUST fail if any of its needed privileges - are not granted. + whose principal identifies the current user. A "group ACE" is + one whose principal is a collection that contains a principal + that identifies the current user. A privilege is granted if it + is granted by an individual ACE and not denied by an individual + ACE, or if it is granted by a group ACE and not denied by an + individual or group ACE. A request MUST fail if any of its + needed privileges are not granted. + Clemm, Hopkins, Sedlar, Whitehead [Page 27] 6.2 ACE Ordering - The DAV:ace-ordering element defines a constraint on how the ACEs - can be ordered in the ACL. + The DAV:ace-ordering element defines a constraint on how the + ACEs can be ordered in the ACL. 6.2.1 DAV:deny-before-grant ACE Ordering - This element indicates that all deny ACEs must precede all grant - ACEs. + This element indicates that all deny ACEs must precede all + grant ACEs. -6.3 Required Principals + 6.3 Allowed ACE - The required principal elements identify which principals must have - an ACE defined in the ACL. + The DAV:allowed-ace XML element specifies constraints on what + kinds of ACEs are allowed in an ACL. + + + + 6.3.1 DAV:principal-only-one-ace ACE Constraint + + This element indicates that a principal can appear in only one + ACE per resource. + + + + 6.3.2 DAV:grant-only ACE Constraint + + This element indicates that ACEs with deny clauses are not + allowed. + + + + 6.4 Required Principals + + The required principal elements identify which principals must + have an ACE defined in the ACL. + (href | all | authenticated | unauthenticated | property | + self)> -Clemm, Hopkins, Sedlar, Whitehead [Page 18] - For example, the following element requires that the ACL contain a - DAV:owner property ACE: + For example, the following element requires that the ACL + contain a DAV:owner property ACE: + Clemm, Hopkins, Sedlar, Whitehead [Page 28] 7 ACCESS CONTROL AND EXISTING METHODS - This section defines the impact of access control functionality on - existing methods. + This section defines the impact of access control functionality + on existing methods. 7.1 OPTIONS If the server supports access control, it MUST return "access- control" as a field in the DAV response header from an OPTIONS request on any resource implemented by that server. 7.1.1 Example - OPTIONS >> Request << @@ -987,563 +1551,878 @@ >> Response << HTTP/1.1 200 OK DAV: 1, 2, access-control Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL In this example, the OPTIONS response indicates that the server supports access control and that /foo.html can have its access control list modified by the ACL method. + 7.2 MOVE + + When a resource is moved from one location to another due to a + MOVE request, the non-inherited ACEs in the DAV:acl property of + the resource MUST NOT be modified, or the MOVE request fails. + + 7.3 COPY + + The DAV:acl property on the resource at the destination of a + COPY MUST be the same as if the resource was created by an + individual resource creation request (e.g. MKCOL, PUT). + 8 ACCESS CONTROL METHODS 8.1 ACL - The ACL method modifies the DAV:acl property of a resource. A new - DAV:acl value must be written in its entirety, including any - inherited ACEs. Unless the DAV:acl property of the resource can be - updated to be exactly the value specified in the ACL request, the - ACL request MUST fail. If a server restricts the set of ACEs - visible to the current user via the DAV:acl property, then the ACL - request would only replace the set of ACEs visible to the current - user, and would not affect any ACE that was not visible. + The ACL method modifies the access control list (which can be + read via the DAV:acl property) of a resource. Specifically, + the ACL method only permits modification to ACEs that are not + inherited, and are not protected. An ACL method invocation + modifies all non-inherited and non-protected ACEs in a + resource's access control list to exactly match the ACEs + contained within in the DAV:acl XML element (specified in + Section 5.4) of the request body. An ACL request body MUST + contain only one DAV:acl XML element. Unless the non-inherited - In order to avoid overwriting DAV:acl changes by another client, a - client SHOULD acquire a WebDAV lock on the resource before - retrieving the DAV:acl property of a resource that it intends on - updating. + Clemm, Hopkins, Sedlar, Whitehead [Page 29] + and non-protected ACEs of the DAV:acl property of the resource + can be updated to be exactly the value specified in the ACL + request, the ACL request MUST fail. -Clemm, Hopkins, Sedlar, Whitehead [Page 19] - When submitting ACEs, clients MUST NOT include the optional prop - element (a child of the principal element). The purpose of this - restriction is to limit the scope of effect of the ACL method to - just the resource identified by the Request-URI; setting the prop - element would additionally require property modification for one or - more principal resources. + It is possible that the ACEs visible to the current user in the + DAV:acl property may only be a portion of the complete set of + ACEs on that resource. If this is the case, an ACL request only + modifies the set of ACEs visible to the current user, and does + not affect any non-visible ACE. + + In order to avoid overwriting DAV:acl changes by another + client, a client SHOULD acquire a WebDAV lock on the resource + before retrieving the DAV:acl property of a resource that it + intends on updating. + + Implementation Note: Two common operations are to add or + remove an ACE from an existing access control list. To + accomplish this, a client uses the PROPFIND method to + retrieve the value of the DAV:acl property, then parses the + returned access control list to remove all inherited and + protected ACEs (these ACEs are tagged with the DAV:inherited + and DAV:protected XML elements). In the remaining set of non- + inherited, non-protected ACEs, the client can add or remove + one or more ACEs before submitting the final ACE set in the + request body of the ACL method. 8.1.1 ACL Preconditions An implementation MAY enforce one or more of the following - constraints on an ACL request. If the constraint is violated, a - 403 (Forbidden) response MUST be returned and the indicated XML - element MUST be returned in the response body. + constraints on an ACL request. If the constraint is violated, + a 403 (Forbidden) response MUST be returned and the indicated + XML element MUST be returned as the top level element in an XML + response body. - : An implementation MAY protect an ACE from - modification or deletion. For example, some implementations - implicitly grant the DAV:owner of a resource DAV:read-acl and - DAV:write-acl privileges, and this cannot be changed by a client. + : A conflict exists between two or more ACEs + submitted in the ACL request. + + : A conflict exists between an ACE + in the ACL request and a protected ACE on the resource. For + example, if the resource has a protected ACE granting DAV:write + to a given principal, then it would be a protected ACE conflict + if the ACL request submitted an ACE denying DAV:write to the + same principal. + + : A conflict exists between an ACE + in the ACL request and an inherited ACE on the resource. For + example, if the resource inherits an ACE from its parent + collection granting DAV:write to a given principal, then it + would be an inherited ACE conflict if the ACL request submitted + an ACE denying DAV:write to the same principal. Note that + reporting of this error will be implementation-dependent. + + Clemm, Hopkins, Sedlar, Whitehead [Page 30] + Implementations have the choice to either report this error, or + to allow the ACE to be set, and then let normal ACE evaluation + rules determine whether the new ACE has any impact on the + privileges available to a specific principal. : An implementation MAY limit the number of ACEs in an ACL. However, ACL-compliant servers MUST support at - least one ACE granting privileges to a single principal, and one - ACE granting privileges to a collection principal. - - : All non-inherited ACEs - MUST precede all inherited ACEs. + least one ACE granting privileges to a single principal, and + one ACE granting privileges to a collection principal. - : All non-inherited deny ACEs MUST + : All non-inherited deny ACEs MUST precede all non-inherited grant ACEs. - If the following precondition is not met, the server MUST return a - 409 (Conflict) response, and the indicated XML element MUST be - returned in the response body: + : For implementations that have + the DAV:principal-only-one-ace constraint (defined in Section + 6.3.1), this XML element indicates that fulfilling the ACL + request would result in multiple ACEs for one or more + principals. - : Inherited ACEs MUST exist on a parent - resource. + : For implementations that have the DAV:grant- + only constraint (defined in Section 6.3.2), this XML element + indicates the request contained one or more deny ACEs. + + : One or more required principals (see + Section 6.4) would not be present in the access control list + after processing the ACL request. The DAV:required-principal + XML element MUST contain a list of the missing principal(s), + following the syntax specified in Section 6.4. 8.1.2 Example: the ACL method In the following example, user "fielding", authenticated by information in the Authorization header, grants the principal - identified by the URL http://www.foo.org/users/esedlar (i.e., the - user "esedlar") read and write privileges, grants the owner of the - resource read-acl and write-acl privileges, and grants everyone - read privileges inherited from the parent collection - http://www.foo.bar/top/. + identified by the URL http://www.foo.org/users/esedlar (i.e., + the user "esedlar") read and write privileges, grants the owner + of the resource read-acl and write-acl privileges, and grants + everyone read privileges. >> Request << ACL /top/container/ HTTP/1.1 Host: www.foo.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="fielding", realm="users@foo.org", nonce="...", - -Clemm, Hopkins, Sedlar, Whitehead [Page 20] uri="/top/container/", response="...", opaque="..." + + Clemm, Hopkins, Sedlar, Whitehead [Page 31] http://www.foo.org/users/esedlar - + + - + + - + + - - - http://www.foo.org/top/ + + >> Response << HTTP/1.1 200 OK -8.1.3 Example: ACL method failure due to omission of protected ACE + 8.1.3 Example: ACL method failure due to protected ACE conflict In the following request, user "fielding", authenticated by - information in the Authorization header, attempts to grant the - principal identified by the URL http://www.foo.org/users/esedlar - (i.e., the user "esedlar") read privileges. Prior to the request, - the DAV:acl property on the resource contained a protected ACE (see - Section 5.4.3) granting DAV:owner the DAV:read-acl and DAV:write- - acl privileges. The ACL method invocation fails because this - protected ACE is omitted, thus violating the semantics of ACE - protection.. + information in the Authorization header, attempts to deny the + principal identified by the URL + http://www.foo.org/users/esedlar (i.e., the user "esedlar") + write privileges. Prior to the request, the DAV:acl property on + the resource contained a protected ACE (see Section 5.4.3) + granting DAV:owner the DAV:read and DAV:write privileges. The + principal identified by URL http://www.foo.org/users/esedlar is + the owner of the resource. The ACL method invocation fails + because the submitted ACE conflicts with the protected ACE, + thus violating the semantics of ACE protection. >> Request << ACL /top/container/ HTTP/1.1 Host: www.foo.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="fielding", realm="users@foo.org", nonce="...", uri="/top/container/", response="...", opaque="..." -Clemm, Hopkins, Sedlar, Whitehead [Page 21] + Clemm, Hopkins, Sedlar, Whitehead [Page 32] http://www.foo.org/users/esedlar - - + + + >> Response << HTTP/1.1 403 Forbidden Content-Type: text/xml; charset="utf-8" Content-Length: xxx - + -8.1.4 Example: ACL method failure due to inherited ACEs preceding non- - inherited ACEs + 8.1.4 Example: ACL method failure due to an inherited ACE conflict - In the following request, user "ejw", authenticated by information - in the Authorization header, tries to change the access control - list on the resource http://www.foo.org/top/index.html. This - resource has two inherited ACEs. + In the following request, user "ejw", authenticated by + information in the Authorization header, tries to change the + access control list on the resource + http://www.foo.org/top/index.html. This resource has two + inherited ACEs. Inherited ACE #1 grants the principal identified by URL http://www.foo.org/users/ejw (i.e., the user "ejw") - http://www.foo.org/privs/write-all and DAV:read-acl privileges. On - this server, http://www.foo.org/privs/write-all is an aggregate - privilege containing DAV:write, and DAV:write-acl. + http://www.foo.org/privs/write-all and DAV:read-acl privileges. + On this server, http://www.foo.org/privs/write-all is an + aggregate privilege containing DAV:write, and DAV:write-acl. - Inherited ACE #2 grants principal DAV:all the DAV:read privilege. + Inherited ACE #2 grants principal DAV:all the DAV:read + privilege. - The request attempts to add a third ACE, granting the principal - identified by the URL http://www.foo.org/users/gclemm (i.e., the - user ôgclemmö) DAV:write permission, but in the request places the - inherited ACEs before the non-inherited ACEs, causing an error on - this specific server implementation. Note that on a different - implementation, this request might be accepted. + The request attempts to set a (non-inherited) ACE, denying the + principal identified by the URL http://www.foo.org/users/ejw + (i.e., the user ôejwö) DAV:write permission. This conflicts + with inherited ACE #1. Note that the decision to report an + inherited ACE conflict is specific to this server + implementation. Another server implementation could have + allowed the new ACE to be set, and then used normal ACE + evaluation rules to determine whether the new ACE has any + impact on the privileges available to a principal. >> Request << ACL /top/index.html HTTP/1.1 Host: www.foo.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ejw", + + Clemm, Hopkins, Sedlar, Whitehead [Page 33] realm="users@foo.org", nonce="...", uri="/top/index.html", response="...", opaque="..." - -Clemm, Hopkins, Sedlar, Whitehead [Page 22] http://www.foo.org/users/ejw - - - - - - - - - - - - - - http://www.foo.org/users/gclemm - >> Response << HTTP/1.1 403 Forbidden Content-Type: text/xml; charset="utf-8" Content-Length: xxx - + -8.1.5 Example: ACL method failure due to an attempt to set grant and deny - in a single ACE. + 8.1.5 Example: ACL method failure due to an attempt to set grant and + deny in a single ACE. - In this example, user "ygoland", authenticated by information in - the Authorization header, tries to change the access control list - on the resource http://www.foo.org/diamond/engagement-ring.gif. The - ACL request includes a single, syntactically and semantically - incorrect ACE, which attempts to grant the collection principal - identified by the URL http://www.foo.org/users/friends/ DAV:read - privilege and deny the principal identified by URL - http://www.foo.org/users/ygoland-so (i.e., the user "ygoland-so") - DAV:read privilege. However, it is illegal to have multiple - principal elements, as well as both a grant and deny element in the - same ACE, so the request fails due to poor syntax. + In this example, user "ygoland", authenticated by information + in the Authorization header, tries to change the access control + list on the resource http://www.foo.org/diamond/engagement- + ring.gif. The ACL request includes a single, syntactically and + semantically incorrect ACE, which attempts to grant the + collection principal identified by the URL + http://www.foo.org/users/friends/ DAV:read privilege and deny + the principal identified by URL + http://www.foo.org/users/ygoland-so (i.e., the user "ygoland- + so") DAV:read privilege. However, it is illegal to have + multiple principal elements, as well as both a grant and deny + element in the same ACE, so the request fails due to poor + syntax. >> Request << ACL /diamond/engagement-ring.gif HTTP/1.1 Host: www.foo.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ygoland", - -Clemm, Hopkins, Sedlar, Whitehead [Page 23] realm="users@foo.org", nonce="...", - uri="/diamond/engagement-ring.gif", response="...", opaque="..." + uri="/diamond/engagement-ring.gif", response="...", + opaque="..." + + Clemm, Hopkins, Sedlar, Whitehead [Page 34] http://www.foo.org/users/friends/ http://www.foo.org/users/ygoland-so >> Response << HTTP/1.1 400 Bad Request Content-Length: 0 Note that if the request had been divided into two ACEs, one to - grant, and one to deny, the request would have been syntactically - well formed. + grant, and one to deny, the request would have been + syntactically well formed. -9 INTERNATIONALIZATION CONSIDERATIONS + 9 ACCESS CONTROL REPORTS - In this specification, the only human-readable content can be found - in the description XML element, found within the DAV:supported- - privilege-set property. This element contains a human-readable - description of the capabilities controlled by a privilege. As a - result, the description element must be capable of representing - descriptions in multiple character sets. Since the description - element is found within a WebDAV property, it is represented on- - the-wire as XML [REC-XML], and hence can leverage XML's language - tagging and character set encoding capabilities. Specifically, XML - processors must, at minimum, be able to read XML elements encoded - using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual - plane. XML examples in this specification demonstrate use of the - charset parameter of the Content-Type header, as defined in - [RFC3023], as well as the XML "encoding" attribute, which together - provide charset identification information for MIME and XML - processors. + 9.1 REPORT Method - For XML elements other than the description element, it is expected - that implementations will treat the property names, privilege - names, and values as tokens, and convert these tokens into human- - readable text in the user's language and character set when - displayed to a person. Only a generic WebDAV property display - utility would display these values in their raw form to a human - user. + A REPORT request is an extensible mechanism for obtaining + information about a resource. Unlike a resource property, + which has a single value, the value of a report can depend on + additional information specified in the REPORT request body and + in the REPORT request headers. -Clemm, Hopkins, Sedlar, Whitehead [Page 24] - For error reporting, we follow the convention of HTTP/1.1 status - codes, including with each status code a short, English description - of the code (e.g., 200 (OK)). While the possibility exists that a - poorly crafted user agent would display this message to a user, - internationalized applications will ignore this message, and - display an appropriate message in the user's language and character - set. + Marshalling: - Further internationalization considerations for this protocol are - described in the WebDAV Distributed Authoring protocol + The body of a REPORT request specifies which report is being + requested, as well as any additional information that will be + used to customize the report. + + The request MAY include a Depth header. + + The response body for a successful request MUST contain the + requested report. + + If a Depth request header is included, the response MUST be a + 207 Multi-Status. + + Postconditions: + + The REPORT method MUST NOT change the content or dead + properties of any resource. + + If a Depth request header is included, the request MUST be + applied separately to the collection itself and to all members + of the collection that satisfy the Depth value. The DAV:prop + element of a DAV:response for a given resource MUST contain the + requested report for that resource. + + Clemm, Hopkins, Sedlar, Whitehead [Page 35] + 9.2 DAV:acl-principal-props Report + + The DAV:acl-principle-props report returns, for all principals + in the DAV:acl property that are identified by http(s) URLs, + the value of the properties specified in the REPORT request + body. In the case where a principal URL appears multiple times, + the DAV:acl-principal-props report MUST return the properties + for that principal only once. + + Marshalling + + The request body MUST be a DAV:acl-principal-props XML element. + + + ANY value: a sequence of one or more elements, with at most one + DAV:prop element. + prop: see RFC 2518, Section 12.11 + + The response body for a successful request MUST be a + DAV:multistatus XML element (i.e., the response uses the same + format as the response for PROPFIND). + + multistatus: see RFC 2518, Section 12.9 + + The response body for a successful DAV:acl-principal-props + REPORT request MUST contain a DAV:response element for each + principal identified by an http(s) URL listed in a + DAV:principal XML element of an ACE within the DAV:acl property + of the resource identified by the Request-URI. + + 9.2.1 Example: DAV:acl-principal-props Report + + Resource http;//www.webdav.org/index.html has an ACL with three + ACEs: + + ACE #1: All principals (DAV:all) have DAV:read and DAV:read- + current-user-privilege-set access. + + ACE #2: The principal identified by + http://www.webdav.org/people/gstein (the user ôgsteinö) is + granted DAV:write, DAV:write-acl, DAV:read-acl privileges. + + ACE #3: The collection principal identified by + http://www.webdav.org/groups/authors/ (the ôauthorsö group) is + granted DAV:write and DAV:read-acl privileges. + + The following example shows a DAV:acl-principal-props report + requesting the DAV:displayname property. It returns the value + of DAV:displayname for resources + http://www.webdav.org/people/gstein and + http://www.webdav.org/groups/authors/ , but not for DAV:all, + since this is not an http(s) URL. + + Clemm, Hopkins, Sedlar, Whitehead [Page 36] + >> Request << + + REPORT /index.html HTTP/1.1 + Host: www.webdav.org + Content-Type: text/xml; charset="utf-8" + Content-Length: xxxx + + + + + + + + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml; charset="utf-8" + Content-Length: xxxx + + + + + http://www.webdav.org/people/gstein + + + Greg Stein + + HTTP/1.1 200 OK + + + + http://www.webdav.org/groups/authors/ + + + Site authors + + HTTP/1.1 200 OK + + + + + 9.3 DAV:principal-match REPORT + + The DAV:principal-match REPORT is used to identify all members + of a collection that match the current user. In particular, if + the collection contains principals, the report can be used to + identify all members of the collection that match the current + user. Alternatively, if the collection contains resources that + have a property that identifies a principal (e.g. DAV:owner), + then the report can be used to identify all members of the + collection whose property identifies a principal that matches + the current user. For example, this report can return all of + + Clemm, Hopkins, Sedlar, Whitehead [Page 37] + the resources in a collection hierarchy that are owned by the + current user. + + Marshalling: + + The request body MUST be a DAV:principal-match XML element. + + + + ANY value: an element whose value identifies a property. The + expectation is the value of the named property typically + contains an href element that contains the URI of a principal + + prop: see RFC 2518, Section 12.11 + + The response body for a successful request MUST be a + DAV:multistatus XML element. + + multistatus: see RFC 2518, Section 12.9 + + The response body for a successful DAV:principal-match REPORT + request MUST contain a DAV:response element for each member of + the collection that matches the current user. When the + DAV:principal-property element is used, a match occurs if the + current user is the same as the principal identified by the URI + found in the DAV:href element of the property identified by the + DAV:principal-property element. When the DAV:self element is + used in a DAV:principal-match report issued against a + collection principal, it matches a child of the collection + principal if that child (a principal resource) identifies the + same principal as the current user. + + If DAV:prop is specified in the request body, the properties + specified in the DAV:prop element MUST be reported in the + DAV:response elements. + + 9.3.1 Example: DAV:principal-match REPORT + + The following example identifies the members of the collection + identified by the URL http://www.webdav.org/doc/ that are owned + by the current user. The current user (ôgclemmö) is + authenticated using Digest authentication. + + >> Request << + + REPORT /doc/ HTTP/1.1 + Host: www.webdav.org + Authorization: Digest username="gclemm", + realm="gclemm@webdav.org", nonce="...", + uri="/papers/", response="...", opaque="..." + Content-Type: text/xml; charset="utf-8" + Content-Length: xxxx + + Clemm, Hopkins, Sedlar, Whitehead [Page 38] + + + + + + + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml; charset="utf-8" + Content-Length: xxxx + + + + + http://www.webdav.org/doc/foo.html + HTTP/1.1 200 OK + + + http://www.webdav.org/doc/img/bar.gif + HTTP/1.1 200 OK + + + + 10 XML PROCESSING + + Implementations of this specification MUST support the XML + element ignore rule, as specified in Section 23.3.2 of + [RFC2518], and the WebDAV XML Namespace interpretation + convention, described in Section 23.4 of [RFC2518]. + + 11 INTERNATIONALIZATION CONSIDERATIONS + + In this specification, the only human-readable content can be + found in the description XML element, found within the + DAV:supported-privilege-set property. This element contains a + human-readable description of the capabilities controlled by a + privilege. As a result, the description element must be + capable of representing descriptions in multiple character + sets. Since the description element is found within a WebDAV + property, it is represented on-the-wire as XML [REC-XML], and + hence can leverage XML's language tagging and character set + encoding capabilities. Specifically, XML processors must, at + minimum, be able to read XML elements encoded using the UTF-8 + [UTF-8] encoding of the ISO 10646 multilingual plane. XML + examples in this specification demonstrate use of the charset + parameter of the Content-Type header, as defined in [RFC3023], + as well as the XML "encoding" attribute, which together provide + charset identification information for MIME and XML processors. + + For XML elements other than the description element, it is + expected that implementations will treat the property names, + privilege names, and values as tokens, and convert these tokens + + Clemm, Hopkins, Sedlar, Whitehead [Page 39] + into human-readable text in the user's language and character + set when displayed to a person. Only a generic WebDAV property + display utility would display these values in their raw form to + a human user. + + For error reporting, we follow the convention of HTTP/1.1 + status codes, including with each status code a short, English + description of the code (e.g., 200 (OK)). While the + possibility exists that a poorly crafted user agent would + display this message to a user, internationalized applications + will ignore this message, and display an appropriate message in + the user's language and character set. + + Further internationalization considerations for this protocol + are described in the WebDAV Distributed Authoring protocol specification [RFC2518]. -10 SECURITY CONSIDERATIONS + 12 SECURITY CONSIDERATIONS - Applications and users of this access control protocol should be - aware of several security considerations, detailed below. In + Applications and users of this access control protocol should + be aware of several security considerations, detailed below. In addition to the discussion in this document, the security - considerations detailed in the HTTP/1.1 specification [RFC2616], - the WebDAV Distributed Authoring Protocol specification [RFC2518], - and the XML Media Types specification [RFC3023] should be - considered in a security analysis of this protocol. + considerations detailed in the HTTP/1.1 specification + [RFC2616], the WebDAV Distributed Authoring Protocol + specification [RFC2518], and the XML Media Types specification + [RFC3023] should be considered in a security analysis of this + protocol. -10.1 Increased Risk of Compromised Users + 12.1 Increased Risk of Compromised Users In the absence of a mechanism for remotely manipulating access - control lists, if a single user's authentication credentials are - compromised, only those resources for which the user has access - permission can be read, modified, moved, or deleted. With the - introduction of this access control protocol, if a single - compromised user has the ability to change ACLs for a broad range - of other users (e.g., a super-user), the number of resources that - could be altered by a single compromised user increases. This risk - can be mitigated by limiting the number of people who have write- - acl privileges across a broad range of resources. + control lists, if a single user's authentication credentials + are compromised, only those resources for which the user has + access permission can be read, modified, moved, or deleted. + With the introduction of this access control protocol, if a + single compromised user has the ability to change ACLs for a + broad range of other users (e.g., a super-user), the number of + resources that could be altered by a single compromised user + increases. This risk can be mitigated by limiting the number of + people who have write-acl privileges across a broad range of + resources. -10.2 Risks of the read-acl and cuprivset Privileges + 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set + Privileges - The ability to read the access privileges (stored in the DAV:acl - property), or the privileges permitted the currently authenticated - user (stored in the DAV:current-user-privilege-set property) on a - resource may seem innocuous, since reading an ACL cannot possibly - affect the resource's state. However, if all resources have world- - readable ACLs, it is possible to perform an exhaustive search for - those resources that have inadvertently left themselves in a - vulnerable state, such as being world-writeable. In particular, the - property retrieval method PROPFIND, executed with Depth infinity on - an entire hierarchy, is a very efficient way to retrieve the - DAV:acl or DAV:current-user-privilege-set properties. Once found, - this vulnerability can be exploited by a denial of service attack - in which the open resource is repeatedly overwritten. Alternately, - writeable resources can be modified in undesirable ways. + The ability to read the access privileges (stored in the + DAV:acl property), or the privileges permitted the currently + authenticated user (stored in the DAV:current-user-privilege- + set property) on a resource may seem innocuous, since reading + an ACL cannot possibly affect the resource's state. However, if + all resources have world-readable ACLs, it is possible to + perform an exhaustive search for those resources that have + inadvertently left themselves in a vulnerable state, such as + being world-writeable. In particular, the property retrieval - To reduce this risk, read-acl privileges should not be granted to - unauthenticated principals, and restrictions on read-acl and + Clemm, Hopkins, Sedlar, Whitehead [Page 40] + method PROPFIND, executed with Depth infinity on an entire + hierarchy, is a very efficient way to retrieve the DAV:acl or + DAV:current-user-privilege-set properties. Once found, this + vulnerability can be exploited by a denial of service attack in + which the open resource is repeatedly overwritten. Alternately, + writeable resources can be modified in undesirable ways. -Clemm, Hopkins, Sedlar, Whitehead [Page 25] + To reduce this risk, read-acl privileges should not be granted + to unauthenticated principals, and restrictions on read-acl and cuprivset privileges for authenticated principals should be carefully analyzed when deploying this protocol. Access to the current-user-privilege-set property will involve a tradeoff of - usability versus security. When the current-user-privilege-set is - visible, user interfaces are expected to provide enhanced + usability versus security. When the current-user-privilege-set + is visible, user interfaces are expected to provide enhanced information concerning permitted and restricted operations, yet - this information may also indicate a vulnerability that could be - exploited. Deployment of this protocol will need to evaluate this - tradeoff in light of the requirements of the deployment + this information may also indicate a vulnerability that could + be exploited. Deployment of this protocol will need to evaluate + this tradeoff in light of the requirements of the deployment environment. -11 AUTHENTICATION + 12.3 No Foreknowledge of Initial ACL + + In an effort to reduce protocol complexity, this protocol + specification intentionally does not address the issue of how + to manage or discover the initial ACL that is placed upon a + resource when it is created. The only way to discover the + initial ACL is to create a new resource, then retrieve the + value of the DAV:acl property. This assumes the principal + creating the resource also has been granted the DAV:read-acl + privilege. + + As a result, it is possible that a principal could create a + resource, and then discover that its ACL grants privileges that + are undesirable. Furthermore, this protocol makes it possible + (though unlikely) that the creating principal could be unable + to modify the ACL, or even delete the resource. Even when the + ACL can be modified, there will be a short period of time when + the resource exists with the initial ACL before its new ACL can + be set. + + Several factors mitigate this risk. Human principals are often + aware of the default access permissions in their editing + environments and take this into account when writing + information. Furthermore, default privilege policies are + usually very conservative, limiting the privileges granted by + the initial ACL. + + 13 AUTHENTICATION Authentication mechanisms defined in WebDAV also apply to this - WebDAV Access Control Protocol, in particular the Basic and Digest - authentication mechanisms defined in [RFC2617]. + WebDAV Access Control Protocol, in particular the Basic and + Digest authentication mechanisms defined in [RFC2617]. -12 IANA CONSIDERATIONS + Clemm, Hopkins, Sedlar, Whitehead [Page 41] + 14 IANA CONSIDERATIONS This document uses the namespace defined by [RFC2518] for XML elements. All other IANA considerations mentioned in [RFC2518] also applicable to WebDAV ACL. -13 INTELLECTUAL PROPERTY + 15 INTELLECTUAL PROPERTY The following notice is copied from RFC 2026, section 10.4, and - describes the position of the IETF concerning intellectual property - claims made against this document. - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use other technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on - the IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances - of licenses to be made available, or the result of an attempt made - to obtain a general license or permission for the use of such - proprietary rights by implementers or users of this specification - can be obtained from the IETF Secretariat. + describes the position of the IETF concerning intellectual + property claims made against this document. - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to practice - this standard. Please address the information to the IETF - Executive Director. + The IETF takes no position regarding the validity or scope of + any intellectual property or other rights that might be claimed + to pertain to the implementation or use other technology + described in this document or the extent to which any license + under such rights might or might not be available; neither does + it represent that it has made any effort to identify any such + rights. Information on the IETF's procedures with respect to + rights in standards-track and standards-related documentation + can be found in BCP-11. Copies of claims of rights made + available for publication and any assurances of licenses to be + made available, or the result of an attempt made to obtain a + general license or permission for the use of such proprietary + rights by implementers or users of this specification can be + obtained from the IETF Secretariat. -14 ACKNOWLEDGEMENTS + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be + required to practice this standard. Please address the + information to the IETF Executive Director. - This protocol is the collaborative product of the WebDAV ACL design - team: Bernard Chester, Geoff Clemm (Rational), Anne Hopkins + 16 ACKNOWLEDGEMENTS -Clemm, Hopkins, Sedlar, Whitehead [Page 26] - (Microsoft), Barry Lind (Xythos), Sean Lyndersay (Microsoft), Eric - Sedlar (Oracle), Greg Stein (Apache.org), and Jim Whitehead (UC - Santa Cruz). The authors are grateful for the detailed review and - comments provided by Jim Amsden, Gino Basso, Murthy Chintalapati, - Dennis Hamilton, Laurie Harper, Ron Jacobs, Chris Knight, and Remy - Maucherat. Prior work on WebDAV access control protocols has been - performed by Yaron Goland, Paul Leach, Lisa Dusseault, Howard - Palmer, and Jon Radoff. We would like to acknowledge the foundation - laid for us by the authors of the WebDAV and HTTP protocols upon - which this protocol is layered, and the invaluable feedback from - the WebDAV working group. + This protocol is the collaborative product of the WebDAV ACL + design team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry + Lind, Sean Lyndersay, Eric Sedlar, Greg Stein, and Jim + Whitehead. The authors are grateful for the detailed review and + comments provided by Jim Amsden, Gino Basso, Murthy + Chintalapati, Dennis Hamilton, Laurie Harper, Ron Jacobs, Chris + Knight, Remy Maucherat, Larry Masinter, Yaron Goland, Lisa + Dusseault, and Joe Orton. Prior work on WebDAV access control + protocols has been performed by Yaron Goland, Paul Leach, Lisa + Dusseault, Howard Palmer, and Jon Radoff. We would like to + acknowledge the foundation laid for us by the authors of the + WebDAV and HTTP protocols upon which this protocol is layered, + and the invaluable feedback from the WebDAV working group. -15 REFERENCES + Clemm, Hopkins, Sedlar, Whitehead [Page 42] + 17 REFERENCES -15.1 Normative References + 17.1 Normative References [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, BCP 14, Harvard, March, 1997. [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible - Markup Language (XML)." World Wide Web Consortium Recommendation - REC-xml-19980210. http://www.w3.org/TR/REC-xml-19980210. + Markup Language (XML)." World Wide Web Consortium + Recommendation REC-xml-19980210. http://www.w3.org/TR/REC-xml- + 19980210. [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2616. U.C.Irvine, Compaq, Xerox, Microsoft, MIT/LCS, June, 1999. - [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. - Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and - Digest Access Authentication. " RFC 2617. Northwestern University, - Verisign, AbiSource, Agranat, Microsoft, Netscape, Open Market, - June, 1999. + [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. + Lawrence, P. Leach, A. Luotonen, L. Stewart, "HTTP + Authentication: Basic and Digest Access Authentication." RFC + 2617. Northwestern University, Verisign, AbiSource, Agranat, + Microsoft, Netscape, Open Market, June, 1999. [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D. - Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV." RFC - 2518. Microsoft, U.C.Irvine, Netscape, Novell, February, 1999. + Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV." + RFC 2518. Microsoft, U.C. Irvine, Netscape, Novell, February, + 1999. [RFC2368] P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL - scheme." RFC 2368. Internet Mail Consortium, Xerox, Netscape, July, - 1998. + scheme." RFC 2368. Internet Mail Consortium, Xerox, Netscape, + July, 1998. [RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255. Netscape, December, 1997. - [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types." RFC - 3023. IBM Tokyo Research Laboratory, simonstl.com, Skymoon + [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types." + RFC 3023. IBM Tokyo Research Laboratory, simonstl.com, Skymoon Ventures, January, 2001. - [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and - ISO 10646." RFC 2279. Alis Technologies. January, 1998. - -Clemm, Hopkins, Sedlar, Whitehead [Page 27] + [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode + and ISO 10646." RFC 2279. Alis Technologies. January, 1998. -15.2 Informational References + 17.2 Informational References - [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 3." - RFC 2026, BCP 9. Harvard, October, 1996. + [RFC2026] S.Bradner, "The Internet Standards Process û Revision + 3." RFC 2026, BCP 9. Harvard, October, 1996. -16 AUTHORS' ADDRESSES + 18 AUTHORS' ADDRESSES Geoffrey Clemm Rational Software 20 Maguire Road Lexington, MA 02421 Email: geoffrey.clemm@rational.com + Clemm, Hopkins, Sedlar, Whitehead [Page 43] Anne Hopkins Microsoft Corporation One Microsoft Way Redmond, WA 98052 Email: annehop@microsoft.com Eric Sedlar Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 Email: esedlar@us.oracle.com Jim Whitehead U.C. Santa Cruz Dept. of Computer Science Baskin Engineering 1156 High Street Santa Cruz, CA 95064 Email: ejw@cse.ucsc.edu -17 APPENDICIES + 19 APPENDICIES -17.1 XML Document Type Definition + 19.1 XML Document Type Definition - + -Clemm, Hopkins, Sedlar, Whitehead [Page 28] + Clemm, Hopkins, Sedlar, Whitehead [Page 44] - + @@ -1553,40 +2432,69 @@ -Clemm, Hopkins, Sedlar, Whitehead [Page 29] - + + + Clemm, Hopkins, Sedlar, Whitehead [Page 45] + + + + + (href | all | authenticated | unauthenticated | property | + self)> - + + + - - - - -Clemm, Hopkins, Sedlar, Whitehead [Page 30] + + + + ANY value: a sequence of one or more elements, with at most one + DAV:prop element. + + + ANY value: an element whose value identifies a property. The + expectation is the value of the named property typically + contains an href element that contains the URI of a principal + + + 20 NOTE TO RFC EDITOR + + *** This section (Section 20) MUST be removed before + publication as an RFC *** + + Section 9.1 defines the REPORT method. The REPORT method is + also defined in draft-ietf-deltav-versioning-15, in Section + 3.6, using identical text. This was done to avoid making this + specification dependent on draft-ietf-deltav-versioning. + + If draft-ietf-deltav-versioning is published as an RFC before + this specification, Section 9.1 MUST be removed. + + Clemm, Hopkins, Sedlar, Whitehead [Page 46]