idnits 2.17.1 draft-ietf-webdav-acl-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 706 has weird spacing: '... This prope...' == Line 2461 has weird spacing: '...contain a DAV...' == Line 2658 has weird spacing: '...MUST be a DAV...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 23, 2003) is 7430 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CaseMap' is mentioned on line 3495, but not defined == Missing Reference: 'UTF-8' is mentioned on line 3511, but not defined == Missing Reference: 'RFC2279' is mentioned on line 3512, but not defined ** Obsolete undefined reference: RFC 2279 (Obsoleted by RFC 3629) == Unused Reference: 'RFC2026' is defined on line 2940, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-XML-INFOSET' -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-XML-NAMES' ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2255 (Obsoleted by RFC 4510, RFC 4516) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Clemm 3 Internet-Draft IBM 4 Expires: June 22, 2004 J. Reschke 5 greenbytes 6 E. Sedlar 7 Oracle Corporation 8 J. Whitehead 9 U.C. Santa Cruz 10 December 23, 2003 12 WebDAV Access Control Protocol 13 draft-ietf-webdav-acl-13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 22, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This document specifies a set of methods, headers, message bodies, 44 properties, and reports that define Access Control extensions to the 45 WebDAV Distributed Authoring Protocol. This protocol permits a client 46 to read and modify access control lists that instruct a server 47 whether to allow or deny operations upon a resource (such as 48 HyperText Transfer Protocol (HTTP) method invocations) by a given 49 principal. A lightweight representation of principals as Web 50 resources supports integration of a wide range of user management 51 repositories. Search operations allow discovery and manipulation of 52 principals using human names. 54 This document is a product of the Web Distributed Authoring and 55 Versioning (WebDAV) working group of the Internet Engineering Task 56 Force. Comments on this draft are welcomed, and should be addressed 57 to the acl@webdav.org [1] mailing list. Other related documents can 58 be found at [2], and [3]. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.1 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1.2 Notational Conventions . . . . . . . . . . . . . . . . . . . 8 65 2. Principals . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3. Privileges . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1 DAV:read Privilege . . . . . . . . . . . . . . . . . . . . . 10 68 3.2 DAV:write Privilege . . . . . . . . . . . . . . . . . . . . 11 69 3.3 DAV:write-properties Privilege . . . . . . . . . . . . . . . 11 70 3.4 DAV:write-content Privilege . . . . . . . . . . . . . . . . 11 71 3.5 DAV:unlock Privilege . . . . . . . . . . . . . . . . . . . . 12 72 3.6 DAV:read-acl Privilege . . . . . . . . . . . . . . . . . . . 12 73 3.7 DAV:read-current-user-privilege-set Privilege . . . . . . . 12 74 3.8 DAV:write-acl Privilege . . . . . . . . . . . . . . . . . . 13 75 3.9 DAV:bind Privilege . . . . . . . . . . . . . . . . . . . . . 13 76 3.10 DAV:unbind Privilege . . . . . . . . . . . . . . . . . . . . 13 77 3.11 DAV:all Privilege . . . . . . . . . . . . . . . . . . . . . 13 78 3.12 Aggregation of Predefined Privileges . . . . . . . . . . . . 13 79 4. Principal Properties . . . . . . . . . . . . . . . . . . . . 14 80 4.1 DAV:alternate-URI-set . . . . . . . . . . . . . . . . . . . 14 81 4.2 DAV:principal-URL . . . . . . . . . . . . . . . . . . . . . 15 82 4.3 DAV:group-member-set . . . . . . . . . . . . . . . . . . . . 15 83 4.4 DAV:group-membership . . . . . . . . . . . . . . . . . . . . 15 84 5. Access Control Properties . . . . . . . . . . . . . . . . . 15 85 5.1 DAV:owner . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 5.1.1 Example: Retrieving DAV:owner . . . . . . . . . . . . . . . 16 87 5.1.2 Example: An Attempt to Set DAV:owner . . . . . . . . . . . . 17 88 5.2 DAV:group . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 5.3 DAV:supported-privilege-set . . . . . . . . . . . . . . . . 19 90 5.3.1 Example: Retrieving a List of Privileges Supported on a 91 Resource . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 5.4 DAV:current-user-privilege-set . . . . . . . . . . . . . . . 22 93 5.4.1 Example: Retrieving the User's Current Set of Assigned 94 Privileges . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 5.5 DAV:acl . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 5.5.1 ACE Principal . . . . . . . . . . . . . . . . . . . . . . . 24 97 5.5.2 ACE Grant and Deny . . . . . . . . . . . . . . . . . . . . . 26 98 5.5.3 ACE Protection . . . . . . . . . . . . . . . . . . . . . . . 26 99 5.5.4 ACE Inheritance . . . . . . . . . . . . . . . . . . . . . . 26 100 5.5.5 Example: Retrieving a Resource's Access Control List . . . . 26 101 5.6 DAV:acl-restrictions . . . . . . . . . . . . . . . . . . . . 28 102 5.6.1 DAV:grant-only . . . . . . . . . . . . . . . . . . . . . . . 29 103 5.6.2 DAV:no-invert ACE Constraint . . . . . . . . . . . . . . . . 29 104 5.6.3 DAV:deny-before-grant . . . . . . . . . . . . . . . . . . . 29 105 5.6.4 Required Principals . . . . . . . . . . . . . . . . . . . . 29 106 5.6.5 Example: Retrieving DAV:acl-restrictions . . . . . . . . . . 30 107 5.7 DAV:inherited-acl-set . . . . . . . . . . . . . . . . . . . 31 108 5.8 DAV:principal-collection-set . . . . . . . . . . . . . . . . 31 109 5.8.1 Example: Retrieving DAV:principal-collection-set . . . . . . 32 110 5.9 Example: PROPFIND to retrieve access control properties . . 33 111 6. ACL Evaluation . . . . . . . . . . . . . . . . . . . . . . . 37 112 7. Access Control and existing methods . . . . . . . . . . . . 39 113 7.1 Any HTTP method . . . . . . . . . . . . . . . . . . . . . . 39 114 7.1.1 Error Handling . . . . . . . . . . . . . . . . . . . . . . . 39 115 7.2 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . 40 116 7.2.1 Example - OPTIONS . . . . . . . . . . . . . . . . . . . . . 40 117 7.3 MOVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 118 7.4 COPY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 119 7.5 LOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 120 8. Access Control Methods . . . . . . . . . . . . . . . . . . . 41 121 8.1 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 122 8.1.1 ACL Preconditions . . . . . . . . . . . . . . . . . . . . . 42 123 8.1.2 Example: the ACL method . . . . . . . . . . . . . . . . . . 44 124 8.1.3 Example: ACL method failure due to protected ACE conflict . 45 125 8.1.4 Example: ACL method failure due to an inherited ACE 126 conflict . . . . . . . . . . . . . . . . . . . . . . . . . . 46 127 8.1.5 Example: ACL method failure due to an attempt to set 128 grant and deny in a single ACE . . . . . . . . . . . . . . . 47 129 9. Access Control Reports . . . . . . . . . . . . . . . . . . . 48 130 9.1 REPORT Method . . . . . . . . . . . . . . . . . . . . . . . 48 131 9.2 DAV:acl-principal-prop-set Report . . . . . . . . . . . . . 49 132 9.2.1 Example: DAV:acl-principal-prop-set Report . . . . . . . . . 50 133 9.3 DAV:principal-match REPORT . . . . . . . . . . . . . . . . . 51 134 9.3.1 Example: DAV:principal-match REPORT . . . . . . . . . . . . 52 135 9.4 DAV:principal-property-search REPORT . . . . . . . . . . . . 53 136 9.4.1 Matching . . . . . . . . . . . . . . . . . . . . . . . . . . 56 137 9.4.2 Example: successful DAV:principal-property-search REPORT . . 56 138 9.5 DAV:principal-search-property-set REPORT . . . . . . . . . . 58 139 9.5.1 Example: DAV:principal-search-property-set REPORT . . . . . 60 140 10. XML Processing . . . . . . . . . . . . . . . . . . . . . . . 61 141 11. Internationalization Considerations . . . . . . . . . . . . 61 142 12. Security Considerations . . . . . . . . . . . . . . . . . . 62 143 12.1 Increased Risk of Compromised Users . . . . . . . . . . . . 62 144 12.2 Risks of the DAV:read-acl and 145 DAV:current-user-privilege-set Privileges . . . . . . . . . 63 147 12.3 No Foreknowledge of Initial ACL . . . . . . . . . . . . . . 63 148 13. Authentication . . . . . . . . . . . . . . . . . . . . . . . 64 149 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 64 150 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 151 Normative References . . . . . . . . . . . . . . . . . . . . 64 152 Informative References . . . . . . . . . . . . . . . . . . . 65 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 66 154 A. WebDAV XML Document Type Definition Addendum . . . . . . . . 67 155 B. WebDAV Method Privilege Table (Normative) . . . . . . . . . 70 156 C. Resolved issues (to be removed by RFC Editor before 157 publication) . . . . . . . . . . . . . . . . . . . . . . . . 71 158 C.1 ED_references_names . . . . . . . . . . . . . . . . . . . . 72 159 C.2 ED_RFC2386 . . . . . . . . . . . . . . . . . . . . . . . . . 72 160 C.3 ED_example_host_names . . . . . . . . . . . . . . . . . . . 72 161 C.4 ED_authors_list . . . . . . . . . . . . . . . . . . . . . . 72 162 C.5 ED_non_ASCII . . . . . . . . . . . . . . . . . . . . . . . . 73 163 C.6 ED_artwork_line_width . . . . . . . . . . . . . . . . . . . 73 164 C.7 ED_xml_typos . . . . . . . . . . . . . . . . . . . . . . . . 73 165 C.8 1_ref_options . . . . . . . . . . . . . . . . . . . . . . . 73 166 C.9 3.2_ED_RFC2518 . . . . . . . . . . . . . . . . . . . . . . . 74 167 C.10 3.3_ED_priv_section_titles . . . . . . . . . . . . . . . . . 74 168 C.11 3.4_write-content-description . . . . . . . . . . . . . . . 74 169 C.12 3.12_ED_bad_reference . . . . . . . . . . . . . . . . . . . 75 170 C.13 4.1_ED_RFC2589 . . . . . . . . . . . . . . . . . . . . . . . 75 171 C.14 5.1_owner_group_details . . . . . . . . . . . . . . . . . . 75 172 C.15 5.1_owner_href_optional . . . . . . . . . . . . . . . . . . 76 173 C.16 5.1.2_responsedescription . . . . . . . . . . . . . . . . . 76 174 C.17 5.5.5_ED_section_numbering . . . . . . . . . . . . . . . . . 76 175 C.18 5.8_unbind . . . . . . . . . . . . . . . . . . . . . . . . . 76 176 C.19 6_ED_RFC3010 . . . . . . . . . . . . . . . . . . . . . . . . 77 177 C.20 6_group_property . . . . . . . . . . . . . . . . . . . . . . 77 178 C.21 5.5.2_TYPO . . . . . . . . . . . . . . . . . . . . . . . . . 77 179 C.22 9.4_ED_reference_casemap . . . . . . . . . . . . . . . . . . 78 180 C.23 11_ED_RFC2279 . . . . . . . . . . . . . . . . . . . . . . . 78 181 C.24 A_ED_appendices . . . . . . . . . . . . . . . . . . . . . . 78 182 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 183 Intellectual Property and Copyright Statements . . . . . . . 82 185 1. Introduction 187 The goal of the WebDAV access control extensions is to provide an 188 interoperable mechanism for handling discretionary access control for 189 content and metadata managed by WebDAV servers. WebDAV access 190 control can be implemented on content repositories with security as 191 simple as that of a UNIX file system, as well as more sophisticated 192 models. The underlying principle of access control is that who you 193 are determines what operations you can perform on a resource. The 194 "who you are" is defined by a "principal" identifier; users, client 195 software, servers, and groups of the previous have principal 196 identifiers. The "operations you can perform" are determined by a 197 single "access control list" (ACL) associated with a resource. An 198 ACL contains a set of "access control entries" (ACEs), where each ACE 199 specifies a principal and a set of privileges that are either granted 200 or denied to that principal. When a principal submits an operation 201 (such as an HTTP or WebDAV method) to a resource for execution, the 202 server evaluates the ACEs in the ACL to determine if the principal 203 has permission for that operation. 205 Since every ACE contains the identifier of a principal, client 206 software operated by a human must provide a mechanism for selecting 207 this principal. This specification uses http(s) scheme URLs to 208 identify principals, which are represented as WebDAV-capable 209 resources. There is no guarantee that the URLs identifying principals 210 will be meaningful to a human. For example, http://www.example.com/u/ 211 256432 and http://www.example.com/people/Greg.Stein are both valid 212 URLs that could be used to identify the same principal. To remedy 213 this, every principal resource has the DAV:displayname property 214 containing a human-readable name for the principal. 216 Since a principal can be identified by multiple URLs, it raises the 217 problem of determining exactly which principal is being referenced in 218 a given ACE. It is impossible for a client to determine that an ACE 219 granting the read privilege to http://www.example.com/people/ 220 Greg.Stein also affects the principal at http://www.example.com/u/ 221 256432. That is, a client has no mechanism for determining that two 222 URLs identify the same principal resource. As a result, this 223 specification requires clients to use just one of the many possible 224 URLs for a principal when creating ACEs. A client can discover which 225 URL to use by retrieving the DAV:principal-URL property (Section 4.2) 226 from a principal resource. No matter which of the principal's URLs is 227 used with PROPFIND, the property always returns the same URL. 229 With a system having hundreds to thousands of principals, the problem 230 arises of how to allow a human operator of client software to select 231 just one of these principals. One approach is to use broad collection 232 hierarchies to spread the principals over a large number of 233 collections, yielding few principals per collection. An example of 234 this is a two level hierarchy with the first level containing 36 235 collections (a-z, 0-9), and the second level being another 36, 236 creating collections /a/a/, /a/b/, ..., /a/z/, such that a principal 237 with last name "Stein" would appear at /s/t/Stein. In effect, this 238 pre-computes a common query, search on last name, and encodes it into 239 a hierarchy. The drawback with this scheme is that it handles only a 240 small set of predefined queries, and drilling down through the 241 collection hierarchy adds unnecessary steps (navigate down/up) when 242 the user already knows the principal's name. While organizing 243 principal URLs into a hierarchy is a valid namespace organization, 244 users should not be forced to navigate this hierarchy to select a 245 principal. 247 This specification provides the capability to perform substring 248 searches over a small set of properties on the resources representing 249 principals. This permits searches based on last name, first name, 250 user name, job title, etc. Two separate searches are supported, both 251 via the REPORT method, one to search principal resources 252 (DAV:principal-property-search, Section 9.4), the other to determine 253 which properties may be searched at all 254 (DAV:principal-search-property-set, Section 9.5). 256 Once a principal has been identified in an ACE, a server evaluating 257 that ACE must know the identity of the principal making a protocol 258 request, and must validate that that principal is who they claim to 259 be, a process known as authentication. This specification 260 intentionally omits discussion of authentication, as the HTTP 261 protocol already has a number of authentication mechanisms [RFC2617]. 262 Some authentication mechanism (such as HTTP Digest Authentication, 263 which all WebDAV compliant implementations are required to support) 264 must be available to validate the identity of a principal. 266 The following issues are out of scope for this document: 268 o Access control that applies only to a particular property on a 269 resource (excepting the access control properties DAV:acl and 270 DAV:current-user-privilege-set), rather than the entire resource, 272 o Role-based security (where a role can be seen as a dynamically 273 defined group of principals), 275 o Specification of the ways an ACL on a resource is initialized, 277 o Specification of an ACL that applies globally to all resources, 278 rather than to a particular resource. 280 o Creation and maintenance of resources representing people or 281 computational agents (principals), and groups of these. 283 This specification is organized as follows. Section 1.1 defines key 284 concepts used throughout the specification, and is followed by a more 285 in-depth discussion of principals (Section 2), and privileges 286 (Section 3). Properties defined on principals are specified in 287 Section 4, and access control properties for content resources are 288 specified in Section 5. The ways ACLs are to be evaluated is 289 described in Section 6. Client discovery of access control capability 290 using OPTIONS is described in Section 7.2. Interactions between 291 access control functionality and existing HTTP and WebDAV methods are 292 described in the remainder of Section 7. The access control setting 293 method, ACL, is specified in Section 8. Four reports that provide 294 limited server-side searching capabilities are described in Section 295 9. Sections on XML processing (Section 10), Internationalization 296 considerations (Section 11), security considerations (Section 12), 297 and authentication (Section 13) round out the specification. An 298 appendix (Appendix A) provides an XML Document Type Definition (DTD) 299 for the XML elements defined in the specification. 301 1.1 Terms 303 This draft uses the terms defined in HTTP [RFC2616] and WebDAV 304 [RFC2518]. In addition, the following terms are defined: 306 principal 308 A "principal" is a distinct human or computational actor that 309 initiates access to network resources. In this protocol, a 310 principal is an HTTP resource that represents such an actor. 312 group 314 A "group" is a principal that represents a set of other 315 principals. 317 privilege 319 A "privilege" controls access to a particular set of HTTP 320 operations on a resource. 322 aggregate privilege 324 An "aggregate privilege" is a privilege that contains a set of 325 other privileges. 327 abstract privilege 328 The modifier "abstract", when applied to a privilege on a 329 resource, means the privilege cannot be set in an access control 330 element (ACE) on that resource. 332 access control list (ACL) 334 An "ACL" is a list of access control elements that define access 335 control to a particular resource. 337 access control element (ACE) 339 An "ACE" either grants or denies a particular set of 340 (non-abstract) privileges for a particular principal. 342 inherited ACE 344 An "inherited ACE" is an ACE that is dynamically shared from the 345 ACL of another resource. When a shared ACE changes on the primary 346 resource, it is also changed on inheriting resources. 348 protected property 350 A "protected property" is one whose value cannot be updated except 351 by a method explicitly defined as updating that specific property. 352 In particular, a protected property cannot be updated with a 353 PROPPATCH request. 355 1.2 Notational Conventions 357 The augmented BNF used by this document to describe protocol elements 358 is described in Section 2.1 of [RFC2616]. Because this augmented BNF 359 uses the basic production rules provided in Section 2.2 of [RFC2616], 360 those rules apply to this document as well. 362 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 363 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 364 document are to be interpreted as described in [RFC2119]. 366 Definitions of XML elements in this document use XML element type 367 declarations (as found in XML Document Type Declarations), described 368 in Section 3.2 of [REC-XML]. When an XML element type in the "DAV:" 369 namespace is referenced in this document outside of the context of an 370 XML fragment, the string "DAV:" will be prefixed to the element name. 372 2. Principals 374 A principal is a network resource that represents a distinct human or 375 computational actor that initiates access to network resources. Users 376 and groups are represented as principals in many implementations; 377 other types of principals are also possible. A URI of any scheme MAY 378 be used to identify a principal resource. However, servers 379 implementing this specification MUST expose principal resources at an 380 http(s) URL, which is a privileged scheme that points to resources 381 that have additional properties, as described in Section 4. So, a 382 principal resource can have multiple URIs, one of which has to be an 383 http(s) scheme URL. Although an implementation SHOULD support 384 PROPFIND and MAY support PROPPATCH to access and modify information 385 about a principal, it is not required to do so. 387 A principal resource may be a group, where a group is a principal 388 that represents a set of other principals, called the members of the 389 group. If a person or computational agent matches a principal 390 resource that is a member of a group, they also match the group. 391 Membership in a group is recursive, so if a principal is a member of 392 group GRPA, and GRPA is a member of group GRPB, then the principal is 393 also a member of GRPB. 395 3. Privileges 397 Ability to perform a given method on a resource MUST be controlled by 398 one or more privileges. Authors of protocol extensions that define 399 new HTTP methods SHOULD specify which privileges (by defining new 400 privileges, or mapping to ones below) are required to perform the 401 method. A principal with no privileges to a resource MUST be denied 402 any HTTP access to that resource, unless the principal matches an ACE 403 constructed using the DAV:all, DAV:authenticated, or 404 DAV:unauthenticated pseudo-principals (see Section 5.5.1). Servers 405 MUST report a 403 "Forbidden" error if access is denied, except in 406 the case where the privilege restricts the ability to know the 407 resource exists, in which case 404 "Not Found" may be returned. 409 Privileges may be containers of other privileges, in which case they 410 are termed "aggregate privileges". If a principal is granted or 411 denied an aggregate privilege, it is semantically equivalent to 412 granting or denying each of the aggregated privileges individually. 413 For example, an implementation may define add-member and 414 remove-member privileges that control the ability to add and remove a 415 member of a group. Since these privileges control the ability to 416 update the state of a group, these privileges would be aggregated by 417 the DAV:write privilege on a group, and granting the DAV:write 418 privilege on a group would also grant the add-member and 419 remove-member privileges. 421 Privileges may be declared to be "abstract" for a given resource, in 422 which case they cannot be set in an ACE on that resource. Aggregate 423 and non-aggregate privileges are both capable of being abstract. 424 Abstract privileges are useful for modeling privileges that otherwise 425 would not be exposed via the protocol. Abstract privileges also 426 provide server implementations with flexibility in implementing the 427 privileges defined in this specification. For example, if a server 428 is incapable of separating the read resource capability from the read 429 ACL capability, it can still model the DAV:read and DAV:read-acl 430 privileges defined in this specification by declaring them abstract, 431 and containing them within a non-abstract aggregate privilege (say, 432 read-all) that holds DAV:read, and DAV:read-acl. In this way, it is 433 possible to set the aggregate privilege, read-all, thus coupling the 434 setting of DAV:read and DAV:read-acl, but it is not possible to set 435 DAV:read, or DAV:read-acl individually. Since aggregate privileges 436 can be abstract, it is also possible to use abstract privileges to 437 group or organize non-abstract privileges. Privilege containment 438 loops are not allowed; therefore, a privilege MUST NOT contain 439 itself. For example, DAV:read cannot contain DAV:read. 441 The set of privileges that apply to a particular resource may vary 442 with the DAV:resourcetype of the resource, as well as between 443 different server implementations. To promote interoperability, 444 however, this specification defines a set of well-known privileges 445 (e.g. DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, 446 DAV:read-current-user-privilege-set, and DAV:all), which can at least 447 be used to classify the other privileges defined on a particular 448 resource. The access permissions on null resources (defined in 449 [RFC2518], Section 3) are solely those they inherit (if any), and 450 they are not discoverable (i.e., the access control properties 451 specified in Section 5 are not defined on null resources). On the 452 transition from null to stateful resource, the initial access control 453 list is set by the server's default ACL value policy (if any). 455 Server implementations MAY define new privileges beyond those defined 456 in this specification. Privileges defined by individual 457 implementations MUST NOT use the DAV: namespace, and instead should 458 use a namespace that they control, such as an http scheme URL. 460 3.1 DAV:read Privilege 462 The read privilege controls methods that return information about the 463 state of the resource, including the resource's properties. Affected 464 methods include GET and PROPFIND. Any implementation-defined 465 privilege that also controls access to GET and PROPFIND must be 466 aggregated under DAV:read - if an ACL grants access to DAV:read, the 467 client may expect that no other privilege needs to be granted to have 468 access to GET and PROPFIND. Additionally, the read privilege MUST 469 control the OPTIONS method. 471 473 3.2 DAV:write Privilege 475 The write privilege controls methods that lock a resource or modify 476 the content, dead properties, or (in the case of a collection) 477 membership of the resource, such as PUT and PROPPATCH. Note that 478 state modification is also controlled via locking (see section 5.3 of 479 [RFC2518]), so effective write access requires that both write 480 privileges and write locking requirements are satisfied. Any 481 implementation-defined privilege that also controls access to methods 482 modifying content, dead properties or collection membership must be 483 aggregated under DAV:write, e.g. if an ACL grants access to 484 DAV:write, the client may expect that no other privilege needs to be 485 granted to have access to PUT and PROPPATCH. 487 489 3.3 DAV:write-properties Privilege 491 The DAV:write-properties privilege controls methods that modify the 492 dead properties of the resource, such as PROPPATCH. Whether this 493 privilege may be used to control access to any live properties is 494 determined by the implementation. Any implementation-defined 495 privilege that also controls access to methods modifying dead 496 properties must be aggregated under DAV:write-properties - e.g. if an 497 ACL grants access to DAV:write-properties, the client can safely 498 expect that no other privilege needs to be granted to have access to 499 PROPPATCH. 501 503 3.4 DAV:write-content Privilege 505 The DAV:write-content privilege controls methods that modify the 506 content of an existing resource, such as PUT. Any 507 implementation-defined privilege that also controls access to content 508 must be aggregated under DAV:write-content - e.g. if an ACL grants 509 access to DAV:write-content, the client can safely expect that no 510 other privilege needs to be granted to have access to PUT. Note that 511 PUT - when applied to an unmapped URI - creates a new resource and 512 therefore is controlled by the DAV:bind privilege on the parent 513 collection. 515 517 3.5 DAV:unlock Privilege 519 The DAV:unlock privilege controls the use of the UNLOCK method by a 520 principal other than the lock owner (the principal that created a 521 lock can always perform an UNLOCK). While the set of users who may 522 lock a resource is most commonly the same set of users who may modify 523 a resource, servers may allow various kinds of administrators to 524 unlock resources locked by others. Any privilege controlling access 525 by non-lock owners to UNLOCK MUST be aggregated under DAV:unlock. 527 A lock owner can always remove a lock by issuing an UNLOCK with the 528 correct lock token and authentication credentials. That is, even if a 529 principal does not have DAV:unlock privilege, they can still remove 530 locks they own. Principals other than the lock owner can remove a 531 lock only if they have DAV:unlock privilege and they issue an UNLOCK 532 with the correct lock token. Lock timeout is not affected by the 533 DAV:unlock privilege. 535 537 3.6 DAV:read-acl Privilege 539 The DAV:read-acl privilege controls the use of PROPFIND to retrieve 540 the DAV:acl property of the resource. 542 544 3.7 DAV:read-current-user-privilege-set Privilege 546 The DAV:read-current-user-privilege-set privilege controls the use of 547 PROPFIND to retrieve the DAV:current-user-privilege-set property of 548 the resource. 550 Clients are intended to use this property to visually indicate in 551 their UI items that are dependent on the permissions of a resource, 552 for example, by graying out resources that are not writeable. 554 This privilege is separate from DAV:read-acl because there is a need 555 to allow most users access to the privileges permitted the current 556 user (due to its use in creating the UI), while the full ACL contains 557 information that may not be appropriate for the current authenticated 558 user. As a result, the set of users who can view the full ACL is 559 expected to be much smaller than those who can read the current user 560 privilege set, and hence distinct privileges are needed for each. 562 564 3.8 DAV:write-acl Privilege 566 The DAV:write-acl privilege controls use of the ACL method to modify 567 the DAV:acl property of the resource. 569 571 3.9 DAV:bind Privilege 573 The DAV:bind privilege allows a method to add a new member URL to the 574 specified collection (for example via PUT or MKCOL). It is ignored 575 for resources that are not collections. 577 579 3.10 DAV:unbind Privilege 581 The DAV:unbind privilege allows a method to remove a member URL from 582 the specified collection (for example via DELETE or MOVE). It is 583 ignored for resources that are not collections. 585 587 3.11 DAV:all Privilege 589 DAV:all is an aggregate privilege that contains the entire set of 590 privileges that can be applied to the resource. 592 594 3.12 Aggregation of Predefined Privileges 596 Server implementations are free to aggregate the predefined 597 privileges (defined above in Sections 3.1-3.10) subject to the 598 following limitations: 600 DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-acl, 601 DAV:write-properties, DAV:write-content, or 602 DAV:read-current-user-privilege-set. 604 DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-acl, or 605 DAV:read-current-user-privilege-set. 607 DAV:read-current-user-privilege-set MUST NOT contain DAV:write, 608 DAV:read, DAV:read-acl, or DAV:write-acl. 610 DAV:write MUST NOT contain DAV:read, DAV:read-acl, or 611 DAV:read-current-user-privilege-set. 613 DAV:read MUST NOT contain DAV:write, DAV:write-acl, 614 DAV:write-properties, or DAV:write-content. 616 DAV:write MUST contain DAV:bind, DAV:unbind, DAV:write-properties and 617 DAV:write-content. 619 4. Principal Properties 621 Principals are manifested to clients as a WebDAV resource, identified 622 by a URL. A principal MUST have a non-empty DAV:displayname property 623 (defined in Section 13.2 of [RFC2518]), and a DAV:resourcetype 624 property (defined in Section 13.9 of [RFC2518]). Additionally, a 625 principal MUST report the DAV:principal XML element in the value of 626 the DAV:resourcetype property. The element type declaration for 627 DAV:principal is: 629 631 This protocol defines the following additional properties for a 632 principal. Since it can be expensive for a server to retrieve access 633 control information, the name and value of these properties SHOULD 634 NOT be returned by a PROPFIND allprop request (as defined in Section 635 12.14.1 of [RFC2518]). 637 4.1 DAV:alternate-URI-set 639 This protected property, if non-empty, contains the URIs of network 640 resources with additional descriptive information about the 641 principal. This property identifies additional network resources 642 (i.e., it contains one or more URIs) that may be consulted by a 643 client to gain additional knowledge concerning a principal. One 644 expected use for this property is the storage of an LDAP [RFC2255] 645 scheme URL. A user-agent encountering an LDAP URL could use LDAP 646 [RFC2251] to retrieve additional machine-readable directory 647 information about the principal, and display that information in its 648 user interface. Support for this property is REQUIRED, and the value 649 is empty if no alternate URI exists for the principal. 651 653 4.2 DAV:principal-URL 655 A principal may have many URLs, but there must be one "principal URL" 656 that clients can use to uniquely identify a principal. This 657 protected property contains the URL that MUST be used to identify 658 this principal in an ACL request. Support for this property is 659 REQUIRED. 661 663 4.3 DAV:group-member-set 665 This property of a group principal identifies the principals that are 666 direct members of this group. Since a group may be a member of 667 another group, a group may also have indirect members (i.e. the 668 members of its direct members). A URL in the DAV:group-member-set 669 for a principal MUST be the DAV:principal-URL of that principal. 671 673 4.4 DAV:group-membership 675 This protected property identifies the groups in which the principal 676 is directly a member. Note that a server may allow a group to be a 677 member of another group, in which case the DAV:group-membership of 678 those other groups would need to be queried in order to determine the 679 groups in which the principal is indirectly a member. Support for 680 this property is REQUIRED. 682 684 5. Access Control Properties 686 This specification defines a number of new properties for WebDAV 687 resources. Access control properties may be retrieved just like 688 other WebDAV properties, using the PROPFIND method. Since it is 689 expensive, for many servers, to retrieve access control information, 690 a PROPFIND allprop request (as defined in Section 12.14.1 of 691 [RFC2518]) SHOULD NOT return the names and values of the properties 692 defined in this section. 694 Access control properties (especially DAV:acl and 695 DAV:inherited-acl-set) are defined on the resource identified by the 696 Request-URI of a PROPFIND request. A direct consequence is that if 697 the resource is accessible via multiple URI, the value of access 698 control properties is the same across these URI. 700 HTTP resources that support the WebDAV Access Control Protocol MUST 701 contain the following properties. Null resources (described in 702 Section 3 of [RFC2518]) MUST NOT contain the following properties. 704 5.1 DAV:owner 706 This property identifies a particular principal as being the "owner" 707 of the resource. Since the owner of a resource often has special 708 access control capabilities (e.g., the owner frequently has permanent 709 DAV:write-acl privilege), clients might display the resource owner in 710 their user interface. 712 Servers MAY implement DAV:owner as protected property and MAY return 713 an empty DAV:owner element as property value in case no owner 714 information is available. 716 718 5.1.1 Example: Retrieving DAV:owner 720 This example shows a client request for the value of the DAV:owner 721 property from a collection resource with URL http://www.example.com/ 722 papers/. The principal making the request is authenticated using 723 Digest authentication. The value of DAV:owner is the URL http:// 724 www.example.com/acl/users/gstein, wrapped in the DAV:href XML 725 element. 727 >> Request << 729 PROPFIND /papers/ HTTP/1.1 730 Host: www.example.com 731 Content-type: text/xml; charset="utf-8" 732 Content-Length: xxx 733 Depth: 0 734 Authorization: Digest username="jim", 735 realm="users@example.com", nonce="...", 736 uri="/papers/", response="...", opaque="..." 738 739 740 741 742 743 744 >> Response << 746 HTTP/1.1 207 Multi-Status 747 Content-Type: text/xml; charset="utf-8" 748 Content-Length: xxx 750 751 752 753 http://www.example.com/papers/ 754 755 756 757 http://www.example.com/acl/users/gstein 758 759 760 HTTP/1.1 200 OK 761 762 763 765 5.1.2 Example: An Attempt to Set DAV:owner 767 The following example shows a client request to modify the value of 768 the DAV:owner property on the resource with URL . Since DAV:owner is a protected property on 770 this particular server, it responds with a 207 (Multi-Status) 771 response that contains a 403 (Forbidden) status code for the act of 772 setting DAV:owner. Section 8.2.1 of [RFC2518] describes PROPPATCH 773 status code information, Section 11 of [RFC2518] describes the 774 Multi-Status response and Sections 1.6 and 3.12 of [RFC3253] describe 775 additional error marshalling for PROPPATCH attempts on protected 776 properties. 778 >> Request << 780 PROPPATCH /papers/ HTTP/1.1 781 Host: www.example.com 782 Content-type: text/xml; charset="utf-8" 783 Content-Length: xxx 784 Depth: 0 785 Authorization: Digest username="jim", 786 realm="users@example.com", nonce="...", 787 uri="/papers/", response="...", opaque="..." 789 790 791 792 793 794 http://www.example.com/acl/users/jim 795 796 797 798 800 >> Response << 802 HTTP/1.1 207 Multi-Status 803 Content-Type: text/xml; charset="utf-8" 804 Content-Length: xxx 806 807 808 809 http://www.example.com/papers/ 810 811 812 HTTP/1.1 403 Forbidden 813 814 815 Failure to set protected property (DAV:owner) 816 817 818 819 821 5.2 DAV:group 823 This property identifies a particular principal as being the "group" 824 of the resource. This property is commonly found on repositories that 825 implement the Unix privileges model. 827 Servers MAY implement DAV:group as protected property and MAY return 828 an empty DAV:group element as property value in case no group 829 information is available. 831 833 5.3 DAV:supported-privilege-set 835 This is a protected property that identifies the privileges defined 836 for the resource. 838 840 Each privilege appears as an XML element, where aggregate privileges 841 list as sub-elements all of the privileges that they aggregate. 843 845 847 An abstract privilege MUST NOT be used in an ACE for that resource. 848 Servers MUST fail an attempt to set an abstract privilege. 850 852 A description is a human-readable description of what this privilege 853 controls access to. Servers MUST indicate the human language of the 854 description using the xml:lang attribute and SHOULD consider the HTTP 855 Accept-Language request header when selecting one of multiple 856 available languages. 858 860 It is envisioned that a WebDAV ACL-aware administrative client would 861 list the supported privileges in a dialog box, and allow the user to 862 choose non-abstract privileges to apply in an ACE. The privileges 863 tree is useful programmatically to map well-known privileges (defined 864 by WebDAV or other standards groups) into privileges that are 865 supported by any particular server implementation. The privilege 866 tree also serves to hide complexity in implementations allowing large 867 number of privileges to be defined by displaying aggregates to the 868 user. 870 5.3.1 Example: Retrieving a List of Privileges Supported on a Resource 872 This example shows a client request for the 873 DAV:supported-privilege-set property on the resource http:// 874 www.example.com/papers/. The value of the DAV:supported-privilege-set 875 property is a tree of supported privileges (using "[XML Namespace , 876 localname]" to identify each privilege): 878 [DAV:, all] (aggregate, abstract) 879 | 880 +-- [DAV:, read] (aggregate) 881 | 882 +-- [DAV:, read-acl] (abstract) 883 +-- [DAV:, read-current-user-privilege-set] (abstract) 884 | 885 +-- [DAV:, write] (aggregate) 886 | 887 +-- [DAV:, write-acl] (abstract) 888 +-- [DAV:, write-properties] 889 +-- [DAV:, write-content] 890 | 891 +-- [DAV:, unlock] 893 This privilege tree is not normative (except that it reflects the 894 normative aggregation rules given in Section 3.12), and many possible 895 privilege trees are possible. 897 >> Request << 899 PROPFIND /papers/ HTTP/1.1 900 Host: www.example.com 901 Content-type: text/xml; charset="utf-8" 902 Content-Length: xxx 903 Depth: 0 904 Authorization: Digest username="gclemm", 905 realm="users@example.com", nonce="...", 906 uri="/papers/", response="...", opaque="..." 908 909 910 911 912 913 915 >> Response << 917 HTTP/1.1 207 Multi-Status 918 Content-Type: text/xml; charset="utf-8" 919 Content-Length: xxx 921 922 923 924 http://www.example.com/papers/ 925 926 927 928 929 930 931 932 Any operation 933 934 935 936 937 Read any object 938 939 940 941 942 Read ACL 943 944 945 946 947 948 949 950 Read current user privilege set property 951 952 953 954 955 956 957 Write any object 958 959 960 961 962 Write ACL 963 964 965 966 967 968 969 Write properties 970 971 972 973 974 975 Write resource content 976 977 978 979 980 981 982 Unlock resource 983 984 985 986 987 988 HTTP/1.1 200 OK 989 990 991 993 5.4 DAV:current-user-privilege-set 995 DAV:current-user-privilege-set is a protected property containing the 996 exact set of privileges (as computed by the server) granted to the 997 currently authenticated HTTP user. Aggregate privileges and their 998 contained privileges are listed. A user-agent can use the value of 999 this property to adjust its user interface to make actions 1000 inaccessible (e.g., by graying out a menu item or button) for which 1001 the current principal does not have permission. This property is also 1002 useful for determining what operations the current principal can 1003 perform, without having to actually execute an operation. 1005 1006 1008 If the current user is granted a specific privilege, that privilege 1009 must belong to the set of privileges that may be set on this 1010 resource. Therefore, each element in the 1011 DAV:current-user-privilege-set property MUST identify a non-abstract 1012 privilege from the DAV:supported-privilege-set property. 1014 5.4.1 Example: Retrieving the User's Current Set of Assigned Privileges 1016 Continuing the example from Section 5.3.1, this example shows a 1017 client requesting the DAV:current-user-privilege-set property from 1018 the resource with URL http://www.example.com/papers/. The username of 1019 the principal making the request is "khare", and Digest 1020 authentication is used in the request. The principal with username 1021 "khare" has been granted the DAV:read privilege. Since the DAV:read 1022 privilege contains the DAV:read-acl and 1023 DAV:read-current-user-privilege-set privileges (see Section 5.3.1), 1024 the principal with username "khare" can read the ACL property, and 1025 the DAV:current-user-privilege-set property. However, the DAV:all, 1026 DAV:read-acl, DAV:write-acl and DAV:read-current-user-privilege-set 1027 privileges are not listed in the value of 1028 DAV:current-user-privilege-set, since (for this example) they are 1029 abstract privileges. DAV:write is not listed since the principal with 1030 username "khare" is not listed in an ACE granting that principal 1031 write permission. 1033 >> Request << 1035 PROPFIND /papers/ HTTP/1.1 1036 Host: www.example.com 1037 Content-type: text/xml; charset="utf-8" 1038 Content-Length: xxx 1039 Depth: 0 1040 Authorization: Digest username="khare", 1041 realm="users@example.com", nonce="...", 1042 uri="/papers/", response="...", opaque="..." 1044 1045 1046 1047 1048 1049 1050 >> Response << 1052 HTTP/1.1 207 Multi-Status 1053 Content-Type: text/xml; charset="utf-8" 1054 Content-Length: xxx 1056 1057 1058 1059 http://www.example.com/papers/ 1060 1061 1062 1063 1064 1065 1066 HTTP/1.1 200 OK 1067 1068 1069 1071 5.5 DAV:acl 1073 This is a protected property that specifies the list of access 1074 control entries (ACEs), which define what principals are to get what 1075 privileges for this resource. 1077 1079 Each DAV:ace element specifies the set of privileges to be either 1080 granted or denied to a single principal. If the DAV:acl property is 1081 empty, no principal is granted any privilege. 1083 1086 5.5.1 ACE Principal 1088 The DAV:principal element identifies the principal to which this ACE 1089 applies. 1091 1094 The current user matches DAV:href only if that user is authenticated 1095 as being (or being a member of) the principal identified by the URL 1096 contained by that DAV:href. 1098 The current user always matches DAV:all. 1100 1102 The current user matches DAV:authenticated only if authenticated. 1104 1106 The current user matches DAV:unauthenticated only if not 1107 authenticated. 1109 1111 DAV:all is the union of DAV:authenticated, and DAV:unauthenticated. 1112 For a given request, the user matches either DAV:authenticated, or 1113 DAV:unauthenticated, but not both (that is, DAV:authenticated and 1114 DAV:unauthenticated are disjoint sets). 1116 The current user matches a DAV:property principal in a DAV:acl 1117 property of a resource only if the value of the identified property 1118 of that resource contains at most one DAV:href XML element, the URI 1119 value of DAV:href identifies a principal, and the current user is 1120 authenticated as being (or being a member of) that principal. For 1121 example, if the DAV:property element contained , the 1122 current user would match the DAV:property principal only if the 1123 current user is authenticated as matching the principal identified by 1124 the DAV:owner property of the resource. 1126 1128 The current user matches DAV:self in a DAV:acl property of the 1129 resource only if that resource is a principal and that principal 1130 matches the current user or, if the principal is a group, a member of 1131 that group matches the current user. 1133 1135 Some servers may support ACEs applying to those users NOT matching 1136 the current principal, e.g. all users not in a particular group. 1137 This can be done by wrapping the DAV:principal element with 1138 DAV:invert. 1140 1142 5.5.2 ACE Grant and Deny 1144 Each DAV:grant or DAV:deny element specifies the set of privileges to 1145 be either granted or denied to the specified principal. A DAV:grant 1146 or DAV:deny element of the DAV:acl of a resource MUST only contain 1147 non-abstract elements specified in the DAV:supported-privilege-set of 1148 that resource. 1150 1151 1152 1154 5.5.3 ACE Protection 1156 A server indicates an ACE is protected by including the DAV:protected 1157 element in the ACE. If the ACL of a resource contains an ACE with a 1158 DAV:protected element, an attempt to remove that ACE from the ACL 1159 MUST fail. 1161 1163 5.5.4 ACE Inheritance 1165 The presence of a DAV:inherited element indicates that this ACE is 1166 inherited from another resource that is identified by the URL 1167 contained in a DAV:href element. An inherited ACE cannot be modified 1168 directly, but instead the ACL on the resource from which it is 1169 inherited must be modified. 1171 Note that ACE inheritance is not the same as ACL initialization. ACL 1172 initialization defines the ACL that a newly created resource will use 1173 (if not specified). ACE inheritance refers to an ACE that is 1174 logically shared - where an update to the resource containing an ACE 1175 will affect the ACE of each resource that inherits that ACE. The 1176 method by which ACLs are initialized or by which ACEs are inherited 1177 is not defined by this document. 1179 1181 5.5.5 Example: Retrieving a Resource's Access Control List 1183 Continuing the example from Sections 5.3.1 and 5.4.1, this example 1184 shows a client requesting the DAV:acl property from the resource with 1185 URL http://www.example.com/papers/. There are two ACEs defined in 1186 this ACL: 1188 ACE #1: The group identified by URL http://www.example.com/acl/ 1189 groups/maintainers (the group of site maintainers) is granted 1190 DAV:write privilege. Since (for this example) DAV:write contains the 1191 DAV:write-acl privilege (see Section 5.3.1), this means the 1192 "maintainers" group can also modify the access control list. 1194 ACE #2: All principals (DAV:all) are granted the DAV:read privilege. 1195 Since (for this example) DAV:read contains DAV:read-acl and 1196 DAV:read-current-user-privilege-set, this means all users (including 1197 all members of the "maintainers" group) can read the DAV:acl property 1198 and the DAV:current-user-privilege-set property. 1200 >> Request << 1202 PROPFIND /papers/ HTTP/1.1 1203 Host: www.example.com 1204 Content-type: text/xml; charset="utf-8" 1205 Content-Length: xxx 1206 Depth: 0 1207 Authorization: Digest username="masinter", 1208 realm="users@example.com", nonce="...", 1209 uri="/papers/", response="...", opaque="..." 1211 1212 1213 1214 1215 1216 >> Response << 1218 HTTP/1.1 207 Multi-Status 1219 Content-Type: text/xml; charset="utf-8" 1220 Content-Length: xxx 1222 1223 1224 http://www.example.com/papers/ 1225 1226 1227 1228 1229 1230 http://www.example.com/acl/groups/maintainers 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 HTTP/1.1 200 OK 1248 1249 1250 1252 5.6 DAV:acl-restrictions 1254 This protected property defines the types of ACLs supported by this 1255 server, to avoid clients needlessly getting errors. When a client 1256 tries to set an ACL via the ACL method, the server may reject the 1257 attempt to set the ACL as specified. The following properties 1258 indicate the restrictions the client must observe before setting an 1259 ACL: 1261 Deny ACEs are not supported 1263 Inverted ACEs are not supported 1265 All deny ACEs must occur before any grant ACEs 1267 Indicates which principals are required to be 1268 present 1270 1274 5.6.1 DAV:grant-only 1276 This element indicates that ACEs with deny clauses are not allowed. 1278 1280 5.6.2 DAV:no-invert ACE Constraint 1282 This element indicates that ACEs with the element are not 1283 allowed. 1285 1287 5.6.3 DAV:deny-before-grant 1289 This element indicates that all deny ACEs must precede all grant 1290 ACEs. 1292 1294 5.6.4 Required Principals 1296 The required principal elements identify which principals must have 1297 an ACE defined in the ACL. 1299 1303 For example, the following element requires that the ACL contain a 1304 DAV:owner property ACE: 1306 1307 1308 1310 5.6.5 Example: Retrieving DAV:acl-restrictions 1312 In this example, the client requests the value of the 1313 DAV:acl-restrictions property. Digest authentication provides 1314 credentials for the principal operating the client. 1316 >> Request << 1318 PROPFIND /papers/ HTTP/1.1 1319 Host: www.example.com 1320 Content-type: text/xml; charset="utf-8" 1321 Content-Length: xxx 1322 Depth: 0 1323 Authorization: Digest username="srcarter", 1324 realm="users@example.com", nonce="...", 1325 uri="/papers/", response="...", opaque="..." 1327 1328 1329 1330 1331 1332 1333 >> Response << 1335 HTTP/1.1 207 Multi-Status 1336 Content-Type: text/xml; charset="utf-8" 1337 Content-Length: xxx 1339 1340 1341 1342 http://www.example.com/papers/ 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 HTTP/1.1 200 OK 1353 1354 1355 1357 5.7 DAV:inherited-acl-set 1359 This protected property contains a set of URLs that identify other 1360 resources that also control the access to this resource. To have a 1361 privilege on a resource, not only must the ACL on that resource 1362 (specified in the DAV:acl property of that resource) grant the 1363 privilege, but so must the ACL of each resource identified in the 1364 DAV:inherited-acl-set property of that resource. Effectively, the 1365 privileges granted by the current ACL are ANDed with the privileges 1366 granted by each inherited ACL. 1368 1370 5.8 DAV:principal-collection-set 1372 This protected property of a resource contains a set of URLs that 1373 identify the root collections that contain the principals that are 1374 available on the server that implements this resource. A WebDAV 1375 Access Control Protocol user agent could use the contents of 1376 DAV:principal-collection-set to retrieve the DAV:displayname property 1377 (specified in Section 13.2 of [RFC2518]) of all principals on that 1378 server, thereby yielding human-readable names for each principal that 1379 could be displayed in a user interface. 1381 1383 Since different servers can control different parts of the URL 1384 namespace, different resources on the same host MAY have different 1385 DAV:principal-collection-set values. The collections specified in the 1386 DAV:principal-collection-set MAY be located on different hosts from 1387 the resource. The URLs in DAV:principal-collection-set SHOULD be http 1388 or https scheme URLs. For security and scalability reasons, a server 1389 MAY report only a subset of the entire set of known principal 1390 collections, and therefore clients should not assume they have 1391 retrieved an exhaustive listing. Additionally, a server MAY elect to 1392 report none of the principal collections it knows about, in which 1393 case the property value would be empty. 1395 The value of DAV:principal-collection-set gives the scope of the 1396 DAV:principal-property-search REPORT (defined in Section 9.4). 1397 Clients use the DAV:principal-property-search REPORT to populate 1398 their user interface with a list of principals. Therefore, servers 1399 that limit a client's ability to obtain principal information will 1400 interfere with the client's ability to manipulate access control 1401 lists, due to the difficulty of getting the URL of a principal for 1402 use in an ACE. 1404 5.8.1 Example: Retrieving DAV:principal-collection-set 1406 In this example, the client requests the value of the 1407 DAV:principal-collection-set property on the collection resource 1408 identified by URL http://www.example.com/papers/. The property 1409 contains the two URLs, http://www.example.com/acl/users/ and http:// 1410 www.example.com/acl/groups/, both wrapped in DAV:href XML elements. 1411 Digest authentication provides credentials for the principal 1412 operating the client. 1414 The client might reasonably follow this request with two separate 1415 PROPFIND requests to retrieve the DAV:displayname property of the 1416 members of the two collections (/acl/users and /acl/groups). This 1417 information could be used when displaying a user interface for 1418 creating access control entries. 1420 >> Request << 1422 PROPFIND /papers/ HTTP/1.1 1423 Host: www.example.com 1424 Content-type: text/xml; charset="utf-8" 1425 Content-Length: xxx 1426 Depth: 0 1427 Authorization: Digest username="yarong", 1428 realm="users@example.com", nonce="...", 1429 uri="/papers/", response="...", opaque="..." 1431 1432 1433 1434 1435 1436 1438 >> Response << 1440 HTTP/1.1 207 Multi-Status 1441 Content-Type: text/xml; charset="utf-8" 1442 Content-Length: xxx 1444 1445 1446 1447 http://www.example.com/papers/ 1448 1449 1450 1451 http://www.example.com/acl/users/ 1452 http://www.example.com/acl/groups/ 1453 1454 1455 HTTP/1.1 200 OK 1456 1457 1458 1460 5.9 Example: PROPFIND to retrieve access control properties 1462 The following example shows how access control information can be 1463 retrieved by using the PROPFIND method to fetch the values of the 1464 DAV:owner, DAV:supported-privilege-set, 1465 DAV:current-user-privilege-set, and DAV:acl properties. 1467 >> Request << 1469 PROPFIND /top/container/ HTTP/1.1 1470 Host: www.example.com 1471 Content-type: text/xml; charset="utf-8" 1472 Content-Length: xxx 1473 Depth: 0 1474 Authorization: Digest username="ejw", 1475 realm="users@example.com", nonce="...", 1476 uri="/top/container/", response="...", opaque="..." 1478 1479 1480 1481 1482 1483 1484 1485 1486 1488 >> Response << 1490 HTTP/1.1 207 Multi-Status 1491 Content-Type: text/xml; charset="utf-8" 1492 Content-Length: xxx 1494 1495 1497 1498 http://www.example.com/top/container/ 1499 1500 1501 1502 http://www.example.com/users/gclemm 1503 1504 1505 1506 1507 1508 1509 Any operation 1510 1511 1512 1513 1514 Read any object 1516 1517 1518 1519 1520 1521 1522 Write any object 1523 1524 1525 1526 1527 Create an object 1528 1529 1530 1531 1532 1533 Update an object 1534 1535 1536 1537 1538 1539 1540 Delete an object 1541 1542 1543 1544 1545 1546 Read the ACL 1547 1548 1549 1550 1551 1552 Write the ACL 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 http://www.example.com/users/esedlar 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 http://www.example.com/groups/marketing 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 http://www.example.com/top 1596 1597 1598 1599 1600 HTTP/1.1 200 OK 1601 1602 1603 1605 The value of the DAV:owner property is a single DAV:href XML element 1606 containing the URL of the principal that owns this resource. 1608 The value of the DAV:supported-privilege-set property is a tree of 1609 supported privileges (using "[XML Namespace , localname]" to identify 1610 each privilege): 1612 [DAV:, all] (aggregate, abstract) 1613 | 1614 +-- [DAV:, read] 1615 +-- [DAV:, write] (aggregate, abstract) 1616 | 1617 +-- [http://www.example.com/acl, create] 1618 +-- [http://www.example.com/acl, update] 1619 +-- [http://www.example.com/acl, delete] 1620 +-- [DAV:, read-acl] 1621 +-- [DAV:, write-acl] 1623 The DAV:current-user-privilege-set property contains two privileges, 1624 DAV:read, and DAV:read-acl. This indicates that the current 1625 authenticated user only has the ability to read the resource, and 1626 read the DAV:acl property on the resource. The DAV:acl property 1627 contains a set of four ACEs: 1629 ACE #1: The principal identified by the URL http://www.example.com/ 1630 users/esedlar is granted the DAV:read, DAV:write, and DAV:read-acl 1631 privileges. 1633 ACE #2: The principals identified by the URL http://www.example.com/ 1634 groups/marketing are denied the DAV:read privilege. In this example, 1635 the principal URL identifies a group. 1637 ACE #3: In this ACE, the principal is a property principal, 1638 specifically the DAV:owner property. When evaluating this ACE, the 1639 value of the DAV:owner property is retrieved, and is examined to see 1640 if it contains a DAV:href XML element. If so, the URL within the 1641 DAV:href element is read, and identifies a principal. In this ACE, 1642 the owner is granted DAV:read-acl, and DAV:write-acl privileges. 1644 ACE #4: This ACE grants the DAV:all principal (all users) the 1645 DAV:read privilege. This ACE is inherited from the resource http:// 1646 www.example.com/top, the parent collection of this resource. 1648 6. ACL Evaluation 1650 WebDAV ACLs are evaluated in similar manner as ACLs on Windows NT and 1651 in NFSv4 [RFC3530]). An ACL is evaluated to determine whether or not 1652 access will be granted for a WebDAV request. ACEs are maintained in 1653 a particular order, and are evaluated until all of the permissions 1654 required by the current request have been granted, at which point the 1655 ACL evaluation is terminated and access is granted. If, during ACL 1656 evaluation, a ACE (matching the current user) is encountered 1657 for a privilege which has not yet been granted, the ACL evaluation is 1658 terminated and access is denied. Failure to have all required 1659 privileges granted results in access being denied. 1661 Note that the semantics of many other existing ACL systems may be 1662 represented via this mechanism, by mixing deny and grant ACEs. For 1663 example, consider the standard "rwx" privilege scheme used by UNIX. 1664 In this scheme, if the current user is the owner of the file, access 1665 is granted if the corresponding privilege bit is set and denied if 1666 not set, regardless of the permissions set on the file's group and 1667 for the world. An ACL for UNIX permissions of "r--rw-r--" might be 1668 constructed like: 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1710 1711 1713 and the would be defined as: 1715 1716 1717 1718 1719 1720 1722 Note that the client can still get errors from a UNIX server in spite 1723 of obeying the , including 1724 (adding an ACE specifying a principal other than the ones in the ACL 1725 above) or (by trying to reorder the ACEs in the 1726 example above), as these particular implementation semantics are too 1727 complex to be captured with the simple (but general) declarative 1728 restrictions. 1730 7. Access Control and existing methods 1732 This section defines the impact of access control functionality on 1733 existing methods. 1735 7.1 Any HTTP method 1737 7.1.1 Error Handling 1739 The WebDAV ACL mechanism requires the usage of HTTP method 1740 "preconditions" as described in section 1.6 of RFC3253 for ALL HTTP 1741 methods. All HTTP methods have an additional precondition called 1742 DAV:need-privileges. If an HTTP method fails due to insufficient 1743 privileges, the response body to the "403 Forbidden" error MUST 1744 contain the element, which in turn contains the 1745 element, which contains one or more 1746 elements indicating which resource had insufficient 1747 privileges, and what the lacking privileges were: 1749 1750 1752 Since some methods require multiple permissions on multiple 1753 resources, this information is needed to resolve any ambiguity. There 1754 is no requirement that all privilege violations be reported - for 1755 implementation reasons, some servers may only report the first 1756 privilege violation. For example: 1758 >> Request << 1760 MOVE /a/b/ HTTP/1.1 1761 Host: www.example.com 1762 Destination: http://www.example.com/c/d 1764 >> Response << 1766 HTTP/1.1 403 Forbidden 1767 Content-Type: text/xml; charset="utf-8" 1768 Content-Length: xxx 1770 1771 1772 1773 /a 1774 1775 1776 1777 /c 1778 1779 1780 1781 1783 7.2 OPTIONS 1785 If the server supports access control, it MUST return 1786 "access-control" as a field in the DAV response header from an 1787 OPTIONS request on any resource implemented by that server. A value 1788 of "access-control" in the DAV header MUST indicate that the server 1789 supports all MUST level requirements and REQUIRED features specified 1790 in this document. 1792 7.2.1 Example - OPTIONS 1794 >> Request << 1796 OPTIONS /foo.html HTTP/1.1 1797 Host: www.example.com 1798 Content-Length: 0 1800 >> Response << 1802 HTTP/1.1 200 OK 1803 DAV: 1, 2, access-control 1804 Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL 1805 In this example, the OPTIONS response indicates that the server 1806 supports access control and that /foo.html can have its access 1807 control list modified by the ACL method. 1809 7.3 MOVE 1811 When a resource is moved from one location to another due to a MOVE 1812 request, the non-inherited and non-protected ACEs in the DAV:acl 1813 property of the resource MUST NOT be modified, or the MOVE request 1814 fails. Handling of inherited and protected ACEs is intentionally 1815 undefined to give server implementations flexibility in how they 1816 implement ACE inheritance and protection. 1818 7.4 COPY 1820 The DAV:acl property on the resource at the destination of a COPY 1821 MUST be the same as if the resource was created by an individual 1822 resource creation request (e.g. MKCOL, PUT). Clients wishing to 1823 preserve the DAV:acl property across a copy need to read the DAV:acl 1824 property prior to the COPY, then perform an ACL operation on the new 1825 resource at the destination to restore, insofar as this is possible, 1826 the original access control list. 1828 7.5 LOCK 1830 A lock on a resource ensures that only the lock owner can modify ACEs 1831 that are not inherited and not protected (these are the only ACEs 1832 that a client can modify with an ACL request). A lock does not 1833 protect inherited or protected ACEs, since a client cannot modify 1834 them with an ACL request on that resource. 1836 8. Access Control Methods 1838 8.1 ACL 1840 The ACL method modifies the access control list (which can be read 1841 via the DAV:acl property) of a resource. Specifically, the ACL 1842 method only permits modification to ACEs that are not inherited, and 1843 are not protected. An ACL method invocation modifies all 1844 non-inherited and non-protected ACEs in a resource's access control 1845 list to exactly match the ACEs contained within in the DAV:acl XML 1846 element (specified in Section 5.5) of the request body. An ACL 1847 request body MUST contain only one DAV:acl XML element. Unless the 1848 non-inherited and non-protected ACEs of the DAV:acl property of the 1849 resource can be updated to be exactly the value specified in the ACL 1850 request, the ACL request MUST fail. 1852 It is possible that the ACEs visible to the current user in the 1853 DAV:acl property may only be a portion of the complete set of ACEs on 1854 that resource. If this is the case, an ACL request only modifies the 1855 set of ACEs visible to the current user, and does not affect any 1856 non-visible ACE. 1858 In order to avoid overwriting DAV:acl changes by another client, a 1859 client SHOULD acquire a WebDAV lock on the resource before retrieving 1860 the DAV:acl property of a resource that it intends on updating. 1862 Implementation Note: Two common operations are to add or remove an 1863 ACE from an existing access control list. To accomplish this, a 1864 client uses the PROPFIND method to retrieve the value of the 1865 DAV:acl property, then parses the returned access control list to 1866 remove all inherited and protected ACEs (these ACEs are tagged 1867 with the DAV:inherited and DAV:protected XML elements). In the 1868 remaining set of non-inherited, non-protected ACEs, the client can 1869 add or remove one or more ACEs before submitting the final ACE set 1870 in the request body of the ACL method. 1872 8.1.1 ACL Preconditions 1874 An implementation MUST enforce the following constraints on an ACL 1875 request. If the constraint is violated, a 403 (Forbidden) or 409 1876 (Conflict) response MUST be returned and the indicated XML element 1877 MUST be returned as a child of a top level DAV:error element in an 1878 XML response body. 1880 Though these status elements are generally expressed as empty XML 1881 elements (and are defined as EMPTY in the DTD), implementations MAY 1882 return additional descriptive XML elements as children of the status 1883 element. Clients MUST be able to accept children of these status 1884 elements. Clients that do not understand the additional XML elements 1885 should ignore them. 1887 (DAV:no-ace-conflict): The ACEs submitted in the ACL request MUST NOT 1888 conflict with each other. This is a catchall error code indicating 1889 that an implementation-specific ACL restriction has been violated. 1891 (DAV:no-protected-ace-conflict): The ACEs submitted in the ACL 1892 request MUST NOT conflict with the protected ACEs on the resource. 1893 For example, if the resource has a protected ACE granting DAV:write 1894 to a given principal, then it would not be consistent if the ACL 1895 request submitted an ACE denying DAV:write to the same principal. 1897 (DAV:no-inherited-ace-conflict): The ACEs submitted in the ACL 1898 request MUST NOT conflict with the inherited ACEs on the resource. 1899 For example, if the resource inherits an ACE from its parent 1900 collection granting DAV:write to a given principal, then it would not 1901 be consistent if the ACL request submitted an ACE denying DAV:write 1902 to the same principal. Note that reporting of this error will be 1903 implementation-dependent. Implementations MUST either report this 1904 error or allow the ACE to be set, and then let normal ACE evaluation 1905 rules determine whether the new ACE has any impact on the privileges 1906 available to a specific principal. 1908 (DAV:limited-number-of-aces): The number of ACEs submitted in the ACL 1909 request MUST NOT exceed the number of ACEs allowed on that resource. 1910 However, ACL-compliant servers MUST support at least one ACE granting 1911 privileges to a single principal, and one ACE granting privileges to 1912 a group. 1914 (DAV:deny-before-grant): All non-inherited deny ACEs MUST precede all 1915 non-inherited grant ACEs. 1917 (DAV:grant-only): The ACEs submitted in the ACL request MUST NOT 1918 include a deny ACE. This precondition applies only when the ACL 1919 restrictions of the resource include the DAV:grant-only constraint 1920 (defined in Section 5.6.1). 1922 (DAV:no-invert): The ACL request MUST NOT include a DAV:invert 1923 element. This precondition applies only when the ACL semantics of 1924 the resource includes the DAV:no-invert constraint (defined in 1925 Section 5.6.2). 1927 (DAV:no-abstract): The ACL request MUST NOT attempt to grant or deny 1928 an abstract privilege (see Section 5.3). 1930 (DAV:not-supported-privilege): The ACEs submitted in the ACL request 1931 MUST be supported by the resource. 1933 (DAV:missing-required-principal): The result of the ACL request MUST 1934 have at least one ACE for each principal identified in a 1935 DAV:required-principal XML element in the ACL semantics of that 1936 resource (see Section 5.5). 1938 (DAV:recognized-principal): Every principal URL in the ACL request 1939 MUST identify a principal resource. 1941 (DAV:allowed-principal): The principals specified in the ACEs 1942 submitted in the ACL request MUST be allowed as principals for the 1943 resource. For example, a server where only authenticated principals 1944 can access resources would not allow the DAV:all or 1945 DAV:unauthenticated principals to be used in an ACE, since these 1946 would allow unauthenticated access to resources. 1948 8.1.2 Example: the ACL method 1950 In the following example, user "fielding", authenticated by 1951 information in the Authorization header, grants the principal 1952 identified by the URL http://www.example.com/users/esedlar (i.e., 1953 the user "esedlar") read and write privileges, grants the owner of 1954 the resource read-acl and write-acl privileges, and grants everyone 1955 read privileges. 1957 >> Request << 1959 ACL /top/container/ HTTP/1.1 1960 Host: www.example.com 1961 Content-Type: text/xml; charset="utf-8" 1962 Content-Length: xxxx 1963 Authorization: Digest username="fielding", 1964 realm="users@example.com", nonce="...", 1965 uri="/top/container/", response="...", opaque="..." 1967 1968 1969 1970 1971 http://www.example.com/users/esedlar 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 >> Response << 1996 HTTP/1.1 200 OK 1998 8.1.3 Example: ACL method failure due to protected ACE conflict 2000 In the following request, user "fielding", authenticated by 2001 information in the Authorization header, attempts to deny the 2002 principal identified by the URL http://www.example.com/users/esedlar 2003 (i.e., the user "esedlar") write privileges. Prior to the request, 2004 the DAV:acl property on the resource contained a protected ACE (see 2005 Section 5.5.3) granting DAV:owner the DAV:read and DAV:write 2006 privileges. The principal identified by URL http://www.example.com/ 2007 users/esedlar is the owner of the resource. The ACL method invocation 2008 fails because the submitted ACE conflicts with the protected ACE, 2009 thus violating the semantics of ACE protection. 2011 >> Request << 2013 ACL /top/container/ HTTP/1.1 2014 Host: www.example.com 2015 Content-Type: text/xml; charset="utf-8" 2016 Content-Length: xxxx 2017 Authorization: Digest username="fielding", 2018 realm="users@example.com", nonce="...", 2019 uri="/top/container/", response="...", opaque="..." 2021 2022 2023 2024 2025 http://www.example.com/users/esedlar 2026 2027 2028 2029 2030 2031 2032 >> Response << 2034 HTTP/1.1 403 Forbidden 2035 Content-Type: text/xml; charset="utf-8" 2036 Content-Length: xxx 2038 2039 2040 2041 2043 8.1.4 Example: ACL method failure due to an inherited ACE conflict 2045 In the following request, user "ejw", authenticated by information in 2046 the Authorization header, tries to change the access control list on 2047 the resource http://www.example.com/top/index.html. This resource has 2048 two inherited ACEs. 2050 Inherited ACE #1 grants the principal identified by URL http:// 2051 www.example.com/users/ejw (i.e., the user "ejw") http:// 2052 www.example.com/privs/write-all and DAV:read-acl privileges. On this 2053 server, http://www.example.com/privs/write-all is an aggregate 2054 privilege containing DAV:write, and DAV:write-acl. 2056 Inherited ACE #2 grants principal DAV:all the DAV:read privilege. 2058 The request attempts to set a (non-inherited) ACE, denying the 2059 principal identified by the URL http://www.example.com/users/ejw 2060 (i.e., the user "ejw") DAV:write permission. This conflicts with 2061 inherited ACE #1. Note that the decision to report an inherited ACE 2062 conflict is specific to this server implementation. Another server 2063 implementation could have allowed the new ACE to be set, and then 2064 used normal ACE evaluation rules to determine whether the new ACE has 2065 any impact on the privileges available to a principal. 2067 >> Request << 2069 ACL /top/index.html HTTP/1.1 2070 Host: www.example.com 2071 Content-Type: text/xml; charset="utf-8" 2072 Content-Length: xxxx 2073 Authorization: Digest username="ejw", 2074 realm="users@example.com", nonce="...", 2075 uri="/top/index.html", response="...", opaque="..." 2077 2078 2079 2080 2081 http://www.example.com/users/ejw 2082 2083 2084 2085 2087 >> Response << 2089 HTTP/1.1 403 Forbidden 2090 Content-Type: text/xml; charset="utf-8" 2091 Content-Length: xxx 2093 2094 2095 2096 2098 8.1.5 Example: ACL method failure due to an attempt to set grant and 2099 deny in a single ACE 2101 In this example, user "ygoland", authenticated by information in the 2102 Authorization header, tries to change the access control list on the 2103 resource http://www.example.com/diamond/engagement-ring.gif. The ACL 2104 request includes a single, syntactically and semantically incorrect 2105 ACE, which attempts to grant the group identified by the URL http:// 2106 www.example.com/users/friends DAV:read privilege and deny the 2107 principal identified by URL http://www.example.com/users/ygoland-so 2108 (i.e., the user "ygoland-so") DAV:read privilege. However, it is 2109 illegal to have multiple principal elements, as well as both a grant 2110 and deny element in the same ACE, so the request fails due to poor 2111 syntax. 2113 >> Request << 2115 ACL /diamond/engagement-ring.gif HTTP/1.1 2116 Host: www.example.com 2117 Content-Type: text/xml; charset="utf-8" 2118 Content-Length: xxxx 2119 Authorization: Digest username="ygoland", 2120 realm="users@example.com", nonce="...", 2121 uri="/diamond/engagement-ring.gif", response="...", 2122 opaque="..." 2124 2125 2126 2127 2128 http://www.example.com/users/friends 2129 2130 2131 2132 http://www.example.com/users/ygoland-so 2133 2134 2135 2136 2138 >> Response << 2140 HTTP/1.1 400 Bad Request 2141 Content-Length: 0 2143 Note that if the request had been divided into two ACEs, one to 2144 grant, and one to deny, the request would have been syntactically 2145 well formed. 2147 9. Access Control Reports 2149 9.1 REPORT Method 2151 The REPORT method (defined in Section 3.6 of [RFC3253]) provides an 2152 extensible mechanism for obtaining information about a resource. 2153 Unlike the PROPFIND method, which returns the value of one or more 2154 named properties, the REPORT method can involve more complex 2155 processing. REPORT is valuable in cases where the server has access 2156 to all of the information needed to perform the complex request (such 2157 as a query), and where it would require multiple requests for the 2158 client to retrieve the information needed to perform the same 2159 request. 2161 A server that supports the WebDAV Access Control Protocol MUST 2162 support the DAV:expand-property report (defined in Section 3.8 of 2163 [RFC3253]). 2165 9.2 DAV:acl-principal-prop-set Report 2167 The DAV:acl-principal-prop-set report returns, for all principals in 2168 the DAV:acl property (of the Request-URI) that are identified by 2169 http(s) URLs or by a DAV:property principal, the value of the 2170 properties specified in the REPORT request body. In the case where a 2171 principal URL appears multiple times, the DAV:acl-principal-prop-set 2172 report MUST return the properties for that principal only once. 2173 Support for this report is REQUIRED. 2175 One expected use of this report is to retrieve the human readable 2176 name (found in the DAV:displayname property) of each principal found 2177 in an ACL. This is useful for constructing user interfaces that show 2178 each ACE in a human readable form. 2180 Marshalling 2182 The request body MUST be a DAV:acl-principal-prop-set XML element. 2184 2185 ANY value: a sequence of one or more elements, with at most one 2186 DAV:prop element. 2187 prop: see RFC 2518, Section 12.11 2189 This report is only defined when the Depth header has value "0"; 2190 other values result in a 400 (Bad Request) error response. Note 2191 that [RFC3253], Section 3.6, states that if the Depth header is 2192 not present, it defaults to a value of "0". 2194 The response body for a successful request MUST be a 2195 DAV:multistatus XML element (i.e., the response uses the same 2196 format as the response for PROPFIND). In the case where there are 2197 no response elements, the returned multistatus XML element is 2198 empty. 2200 multistatus: see RFC 2518, Section 12.9 2202 The response body for a successful DAV:acl-principal-prop-set 2203 REPORT request MUST contain a DAV:response element for each 2204 principal identified by an http(s) URL listed in a DAV:principal 2205 XML element of an ACE within the DAV:acl property of the resource 2206 identified by the Request-URI. 2208 Postconditions: 2210 (DAV:number-of-matches-within-limits): The number of matching 2211 principals must fall within server-specific, predefined limits. 2212 For example, this condition might be triggered if a search 2213 specification would cause the return of an extremely large number 2214 of responses. 2216 9.2.1 Example: DAV:acl-principal-prop-set Report 2218 Resource http://www.example.com/index.html has an ACL with three 2219 ACEs: 2221 ACE #1: All principals (DAV:all) have DAV:read and 2222 DAV:read-current-user-privilege-set access. 2224 ACE #2: The principal identified by http://www.example.com/people/ 2225 gstein (the user "gstein") is granted DAV:write, DAV:write-acl, 2226 DAV:read-acl privileges. 2228 ACE #3: The group identified by http://www.example.com/groups/authors 2229 (the "authors" group) is granted DAV:write and DAV:read-acl 2230 privileges. 2232 The following example shows a DAV:acl-principal-prop-set report 2233 requesting the DAV:displayname property. It returns the value of 2234 DAV:displayname for resources http://www.example.com/people/gstein 2235 and http://www.example.com/groups/authors , but not for DAV:all, 2236 since this is not an http(s) URL. 2238 >> Request << 2240 REPORT /index.html HTTP/1.1 2241 Host: www.example.com 2242 Content-Type: text/xml; charset="utf-8" 2243 Content-Length: xxxx 2244 Depth: 0 2246 2247 2248 2249 2250 2251 2252 >> Response << 2254 HTTP/1.1 207 Multi-Status 2255 Content-Type: text/xml; charset="utf-8" 2256 Content-Length: xxxx 2258 2259 2260 2261 http://www.example.com/people/gstein 2262 2263 2264 Greg Stein 2265 2266 HTTP/1.1 200 OK 2267 2268 2269 2270 http://www.example.com/groups/authors 2271 2272 2273 Site authors 2274 2275 HTTP/1.1 200 OK 2276 2277 2278 2280 9.3 DAV:principal-match REPORT 2282 The DAV:principal-match REPORT is used to identify all members (at 2283 any depth) of the collection identified by the Request-URI that are 2284 principals and that match the current user. In particular, if the 2285 collection contains principals, the report can be used to identify 2286 all members of the collection that match the current user. 2287 Alternatively, if the collection contains resources that have a 2288 property that identifies a principal (e.g. DAV:owner), the report can 2289 be used to identify all members of the collection whose property 2290 identifies a principal that matches the current user. For example, 2291 this report can return all of the resources in a collection hierarchy 2292 that are owned by the current user. Support for this report is 2293 REQUIRED. 2295 Marshalling: 2297 The request body MUST be a DAV:principal-match XML element. 2299 2300 2301 ANY value: an element whose value identifies a property. The 2302 expectation is the value of the named property typically contains 2303 an href element that contains the URI of a principal 2304 2305 prop: see RFC 2518, Section 12.11 2307 This report is only defined when the Depth header has value "0"; 2308 other values result in a 400 (Bad Request) error response. Note 2309 that [RFC3253], Section 3.6, states that if the Depth header is 2310 not present, it defaults to a value of "0". The response body for 2311 a successful request MUST be a DAV:multistatus XML element. In the 2312 case where there are no response elements, the returned 2313 multistatus XML element is empty. 2315 multistatus: see RFC 2518, Section 12.9 2317 The response body for a successful DAV:principal-match REPORT 2318 request MUST contain a DAV:response element for each member of the 2319 collection that matches the current user. When the 2320 DAV:principal-property element is used, a match occurs if the 2321 current user is matched by the principal identified by the URI 2322 found in the DAV:href element of the property identified by the 2323 DAV:principal-property element. When the DAV:self element is used 2324 in a DAV:principal-match report issued against a group, it matches 2325 the group if a member identifies the same principal as the current 2326 user. 2328 If DAV:prop is specified in the request body, the properties 2329 specified in the DAV:prop element MUST be reported in the 2330 DAV:response elements. 2332 9.3.1 Example: DAV:principal-match REPORT 2334 The following example identifies the members of the collection 2335 identified by the URL http://www.example.com/doc that are owned by 2336 the current user. The current user ("gclemm") is authenticated using 2337 Digest authentication. 2339 >> Request << 2341 REPORT /doc/ HTTP/1.1 2342 Host: www.example.com 2343 Authorization: Digest username="gclemm", 2344 realm="users@example.com", nonce="...", 2345 uri="/papers/", response="...", opaque="..." 2346 Content-Type: text/xml; charset="utf-8" 2347 Content-Length: xxxx 2348 Depth: 0 2350 2351 2352 2353 2354 2355 2357 >> Response << 2359 HTTP/1.1 207 Multi-Status 2360 Content-Type: text/xml; charset="utf-8" 2361 Content-Length: xxxx 2363 2364 2365 2366 http://www.example.com/doc/foo.html 2367 HTTP/1.1 200 OK 2368 2369 2370 http://www.example.com/doc/img/bar.gif 2371 HTTP/1.1 200 OK 2372 2373 2375 9.4 DAV:principal-property-search REPORT 2377 The DAV:principal-property-search REPORT performs a search for all 2378 principals whose properties contain character data that matches the 2379 search criteria specified in the request. One expected use of this 2380 report is to discover the URL of a principal associated with a given 2381 person or group by searching for them by name. This is done by 2382 searching over DAV:displayname, which is defined on all principals. 2384 The actual search method (exact matching vs. substring matching vs, 2385 prefix-matching, case-sensitivity) deliberately is left to the server 2386 implementation to allow implementation on a wide set of possible user 2387 management systems. In cases where the implementation of 2388 DAV:principal-property-search is not constrained by the semantics of 2389 an underlying user management repository, preferred default semantics 2390 are caseless substring matches. 2392 For implementation efficiency, servers do not typically support 2393 searching on all properties. A search requesting properties that are 2394 not searchable for a particular principal will not match that 2395 principal. 2397 Support for the DAV:principal-property-search report is REQUIRED. 2399 Implementation Note: The value of a WebDAV property is a sequence 2400 of well-formed XML, and hence can include any character in the 2401 Unicode/ISO-10646 standard, that is, most known characters in 2402 human languages. Due to the idiosyncrasies of case mapping across 2403 human languages, implementation of case-insensitive matching is 2404 non-trivial. Implementors of servers that do perform substring 2405 matching are strongly encouraged to consult "The Unicode Standard" 2406 [UNICODE4], especially Section 5.18, Subsection "Caseless 2407 Matching", for guidance when implementing their case-insensitive 2408 matching algorithms. 2410 Implementation Note: Some implementations of this protocol will 2411 use an LDAP repository for storage of principal metadata. The 2412 schema describing each attribute (akin to a WebDAV property) in an 2413 LDAP repository specifies whether it supports case-sensitive or 2414 caseless searching. One of the benefits of leaving the search 2415 method to the discretion of the server implementation is the 2416 default LDAP attribute search behavior can be used when 2417 implementing the DAV:principal-property-search report. 2419 Marshalling: 2421 The request body MUST be a DAV:principal-property-search XML 2422 element containing a search specification and an optional list of 2423 properties. For every principal that matches the search 2424 specification, the response will contain the value of the 2425 requested properties on that principal. 2427 2430 By default, the report searches all members (at any depth) of the 2431 collection identified by the Request-URI. If 2432 DAV:apply-to-principal-collection-set is specified in the request 2433 body, the request is applied instead to each collection identified 2434 by the DAV:prinicipal-collection-set property of the resource 2435 identified by the Request-URI. 2437 The DAV:property-search element contains a prop element 2438 enumerating the properties to be searched and a match element, 2439 containing the search string. 2441 2442 prop: see RFC 2518, Section 12.11 2444 2446 Multiple property-search elements or multiple elements within a 2447 DAV:prop element will be interpreted with a logical AND. 2449 This report is only defined when the Depth header has value "0"; 2450 other values result in a 400 (Bad Request) error response. Note 2451 that [RFC3253], Section 3.6, states that if the Depth header is 2452 not present, it defaults to a value of "0". 2454 The response body for a successful request MUST be a 2455 DAV:multistatus XML element. In the case where there are no 2456 response elements, the returned multistatus XML element is empty. 2458 multistatus: see RFC 2518, Section 12.9 2460 The response body for a successful DAV:principal-property-search 2461 REPORT request MUST contain a DAV:response element for each 2462 principal whose property values satisfy the search specification 2463 given in DAV:principal-property-search. 2465 The response body for an unsuccessful 2466 DAV:principal-property-search REPORT request MUST contain, after 2467 the XML element indicating the failed precondition or 2468 postcondition, a DAV:prop element containing the property that 2469 caused the pre/postcondition to fail. 2471 If DAV:prop is specified in the request body, the properties 2472 specified in the DAV:prop element MUST be reported in the 2473 DAV:response elements. 2475 Preconditions: 2477 None 2479 Postconditions: 2481 (DAV:number-of-matches-within-limits): The number of matching 2482 principals must fall within server-specific, predefined limits. 2483 For example, this condition might be triggered if a search 2484 specification would cause the return of an extremely large number 2485 of responses. 2487 9.4.1 Matching 2489 There are several cases to consider when matching strings. The 2490 easiest case is when a property value is "simple" and has only 2491 character information item content (see [REC-XML-INFOSET]). For 2492 example, the search string "julian" would match the DAV:displayname 2493 property with value "Julian Reschke". Note that the on-the-wire 2494 marshalling of DAV:displayname in this case is: 2496 Julian Reschke 2498 The name of the property is encoded into the XML element information 2499 item, and the character information item content of the property is 2500 "Julian Reschke". 2502 A more complicated case occurs when properties have mixed content 2503 (that is, compound values consisting of multiple child element items, 2504 other types of information items, and character information item 2505 content). Consider the property "aprop" in the namespace "http:// 2506 www.example.com/props/", marshalled as: 2508 2509 {cdata 0}{cdata 1} 2510 {cdata 2}{cdata 3} 2511 2513 In this case, matching is performed on each individual contiguous 2514 sequence of character information items. In the example above, a 2515 search string would be compared to the four following strings: 2517 {cdata 0} 2518 {cdata 1} 2519 {cdata 2} 2520 {cdata 3} 2522 That is, four individual matches would be performed, one each for 2523 {cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}. 2525 9.4.2 Example: successful DAV:principal-property-search REPORT 2527 In this example, the client requests the principal URLs of all users 2528 whose DAV:displayname property contains the substring "doE" and whose 2529 "title" property in the namespace "http://BigCorp.com/ns/" (that is, 2530 their professional title) contains "Sales". In addition, the client 2531 requests five properties to be returned with the matching principals: 2533 In the DAV: namespace: displayname 2535 In the http://www.example.com/ns/ namespace: department, phone, 2536 office, salary 2538 The response shows that two principal resources meet the search 2539 specification, "John Doe" and "Zygdoebert Smith". The property 2540 "salary" in namespace "http://www.example.com/ns/" is not returned, 2541 since the principal making the request does not have sufficient 2542 access permissions to read this property. 2544 >> Request << 2546 REPORT /users/ HTTP/1.1 2547 Host: www.example.com 2548 Content-Type: text/xml; charset=utf-8 2549 Content-Length: xxxx 2550 Depth: 0 2552 2553 2554 2555 2556 2557 2558 doE 2559 2560 2561 2562 2563 2564 Sales 2565 2566 2567 2568 2569 2570 2571 2572 2573 2575 >> Response << 2576 HTTP/1.1 207 Multi-Status 2577 Content-Type: text/xml; charset=utf-8 2578 Content-Length: xxxx 2580 2581 2582 2583 http://www.example.com/users/jdoe 2584 2585 2586 John Doe 2587 Widget Sales 2588 234-4567 2589 209 2590 2591 HTTP/1.1 200 OK 2592 2593 2594 2595 2596 2597 HTTP/1.1 403 Forbidden 2598 2599 2600 2601 http://www.example.com/users/zsmith 2602 2603 2604 Zygdoebert Smith 2605 Gadget Sales 2606 234-7654 2607 114 2608 2609 HTTP/1.1 200 OK 2610 2611 2612 2613 2614 2615 HTTP/1.1 403 Forbidden 2616 2617 2618 2620 9.5 DAV:principal-search-property-set REPORT 2622 The DAV:principal-search-property-set REPORT identifies those 2623 properties that may be searched using the 2624 DAV:principal-property-search REPORT (defined in Section 9.4). 2626 Servers MUST support the DAV:principal-search-property-set REPORT on 2627 all collections identified in the value of a 2628 DAV:principal-collection-set property. 2630 An access control protocol user agent could use the results of the 2631 DAV:principal-search-property-set REPORT to present a query interface 2632 to the user for retrieving principals. 2634 Support for this report is REQUIRED. 2636 Implementation Note: Some clients will have only limited screen 2637 real estate for the display of lists of searchable properties. In 2638 this case, a user might appreciate having the most frequently 2639 searched properties be displayed on-screen, rather than having to 2640 scroll through a long list of searchable properties. One mechanism 2641 for signaling the most frequently searched properties is to return 2642 them towards the start of a list of properties. A client can then 2643 preferentially display the list of properties in order, increasing 2644 the likelihood that the most frequently searched properties will 2645 appear on-screen, and will not require scrolling for their 2646 selection. 2648 Marshalling: 2650 The request body MUST be an empty 2651 DAV:principal-search-property-set XML element. 2653 This report is only defined when the Depth header has value "0"; 2654 other values result in a 400 (Bad Request) error response. Note 2655 that [RFC3253], Section 3.6, states that if the Depth header is 2656 not present, it defaults to a value of "0". 2658 The response body MUST be a DAV:principal-search-property-set XML 2659 element, containing a DAV:principal-search-property XML element 2660 for each property that may be searched with the 2661 DAV:principal-property-search REPORT. A server MAY limit its 2662 response to just a subset of the searchable properties, such as 2663 those likely to be useful to an interactive access control client. 2665 2668 Each DAV:principal-search-property XML element contains exactly 2669 one searchable property, and a description of the property. 2671 2673 The DAV:prop element contains one principal property on which the 2674 server is able to perform a DAV:principal-property-search REPORT. 2676 prop: see RFC 2518, Section 12.11 2678 The description element is a human-readable description of what 2679 information this property represents. Servers MUST indicate the 2680 human language of the description using the xml:lang attribute and 2681 SHOULD consider the HTTP Accept-Language request header when 2682 selecting one of multiple available languages. 2684 2686 9.5.1 Example: DAV:principal-search-property-set REPORT 2688 In this example, the client determines the set of searchable 2689 principal properties by requesting the 2690 DAV:principal-search-property-set REPORT on the root of the server's 2691 principal URL collection set, identified by http://www.example.com/ 2692 users/. 2694 >> Request << 2696 REPORT /users/ HTTP/1.1 2697 Host: www.example.com 2698 Content-Type: text/xml; charset="utf-8" 2699 Content-Length: xxx 2700 Accept-Language: en, de 2701 Authorization: BASIC d2FubmFtYWs6cGFzc3dvcmQ= 2702 Depth: 0 2704 2705 2706 >> Response << 2708 HTTP/1.1 200 OK 2709 Content-Type: text/xml; charset="utf-8" 2710 Content-Length: xxx 2712 2713 2714 2715 2716 2717 2718 Full name 2719 2720 2721 2722 2723 2724 Job title 2725 2726 2728 10. XML Processing 2730 Implementations of this specification MUST support the XML element 2731 ignore rule, as specified in Section 23.3.2 of [RFC2518], and the XML 2732 Namespace recommendation [REC-XML-NAMES]. 2734 Note that use of the DAV namespace is reserved for XML elements and 2735 property names defined in a standards-track or Experimental IETF RFC. 2737 11. Internationalization Considerations 2739 In this specification, the only human-readable content can be found 2740 in the description XML element, found within the 2741 DAV:supported-privilege-set property. This element contains a 2742 human-readable description of the capabilities controlled by a 2743 privilege. As a result, the description element must be capable of 2744 representing descriptions in multiple character sets. Since the 2745 description element is found within a WebDAV property, it is 2746 represented on the wire as XML [REC-XML], and hence can leverage 2747 XML's language tagging and character set encoding capabilities. 2748 Specifically, XML processors at minimum must be able to read XML 2749 elements encoded using the UTF-8 [RFC3629] encoding of the ISO 10646 2750 multilingual plane. XML examples in this specification demonstrate 2751 use of the charset parameter of the Content-Type header, as defined 2752 in [RFC3023], as well as the XML "encoding" attribute, which together 2753 provide charset identification information for MIME and XML 2754 processors. Futhermore, this specification requires server 2755 implementations to tag description fields with the xml:lang attribute 2756 (see Section 2.12 of [REC-XML]), which specifies the human language 2757 of the description. Additionally, server implementations should take 2758 into account the value of the Accept-Language HTTP header to 2759 determine which description string to return. 2761 For XML elements other than the description element, it is expected 2762 that implementations will treat the property names, privilege names, 2763 and values as tokens, and convert these tokens into human-readable 2764 text in the user's language and character set when displayed to a 2765 person. Only a generic WebDAV property display utility would display 2766 these values in their raw form to a human user. 2768 For error reporting, we follow the convention of HTTP/1.1 status 2769 codes, including with each status code a short, English description 2770 of the code (e.g., 200 (OK)). While the possibility exists that a 2771 poorly crafted user agent would display this message to a user, 2772 internationalized applications will ignore this message, and display 2773 an appropriate message in the user's language and character set. 2775 Further internationalization considerations for this protocol are 2776 described in the WebDAV Distributed Authoring protocol specification 2777 [RFC2518]. 2779 12. Security Considerations 2781 Applications and users of this access control protocol should be 2782 aware of several security considerations, detailed below. In addition 2783 to the discussion in this document, the security considerations 2784 detailed in the HTTP/1.1 specification [RFC2616], the WebDAV 2785 Distributed Authoring Protocol specification [RFC2518], and the XML 2786 Media Types specification [RFC3023] should be considered in a 2787 security analysis of this protocol. 2789 12.1 Increased Risk of Compromised Users 2791 In the absence of a mechanism for remotely manipulating access 2792 control lists, if a single user's authentication credentials are 2793 compromised, only those resources for which the user has access 2794 permission can be read, modified, moved, or deleted. With the 2795 introduction of this access control protocol, if a single compromised 2796 user has the ability to change ACLs for a broad range of other users 2797 (e.g., a super-user), the number of resources that could be altered 2798 by a single compromised user increases. This risk can be mitigated by 2799 limiting the number of people who have write-acl privileges across a 2800 broad range of resources. 2802 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set 2803 Privileges 2805 The ability to read the access privileges (stored in the DAV:acl 2806 property), or the privileges permitted the currently authenticated 2807 user (stored in the DAV:current-user-privilege-set property) on a 2808 resource may seem innocuous, since reading an ACL cannot possibly 2809 affect the resource's state. However, if all resources have 2810 world-readable ACLs, it is possible to perform an exhaustive search 2811 for those resources that have inadvertently left themselves in a 2812 vulnerable state, such as being world-writeable. In particular, the 2813 property retrieval method PROPFIND, executed with Depth infinity on 2814 an entire hierarchy, is a very efficient way to retrieve the DAV:acl 2815 or DAV:current-user-privilege-set properties. Once found, this 2816 vulnerability can be exploited by a denial of service attack in which 2817 the open resource is repeatedly overwritten. Alternately, writeable 2818 resources can be modified in undesirable ways. 2820 To reduce this risk, read-acl privileges should not be granted to 2821 unauthenticated principals, and restrictions on read-acl and 2822 read-current-user-privilege-set privileges for authenticated 2823 principals should be carefully analyzed when deploying this protocol. 2824 Access to the current-user-privilege-set property will involve a 2825 tradeoff of usability versus security. When the 2826 current-user-privilege-set is visible, user interfaces are expected 2827 to provide enhanced information concerning permitted and restricted 2828 operations, yet this information may also indicate a vulnerability 2829 that could be exploited. Deployment of this protocol will need to 2830 evaluate this tradeoff in light of the requirements of the deployment 2831 environment. 2833 12.3 No Foreknowledge of Initial ACL 2835 In an effort to reduce protocol complexity, this protocol 2836 specification intentionally does not address the issue of how to 2837 manage or discover the initial ACL that is placed upon a resource 2838 when it is created. The only way to discover the initial ACL is to 2839 create a new resource, then retrieve the value of the DAV:acl 2840 property. This assumes the principal creating the resource also has 2841 been granted the DAV:read-acl privilege. 2843 As a result, it is possible that a principal could create a resource, 2844 and then discover that its ACL grants privileges that are 2845 undesirable. Furthermore, this protocol makes it possible (though 2846 unlikely) that the creating principal could be unable to modify the 2847 ACL, or even delete the resource. Even when the ACL can be modified, 2848 there will be a short period of time when the resource exists with 2849 the initial ACL before its new ACL can be set. 2851 Several factors mitigate this risk. Human principals are often aware 2852 of the default access permissions in their editing environments and 2853 take this into account when writing information. Furthermore, default 2854 privilege policies are usually very conservative, limiting the 2855 privileges granted by the initial ACL. 2857 13. Authentication 2859 Authentication mechanisms defined for use with HTTP and WebDAV also 2860 apply to this WebDAV Access Control Protocol, in particular the Basic 2861 and Digest authentication mechanisms defined in [RFC2617]. 2862 Implementation of the ACL spec requires that Basic authentication, if 2863 used, MUST only be supported over secure transport such as TLS. 2865 14. IANA Considerations 2867 This document uses the namespace defined by [RFC2518] for XML 2868 elements. That is, this specification uses the "DAV:" URI namespace, 2869 previously registered in the URI schemes registry. All other IANA 2870 considerations mentioned in [RFC2518] are also applicable to this 2871 specification. 2873 15. Acknowledgements 2875 This protocol is the collaborative product of the WebDAV ACL design 2876 team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry Lind, Sean 2877 Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead. The authors 2878 are grateful for the detailed review and comments provided by Jim 2879 Amsden, Dylan Barrell, Gino Basso, Murthy Chintalapati, Lisa 2880 Dusseault, Stefan Eissing, Tim Ellison, Yaron Goland, Dennis 2881 Hamilton, Laurie Harper, Eckehard Hermann, Ron Jacobs, Chris Knight, 2882 Remy Maucherat, Larry Masinter, Joe Orton, Peter Raymond, Julian 2883 Reschke, and Keith Wannamaker. We thank Keith Wannamaker for the 2884 initial text of the principal property search sections. Prior work on 2885 WebDAV access control protocols has been performed by Yaron Goland, 2886 Paul Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff. We would 2887 like to acknowledge the foundation laid for us by the authors of the 2888 DeltaV, WebDAV and HTTP protocols upon which this protocol is 2889 layered, and the invaluable feedback from the WebDAV working group. 2891 Normative References 2893 [REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 2894 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC 2895 REC-xml-20001006, October 2000, . 2898 [REC-XML-INFOSET] 2899 Cowan, J. and R. Tobin, "XML Information Set", W3C REC 2900 REC-xml-infoset-20011024, October 2001, . 2903 [REC-XML-NAMES] 2904 Bray, T., Hollander, D. and A. Layman, "Namespaces in 2905 XML", W3C REC REC-xml-names-19990114, January 1999, 2906 . 2908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2909 Requirement Levels", BCP 14, RFC 2119, March 1997. 2911 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 2912 Jensen, "HTTP Extensions for Distributed Authoring -- 2913 WEBDAV", RFC 2518, February 1999. 2915 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2916 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 2917 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2919 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2920 Leach, P., Luotonen, A. and L. Stewart, "HTTP 2921 Authentication: Basic and Digest Access Authentication", 2922 RFC 2617, June 1999. 2924 [RFC3023] Makoto, M., St.Laurent, S. and D. Kohn, "XML Media Types", 2925 RFC 3023, January 2001. 2927 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. 2928 Whitehead, "Versioning Extensions to WebDAV", RFC 3253, 2929 March 2002. 2931 [RFC3530] Shepler, S., Ed., Callaghan, B., Robinson, D., Thurlow, 2932 R., Beame, C., Eisler, M. and D. Noveck, "Network File 2933 System (NFS) version 4 Protocol", RFC 3530, April 2003. 2935 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2936 10646", RFC 3629, STD 63, November 2003. 2938 Informative References 2940 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2941 3", BCP 9, RFC 2026, October 1996. 2943 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 2944 Access Protocol (v3)", RFC 2251, December 1997. 2946 [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, 2947 December 1997. 2949 [UNICODE4] 2950 The Unicode Consortium, "The Unicode Standard - Version 2951 4.0", Addison-Wesley , August 2003, . 2954 ISBN 0321185781 [4]. 2956 URIs 2958 [1] 2960 [2] 2962 [3] 2964 [4] 2966 Authors' Addresses 2968 G. Clemm 2969 IBM 2970 20 Maguire Road 2971 Lexington, MA 02421 2973 EMail: geoffrey.clemm@us.ibm.com 2975 Julian F. Reschke 2976 greenbytes GmbH 2977 Salzmannstrasse 152 2978 Muenster, NW 48159 2979 Germany 2981 EMail: julian.reschke@greenbytes.de 2983 E. Sedlar 2984 Oracle Corporation 2985 500 Oracle Parkway 2986 Redwood Shores, CA 94065 2988 EMail: eric.sedlar@oracle.com 2989 J. Whitehead 2990 U.C. Santa Cruz, Dept. of Computer Science 2991 1156 High Street 2992 Santa Cruz, CA 95064 2994 EMail: ejw@cse.ucsc.edu 2996 Appendix A. WebDAV XML Document Type Definition Addendum 2998 All XML elements defined in this Document Type Definition (DTD) 2999 belong to the DAV namespace. This DTD should be viewed as an addendum 3000 to the DTD provided in [RFC2518], section 23.1. 3002 3018 3020 3021 3022 3023 3025 3027 3029 3031 3033 3034 3036 3037 3040 3041 3042 3044 3046 3048 3050 3051 3054 3058 3059 3060 3061 3062 3064 3066 3067 3068 3070 3072 3073 3075 3078 3079 3080 3082 3086 3088 3090 3092 3094 3096 3097 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3115 3116 ANY value: a sequence of one or more elements, with at most one 3117 DAV:prop element. 3119 3120 3121 ANY value: an element whose value identifies a property. The 3122 expectation is the value of the named property typically contains 3123 an href element that contains the URI of a principal 3124 3126 3127 3128 3130 3132 3133 3135 Appendix B. WebDAV Method Privilege Table (Normative) 3137 The following table of WebDAV methods (as defined in RFC 2518, 2616, 3138 and 3253) clarifies which privileges are required for access for each 3139 method. Note that the privileges listed, if denied, MUST cause 3140 access to be denied. However, given that a specific implementation 3141 MAY define an additional custom privilege to control access to 3142 existing methods, having all of the indicated privileges does not 3143 mean that access will be granted. Note that lack of the indicated 3144 privileges does not imply that access will be denied, since a 3145 particular implementation may use a sub-privilege aggregated under 3146 the indicated privilege to control access. Privileges required refer 3147 to the current resource being processed unless otherwise specified. 3149 +---------------------------------+---------------------------------+ 3150 | METHOD | PRIVILEGES | 3151 +---------------------------------+---------------------------------+ 3152 | GET | | 3153 | HEAD | | 3154 | OPTIONS | | 3155 | PUT (target exists) | on target | 3156 | | resource | 3157 | PUT (no target exists) | on parent collection | 3158 | | of target | 3159 | PROPPATCH | | 3160 | ACL | | 3161 | PROPFIND | (plus and | 3162 | | as needed) | 3164 | COPY (target exists) | , and | 3165 | | on target | 3166 | | resource | 3167 | COPY (no target exists) | , on target | 3168 | | collection | 3169 | MOVE (no target exists) | on source collection | 3170 | | and on target | 3171 | | collection | 3172 | MOVE (target exists) | As above, plus on | 3173 | | the target collection | 3174 | DELETE | on parent collection | 3175 | LOCK (target exists) | | 3176 | LOCK (no target exists) | on parent collection | 3177 | MKCOL | on parent collection | 3178 | UNLOCK | | 3179 | CHECKOUT | | 3180 | CHECKIN | | 3181 | REPORT | (on all referenced | 3182 | | resources) | 3183 | VERSION-CONTROL | | 3184 | MERGE | | 3185 | MKWORKSPACE | on parent | 3186 | | collection | 3187 | BASELINE-CONTROL | and | 3188 | | | 3189 | MKACTIVITY | on parent | 3190 | | collection | 3191 +---------------------------------+---------------------------------+ 3193 Appendix C. Resolved issues (to be removed by RFC Editor before 3194 publication) 3196 Issues that were either rejected or resolved in this version of this 3197 document. 3199 C.1 ED_references_names 3201 Type: edit 3203 3205 julian.reschke@greenbytes.de (2003-11-03): Replace "Informative 3206 References" by "Informational References". 3208 Resolution (2003-11-06): Section title renamed from "Informative 3209 References" to "Informational References" (no change tracking). 3211 C.2 ED_RFC2386 3213 Type: edit 3215 3217 julian.reschke@greenbytes.de (2003-11-03): RFC2386 is listed, but not 3218 mentioned in the spec. 3220 Resolution (2003-11-06): Entry RFC2386 removed from references (no 3221 change tracking). 3223 C.3 ED_example_host_names 3225 Type: edit 3227 3229 julian.reschke@greenbytes.de (2003-11-06): When changing the host 3230 names, we forgot to also update user names that appear in 3231 "Authorization" headers (such as "gclemm@webdav.org"). I'd recommend 3232 to just replace "@webdav.org" with "@example.com". Also fix broken 3233 realms (always say "users@example.com"). 3235 Resolution (2003-11-06): All realms changed to "users@example.com". 3237 C.4 ED_authors_list 3239 Type: edit 3241 geoffrey.clemm@us.ibm.com (2003-11-06): Remove Anne Hopkins from 3242 authors list (keep her name in the Acknowledgements section). 3244 geoffrey.clemm@us.ibm.com (2003-12-20): Add Julian Reschke to authors 3245 list. 3247 Resolution (2003-12-20): Removed Anne Hopkins from authors list (both 3248 in front page and in "authors" section). Added Julian Reschke to 3249 authors list. 3251 C.5 ED_non_ASCII 3253 Type: edit 3255 3257 julian.reschke@greenbytes.de (2003-11-03): some non-ASCII characters 3258 (long dashes and quotes) are present 3260 Resolution (2003-11-04): Fixed in Sections 3.1, 3.3, 3.4, 6, 7.1.1. 3262 C.6 ED_artwork_line_width 3264 Type: edit 3266 3268 julian.reschke@greenbytes.de (2003-11-03): In request/responses/DTDs, 3269 the line width sometimes exceeds what's allowed in an RFC (I think 72 3270 characters). 3272 Resolution (2003-11-04): Added line breaks and/or changed indention 3273 in some of the figures (no change tracking). 3275 C.7 ED_xml_typos 3277 Type: edit 3279 3281 julian.reschke@greenbytes.de (2003-11-03): There were a few typos in 3282 the XML examples 3284 Resolution (2003-11-04): Several XML message bodies fixed (no change 3285 tracking). 3287 C.8 1_ref_options 3289 Type: edit 3291 3292 julian.reschke@greenbytes.de (2003-11-04): "Client discovery of 3293 access control capability using OPTIONS is described in Section 7.1." 3294 The reference should be to "7.2". 3296 Resolution (2003-11-04): Replaced "7.1" with "7.2" 3298 C.9 3.2_ED_RFC2518 3300 Type: edit 3302 3304 julian.reschke@greenbytes.de (2003-11-03): Fix references 3305 ("[WEBDAV]") to RFC2518. 3307 Resolution (2003-11-05): Replaced "[WEBDAV]" by "[RFC2518]". 3309 C.10 3.3_ED_priv_section_titles 3311 Type: edit 3313 3315 julian.reschke@greenbytes.de (2003-11-07): Section titles for 3316 DAV:write-properties, DAV:write-content and DAV:unlock missing word 3317 "Privilege". 3319 Resolution (2003-11-07): Added "Privilege" to the section titles (no 3320 change tracking). 3322 C.11 3.4_write-content-description 3324 Type: change 3326 3328 csharp@mac.com (2003-11-18): If DAV:write-content is just an 3329 aggregate of DAV:bind and DAV:unbind why doesn't it state that "the 3330 client can safely expect that no other privilege needs to be granted 3331 to have access to MKCOL,PUT, DELETE,MOVE, COPY"? If it is not an 3332 aggregate why does it exist? 3334 Resolution (2003-11-18): Update description of DAV:write-content so 3335 that it doesn't refer to collection membership; clarify the 3336 distinction between PUT to an existing reource (modifying content) 3337 and PUT on an unmapped URI (creating a new resource, requiring 3338 privileges on the parent collection). Define aggregation of DAV:bind 3339 and DAV:unbind in 3.12. 3341 C.12 3.12_ED_bad_reference 3343 Type: edit 3345 3347 julian.reschke@greenbytes.de (2003-11-03): section 3.12 talks about 3348 "defined above in Sections 3.1-3.9". I think this should be "defined 3349 above in Sections 3.1-3.11" or simply "defined in above sections" 3351 geoffrey.clemm@us.ibm.com (2003-11-06): For the section 3.12 issue, 3352 I'd prefer to change it to say "Sections 3.1-3.10" (the DAV:all 3353 privilege from section 3.11 should not be included in another 3354 privilege). 3356 Resolution (2003-11-06): Replace "Sections 3.1-3.9" by "Sections 3357 3.1-3.10". 3359 C.13 4.1_ED_RFC2589 3361 Type: edit 3363 3365 julian.reschke@greenbytes.de (2003-11-03): text quotes RFC2589 3366 ("Lightweight Directory Access Protocol (v3): Extensions for Dynamic 3367 Directory Services"), but references section has RFC2251 3368 ("Lightweight Directory Access Protocol (v3)") 3370 geoffrey.clemm@us.ibm.com (2003-11-06): The LDAP reference should be 3371 RFC2251 (not RFC2589). 3373 Resolution (2003-11-06): Replaced "[RFC2589]" by "[RFC2251]". 3375 C.14 5.1_owner_group_details 3377 Type: edit 3379 3381 julian.reschke@greenbytes.de (2003-11-07): State that DAV:owner and 3382 DAV:group MAY be protected. Also state that they MAY be empty if the 3383 server can't provide the information. 3385 Resolution (2003-11-08): Added paragraphs stating both for both 3386 properties. 3388 C.15 5.1_owner_href_optional 3390 Type: edit 3392 3394 julian.reschke@greenbytes.de (2003-11-06): href element should be 3395 optional in case the server doesn't have owner information. 3397 Resolution (2003-11-06): Updated DTD fragment. 3399 C.16 5.1.2_responsedescription 3401 Type: edit 3403 3405 julian.reschke@greenbytes.de (2003-11-07): Add DAV:error element to 3406 DAV:responsedescription in example and update explanation. 3408 Resolution (2003-11-08): DAV:error subelement added to 3409 DAV:responsedescription in response. 3411 C.17 5.5.5_ED_section_numbering 3413 Type: edit 3415 3417 julian.reschke@greenbytes.de (2003-11-03): missing section numbering 3418 for "Example: Retrieving DAV:acl-restrictions" 3420 Resolution (2003-11-04): Added section number (no change tracking). 3422 C.18 5.8_unbind 3424 Type: change 3426 3428 julian.reschke@greenbytes.de (2003-11-03): A:unbind: mismatch between 3429 XML response and privilege tree in figure. 3431 eric.sedlar@oracle.com (2003-11-04): The change in the XML response 3432 should be rolled back. "delete" is a custom privilege in the 3433 example. 3435 Resolution (2003-11-04): Changed example response back to use 3436 A:delete. 3438 C.19 6_ED_RFC3010 3440 Type: edit 3442 3444 julian.reschke@greenbytes.de (2003-11-03): Fix references ("[NFSV4]") 3445 to RFC3010. 3447 Resolution (2003-11-11): Replaced "[NVSV4]" by "[RFC3530]" (which 3448 obsoletes RFC3010). 3450 C.20 6_group_property 3452 Type: change 3454 3456 julian.reschke@greenbytes.de (2003-11-03): in section 6 the following 3457 example is used...: However, there is no such thing as a 3459 DAV:group property. I'm not sure what the best fix for this would 3460 be... If the "group" thing is essential, this may mean that an 3461 important live property is missing? If it's not essential, can this 3462 example rewritten without that property? (Or with a non-DAV: property 3463 from an example namespace?) 3465 geoffry.clemm@us.ibm.com (2003-11-06): Proposal to add DAV:group 3466 property. 3468 eric.sedlar@oracle.com (2003-11-06): I have a problem with adding 3469 this property. If a particular vendor wants to add 3470 that's great, but I think we are going to have minimal 3471 interoperability with this. We discussed this before and weren't 3472 able to find anyone who actually wanted to use this. 3474 Resolution (2003-11-06): Added section 5.2 ("DAV:group"). Subsequent 3475 sections renumbered. 3477 C.21 5.5.2_TYPO 3479 Type: edit 3481 3483 peter.nevermann@softwareag.com (2003-10-22): Precondition 3484 DAV:no-invert should refer to section 5.5.2 for the DAV:no-invert 3485 constraint ... not 6.3.4. 3487 Resolution (2003-11-04): Reference fixed. 3489 C.22 9.4_ED_reference_casemap 3491 Type: edit 3493 3495 julian.reschke@greenbytes.de (2003-11-03): Update [CaseMap] reference 3496 to "[UNICODE4] The Unicode Consortium, "The Unicode Standard - 3497 Version 4.0", Addison-Wesley, August 2003. ISBN 0321185781" (section 3498 5.18). 3500 Resolution (2003-11-06): Removed "[CaseMap]" from references, add 3501 "[UNICODE]" to references. Cite using '...especially Section 2.3 3502 ("Caseless Matching"), Section 5.18, Subsection "Caseless 3503 Matching"...'. 3505 C.23 11_ED_RFC2279 3507 Type: edit 3509 3511 julian.reschke@greenbytes.de (2003-11-03): Replace [UTF-8] by 3512 [RFC2279] for consistency. 3514 Resolution (2003-11-11): Reference name changed both in text and 3515 references section to RFC3629 (update of RFC2279). 3517 C.24 A_ED_appendices 3519 Type: edit 3521 3523 julian.reschke@greenbytes.de (2003-11-03): Appendices should indeed 3524 be appendices, not a regular section (see 3525 draft-rfc-editor-rfc2223bis). 3527 Resolution (2003-11-04): Moved Section 19.1 to Appendix A and Section 3528 19.2 to Appendix B. 3530 Index 3532 A 3533 ACL method 41 3535 C 3536 Condition Names 3537 DAV:allowed-principal (pre) 43 3538 DAV:deny-before-grant (pre) 43 3539 DAV:grant-only (pre) 43 3540 DAV:limited-number-of-aces (pre) 43 3541 DAV:missing-required-principal (pre) 43 3542 DAV:no-abstract (pre) 43 3543 DAV:no-ace-conflict (pre) 42 3544 DAV:no-inherited-ace-conflict (pre) 42 3545 DAV:no-invert (pre) 43 3546 DAV:no-protected-ace-conflict (pre) 42 3547 DAV:not-supported-privilege (pre) 43 3548 DAV:number-of-matches-within-limits (post) 50, 55 3549 DAV:recognized-principal (pre) 43 3551 D 3552 DAV header 3553 compliance class 'access-control' 40 3554 DAV:acl property 24 3555 DAV:acl-principal-prop-set report 49 3556 DAV:acl-restrictions property 28 3557 DAV:all privilege 13 3558 DAV:allowed-principal precondition 43 3559 DAV:alternate-URI-set property 14 3560 DAV:bind privilege 13 3561 DAV:current-user-privilege-set property 22 3562 DAV:deny-before-grant precondition 43 3563 DAV:grant-only precondition 43 3564 DAV:group property 18 3565 DAV:group-member-set property 15 3566 DAV:group-membership property 15 3567 DAV:inherited-acl-set property 31 3568 DAV:limited-number-of-aces precondition 43 3569 DAV:missing-required-principal precondition 43 3570 DAV:no-abstract precondition 43 3571 DAV:no-ace-conflict precondition 42 3572 DAV:no-inherited-ace-conflict precondition 42 3573 DAV:no-invert precondition 43 3574 DAV:no-protected-ace-conflict precondition 42 3575 DAV:not-supported-privilege precondition 43 3576 DAV:number-of-matches-within-limits postcondition 50, 55 3577 DAV:owner property 16 3578 DAV:principal resource type 14 3579 DAV:principal-collection-set property 31 3580 DAV:principal-match report 51 3581 DAV:principal-property-search 53 3582 DAV:principal-search-property-set 58 3583 DAV:principal-URL property 15 3584 DAV:read privilege 10 3585 DAV:read-acl privilege 12 3586 DAV:read-current-user-privilege-set privilege 12 3587 DAV:recognized-principal precondition 43 3588 DAV:supported-privilege-set property 19 3589 DAV:unbind privilege 13 3590 DAV:unlock privilege 12 3591 DAV:write privilege 11 3592 DAV:write-acl privilege 13 3593 DAV:write-content privilege 11 3594 DAV:write-properties privilege 11 3596 M 3597 Methods 3598 ACL 41 3600 P 3601 Privileges 3602 DAV:all 13 3603 DAV:bind 13 3604 DAV:read 10 3605 DAV:read-acl 12 3606 DAV:read-current-user-privilege-set 12 3607 DAV:unbind 13 3608 DAV:unlock 12 3609 DAV:write 11 3610 DAV:write-acl 13 3611 DAV:write-content 11 3612 DAV:write-properties 11 3613 Properties 3614 DAV:acl 24 3615 DAV:acl-restrictions 28 3616 DAV:alternate-URI-set 14 3617 DAV:current-user-privilege-set 22 3618 DAV:group 18 3619 DAV:group-member-set 15 3620 DAV:group-membership 15 3621 DAV:inherited-acl-set 31 3622 DAV:owner 16 3623 DAV:principal-collection-set 31 3624 DAV:principal-URL 15 3625 DAV:supported-privilege-set 19 3627 R 3628 Reports 3629 DAV:acl-principal-prop-set 49 3630 DAV:principal-match 51 3631 DAV:principal-property-search 53 3632 DAV:principal-search-property-set 58 3633 Resource Types 3634 DAV:principal 14 3636 Intellectual Property Statement 3638 The IETF takes no position regarding the validity or scope of any 3639 intellectual property or other rights that might be claimed to 3640 pertain to the implementation or use of the technology described in 3641 this document or the extent to which any license under such rights 3642 might or might not be available; neither does it represent that it 3643 has made any effort to identify any such rights. Information on the 3644 IETF's procedures with respect to rights in standards-track and 3645 standards-related documentation can be found in BCP-11. Copies of 3646 claims of rights made available for publication and any assurances of 3647 licenses to be made available, or the result of an attempt made to 3648 obtain a general license or permission for the use of such 3649 proprietary rights by implementors or users of this specification can 3650 be obtained from the IETF Secretariat. 3652 The IETF invites any interested party to bring to its attention any 3653 copyrights, patents or patent applications, or other proprietary 3654 rights which may cover technology that may be required to practice 3655 this standard. Please address the information to the IETF Executive 3656 Director. 3658 Full Copyright Statement 3660 Copyright (C) The Internet Society (2003). All Rights Reserved. 3662 This document and translations of it may be copied and furnished to 3663 others, and derivative works that comment on or otherwise explain it 3664 or assist in its implementation may be prepared, copied, published 3665 and distributed, in whole or in part, without restriction of any 3666 kind, provided that the above copyright notice and this paragraph are 3667 included on all such copies and derivative works. However, this 3668 document itself may not be modified in any way, such as by removing 3669 the copyright notice or references to the Internet Society or other 3670 Internet organizations, except as needed for the purpose of 3671 developing Internet standards in which case the procedures for 3672 copyrights defined in the Internet Standards process must be 3673 followed, or as required to translate it into languages other than 3674 English. 3676 The limited permissions granted above are perpetual and will not be 3677 revoked by the Internet Society or its successors or assignees. 3679 This document and the information contained herein is provided on an 3680 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3681 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3682 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3683 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3684 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3686 Acknowledgment 3688 Funding for the RFC Editor function is currently provided by the 3689 Internet Society.