--- 1/draft-ietf-webdav-acl-06.txt 2006-02-05 02:10:14.000000000 +0100 +++ 2/draft-ietf-webdav-acl-07.txt 2006-02-05 02:10:14.000000000 +0100 @@ -1,1338 +1,1422 @@ - INTERNET-DRAFT Geoffrey Clemm, Rational Software - draft-ietf-webdav-acl-06 Anne Hopkins, Microsoft Corporation +draft-ietf-webdav-acl-07 Anne Hopkins, Microsoft Corporation Eric Sedlar, Oracle Corporation Jim Whitehead, U.C. Santa Cruz - Expires December 21, 2001 June 21, 2001 +Expires May 9, 2001 November 9, 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 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 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 read and modify +access control lists that instruct a server whether to allow 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.......................................................5 +1.1 Terms............................................................7 +1.2 Notational Conventions...........................................8 - 2 PRINCIPALS.....................................................6 +2 PRINCIPALS.........................................................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 +3 PRIVILEGES.........................................................9 +3.1 DAV:read Privilege..............................................11 +3.2 DAV:write Privilege.............................................11 +3.3 DAV:read-acl Privilege..........................................11 +3.4 DAV:read-current-user-privilege-set Privilege...................11 +3.5 DAV:write-acl Privilege.........................................12 +3.6 DAV:all Privilege...............................................12 +3.7 Aggregation of Predefined Privileges............................12 - 4 PRINCIPAL PROPERTIES..........................................10 - 4.1 DAV:alternate-URL..........................................10 +4 PRINCIPAL PROPERTIES..............................................12 +4.1 DAV:alternate-URI-set...........................................13 - 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 ACCESS CONTROL PROPERTIES.........................................13 +5.1 DAV:owner.......................................................13 + 5.1.1 Example: Retrieving DAV:owner................................14 + 5.1.2 Example: An Attempt to Set DAV:owner.........................15 +5.2 DAV:supported-privilege-set.....................................16 5.2.1 Example: Retrieving a List of Privileges Supported on a - Resource.................................................14 - 5.3 DAV:current-user-privilege-set.............................15 + Resource.....................................................16 +5.3 DAV:current-user-privilege-set..................................18 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 + Privileges.........................................................19 +5.4 DAV:acl.........................................................20 + 5.4.1 ACE Principal................................................20 + 5.4.2 ACE Grant and Deny...........................................21 + 5.4.3 ACE Protection...............................................21 + 5.4.4 ACE Inheritance..............................................22 + 5.4.5 Example: Retrieving a Resource's Access Control List......22 +5.5 DAV:acl-semantics...............................................23 + 5.5.1 Example: Retrieving DAV:acl-semantics........................24 +5.6 DAV:principal-collection-set....................................25 + 5.6.1 Example: Retrieving DAV:principal-collection-set.............26 +5.7 Example: PROPFIND to retrieve access control properties.........27 - 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 +6 ACL SEMANTICS.....................................................30 +6.1 ACE Combination.................................................31 + 6.1.1 DAV:first-match ACE Combination..............................31 + 6.1.2 DAV:all-grant-before-any-deny ACE Combination................31 + 6.1.3 DAV:specific-deny-overrides-grant ACE Combination............31 +6.2 ACE Ordering....................................................31 + 6.2.1 DAV:deny-before-grant ACE Ordering...........................32 +6.3 Allowed ACE.....................................................32 + 6.3.1 DAV:principal-only-one-ace ACE Constraint....................32 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 + 6.3.2 DAV:grant-only ACE Constraint................................32 +6.4 Required Principals.............................................32 - 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 +7 ACCESS CONTROL AND EXISTING METHODS...............................32 +7.1 OPTIONS.........................................................33 + 7.1.1 Example - OPTIONS............................................33 +7.2 MOVE............................................................33 +7.3 COPY............................................................33 +7.4 DELETE..........................................................33 +7.5 LOCK............................................................34 - 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 +8 ACCESS CONTROL METHODS............................................34 +8.1 ACL.............................................................34 + 8.1.1 ACL Preconditions............................................34 + 8.1.2 Example: the ACL method......................................36 + 8.1.3 Example: ACL method failure due to protected ACE conflict....37 + 8.1.4 Example: ACL method failure due to an inherited ACE conflict 38 + 8.1.5 Example: ACL method failure due to an attempt to set grant + and deny in a single ACE.....................................39 - 10 XML PROCESSING..............................................39 +9 ACCESS CONTROL REPORTS............................................40 +9.1 REPORT Method...................................................40 +9.2 DAV:acl-principal-props Report..................................40 + 9.2.1 Example: DAV:acl-principal-props Report......................40 +9.3 DAV:principal-match REPORT......................................42 + 9.3.1 Example: DAV:principal-match REPORT..........................43 +9.4 DAV:principal-property-search REPORT............................44 + 9.4.1 Matching.....................................................45 + 9.4.2 Example: successful DAV:principal-property-search REPORT.....46 + 9.4.3 Example: Unsuccessful DAV:principal-property-search REPORT...48 +9.5 DAV:principal-search-property-set REPORT........................49 + 9.5.1 Example: DAV:principal-search-property-set REPORT............50 - 11 INTERNATIONALIZATION CONSIDERATIONS.........................39 +10 XML PROCESSING..................................................51 - 12 SECURITY CONSIDERATIONS.....................................40 - 12.1 Increased Risk of Compromised Users........................40 +11 INTERNATIONALIZATION CONSIDERATIONS.............................51 + +12 SECURITY CONSIDERATIONS.........................................52 +12.1 Increased Risk of Compromised Users...........................52 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set - Privileges.................................................40 - 12.3 No Foreknowledge of Initial ACL............................41 + Privileges....................................................52 +12.3 No Foreknowledge of Initial ACL...............................53 - 13 AUTHENTICATION..............................................41 +13 AUTHENTICATION..................................................53 - 14 IANA CONSIDERATIONS.........................................42 +14 IANA CONSIDERATIONS.............................................53 - 15 INTELLECTUAL PROPERTY.......................................42 +15 INTELLECTUAL PROPERTY...........................................54 - 16 ACKNOWLEDGEMENTS............................................42 +16 ACKNOWLEDGEMENTS................................................54 - 17 REFERENCES..................................................43 - 17.1 Normative References.......................................43 - 17.2 Informational References...................................43 +Clemm, Hopkins, Sedlar, Whitehead [Page 3] - 18 AUTHORS' ADDRESSES..........................................43 +17 REFERENCES......................................................55 +17.1 Normative References..........................................55 +17.2 Informational References......................................56 - 19 APPENDICIES.................................................44 - 19.1 XML Document Type Definition...............................44 +18 AUTHORS' ADDRESSES..............................................56 - 20 NOTE TO RFC EDITOR..........................................46 +19 APPENDICIES.....................................................57 +19.1 XML Document Type Definition..................................57 + +20 NOTE TO RFC EDITOR..............................................59 + +Clemm, Hopkins, Sedlar, Whitehead [Page 4] - 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 and metadata managed by 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 what operations you can perform on 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 "operations you can perform" 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. + Since every ACE contains the identifier of a principal, client + software operated by a human must provide a mechanism for selecting + this principal. This specification uses http(s) scheme URLs to + identify principals, which are represented as WebDAV-capable + resources. There is no guarantee that the URLs identifying principals + will be meaningful to a human. For example, + http://www.dav.org/u/256432 and http://www.dav.org/people/Greg.Stein + are both valid URLs that could be used to identify the same + principal. To remedy this, every principal resource has the + DAV:displayname property containing a human-readable name for the + principal. + + Since a principal can be identified by multiple URLs, it raises the + problem of determining exactly which principal's operations are being + described in a given ACE. It is impossible for a client to determine + that an ACE granting the read privilege to + http://www.dav.org/people/Greg.Stein also affects the principal at + http://www.dav.org/u/256432. That is, a client has no mechanism for + determining that two URLs identify the same principal resource. As a + result, this specification requires clients to use just one of the + many possible URLs for a principal when creating ACEs. A client can + discover this URL by retrieving the DAV:principal-URL property + (Section 4.2) from a principal resource. No matter which of the + principal's URLs is used with PROPFIND, the property always returns + the same URL. + + Once a system has hundreds to thousands of principals, the problem + arises of how to allow a human operator of client software to select + just one of these principals. One approach is to use broad collection + +Clemm, Hopkins, Sedlar, Whitehead [Page 5] + hierarchies to spread the principals over a large number of + collections, yielding few principals per collection. An example of + this is a two level hierarchy with the first level containing 36 + collections (a-z, 0-9), and the second level being another 36, + creating collections /a/a/, /a/b/, à, /a/z/, such that a principal + with last name "Stein" would appear at /s/t/Stein. In effect, this + pre-computes a common query, search on last name, and encodes it into + a hierarchy. The drawback with this scheme is that it handles only a + small set of predefined queries, and drilling down through the + collection hierarchy adds unnecessary steps (navigate down/up) when + the user already knows the principal's name. While organizing + principal URLs into a hierarchy is a valid namespace organization, + users should not be forced to navigate this hierarchy to select a + principal. + + This specification provides the capability to perform substring + searches on a small set of properties on the resources representing + principals. This permits searches based on last name, first name, + user name, job title, etc. Two separate searches are supported, via + the REPORT method, one to search principal resources, the other to + determine which properties may be searched at all. + + Once a principal has been identified in an ACE, a server evaluating + that ACE must know the identity of the principal making a protocol + request, and must validate that that principal is who they claim to + be, a process known as authentication. 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. 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 all resources , rather than to a particular resource. - * Creation and maintenance of resources representing people - or computational agents (principals), and groups of these. + * 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 + This specification is organized as follows. Section 1.1 defines key + concepts used throughout the specification, and is followed by a more - Clemm, Hopkins, Sedlar, Whitehead [Page 4] - (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. +Clemm, Hopkins, Sedlar, Whitehead [Page 6] + 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.4). Client discovery of access + control capability using OPTIONS is described in Section 7.1. + Interactions between access control functionality and existing HTTP + and WebDAV methods are described in the remainder of Section 7. The + access control setting method, ACL, is specified in Section 8. Four + reports that provide limited server-side searching capabilities are + described in Section 9. A note on XML processing (Section 10), + Internationalization considerations (Section 11), security + considerations (Section 12), and a note on authentication (Section + 13) 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 a privilege, means the - privilege cannot be set in an access control element (ace). + privilege cannot be set in an access control element (ACE). access control list (ACL) - An "ACL" is a list of access control elements that define - access control to a particular resource. +Clemm, Hopkins, Sedlar, Whitehead [Page 7] + An "ACL" is a list of access control elements that define access + control to a particular resource. - access control element (ace) + 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 + inherited ACE - 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. + 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. 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. + 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. + 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. - 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]. + 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]. When an XML element type in the "DAV:" + namespace is referenced in this document outside of the context of an + XML fragment, the string "DAV:" will be prefixed to the element type. 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 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 is a network resource that represents a distinct human or + computational actor that initiates access to network resources. Users + and groups are represented as principals in many implementations; + 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 URIs, one of which has to be an + http(s) scheme URL. Although an implementation SHOULD support - 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 8] + PROPFIND and MAY support PROPPATCH to access and modify information + about a principal, it is not required to do so. - 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. + 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 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. + 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 + 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/. + 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. + 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, unless the principal matches - 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 the ability to update the state - of a collection, these privileges would be aggregated by the +Clemm, Hopkins, Sedlar, Whitehead [Page 9] + an ACE constructed using the DAV:all, DAV:authenticated, or + DAV:unauthenticated pseudo-principals (see Section 5.4.1). + + 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 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. + privilege on a collection would also grant the add-member and remove- + member privileges. - 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 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. + 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 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, 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). + 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 resources (defined in [RFC2518], + Section 3) 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 resources). On the transition from + null to stateful resource, the initial access control list is set by + the server's default ACL value policy (if any). + + Server implementations MAY define new privileges beyond those defined + in this specification. Privileges defined by individual + +Clemm, Hopkins, Sedlar, Whitehead [Page 10] + implementations MUST NOT use the DAV: namespace, and instead should + use a namespace that they control, such as an http scheme URL. 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 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. + 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 [WEBDAV]), so + effective write access requires that both write privileges and write + locking requirements are satisfied. 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-current-user-privilege-set Privilege - 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. + 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. + 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. +Clemm, Hopkins, Sedlar, Whitehead [Page 11] + 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. + 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 the entire set - of privileges that apply to the resource. + DAV:all is an aggregate privilege that contains the entire set of + privileges that can be applied 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: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: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 (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: + Principals are manifested to clients as a WebDAV resource, identified + by a URL. A principal MUST have a DAV:displayname 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 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.1 DAV:alternate-URL +Clemm, Hopkins, Sedlar, Whitehead [Page 12] + SHOULD NOT be returned by a PROPFIND allprop request (as defined in + Section 12.14.1 of [RFC2518]). - 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. . +4.1 DAV:alternate-URI-set - + This protected property, if non-empty, contains the URIs of network + resources with additional descriptive information about the + principal. This property identifies 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. One + expected use for this property is the storage of an ldap [RFC2255] + scheme URL. A user-agent encountering an ldap URL could use LDAP + [RFC2589] to retrieve additional machine-readable directory + information about the principal, and display that information in its + user interface. Support for this property is REQUIRED, and the value + is empty if no alternate URI 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. - Since it is expensive, for many servers, to retrieve access +4.2 DAV:principal-URL - 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. + This protected property contains the URL that MUST be used to + identify this principal in an ACL request. - 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 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. 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 values of the properties + defined in this section. + + HTTP resources that support the WebDAV Access Control Protocol MUST + contain the following properties. Null resources (described in + Section 3 of [RFC2518]) MUST NOT contain the following properties: 5.1 DAV:owner - 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. + 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 13] + 5.1.1 Example: Retrieving DAV:owner - 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. + 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 - + http://www.webdav.org/_acl/users/gstein + HTTP/1.1 200 OK +Clemm, Hopkins, Sedlar, Whitehead [Page 14] + 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 + 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. + property, the server responds with a 207 (Multi-Status) response that + contains a 403 (Forbidden) status code for the act of setting + DAV:owner. Section 8.2.1 of [RFC2518] describes PROPPATCH status code + information, and Section 11 of [RFC2518] 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 - + 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 - + HTTP/1.1 403 Forbidden Failure to set protected property (DAV:owner) + + +Clemm, Hopkins, Sedlar, Whitehead [Page 15] 5.2 DAV:supported-privilege-set - This is a protected 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 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. + A description is a human-readable description of what this privilege + controls access to. Servers MUST indicate the human language of the + description using the xml:lang attribute and SHOULD consider the HTTP + Accept-Language request header when selecting one of multiple + available languages. - 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 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. + 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 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 +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: + 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) + +Clemm, Hopkins, Sedlar, Whitehead [Page 16] | +-- 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. + 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 + Any + operation - Read any object + +Clemm, Hopkins, Sedlar, Whitehead [Page 17] + Read any + object - Read ACL + Read + ACL - Read current user privilege set - property + Read current user + privilege set property - Write any object + Write any + object - Write ACL + Write + ACL + HTTP/1.1 200 OK 5.3 DAV:current-user-privilege-set - 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. + 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 18] - - 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 +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. + 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 19] - - Clemm, Hopkins, Sedlar, Whitehead [Page 16] http://www.webdav.org/papers/ - HTTP/1.1 200 OK + HTTP/1.1 200 OK 5.4 DAV:acl 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. + 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. - 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. + 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. 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. +Clemm, Hopkins, Sedlar, Whitehead [Page 20] 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 - (that is, DAV:authenticated and DAV:unauthenticated are - disjoint sets). + 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 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. + 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 or a - member of that principal collection. + resource only if that resource is a principal object and the current + user is authenticated as being that principal or a member of that + principal collection. 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. + A server indicates an ACE is protected by including the DAV:protected + element in the ACE. If the ACL of a resource contains an ACE with a + DAV:protected element, an attempt to remove that ACE from the ACL + MUST fail.. +Clemm, Hopkins, Sedlar, Whitehead [Page 21] + 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. - 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. + 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 +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: + 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. + 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. + 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="..." + +Clemm, Hopkins, Sedlar, Whitehead [Page 22] + + >> 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/ - + + HTTP/1.1 200 OK 5.5 DAV:acl-semantics - 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). + This is a protected property that defines the ACL semantics. These + semantics define how multiple ACEs that match the current user are - 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 23] + 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. - 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. + 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" + +Clemm, Hopkins, Sedlar, Whitehead [Page 24] Content-Length: xxx http://www.webdav.org/papers/ - HTTP/1.1 200 OK - - Clemm, Hopkins, Sedlar, Whitehead [Page 21] + HTTP/1.1 200 OK 5.6 DAV:principal-collection-set This protected property contains zero, one, or more URLs that - identify a collection principal. It is expected that - 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. + identify a collection principal. It is expected that implementations + of this protocol will typically use a relatively small number of + locations in the URL namespace for principals, 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 retrieve 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, in which case - the property value would be empty. + 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 + +Clemm, Hopkins, Sedlar, Whitehead [Page 25] + 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. + + The value of DAV:principal-collection-set gives the scope of the + DAV:principal-property-search REPORT (defined in Section 9.4). + Clients use the DAV:principal-property-search REPORT to populate + their user interface with a list of principals. Therefore, servers + that limit a client's ability to obtain principal information will + interfere with the client's ability to manipulate access control + lists, due to the difficulty of getting the URL of a principal for + use in an ACE. 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, + 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 + http://www.webdav.org/_acl/groups/, both wrapped in XML + elements. Digest authentication provides credentials for the + principal operating the client. - 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. + The client might reasonably follow this request with two separate + PROPFIND requests to retrieve the DAV:displayname 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 << +Clemm, Hopkins, Sedlar, Whitehead [Page 26] 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/ + HTTP/1.1 200 OK 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 27] >> Response << HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxx 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 + Any operation - Read any object + Read any + object - Write any object + Write any + object - Create an object + Create an + object - - Clemm, Hopkins, Sedlar, Whitehead [Page 24] - Update an object + Update an + object - Delete an object + Delete an + object - Read the ACL + Read the ACL + +Clemm, Hopkins, Sedlar, Whitehead [Page 28] - Write the ACL + Write the + ACL @@ -1348,198 +1432,190 @@ http://www.foo.org/groups/marketing/ - - + - http://www.foo.org/top/ - - - Clemm, Hopkins, Sedlar, Whitehead [Page 25] + http://www.foo.org/top/ + HTTP/1.1 200 OK - 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: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: +Clemm, Hopkins, Sedlar, Whitehead [Page 29] + 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 +-- 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: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. + 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. - + - +Clemm, Hopkins, Sedlar, Whitehead [Page 30] 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 - principal. + 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 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. + 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. 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. + 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. 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. + 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. - 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. +Clemm, Hopkins, Sedlar, Whitehead [Page 31] + 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 Allowed ACE - The DAV:allowed-ace XML element specifies constraints on what - kinds of ACEs are allowed in an 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. + 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. + 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. + The required principal elements identify which principals must have + an ACE defined in the ACL. + (all? | authenticated? | unauthenticated? | self? | href* | + property*)> - 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. + +Clemm, Hopkins, Sedlar, Whitehead [Page 32] 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 << @@ -1553,151 +1629,181 @@ 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. + When a resource is moved from one location to another due to a MOVE + request, the non-inherited and non-protected ACEs in the DAV:acl + property of the resource MUST NOT be modified, or the MOVE request + fails. Handling of inherited and protected ACEs is intentionally + undefined to give server implementations flexibility in how they + implement ACE inheritance and protection. 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). + 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). Clients wishing to + preserve the DAV:acl property across a copy need to read the DAV:acl + property prior to the COPY, then perform an ACL operation on the new + resource at the destination to restore, insofar as this is possible, + the original access control list. + +7.4 DELETE + + The precise combination of privileges and resources necessary to + permit the DELETE method is intentionally left to the discretion of + each server implementation. It is envisioned that on some servers, + DELETE will require write permission on the collection containing the + resource to be deleted. On other servers, it might also require + write permission on the resource being deleted. + +Clemm, Hopkins, Sedlar, Whitehead [Page 33] + +7.5 LOCK + + A lock on a resource ensures that only the lock owner can modify ACEs + that are not inherited and not protected (these are the only ACEs + that a client can modify with an ACL request). A lock does not + protect inherited or protected ACEs, since a client cannot modify + them with an ACL request on that resource. 8 ACCESS CONTROL METHODS 8.1 ACL - 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 - - 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. + 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 + 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. 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. + 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. + 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. + 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 as the top level element in an XML - 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. +Clemm, Hopkins, Sedlar, Whitehead [Page 34] : 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 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. + : 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. 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. - 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. - : 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 deny ACEs MUST precede + all non-inherited grant ACEs. - : All non-inherited deny ACEs MUST - precede all non-inherited grant ACEs. + : 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. - : 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. + : 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. - : 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. + : The ACL request attempts to set an abstract + privilege in an ACE (see Section 5.2). - : 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. + : One or more of the privileges in the ACL + request is not supported by the resource. + + : 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. + + : One or more of the principal URLs in the + ACL request does not identify a principal resource. + +Clemm, Hopkins, Sedlar, Whitehead [Page 35] + : One or more of the principal URLs in the + ACL request is not allowed in an ACE. For example, a server where + only authenticated principals can access resources would not allow + the DAV:all or DAV:unauthenticated principals to be used in an ACE, + since these would allow unauthenticated access to resources. 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. + 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="...", uri="/top/container/", response="...", opaque="..." - - Clemm, Hopkins, Sedlar, Whitehead [Page 31] http://www.foo.org/users/esedlar @@ -1706,274 +1812,245 @@ - + + +Clemm, Hopkins, Sedlar, Whitehead [Page 36] + >> Response << HTTP/1.1 200 OK 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 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. + 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 32] http://www.foo.org/users/esedlar >> Response << HTTP/1.1 403 Forbidden Content-Type: text/xml; charset="utf-8" Content-Length: xxx - + + +Clemm, Hopkins, Sedlar, Whitehead [Page 37] 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 + 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 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. + 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="..." http://www.foo.org/users/ejw >> Response << HTTP/1.1 403 Forbidden Content-Type: text/xml; charset="utf-8" Content-Length: xxx - + +Clemm, Hopkins, Sedlar, Whitehead [Page 38] + 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 + 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", 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. + +Clemm, Hopkins, Sedlar, Whitehead [Page 39] 9 ACCESS CONTROL REPORTS 9.1 REPORT Method - 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. - - Marshalling: - - 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. + The REPORT method (defined in Section 3.6 of [RFCxxxx]) provides an + extensible mechanism for obtaining information about a resource. + Unlike the PROPFIND method, which returns the value of one or more + named properties, the REPORT method can involve more complex + processing. REPORT is valuable in cases where the server has access + to all of the information needed to perform the complex request (such + as a query), and where it would require multiple requests for the + client to retrieve the information needed to perform the same + request. - 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. + 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). + 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. + 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: + 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 #1: All principals (DAV:all) have DAV:read and DAV:read-current- + user-privilege-set access. +Clemm, Hopkins, Sedlar, Whitehead [Page 40] 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. + 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 + 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. + 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 @@ -1995,94 +2072,99 @@ Greg Stein HTTP/1.1 200 OK http://www.webdav.org/groups/authors/ + +Clemm, Hopkins, Sedlar, Whitehead [Page 41] 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 + 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 the resources in a collection + hierarchy that are owned by the current user. - Clemm, Hopkins, Sedlar, Whitehead [Page 37] - the resources in a collection hierarchy that are owned by the - current user. + The Depth header (defined in Section 9.2 of [RFC2518]), with value + "infinity", can be used with this report. In this case, the report + operates on the collection in the Request-URI, as well as all child + collections, grandchild collections, etc. 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 + 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. + 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. + 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 + +Clemm, Hopkins, Sedlar, Whitehead [Page 42] + 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. + 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 + Depth: infinity - Clemm, Hopkins, Sedlar, Whitehead [Page 38] >> Response << HTTP/1.1 207 Multi-Status @@ -2094,335 +2176,724 @@ 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 +Clemm, Hopkins, Sedlar, Whitehead [Page 43] + +9.4 DAV:principal-property-search REPORT + + The DAV:principal-property-search REPORT performs a substring search + on the character data value of specified properties. The server MUST + perform caseless matching of substrings. Only properties defined on + principal or collection principal resources are searched. For + implementation efficiency, servers do not typically support substring + searching on all properties. A client can discover the set of + searchable properties by using the principal-search-property-set + REPORT, defined in Section 9.5. + + Implementation Note: The value of a WebDAV property is a sequence + of well-formed XML, and hence can include any character in the + Unicode/ISO-10646 standard, that is, most known characters in + human languages. Due to the idiosyncrasies of case mapping across + human languages, implementation of caseless matching is non- + trivial. Implementors are strongly encouraged to consult + [CaseMap], especially Section 2.3 ("Caseless Matching"), for + guidance when implementing their caseless matching algorithms. + + Marshalling: + + The DAV:principal-collection-set property of the resource identified + by the Request-URI specifies the scope of the DAV:principal-property- + search REPORT, as follows: + + - All principal and collection principal resources identified in + DAV:principal-collection-set are searched + - All principal and collection principal resources that are + descendents of a collection principal resource identified in + DAV:principal collection-set are searched. + + Servers MUST support the DAV:principal-property-search REPORT on all + principal collections identified in the value of a DAV:principal- + collection-set property. + + The request body MUST be a DAV:principal-property-search XML element + containing a search specification and an optional list of properties. + For every principal that matches the search specification, the + response will contain the value of the properties on that principal. + + + + The DAV:property-search element contains a prop element enumerating + the properties to be searched and a caseless-substring element, + containing the search string. + + + prop: see RFC 2518, Section 12.11 + + + +Clemm, Hopkins, Sedlar, Whitehead [Page 44] + Multiple property-search elements or multiple elements within a + DAV:prop element will be interpreted with a logical AND. An empty + DAV:caseless-substring element will match all properties specified in + its parent DAV:property-search element. + + 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-property-search + REPORT request MUST contain a DAV:response element for each + principal whose property values satisfy the search specification + given in DAV:principal-property-search. + + 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. + + Errors: + + If a request specifies a search of a property that is not + searchable, a 403 (Forbidden) response MUST be returned and the + response body MUST be a DAV:non-searchable-property element, + containing the unsearchable properties. + + + +9.4.1 Matching + + There are several cases to consider when matching strings. The + easiest case is when a property value is "simple" and has only + character information item content (see [REC-XMLINFOSET]). For + example, the search string "julian" would match the DAV:displayname + property with value "Julian Reschke". Note that the on-the-wire + marshalling of DAV:displayname in this case is: + + Julian Reschke + + The name of the property is encoded into the XML element information + item, and the character information item content of the property is + "Julian Reschke". + + The more complicated case occurred when properties have mixed content + (that is, compound values consisting of multiple child element items, + other types of information items, and character information item + content). Consider the property http://www.webdav.org/props/aprop, + marshalled as: + +Clemm, Hopkins, Sedlar, Whitehead [Page 45] + + {cdata 0}{cdata 1} + {cdata 2}{cdata 3} + + + In this case, substring matching is performed on each individual + contiguous sequence of character information items. In the example + above, a search string would be compared to the four following + strings: + + {cdata 0} + {cdata 1} + {cdata 2} + {cdata 3} + + That is, four individual caseless substring matches would be + performed, one each for {cdata 0}, {cdata 1}, {cdata 2}, and {cdata + 3}. + +9.4.2 Example: successful DAV:principal-property-search REPORT + + In this example, the client requests the principal URLs of all users + whose DAV:displayname property contains the substring "doE" and whose + http://BigCorp.com/ns/title property (that is, their professional + title) contains "sales". In addition, the client requests five + properties to be returned with the matching principals: + + In the DAV: namespace: displayname + In the http://www.BigCorp.com/ns/ namespace: department, phone, + office, salary + + The response shows that two principal resources meet the search + specification, "John Doe" and "Zygdoebert Smith". The property + "salary" in namespace "http://www.BigCorp.com/ns/" is not returned, + since the principal making the request does not have sufficient + access permissions to read this property. + + >> Request << + + REPORT /users/ HTTP/1.1 + Host: www.BigCorp.com + Content-Type: text/xml; charset=utf-8 + Content-Length: xxxx + + + + + + +Clemm, Hopkins, Sedlar, Whitehead [Page 46] + + + doE + + + + + + sales + + + + + + + + + + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml; charset=utf-8 + Content-Length: xxxx + + + + + http://www.BigCorp.com/users/jdoe + + + John Doe + Widget Sales + 234-4567 + 209 + + HTTP/1.1 200 OK + + + + + + HTTP/1.1 403 Forbidden + + + + http://www.BigCorp.com/users/zsmith + + +Clemm, Hopkins, Sedlar, Whitehead [Page 47] + + Zygdoebert Smith + Gadget Sales + 234-7654 + 114 + + HTTP/1.1 200 OK + + + + + + HTTP/1.1 403 Forbidden + + + + +9.4.3 Example: Unsuccessful DAV:principal-property-search REPORT + + In this example, the client requests a search on the non-searchable + property "phone" in the namespace "http://www.BigCorp.com/ns/". The + response is a 403 (Forbidden), with a response body containing the + XML element DAV:non-searchable-property listing the non-searchable + property. + + >> Request << + + REPORT /users/ HTTP/1.1 + Host: www.BigCorp.com + Content-Type: text/xml; charset=utf-8 + Content-Length: xxxx + + + + + + + + 232 + + + + >> Response << + + HTTP/1.1 403 FORBIDDEN + Content-Type: text/xml; charset=utf-8 + Content-Length: xxxx + +Clemm, Hopkins, Sedlar, Whitehead [Page 48] + + + + + + + +9.5 DAV:principal-search-property-set REPORT + + The DAV:principal-search-property-set REPORT identifies those + properties that may be searched using the DAV:principal-property- + search REPORT (defined in Section 9.4). The DAV:principal-collection- + set property of the resource identified by the Request-URI specifies + the scope of the DAV:principal-search-property-set REPORT, as + follows: + + - All principal and collection principal resources identified in + DAV:principal-collection-set are in scope + - All principal and collection principal resources that are + descendents of a collection principal resource identified in + DAV:principal collection-set are also in scope. + + Principals and collection principals within this scope are examined + for searchable properties. + + Servers MUST support the DAV:principal-search-property-set REPORT on + all principal collections identified in the value of a DAV:principal- + collection-set property. + + An access control protocol user agent could use the results of the + DAV:principal-search-property-set REPORT to present a query interface + to the user for retrieving principals. + + Marshalling: + + The request body MUST be an empty DAV:principal-search-property-set + XML element. + + The response body MUST be a DAV:principal-search-property-set XML + element, containing a DAV:principal-search-property XML element for + each property that may be searched with the DAV:principal-property- + search REPORT. A server MAY limit its response to just a subset of + the searchable properties, such as those likely to be useful to an + interactive access control client. + + + + Each DAV:principal-search-property XML element contains exactly one + searchable property, and a description of the property. + +Clemm, Hopkins, Sedlar, Whitehead [Page 49] + + + The DAV:prop element contains one principal property on which the + server is able to perform DAV:principal-property-search REPORTs. + + prop: see RFC 2518, Section 12.11 + + The description element is a human-readable description of what + information this property represents. Servers MUST indicate the human + language of the description using the xml:lang attribute and SHOULD + consider the HTTP Accept-Language request header when selecting one + of multiple available languages. + + + +9.5.1 Example: DAV:principal-search-property-set REPORT + + In this example, the client determines the set of searchable + principal properties by requesting the DAV:principal-search-property- + set REPORT on the root of the serverÆs principal URL collection set, + identified by http://www.BigCorp.com/users/. + + >> Request << + + REPORT /users/ HTTP/1.1 + Host: www.BigCorp.com + Content-Type: text/xml; charset="utf-8" + Content-Length: xxx + Accept-Language: en, de + Authorization: BASIC d2FubmFtYWs6cGFzc3dvcmQ= + + + + + >> Response << + + HTTP/1.1 200 OK + Content-Type: text/xml; charset="utf-8" + Content-Length: xxx + + + + + + + + Full name + + + + + +Clemm, Hopkins, Sedlar, Whitehead [Page 50] + + Job title + + + 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]. + Implementations of this specification MUST support the XML element + ignore rule, as specified in Section 23.3.2 of [RFC2518], and the XML + Namespace Recommendation [REC-XML-NAMES]. + + Note that use of the DAV namespace is reserved for XML elements and + property names defined in a standards-track or Experimental IETF RFC. 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. + 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. Furthermore, this + specification requires server implementations to tag description + fields with the xml:lang attribute (see Section 2.12 of [REC-XML]), + which specifies the human language of the description. Additionally, + server implementations should take into account the value of the + Accept-Language HTTP header to determine which description string to + return. - 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 + 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. - 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, - 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. +Clemm, Hopkins, Sedlar, Whitehead [Page 51] + 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]. + Further internationalization considerations for this protocol are + described in the WebDAV Distributed Authoring protocol specification + [RFC2518]. 12 SECURITY CONSIDERATIONS - 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. + 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. 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. 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 + 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. - 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. + To reduce this risk, read-acl privileges should not be granted to + unauthenticated principals, and restrictions on read-acl and read- - 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 - 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 - environment. +Clemm, Hopkins, Sedlar, Whitehead [Page 52] + current-user-privilege-set 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 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 environment. 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. + 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. + 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. + 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]. + Authentication mechanisms defined for use with HTTP and WebDAV also + apply to this WebDAV Access Control Protocol, in particular the Basic + and Digest authentication mechanisms defined in [RFC2617]. - 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. + elements. All other IANA considerations mentioned in [RFC2518] also + applicable to WebDAV ACL. + +Clemm, Hopkins, Sedlar, Whitehead [Page 53] 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. + 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. + 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. - 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 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. 16 ACKNOWLEDGEMENTS - 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. + 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, Joe Orton, Stefan Eissing, Julian + Reschke, Keith Wannamaker, Tim Ellison, and Dylan Barrell. We thank + Keith Wannamaker for the initial text of the principal property + search sections. 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 DeltaV, WebDAV and HTTP protocols + upon which this protocol is layered, and the invaluable feedback from + the WebDAV working group. + +Clemm, Hopkins, Sedlar, Whitehead [Page 54] - Clemm, Hopkins, Sedlar, Whitehead [Page 42] 17 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.http://www.w3.org/TR/REC-xml - [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. + [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, ôName Spaces in + XML" World Wide Web Consortium Recommendation REC-xml-names. + http://www.w3.org/TR/REC-xml-names/ - [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. + [RFCxxxx] G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead, + "Versioning Extensions to WebDAV." RFC xxxx. Rational, IBM, + Microsoft, U.C. Santa Cruz, 2001. - [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, + [REC-XML-INFOSET] J. Cowan, R. Tobin, "XML Information Set." World + Wide Web Consortium Recommendation REC-xml-infoset. + http://www.w3.org/TR/xml-infoset/ + + [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. + [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. + [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 Ventures, + January, 2001. - [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. - [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 55] 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. + + [RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255. + Netscape, December, 1997. + + [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access + Protocol (v3)." RFC 2251. Critical Angle, Netscape, Isode, December, + 1997. + + [CaseMap] M. Davis, "Case Mappings", Unicode Technical Report #21, + 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 +Clemm, Hopkins, Sedlar, Whitehead [Page 56] + 19 APPENDICIES - 19.1 XML Document Type Definition +19.1 WebDAV XML Document Type Definition Addendum + + All XML elements defined in this Document Type Definition (DTD) + belong to the DAV namespace. This DTD should be viewed as an addendum + to the DTD provided in [RFC2518], section 23.1. - + - + + - Clemm, Hopkins, Sedlar, Whitehead [Page 44] +Clemm, Hopkins, Sedlar, Whitehead [Page 57] - + @@ -2434,67 +2905,74 @@ - - + - - Clemm, Hopkins, Sedlar, Whitehead [Page 45] + +Clemm, Hopkins, Sedlar, Whitehead [Page 58] + (all? | authenticated? | unauthenticated? | self? | href* + |property*)> - + 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 + 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. +20 NOTE TO RFC EDITOR - If draft-ietf-deltav-versioning is published as an RFC before - this specification, Section 9.1 MUST be removed. + As of the writing of this specification, the DeltaV protocol, + described in draft-ietf-deltav-versioning-20, has been approved by + the IESG, but not yet published as an RFC. Within this specification, + the DeltaV protocol is referenced as [RFCxxxx]. These references need + to be replaced with the actual RFC number. As well, the citation in + Section 17.1 also needs to be updated with the correct RFC number, + and the month of issue. - Clemm, Hopkins, Sedlar, Whitehead [Page 46] +Clemm, Hopkins, Sedlar, Whitehead [Page 59]