idnits 2.17.1 draft-ietf-webdav-acl-09.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 15 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2331 has weird spacing: '...contain 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 (July 26, 2002) is 7945 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: 'WEBDAV' is mentioned on line 460, but not defined == Missing Reference: 'RFC2589' is mentioned on line 610, but not defined == Unused Reference: 'RFC2368' is defined on line 2852, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 2863, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 2869, 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-NAMES' -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-XML-INFOSET' ** 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 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) -- Obsolete informational reference (is this intentional?): RFC 2255 (Obsoleted by RFC 4510, RFC 4516) -- Obsolete informational reference (is this intentional?): RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Geoffrey Clemm, Rational Software 2 draft-ietf-webdav-acl-09 Anne Hopkins, Microsoft Corporation 3 Eric Sedlar, Oracle Corporation 4 Jim Whitehead, U.C. Santa Cruz 6 Expires January 26, 2003 July 26, 2002 8 WebDAV Access Control Protocol 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Abstract 28 This document specifies a set of methods, headers, message bodies, 29 properties, and reports that define Access Control extensions to the 30 WebDAV Distributed Authoring Protocol. This protocol permits a client 31 to read and modify access control lists that instruct a server 32 whether to allow or deny operations upon a resource (such as 33 HyperText Transfer Protocol (HTTP) method invocations) by a given 34 principal. A lightweight representation of principals as Web 35 resources supports integration of a wide range of user management 36 repositories. Search operations allow discovery and manipulation of 37 principals using human names. 39 This document is a product of the Web Distributed Authoring and 40 Versioning (WebDAV) working group of the Internet Engineering Task 41 Force. Comments on this draft are welcomed, and should be addressed 42 to the acl@webdav.org mailing list. Other related documents can be 43 found at http://www.webdav.org/acl/, and 44 http://www.ics.uci.edu/pub/ietf/webdav/. 46 Table of Contents 48 1 INTRODUCTION....................................................4 49 1.1 Terms.........................................................7 50 1.2 Notational Conventions........................................8 52 2 PRINCIPALS......................................................8 54 3 PRIVILEGES......................................................9 55 3.1 DAV:read Privilege...........................................10 56 3.2 DAV:write Privilege..........................................10 57 3.3 DAV:write-properties.........................................10 58 3.4 DAV:write-content............................................11 59 3.5 DAV:unlock...................................................11 60 3.6 DAV:read-acl Privilege.......................................12 61 3.7 DAV:read-current-user-privilege-set Privilege................12 62 3.8 DAV:write-acl Privilege......................................12 63 3.9 DAV:all Privilege............................................12 64 3.10 Aggregation of Predefined Privileges........................12 66 4 PRINCIPAL PROPERTIES...........................................13 67 4.1 DAV:alternate-URI-set........................................14 68 4.2 DAV:principal-URL............................................14 69 4.3 DAV:group-member-set.........................................14 70 4.4 DAV:group-membership.........................................14 72 5 ACCESS CONTROL PROPERTIES......................................15 73 5.1 DAV:owner....................................................15 74 5.1.1 Example: Retrieving DAV:owner............................15 75 5.1.2 Example: An Attempt to Set DAV:owner.....................16 76 5.2 DAV:supported-privilege-set..................................17 77 5.2.1 Example: Retrieving a List of Privileges Supported on a 78 Resource.......................................................18 79 5.3 DAV:current-user-privilege-set...............................20 80 5.3.1 Example: Retrieving the User's Current Set of Assigned 81 Privileges.....................................................21 82 5.4 DAV:acl......................................................22 83 5.4.1 ACE Principal............................................22 84 5.4.2 ACE Grant and Deny.......................................24 85 5.4.3 ACE Protection...........................................24 86 5.4.4 ACE Inheritance..........................................24 87 5.4.5 Example: Retrieving a Resource's Access Control List.....25 88 5.5 DAV:acl-semantics............................................26 89 5.5.1 Example: Retrieving DAV:acl-semantics....................27 90 5.6 DAV:inherited-acl-set........................................28 91 5.7 DAV:principal-collection-set.................................28 92 5.7.1 Example: Retrieving DAV:principal-collection-set.........29 93 5.8 Example: PROPFIND to retrieve access control properties......30 94 6 ACL SEMANTICS..................................................34 95 6.1 ACE Combination..............................................34 96 6.1.1 DAV:first-match ACE Combination..........................34 97 6.1.2 DAV:all-grant-before-any-deny ACE Combination............34 98 6.1.3 DAV:specific-deny-overrides-grant ACE Combination........35 99 6.2 ACE Ordering.................................................35 100 6.2.1 DAV:deny-before-grant ACE Ordering.......................35 101 6.3 Allowed ACE..................................................35 102 6.3.1 DAV:principal-only-one-ace ACE Constraint................35 103 6.3.2 DAV:grant-only ACE Constraint............................35 104 6.3.3 DAV:no-invert ACE Constraint.............................36 105 6.4 Required Principals..........................................36 107 7 ACCESS CONTROL AND EXISTING METHODS............................36 108 7.1 OPTIONS......................................................36 109 7.1.1 Example - OPTIONS........................................36 110 7.2 MOVE.........................................................37 111 7.3 COPY.........................................................37 112 7.4 DELETE.......................................................37 113 7.5 LOCK.........................................................37 115 8 ACCESS CONTROL METHODS.........................................37 116 8.1 ACL..........................................................37 117 8.1.1 ACL Preconditions........................................38 118 8.1.2 Example: the ACL method..................................40 119 8.1.3 Example: ACL method failure due to protected ACE 120 conflict ................................................41 121 8.1.4 Example: ACL method failure due to an inherited ACE 122 conflict ................................................42 123 8.1.5 Example: ACL method failure due to an attempt to set 124 grant and deny in a single ACE ..........................43 126 9 ACCESS CONTROL REPORTS.........................................44 127 9.1 REPORT Method................................................44 128 9.2 DAV:acl-principal-prop-set Report............................44 129 9.2.1 Example: DAV:acl-principal-prop-set Report...............45 130 9.3 DAV:principal-match REPORT...................................46 131 9.3.1 Example: DAV:principal-match REPORT......................48 132 9.4 DAV:principal-property-search REPORT.........................48 133 9.4.1 Matching.................................................51 134 9.4.2 Example: successful DAV:principal-property-search REPORT 51 135 9.4.3 Example: Unsuccessful DAV:principal-property-search 136 REPORT ..................................................53 137 9.5 DAV:principal-search-property-set REPORT.....................54 138 9.5.1 Example: DAV:principal-search-property-set REPORT........56 140 10 XML PROCESSING...............................................57 142 11 INTERNATIONALIZATION CONSIDERATIONS..........................57 143 12 SECURITY CONSIDERATIONS......................................58 144 12.1 Increased Risk of Compromised Users.........................58 145 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set 146 Privileges.......................................................58 147 12.3 No Foreknowledge of Initial ACL.............................59 149 13 AUTHENTICATION...............................................59 151 14 IANA CONSIDERATIONS..........................................60 153 15 INTELLECTUAL PROPERTY........................................60 155 16 ACKNOWLEDGEMENTS.............................................60 157 17 REFERENCES...................................................61 158 17.1 Normative References........................................61 159 17.2 Informational References....................................61 161 18 AUTHORS' ADDRESSES...........................................62 163 19 APPENDICES...................................................63 164 19.1 WebDAV XML Document Type Definition Addendum................63 166 1 INTRODUCTION 168 The goal of the WebDAV access control extensions is to provide an 169 interoperable mechanism for handling discretionary access control 170 for content and metadata managed by WebDAV servers. WebDAV access 171 control can be implemented on content repositories with security as 172 simple as that of a UNIX file system, as well as more sophisticated 173 models. The underlying principle of access control is that who you 174 are determines what operations you can perform on a resource. The 175 "who you are" is defined by a "principal" identifier; users, client 176 software, servers, and groups of the previous have principal 177 identifiers. The "operations you can perform" are determined by a 178 single "access control list" (ACL) associated with a resource. An 179 ACL contains a set of "access control entries" (ACEs), where each 180 ACE specifies a principal and a set of privileges that are either 181 granted or denied to that principal. When a principal submits an 182 operation (such as an HTTP or WebDAV method) to a resource for 183 execution, the server evaluates the ACEs in the ACL to determine if 184 the principal has permission for that operation. 186 Since every ACE contains the identifier of a principal, client 187 software operated by a human must provide a mechanism for selecting 188 this principal. This specification uses http(s) scheme URLs to 189 identify principals, which are represented as WebDAV-capable 190 resources. There is no guarantee that the URLs identifying 191 principals will be meaningful to a human. For example, 192 http://www.dav.org/u/256432 and 193 http://www.dav.org/people/Greg.Stein are both valid URLs that could 194 be used to identify the same principal. To remedy this, every 195 principal resource has the DAV:displayname property containing a 196 human-readable name for the principal. 198 Since a principal can be identified by multiple URLs, it raises the 199 problem of determining exactly which principal is being referenced 200 in a given ACE. It is impossible for a client to determine that an 201 ACE granting the read privilege to 202 http://www.dav.org/people/Greg.Stein also affects the principal at 203 http://www.dav.org/u/256432. That is, a client has no mechanism for 204 determining that two URLs identify the same principal resource. As 205 a result, this specification requires clients to use just one of 206 the many possible URLs for a principal when creating ACEs. A client 207 can discover which URL to use by retrieving the DAV:principal-URL 208 property (Section 4.2) from a principal resource. No matter which 209 of the principal's URLs is used with PROPFIND, the property always 210 returns the same URL. 212 With a system having hundreds to thousands of principals, the 213 problem arises of how to allow a human operator of client software 214 to select just one of these principals. One approach is to use 215 broad collection hierarchies to spread the principals over a large 216 number of collections, yielding few principals per collection. An 217 example of this is a two level hierarchy with the first level 218 containing 36 collections (a-z, 0-9), and the second level being 219 another 36, creating collections /a/a/, /a/b/, ..., /a/z/, such 220 that a principal with last name "Stein" would appear at /s/t/Stein. 221 In effect, this pre-computes a common query, search on last name, 222 and encodes it into a hierarchy. The drawback with this scheme is 223 that it handles only a small set of predefined queries, and 224 drilling down through the collection hierarchy adds unnecessary 225 steps (navigate down/up) when the user already knows the 226 principal's name. While organizing principal URLs into a hierarchy 227 is a valid namespace organization, users should not be forced to 228 navigate this hierarchy to select a principal. 230 This specification provides the capability to perform substring 231 searches over a small set of properties on the resources 232 representing principals. This permits searches based on last name, 233 first name, user name, job title, etc. Two separate searches are 234 supported, both via the REPORT method, one to search principal 235 resources (DAV:principal-property-search, Section 9.4), the other 236 to determine which properties may be searched at all 237 (DAV:principal-search-property-set, Section 9.5). 239 Once a principal has been identified in an ACE, a server evaluating 240 that ACE must know the identity of the principal making a protocol 241 request, and must validate that that principal is who they claim to 242 be, a process known as authentication. This specification 243 intentionally omits discussion of authentication, as the HTTP 244 protocol already has a number of authentication mechanisms 245 [RFC2617]. Some authentication mechanism (such as HTTP Digest 246 Authentication, which all WebDAV compliant implementations are 247 required to support) must be available to validate the identity of 248 a principal. 250 The following issues are out of scope for this document: 252 * Access control that applies only to a particular property on a 253 resource (excepting the access control properties DAV:acl and 254 DAV:current-user-privilege-set), rather than the entire 255 resource, 257 * Role-based security (where a role can be seen as a dynamically 258 defined group of principals), 260 * Specification of the ways an ACL on a resource is initialized, 262 * Specification of an ACL that applies globally to all 263 resources, rather than to a particular resource. 265 * Creation and maintenance of resources representing people or 266 computational agents (principals), and groups of these. 268 This specification is organized as follows. Section 1.1 defines key 269 concepts used throughout the specification, and is followed by a 270 more in-depth discussion of principals (Section 2), and privileges 271 (Section 3). Properties defined on principals are specified in 272 Section 4, and access control properties for content resources are 273 specified in Section 5. The semantics of access control lists are 274 described in Section 6, including sections on ACE combination 275 (Section 6.1), ACE ordering (Section 6.2), and principals required 276 to be present in an ACE (Section 6.3.2). Client discovery of access 277 control capability using OPTIONS is described in Section 7.1. 278 Interactions between access control functionality and existing HTTP 279 and WebDAV methods are described in the remainder of Section 7. The 280 access control setting method, ACL, is specified in Section 8. Four 281 reports that provide limited server-side searching capabilities are 282 described in Section 9. Sections on XML processing (Section 10), 283 Internationalization considerations (Section 11), security 284 considerations (Section 12), and authentication (Section 13) round 285 out the specification. An appendix (Section 19.1) provides an XML 286 Document Type Definition (DTD) for the XML elements defined in the 287 specification. 289 1.1 Terms 291 This draft uses the terms defined in HTTP [RFC2616] and WebDAV 292 [RFC2518]. In addition, the following terms are defined: 294 principal 295 A "principal" is a distinct human or computational actor that 296 initiates access to network resources. In this protocol, a 297 principal is an HTTP resource that represents such an actor. 299 group 300 A "group" is a principal that represents a set of other principals. 302 privilege 303 A "privilege" controls access to a particular set of HTTP 304 operations on a resource. 306 aggregate privilege 307 An "aggregate privilege" is a privilege that contains a set of 308 other privileges. 310 abstract privilege 311 The modifier "abstract", when applied to a privilege on a resource, 312 means the privilege cannot be set in an access control element 313 (ACE) on that resource . 315 access control list (ACL) 316 An "ACL" is a list of access control elements that define access 317 control to a particular resource. 319 access control element (ACE) 320 An "ACE" either grants or denies a particular set of (non-abstract) 321 privileges for a particular principal. 323 inherited ACE 324 An "inherited ACE" is an ACE that is dynamically shared from the 325 ACL of another resource. When a shared ACE changes on the primary 326 resource, it is also changed on inheriting resources. 328 protected property 329 A "protected property" is one whose value cannot be updated except 330 by a method explicitly defined as updating that specific property. 331 In particular, a protected property cannot be updated with a 332 PROPPATCH request. 334 1.2 Notational Conventions 336 The augmented BNF used by this document to describe protocol 337 elements is described in Section 2.1 of [RFC2616]. Because this 338 augmented BNF uses the basic production rules provided in Section 339 2.2 of [RFC2616], those rules apply to this document as well. 341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 342 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 343 this document are to be interpreted as described in [RFC2119]. 345 Definitions of XML elements in this document use XML element type 346 declarations (as found in XML Document Type Declarations), 347 described in Section 3.2 of [REC-XML]. When an XML element type in 348 the "DAV:" namespace is referenced in this document outside of the 349 context of an XML fragment, the string "DAV:" will be prefixed to 350 the element name. 352 2 PRINCIPALS 354 A principal is a network resource that represents a distinct human 355 or computational actor that initiates access to network resources. 356 Users and groups are represented as principals in many 357 implementations; other types of principals are also possible. A URI 358 of any scheme MAY be used to identify a principal resource. 359 However, servers implementing this specification MUST expose 360 principal resources at an http(s) URL, which is a privileged scheme 361 that points to resources that have additional properties, as 362 described in Section 4. So, a principal resource can have multiple 363 URIs, one of which has to be an http(s) scheme URL. Although an 364 implementation SHOULD support PROPFIND and MAY support PROPPATCH to 365 access and modify information about a principal, it is not required 366 to do so. 368 A principal resource may be a group, where a group is a principal 369 that represents a set of other principals, called the members of 370 the group. If a person or computational agent matches a principal 371 resource that is a member of a group, they also match the group. 372 Membership in a group is recursive, so if a principal is a member 373 of group GRPA, and GRPA is a member of group GRPB, then the 374 principal is also a member of GRPB. 376 3 PRIVILEGES 378 Ability to perform a given method on a resource SHOULD be 379 controlled by one or more privileges. Authors of protocol 380 extensions that define new HTTP methods SHOULD specify which 381 privileges (by defining new privileges, or mapping to ones below) 382 are required to perform the method. A principal with no privileges 383 to a resource SHOULD be denied any HTTP access to that resource, 384 unless the principal matches an ACE constructed using the DAV:all, 385 DAV:authenticated, or DAV:unauthenticated pseudo-principals (see 386 Section 5.4.1). 388 Privileges may be containers of other privileges, in which case 389 they are termed "aggregate privileges". If a principal is granted 390 or denied an aggregate privilege, it is semantically equivalent to 391 granting or denying each of the aggregated privileges individually. 392 For example, an implementation may define add-member and remove- 393 member privileges that control the ability to add and remove a 394 member of a group. Since these privileges control the ability to 395 update the state of a group, these privileges would be aggregated 396 by the DAV:write privilege on a group, and granting the DAV:write 397 privilege on a group would also grant the add-member and remove- 398 member privileges. 400 Privileges may be declared to be "abstract" for a given resource, 401 in which case they cannot be set in an ACE on that resource. 402 Aggregate and non-aggregate privileges are both capable of being 403 abstract. Abstract privileges are useful for modeling privileges 404 that otherwise would not be exposed via the protocol. Abstract 405 privileges also provide server implementations with flexibility in 406 implementing the privileges defined in this specification. For 407 example, if a server is incapable of separating the read resource 408 capability from the read ACL capability, it can still model the 409 DAV:read and DAV:read-acl privileges defined in this specification 410 by declaring them abstract, and containing them within a non- 411 abstract aggregate privilege (say, read-all) that holds DAV:read, 412 and DAV:read-acl. In this way, it is possible to set the aggregate 413 privilege, read-all, thus coupling the setting of DAV:read and 414 DAV:read-acl, but it is not possible to set DAV:read, or DAV:read- 415 acl individually. Since aggregate privileges can be abstract, it is 416 also possible to use abstract privileges to group or organize non- 417 abstract privileges. Privilege containment loops are not allowed; 418 therefore, a privilege MUST NOT contain itself. For example, 419 DAV:read cannot contain DAV:read. 421 The set of privileges that apply to a particular resource may vary 422 with the DAV:resourcetype of the resource, as well as between 423 different server implementations. To promote interoperability, 424 however, this specification defines a set of well-known privileges 425 (e.g. DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, DAV:read- 426 current-user-privilege-set, and DAV:all), which can at least be 427 used to classify the other privileges defined on a particular 428 resource. The access permissions on null resources (defined in 429 [RFC2518], Section 3) are solely those they inherit (if any), and 430 they are not discoverable (i.e., the access control properties 431 specified in Section 5 are not defined on null resources). On the 432 transition from null to stateful resource, the initial access 433 control list is set by the server's default ACL value policy (if 434 any). 436 Server implementations MAY define new privileges beyond those 437 defined in this specification. Privileges defined by individual 438 implementations MUST NOT use the DAV: namespace, and instead should 439 use a namespace that they control, such as an http scheme URL. 441 3.1 DAV:read Privilege 443 The read privilege controls methods that return information about 444 the state of the resource, including the resource's properties. 445 Affected methods include GET and PROPFIND. Any implementation- 446 defined privilege that also controls access to GET and PROPFIND 447 must be aggregated under DAV:read�if an ACL grants access to 448 DAV:read, the client may expect that no other privilege needs to be 449 granted to have access to GET and PROPFIND. Additionally, the read 450 privilege MAY control the OPTIONS method. 452 454 3.2 DAV:write Privilege 456 The write privilege controls methods that lock a resource or modify 457 the content, dead properties, or (in the case of a collection) 458 membership of the resource, such as PUT and PROPPATCH. Note that 459 state modification is also controlled via locking (see section 5.3 460 of [WEBDAV]), so effective write access requires that both write 461 privileges and write locking requirements are satisfied. Any 462 implementation-defined privilege that also controls access to 463 methods modifying content, dead properties or collection membership 464 must be aggregated under DAV:write, e.g. if an ACL grants access to 465 DAV:write, the client may expect that no other privilege needs to 466 be granted to have access to PUT and PROPPATCH. 468 470 3.3 DAV:write-properties 472 The DAV:write-properties privilege controls methods that modify the 473 dead properties of the resource, such as PROPPATCH. Whether this 474 privilege may be used to control access to any live properties is 475 determined by the implementation. Any implementation-defined 476 privilege that also controls access to methods modifying dead 477 properties must be aggregated under DAV:write-properties�e.g. if an 478 ACL grants access to DAV:write-properties, the client can safely 479 expect that no other privilege needs to be granted to have access 480 to PROPPATCH. 482 484 3.4 DAV:write-content 486 The DAV:write-content privilege controls methods that modify the 487 content or (in the case of a collection) membership of the 488 resource, such as PUT and DELETE. Any implementation-defined 489 privilege that also controls access to content or alteration of 490 collection membership must be aggregated under DAV:write-content� 491 e.g. if an ACL grants access to DAV:write-content, the client can 492 safely expect that no other privilege needs to be granted to have 493 access to PUT or DELETE. 495 497 3.5 DAV:unlock 499 The DAV:unlock privilege controls the use of the UNLOCK method by a 500 principal other than the lock owner (the principal that created a 501 lock can always perform an UNLOCK). While the set of users who may 502 lock a resource is most commonly the same set of users who may 503 modify a resource, servers may allow various kinds of 504 administrators to unlock resources locked by others. Any privilege 505 controlling access by non-lock owners to UNLOCK MUST be aggregated 506 under DAV:unlock. 508 A lock owner can always remove a lock by issuing an UNLOCK with the 509 correct lock token and authentication credentials. That is, even if 510 a principal does not have DAV:unlock privilege, they can still 511 remove locks they own. Principals other than the lock owner can 512 remove a lock only if they have DAV:unlock privilege and they issue 513 an UNLOCK with the correct lock token. Lock timeout is not affected 514 by the DAV:unlock privilege. 516 517 3.6 DAV:read-acl Privilege 519 The DAV:read-acl privilege controls the use of PROPFIND to retrieve 520 the DAV:acl property of the resource. 522 524 3.7 DAV:read-current-user-privilege-set Privilege 526 The DAV:read-current-user-privilege-set privilege controls the use 527 of PROPFIND to retrieve the DAV:current-user-privilege-set property 528 of the resource. 530 Clients are intended to use this property to visually indicate in 531 their UI items that are dependent on the permissions of a resource, 532 for example, by graying out resources that are not writeable. 534 This privilege is separate from DAV:read-acl because there is a 535 need to allow most users access to the privileges permitted the 536 current user (due to its use in creating the UI), while the full 537 ACL contains information that may not be appropriate for the 538 current authenticated user. As a result, the set of users who can 539 view the full ACL is expected to be much smaller than those who can 540 read the current user privilege set, and hence distinct privileges 541 are needed for each. 543 545 3.8 DAV:write-acl Privilege 547 The DAV:write-acl privilege controls use of the ACL method to 548 modify the DAV:acl property of the resource. 550 552 3.9 DAV:all Privilege 554 DAV:all is an aggregate privilege that contains the entire set of 555 privileges that can be applied to the resource. 557 559 3.10 Aggregation of Predefined Privileges 561 Server implementations are free to aggregate the predefined 562 privileges (defined above in Sections 3.1-3.9) subject to the 563 following limitations: 565 DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-acl, 566 DAV:write-properties, DAV:write-content, or DAV:read-current-user- 567 privilege-set. 569 DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-acl, 570 or DAV:read-current-user-privilege-set. 572 DAV:read-current-user-privilege-set MUST NOT contain DAV:write, 573 DAV:read, DAV:read-acl, or DAV:write-acl. 575 DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read- 576 current-user-privilege-set. 578 DAV:read MUST NOT contain DAV:write, DAV:write-acl, DAV:write- 579 properties, or DAV:write-content. 581 DAV:write MUST contain DAV:write-properties and DAV:write-content. 583 4 PRINCIPAL PROPERTIES 585 Principals are manifested to clients as a WebDAV resource, 586 identified by a URL. A principal MUST have a non-empty 587 DAV:displayname property (defined in Section 13.2 of [RFC2518]), 588 and a DAV:resourcetype property (defined in Section 13.9 of 589 [RFC2518]). Additionally, a principal MUST report the 590 DAV:principal XML element in the value of the DAV:resourcetype 591 property. The element type declaration for DAV:principal is: 593 595 This protocol defines the following additional properties for a 596 principal. Since it can be expensive for a server to retrieve 597 access control information, the name and value of these properties 598 SHOULD NOT be returned by a PROPFIND allprop request (as defined in 599 Section 12.14.1 of [RFC2518]). 601 4.1 DAV:alternate-URI-set 603 This protected property, if non-empty, contains the URIs of network 604 resources with additional descriptive information about the 605 principal. This property identifies additional network resources 606 (i.e., it contains one or more URIs) that may be consulted by a 607 client to gain additional knowledge concerning a principal. One 608 expected use for this property is the storage of an LDAP [RFC2255] 609 scheme URL. A user-agent encountering an LDAP URL could use LDAP 610 [RFC2589] to retrieve additional machine-readable directory 611 information about the principal, and display that information in 612 its user interface. Support for this property is REQUIRED, and the 613 value is empty if no alternate URI exists for the principal. 615 617 4.2 DAV:principal-URL 619 A principal may have many URLs, but there must be one primary URL 620 that clients can use to uniquely identify a principal�the 621 principal-URL. This protected property contains the URL that MUST 622 be used to identify this principal in an ACL request. Support for 623 this property is REQUIRED. 625 627 4.3 DAV:group-member-set 629 This property of a group principal identifies the principals that 630 are direct members of this group. Since a group may be a member of 631 another group, a group may also have indirect members (i.e. the 632 members of its direct members). A URL in the DAV:group-member-set 633 for a principal MUST be the DAV:principal-URL of that principal. 635 637 4.4 DAV:group-membership 639 This protected property identifies the groups in which the 640 principal is directly a member. Note that a server may allow a 641 group to be a member of another group, in which case the DAV:group- 642 membership of those other groups would need to be queried in order 643 to determine the groups in which the principal is indirectly a 644 member. Support for this property is REQUIRED. 646 647 5 ACCESS CONTROL PROPERTIES 649 This specification defines a number of new properties for WebDAV 650 resources. Access control properties may be retrieved just like 651 other WebDAV properties, using the PROPFIND method. Since it is 652 expensive, for many servers, to retrieve access control 653 information, a PROPFIND allprop request (as defined in Section 654 12.14.1 of [RFC2518]) SHOULD NOT return the names and values of the 655 properties defined in this section. 657 HTTP resources that support the WebDAV Access Control Protocol MUST 658 contain the following properties. Null resources (described in 659 Section 3 of [RFC2518]) MUST NOT contain the following properties: 661 5.1 DAV:owner 663 This protected property identifies a particular principal as being 664 the "owner" of the resource. Since the owner of a resource often 665 has special access control capabilities (e.g., the owner frequently 666 has permanent DAV:write-acl privilege), clients might display the 667 resource owner in their user interface. 669 671 5.1.1 Example: Retrieving DAV:owner 673 This example shows a client request for the value of the DAV:owner 674 property from a collection resource with URL 675 http://www.webdav.org/papers/. The principal making the request is 676 authenticated using Digest authentication. The value of DAV:owner 677 is the URL http://www.webdav.org/acl/users/gstein, wrapped in the 678 DAV:href XML element. 680 >> Request << 682 PROPFIND /papers/ HTTP/1.1 683 Host: www.webdav.org 684 Content-type: text/xml; charset="utf-8" 685 Content-Length: xxx 686 Depth: 0 687 Authorization: Digest username="jim", 688 realm="jim@webdav.org", nonce="...", 689 uri="/papers/", response="...", opaque="..." 691 692 693 694 695 696 697 >> Response << 699 HTTP/1.1 207 Multi-Status 700 Content-Type: text/xml; charset="utf-8" 701 Content-Length: xxx 703 704 705 706 http://www.webdav.org/papers/ 707 708 709 710 http://www.webdav.org/acl/users/gstein 711 712 713 HTTP/1.1 200 OK 714 715 716 718 5.1.2 Example: An Attempt to Set DAV:owner 720 The following example shows a client request to modify the value of 721 the DAV:owner property on the resource with URL 722 . Since DAV:owner is a protected 723 property, the server responds with a 207 (Multi-Status) response 724 that contains a 403 (Forbidden) status code for the act of setting 725 DAV:owner. Section 8.2.1 of [RFC2518] describes PROPPATCH status 726 code information, and Section 11 of [RFC2518] describes the Multi- 727 Status response. 729 >> Request << 731 PROPPATCH /papers/ HTTP/1.1 732 Host: www.webdav.org 733 Content-type: text/xml; charset="utf-8" 734 Content-Length: xxx 735 Depth: 0 736 Authorization: Digest username="jim", 737 realm="jim@webdav.org", nonce="...", 738 uri="/papers/", response="...", opaque="..." 740 741 742 743 744 745 http://www.webdav.org/acl/users/jim 746 747 748 749 751 >> Response << 753 HTTP/1.1 207 Multi-Status 754 Content-Type: text/xml; charset="utf-8" 755 Content-Length: xxx 757 758 759 760 http://www.webdav.org/papers/ 761 762 763 HTTP/1.1 403 Forbidden 764 765 Failure to set protected property (DAV:owner) 766 767 768 769 771 5.2 DAV:supported-privilege-set 773 This is a protected property that identifies the privileges defined 774 for the resource. 776 778 Each privilege appears as an XML element, where aggregate 779 privileges list as sub-elements all of the privileges that they 780 aggregate. 782 784 786 An abstract privilege MUST NOT be used in an ACE for that resource. 787 Servers MUST fail an attempt to set an abstract privilege. 789 790 A description is a human-readable description of what this 791 privilege controls access to. Servers MUST indicate the human 792 language of the description using the xml:lang attribute and SHOULD 793 consider the HTTP Accept-Language request header when selecting one 794 of multiple available languages. 796 798 It is envisioned that a WebDAV ACL-aware administrative client 799 would list the supported privileges in a dialog box, and allow the 800 user to choose non-abstract privileges to apply in an ACE. The 801 privileges tree is useful programmatically to map well-known 802 privileges (defined by WebDAV or other standards groups) into 803 privileges that are supported by any particular server 804 implementation. The privilege tree also serves to hide complexity 805 in implementations allowing large number of privileges to be 806 defined by displaying aggregates to the user. 808 5.2.1 Example: Retrieving a List of Privileges Supported on a 809 Resource 811 This example shows a client request for the DAV:supported- 812 privilege-set property on the resource 813 http://www.webdav.org/papers/. The value of the DAV:supported- 814 privilege-set property is a tree of supported privileges (using 815 "[XML Namespace , localname]" to identify each privilege): 817 [DAV:, all] (aggregate, abstract) 818 | 819 +-- [DAV:, read] (aggregate) 820 | 821 +-- [DAV:, read-acl] (abstract) 822 +-- [DAV:, read-current-user-privilege-set] (abstract) 823 | 824 +-- [DAV:, write] (aggregate) 825 | 826 +-- [DAV:, write-acl] (abstract) 827 +-- [DAV:, write-properties] 828 +-- [DAV:, write-content] 829 | 830 +-- [DAV:, unlock] 832 This privilege tree is not normative (except that it reflects the 833 normative aggregation rules given in Section 3.10), and many 834 possible privilege trees are possible. 836 >> Request << 838 PROPFIND /papers/ HTTP/1.1 839 Host: www.webdav.org 840 Content-type: text/xml; charset="utf-8" 841 Content-Length: xxx 842 Depth: 0 843 Authorization: Digest username="gclemm", 844 realm="gclemm@webdav.org", nonce="...", 845 uri="/papers/", response="...", opaque="..." 847 848 849 850 851 852 854 >> Response << 856 HTTP/1.1 207 Multi-Status 857 Content-Type: text/xml; charset="utf-8" 858 Content-Length: xxx 860 861 862 863 http://www.webdav.org/papers/ 864 865 866 867 868 869 870 Any 871 operation 872 873 874 Read any 875 object 876 877 878 879 Read 880 ACL 881 882 883 884 885 886 887 Read current user 888 privilege set property 889 890 891 892 893 Write any 894 object 895 896 897 Write 898 ACL 899 900 901 902 903 Write 904 properties 905 906 907 908 Write resource 909 content 910 911 912 913 914 Unlock 915 resource 916 917 918 919 920 HTTP/1.1 200 OK 921 922 923 925 5.3 DAV:current-user-privilege-set 927 DAV:current-user-privilege-set is a protected property containing 928 the exact set of privileges (as computed by the server) granted to 929 the currently authenticated HTTP user. Aggregate privileges and 930 their contained privileges are listed. A user-agent can use the 931 value of this property to adjust its user interface to make actions 932 inaccessible (e.g., by graying out a menu item or button) for which 933 the current principal does not have permission. This is 934 particularly useful for an access control user interface, which can 935 be constructed without knowing the ACE combining semantics of the 936 server. This property is also useful for determining what 937 operations the current principal can perform, without having to 938 actually execute an operation. 940 941 943 If the current user is granted a specific privilege, that privilege 944 must belong to the set of privileges that may be set on this 945 resource. Therefore, each element in the DAV:current-user- 946 privilege-set property MUST identify a non-abstract privilege from 947 the DAV:supported-privilege-set property. 949 5.3.1 Example: Retrieving the User's Current Set of Assigned 950 Privileges 952 Continuing the example from Section 5.2.1, this example shows a 953 client requesting the DAV:current-user-privilege-set property from 954 the resource with URL http://www.webdav.org/papers/. The username 955 of the principal making the request is "khare", and Digest 956 authentication is used in the request. The principal with username 957 "khare" has been granted the DAV:read privilege. Since the DAV:read 958 privilege contains the DAV:read-acl and DAV:read-current-user- 959 privilege-set privileges (see Section 5.2.1), the principal with 960 username "khare" can read the ACL property, and the DAV:current- 961 user-privilege-set property. However, the DAV:all, DAV:read-acl, 962 DAV:write-acl and DAV:read-current-user-privilege-set privileges 963 are not listed in the value of DAV:current-user-privilege-set, 964 since (for this example) they are abstract privileges. DAV:write is 965 not listed since the principal with username "khare" is not listed 966 in an ACE granting that principal write permission. 968 >> Request << 970 PROPFIND /papers/ HTTP/1.1 971 Host: www.webdav.org 972 Content-type: text/xml; charset="utf-8" 973 Content-Length: xxx 974 Depth: 0 975 Authorization: Digest username="khare", 976 realm="khare@webdav.org", nonce="...", 977 uri="/papers/", response="...", opaque="..." 978 979 980 981 982 983 985 >> Response << 987 HTTP/1.1 207 Multi-Status 988 Content-Type: text/xml; charset="utf-8" 989 Content-Length: xxx 991 992 993 994 http://www.webdav.org/papers/ 995 996 997 998 999 1000 1001 HTTP/1.1 200 OK 1002 1003 1004 1006 5.4 DAV:acl 1008 This is a protected property that specifies the list of access 1009 control entries (ACEs), which define what principals are to get 1010 what privileges for this resource. 1012 1014 Each DAV:ace element specifies the set of privileges to be either 1015 granted or denied to a single principal. If the DAV:acl property 1016 is empty, no principal is granted any privilege. 1018 1021 5.4.1 ACE Principal 1023 The DAV:principal element identifies the principal to which this 1024 ACE applies. 1026 1030 The current user matches DAV:href only if that user is 1031 authenticated as being (or being a member of) the principal 1032 identified by the URL contained by that DAV:href. 1034 The current user always matches DAV:all. 1036 1038 The current user matches DAV:authenticated only if authenticated. 1040 1042 The current user matches DAV:unauthenticated only if not 1043 authenticated. 1045 1047 DAV:all is the union of DAV:authenticated, and DAV:unauthenticated. 1048 For a given request, the user matches either DAV:authenticated, or 1049 DAV:unauthenticated, but not both (that is, DAV:authenticated and 1050 DAV:unauthenticated are disjoint sets). 1052 The current user matches a DAV:property principal in a DAV:acl 1053 property of a resource only if the value of the identified property 1054 of that resource contains at most one DAV:href XML element, the URI 1055 value of DAV:href identifies a principal, and the current user is 1056 authenticated as being (or being a member of) that principal. For 1057 example, if the DAV:property element contained , the 1058 current user would match the DAV:property principal only if the 1059 current user is authenticated as matching the principal identified 1060 by the DAV:owner property of the resource. 1062 1064 Alternately, some servers may support ACEs applying to those users 1065 NOT matching the current principal, e.g. all users not in a 1066 particular group. This can be done by wrapping the DAV:principal 1067 element with DAV:invert. 1069 1070 The current user matches DAV:self in a DAV:acl property of the 1071 resource only if that resource is a principal and that principal 1072 matches the current user or, if the principal is a group, a member 1073 of that group matches the current user. 1075 1077 5.4.2 ACE Grant and Deny 1079 Each DAV:grant or DAV:deny element specifies the set of privileges 1080 to be either granted or denied to the specified principal. A 1081 DAV:grant or DAV:deny element of the DAV:acl of a resource MUST 1082 only contain non-abstract elements specified in the DAV:supported- 1083 privilege-set of that resource. 1085 1086 1087 1089 5.4.3 ACE Protection 1091 A server indicates an ACE is protected by including the 1092 DAV:protected element in the ACE. If the ACL of a resource contains 1093 an ACE with a DAV:protected element, an attempt to remove that ACE 1094 from the ACL MUST fail. 1096 1098 5.4.4 ACE Inheritance 1100 The presence of a DAV:inherited element indicates that this ACE is 1101 inherited from another resource that is identified by the URL 1102 contained in a DAV:href element. An inherited ACE cannot be 1103 modified directly, but instead the ACL on the resource from which 1104 it is inherited must be modified. 1106 Note that ACE inheritance is not the same as ACL initialization. 1107 ACL initialization defines the ACL that a newly created resource 1108 will use (if not specified). ACE inheritance refers to an ACE that 1109 is logically shared - where an update to the resource containing an 1110 ACE will affect the ACE of each resource that inherits that ACE. 1111 The method by which ACLs are initialized or by which ACEs are 1112 inherited is not defined by this document. 1114 1115 5.4.5 Example: Retrieving a Resource's Access Control List 1117 Continuing the example from Sections 5.2.1 and 5.3.1, this example 1118 shows a client requesting the DAV:acl property from the resource 1119 with URL http://www.webdav.org/papers/. There are two ACEs defined 1120 in this ACL: 1122 ACE #1: The group identified by URL 1123 http://www.webdav.org/acl/groups/maintainers (the group of site 1124 maintainers) is granted DAV:write privilege. Since (for this 1125 example) DAV:write contains the DAV:write-acl privilege (see 1126 Section 5.2.1), this means the "maintainers" group can also modify 1127 the access control list. 1129 ACE #2: All principals (DAV:all) are granted the DAV:read 1130 privilege. Since (for this example) DAV:read contains DAV:read-acl 1131 and DAV:read-current-user-privilege-set, this means all users 1132 (including all members of the "maintainers" group) can read the 1133 DAV:acl property and the DAV:current-user-privilege-set property. 1135 >> Request << 1137 PROPFIND /papers/ HTTP/1.1 1138 Host: www.webdav.org 1139 Content-type: text/xml; charset="utf-8" 1140 Content-Length: xxx 1141 Depth: 0 1142 Authorization: Digest username="masinter", 1143 realm="webdav.org", nonce="...", 1144 uri="/papers/", response="...", opaque="..." 1146 1147 1148 1149 1150 1151 1153 >> Response << 1155 HTTP/1.1 207 Multi-Status 1156 Content-Type: text/xml; charset="utf-8" 1157 Content-Length: xxx 1159 1160 1161 1162 http://www.webdav.org/papers/ 1163 1164 1165 1166 1167 1168 http://www.webdav.org/acl/groups/maintainers 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 HTTP/1.1 200 OK 1185 1186 1187 1189 5.5 DAV:acl-semantics 1191 This is a protected property that defines the ACL semantics of the 1192 ACEs specified in the DAV:acl property of this resource. These 1193 semantics define how multiple ACEs that match the current user are 1194 combined, what are the constraints on how ACEs can be ordered, and 1195 which principals must have an ACE. A client user interface could 1196 use the value of this property to provide feedback to a human 1197 operator concerning the impact of proposed changes to an ACL. 1198 Alternately, a client can use this property to help it determine, 1199 before submitting an ACL method invocation, what ACL changes it 1200 needs to make to accomplish a specific goal (or whether that goal 1201 is even achievable on this server). 1203 Since it is not practical to require all implementations to use the 1204 same ACL semantics, the DAV:acl-semantics property is used to 1205 identify the ACL semantics for a particular resource. The DAV:acl- 1206 semantics element is defined in Section 6. 1208 5.5.1 Example: Retrieving DAV:acl-semantics 1210 In this example, the client requests the value of the DAV:acl- 1211 semantics property. Digest authentication provides credentials for 1212 the principal operating the client. In this example, the ACE 1213 combination semantics are DAV:first-match, described in Section 1214 6.1.1, the ACE ordering semantics are not specified (some value 1215 other than DAV:deny-before-grant, described in Section 6.2.1), the 1216 DAV:allowed-ace element states that only one ACE is permitted for 1217 each principal, and an ACE describing the privileges granted the 1218 DAV:all principal must exist in every ACL. 1220 >> Request << 1222 PROPFIND /papers/ HTTP/1.1 1223 Host: www.webdav.org 1224 Content-type: text/xml; charset="utf-8" 1225 Content-Length: xxx 1226 Depth: 0 1227 Authorization: Digest username="srcarter", 1228 realm="srcarter@webdav.org", nonce="...", 1229 uri="/papers/", response="...", opaque="..." 1231 1232 1233 1234 1235 1236 1238 >> Response << 1240 HTTP/1.1 207 Multi-Status 1241 Content-Type: text/xml; charset="utf-8" 1242 Content-Length: xxx 1244 1245 1246 1247 http://www.webdav.org/papers/ 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 HTTP/1.1 200 OK 1264 1265 1266 1268 5.6 DAV:inherited-acl-set 1270 This protected property contains a set of URLs that identify other 1271 resources that also control the access to this resource. To have a 1272 privilege on a resource, not only must the ACL on that resource 1273 (specified in the DAV:acl property of that resource) grant the 1274 privilege, but so must the ACL of each resource identified in the 1275 DAV:inherited-acl-set property of that resource. Effectively, the 1276 privileges granted by the current ACL are ANDed with the privileges 1277 granted by each inherited ACL. 1279 1281 Note that the ACL semantics of a resource are specified in the 1282 DAV:acl-semantics property of that resource, and therefore each 1283 inherited ACL can have different ACL semantics. 1285 5.7 DAV:principal-collection-set 1287 This protected property of a resource contains a set of URLs that 1288 identify the root collections that contain the principals that are 1289 available on the server that implements this resource. A WebDAV 1290 Access Control Protocol user agent could use the contents of 1291 DAV:principal-collection-set to retrieve the DAV:displayname 1292 property (specified in Section 13.2 of [RFC2518]) of all principals 1293 on that server, thereby yielding human-readable names for each 1294 principal that could be displayed in a user interface. 1296 1297 Since different servers can control different parts of the URL 1298 namespace, different resources on the same host MAY have different 1299 DAV:principal-collection-set values. The collections specified in 1300 the DAV:principal-collection-set MAY be located on different hosts 1301 from the resource. The URLs in DAV:principal-collection-set SHOULD 1302 be http or https scheme URLs. For security and scalability reasons, 1303 a server MAY report only a subset of the entire set of known 1304 principal collections, and therefore clients should not assume they 1305 have retrieved an exhaustive listing. Additionally, a server MAY 1306 elect to report none of the principal collections it knows about, 1307 in which case the property value would be empty. 1309 The value of DAV:principal-collection-set gives the scope of the 1310 DAV:principal-property-search REPORT (defined in Section 9.4). 1311 Clients use the DAV:principal-property-search REPORT to populate 1312 their user interface with a list of principals. Therefore, servers 1313 that limit a client's ability to obtain principal information will 1314 interfere with the client's ability to manipulate access control 1315 lists, due to the difficulty of getting the URL of a principal for 1316 use in an ACE. 1318 5.7.1 Example: Retrieving DAV:principal-collection-set 1320 In this example, the client requests the value of the 1321 DAV:principal-collection-set property on the collection resource 1322 identified by URL http://www.webdav.org/papers/. The property 1323 contains the two URLs, http://www.webdav.org/acl/users/ and 1324 http://www.webdav.org/acl/groups/, both wrapped in DAV:href XML 1325 elements. Digest authentication provides credentials for the 1326 principal operating the client. 1328 The client might reasonably follow this request with two separate 1329 PROPFIND requests to retrieve the DAV:displayname property of the 1330 members of the two collections (/acl/users and /acl/groups). This 1331 information could be used when displaying a user interface for 1332 creating access control entries. 1334 >> Request << 1336 PROPFIND /papers/ HTTP/1.1 1337 Host: www.webdav.org 1338 Content-type: text/xml; charset="utf-8" 1339 Content-Length: xxx 1340 Depth: 0 1341 Authorization: Digest username="yarong", 1342 realm="yarong@webdav.org", nonce="...", 1343 uri="/papers/", response="...", opaque="..." 1345 1346 1347 1348 1349 1350 1351 >> Response << 1353 HTTP/1.1 207 Multi-Status 1354 Content-Type: text/xml; charset="utf-8" 1355 Content-Length: xxx 1357 1358 1359 1360 http://www.webdav.org/papers/ 1361 1362 1363 1364 http://www.webdav.org/acl/users/ 1365 http://www.webdav.org/acl/groups/ 1366 1367 1368 HTTP/1.1 200 OK 1369 1370 1371 1373 5.8 Example: PROPFIND to retrieve access control properties 1375 The following example shows how access control information can be 1376 retrieved by using the PROPFIND method to fetch the values of the 1377 DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege- 1378 set, and DAV:acl properties. 1380 >> Request << 1382 PROPFIND /top/container/ HTTP/1.1 1383 Host: www.foo.org 1384 Content-type: text/xml; charset="utf-8" 1385 Content-Length: xxx 1386 Depth: 0 1387 Authorization: Digest username="ejw", 1388 realm="users@foo.org", nonce="...", 1389 uri="/top/container/", response="...", opaque="..." 1391 1392 1393 1394 1395 1396 1397 1398 1399 1401 >> Response << 1403 HTTP/1.1 207 Multi-Status 1404 Content-Type: text/xml; charset="utf-8" 1405 Content-Length: xxx 1407 1408 1411 http://www.foo.org/top/container/ 1412 1413 1414 1415 http://www.foo.org/users/gclemm 1416 1417 1418 1419 1420 Any operation 1421 1422 1423 Read any 1424 object 1425 1426 1427 1428 1429 Write any 1430 object 1431 1432 1433 Create an 1434 object 1435 1436 1437 1438 Update an 1439 object 1440 1441 1442 1443 Delete an 1444 object 1445 1446 1447 1448 1449 Read the ACL 1450 1451 1452 1453 Write the 1454 ACL 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 http://www.foo.org/users/esedlar 1466 1467 1468 1469 1470 1471 1472 1473 1474 http://www.foo.org/groups/marketing 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 http://www.foo.org/top 1492 1493 1494 HTTP/1.1 200 OK 1495 1497 The value of the DAV:owner property is a single DAV:href XML 1498 element containing the URL of the principal that owns this 1499 resource. 1501 The value of the DAV:supported-privilege-set property is a tree of 1502 supported privileges (using "[XML Namespace , localname]" to 1503 identify each privilege): 1505 [DAV:, all] (aggregate, abstract) 1506 | 1507 +-- [DAV:, read] 1508 +-- [DAV:, write] (aggregate, abstract) 1509 | 1510 +-- [http://www.webdav.org/acl, create] 1511 +-- [http://www.webdav.org/acl, update] 1512 +-- [http://www.webdav.org/acl, delete] 1513 +-- [DAV:, read-acl] 1514 +-- [DAV:, write-acl] 1516 The DAV:current-user-privilege-set property contains two 1517 privileges, DAV:read, and DAV:read-acl. This indicates that the 1518 current authenticated user only has the ability to read the 1519 resource, and read the DAV:acl property on the resource. 1521 The DAV:acl property contains a set of four ACEs: 1523 ACE #1: The principal identified by the URL 1524 http://www.foo.org/users/esedlar is granted the DAV:read, 1525 DAV:write, and DAV:read-acl privileges. 1527 ACE #2: The principals identified by the URL 1528 http://www.foo.org/groups/marketing are denied the DAV:read 1529 privilege. In this example, the principal URL identifies a group. 1531 ACE #3: In this ACE, the principal is a property principal, 1532 specifically the DAV:owner property. When evaluating this ACE, the 1533 value of the DAV:owner property is retrieved, and is examined to 1534 see if it contains a DAV:href XML element. If so, the URL within 1535 the DAV:href element is read, and identifies a principal. In this 1536 ACE, the owner is granted DAV:read-acl, and DAV:write-acl 1537 privileges. 1539 ACE #4: This ACE grants the DAV:all principal (all users) the 1540 DAV:read privilege. This ACE is inherited from the resource 1541 http://www.foo.org/top, the parent collection of this resource. 1543 6 ACL SEMANTICS 1545 The ACL semantics define how multiple ACEs that match the current 1546 user are combined, what are the constraints on how ACEs can be 1547 ordered, and which principals must have an ACE. 1549 1552 6.1 ACE Combination 1554 The DAV:ace-combination element defines how privileges from 1555 multiple ACEs that match the current user will be combined to 1556 determine the access privileges for that user. Multiple ACEs may 1557 match the same user because the same principal can appear in 1558 multiple ACEs, because multiple principals can identify the same 1559 user, and because one principal can be a member of another 1560 principal. 1562 1566 6.1.1 DAV:first-match ACE Combination 1568 The ACEs are evaluated in the order in which they appear in the 1569 ACL. If the first ACE that matches the current user does not grant 1570 all the privileges needed for the request, the request MUST fail. 1572 1574 6.1.2 DAV:all-grant-before-any-deny ACE Combination 1576 The ACEs are evaluated in the order in which they appear in the 1577 ACL. If an evaluated ACE denies a privilege needed for the 1578 request, the request MUST fail. If all ACEs have been evaluated 1579 without the user being granted all privileges needed for the 1580 request, the request MUST fail. 1582 1583 6.1.3 DAV:specific-deny-overrides-grant ACE Combination 1585 All ACEs in the ACL are evaluated. An "individual ACE" is one 1586 whose principal matches the current user. A "group ACE" is one 1587 whose principal is a group that has a member that matches the 1588 current user. A privilege is granted if it is granted by an 1589 individual ACE and not denied by an individual ACE, or if it is 1590 granted by a group ACE and not denied by an individual or group 1591 ACE. A request MUST fail if any of its needed privileges are not 1592 granted. 1594 1596 6.2 ACE Ordering 1598 The DAV:ace-ordering element defines a constraint on how the ACEs 1599 can be ordered in the ACL. 1601 1603 6.2.1 DAV:deny-before-grant ACE Ordering 1605 This element indicates that all deny ACEs must precede all grant 1606 ACEs. 1608 1610 6.3 Allowed ACE 1612 The DAV:allowed-ace XML element specifies constraints on what kinds 1613 of ACEs are allowed in an ACL. 1615 1618 6.3.1 DAV:principal-only-one-ace ACE Constraint 1620 This element indicates that a principal can appear in only one ACE 1621 per resource. 1623 1625 6.3.2 DAV:grant-only ACE Constraint 1627 This element indicates that ACEs with deny clauses are not allowed. 1629 1630 6.3.3 DAV:no-invert ACE Constraint 1632 This element indicates that ACEs with the element are not 1633 allowed. 1635 1637 6.4 Required Principals 1639 The required principal elements identify which principals must have 1640 an ACE defined in the ACL. 1642 1646 For example, the following element requires that the ACL contain a 1647 DAV:owner property ACE: 1649 1650 1651 1653 7 ACCESS CONTROL AND EXISTING METHODS 1655 This section defines the impact of access control functionality on 1656 existing methods. 1658 7.1 OPTIONS 1660 If the server supports access control, it MUST return "access- 1661 control" as a field in the DAV response header from an OPTIONS 1662 request on any resource implemented by that server. A value of 1663 "access-control" in the DAV header MUST indicate that the server 1664 supports all MUST level requirements and REQUIRED features 1665 specified in this document. 1667 7.1.1 Example - OPTIONS 1669 >> Request << 1671 OPTIONS /foo.html HTTP/1.1 1672 Host: www.webdav.org 1673 Content-Length: 0 1675 >> Response << 1677 HTTP/1.1 200 OK 1678 DAV: 1, 2, access-control 1679 Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL 1680 In this example, the OPTIONS response indicates that the server 1681 supports access control and that /foo.html can have its access 1682 control list modified by the ACL method. 1684 7.2 MOVE 1686 When a resource is moved from one location to another due to a MOVE 1687 request, the non-inherited and non-protected ACEs in the DAV:acl 1688 property of the resource MUST NOT be modified, or the MOVE request 1689 fails. Handling of inherited and protected ACEs is intentionally 1690 undefined to give server implementations flexibility in how they 1691 implement ACE inheritance and protection. 1693 7.3 COPY 1695 The DAV:acl property on the resource at the destination of a COPY 1696 MUST be the same as if the resource was created by an individual 1697 resource creation request (e.g. MKCOL, PUT). Clients wishing to 1698 preserve the DAV:acl property across a copy need to read the 1699 DAV:acl property prior to the COPY, then perform an ACL operation 1700 on the new resource at the destination to restore, insofar as this 1701 is possible, the original access control list. 1703 7.4 DELETE 1705 The precise combination of privileges and resources necessary to 1706 permit the DELETE method is intentionally left to the discretion of 1707 each server implementation. It is envisioned that on some servers, 1708 DELETE will require write permission on the collection containing 1709 the resource to be deleted. On other servers, it might also 1710 require write permission on the resource being deleted. 1712 7.5 LOCK 1714 A lock on a resource ensures that only the lock owner can modify 1715 ACEs that are not inherited and not protected (these are the only 1716 ACEs that a client can modify with an ACL request). A lock does not 1717 protect inherited or protected ACEs, since a client cannot modify 1718 them with an ACL request on that resource. 1720 8 ACCESS CONTROL METHODS 1722 8.1 ACL 1724 The ACL method modifies the access control list (which can be read 1725 via the DAV:acl property) of a resource. Specifically, the ACL 1726 method only permits modification to ACEs that are not inherited, 1727 and are not protected. An ACL method invocation modifies all non- 1728 inherited and non-protected ACEs in a resource's access control 1729 list to exactly match the ACEs contained within in the DAV:acl XML 1730 element (specified in Section 5.4) of the request body. An ACL 1731 request body MUST contain only one DAV:acl XML element. Unless the 1732 non-inherited and non-protected ACEs of the DAV:acl property of the 1733 resource can be updated to be exactly the value specified in the 1734 ACL request, the ACL request MUST fail. 1736 It is possible that the ACEs visible to the current user in the 1737 DAV:acl property may only be a portion of the complete set of ACEs 1738 on that resource. If this is the case, an ACL request only modifies 1739 the set of ACEs visible to the current user, and does not affect 1740 any non-visible ACE. 1742 In order to avoid overwriting DAV:acl changes by another client, a 1743 client SHOULD acquire a WebDAV lock on the resource before 1744 retrieving the DAV:acl property of a resource that it intends on 1745 updating. 1747 Implementation Note: Two common operations are to add or remove 1748 an ACE from an existing access control list. To accomplish this, 1749 a client uses the PROPFIND method to retrieve the value of the 1750 DAV:acl property, then parses the returned access control list 1751 to remove all inherited and protected ACEs (these ACEs are 1752 tagged with the DAV:inherited and DAV:protected XML elements). 1753 In the remaining set of non-inherited, non-protected ACEs, the 1754 client can add or remove one or more ACEs before submitting the 1755 final ACE set in the request body of the ACL method. 1757 8.1.1 ACL Preconditions 1759 An implementation MAY enforce one or more of the following 1760 constraints on an ACL request. If the constraint is violated, a 1761 403 (Forbidden) or 409 (Conflict) response MUST be returned and the 1762 indicated XML element MUST be returned as a child of a top level 1763 DAV:error element in an XML response body. 1765 (DAV:no-ace-conflict): The ACEs submitted in the ACL request MUST 1766 NOT conflict with each other. What is considered a conflict 1767 depends on the ACL semantics of that resource. 1769 (DAV:no-protected-ace-conflict): The ACEs submitted in the ACL 1770 request MUST NOT conflict with the protected ACEs on the resource. 1771 For example, if the resource has a protected ACE granting DAV:write 1772 to a given principal, then it would not be consistent if the ACL 1773 request submitted an ACE denying DAV:write to the same principal. 1775 (DAV:no-inherited-ace-conflict): The ACEs submitted in the ACL 1776 request MUST NOT conflict with the inherited ACEs on the resource. 1777 For example, if the resource inherits an ACE from its parent 1778 collection granting DAV:write to a given principal, then it would 1779 not be consistent if the ACL request submitted an ACE denying 1780 DAV:write to the same principal. Note that reporting of this error 1781 will be implementation-dependent. Implementations have the choice 1782 to either report this error, or to allow the ACE to be set, and 1783 then let normal ACE evaluation rules determine whether the new ACE 1784 has any impact on the privileges available to a specific principal. 1786 (DAV:limited-number-of-aces): The number of ACEs submitted in the 1787 ACL request MUST NOT exceed the number of ACEs allowed on that 1788 resource. However, ACL-compliant servers MUST support at least one 1789 ACE granting privileges to a single principal, and one ACE granting 1790 privileges to a group. 1792 (DAV:deny-before-grant): All non-inherited deny ACEs MUST precede 1793 all non-inherited grant ACEs. 1795 (DAV:principal-only-one-ace): The ACL request MUST NOT result in 1796 more than one ACE for a given principal. This precondition applies 1797 only when the ACL semantics of the resource includes the 1798 DAV:principal-only-one-ace constraint (defined in Section 6.3.1). 1800 (DAV:grant-only): The ACEs submitted in the ACL request MUST NOT 1801 include a deny ACE. This precondition applies only when the ACL 1802 semantics of the resource includes the DAV:grant-only constraint 1803 (defined in Section 6.3.2). 1805 (DAV:no-invert): The ACL request MUST NOT include a DAV:invert 1806 element. This precondition applies only when the ACL semantics of 1807 the resource includes the DAV:no-invert constraint (defined in 1808 Section 6.3.4). 1810 (DAV:no-abstract): The ACL request MUST NOT attempt to grant or 1811 deny an abstract privilege (see Section 5.2). 1813 (DAV:not-supported-privilege): The ACEs submitted in the ACL 1814 request MUST be supported by the resource. 1816 (DAV:missing-required-principal): The result of the ACL request 1817 MUST have at least one ACE for each principal identified in a 1818 DAV:required-principal XML element in the ACL semantics of that 1819 resource (see Section 6.3.2). 1821 (DAV:recognized-principal): Every principal URL in the ACL request 1822 MUST identify a principal resource. 1824 (DAV:allowed-principal): The principals specified in the ACEs 1825 submitted in the ACL request MUST be allowed as principals for the 1826 resource. For example, a server where only authenticated principals 1827 can access resources would not allow the DAV:all or 1828 DAV:unauthenticated principals to be used in an ACE, since these 1829 would allow unauthenticated access to resources. 1831 8.1.2 Example: the ACL method 1833 In the following example, user "fielding", authenticated by 1834 information in the Authorization header, grants the principal 1835 identified by the URL http://www.foo.org/users/esedlar (i.e., the 1836 user "esedlar") read and write privileges, grants the owner of the 1837 resource read-acl and write-acl privileges, and grants everyone 1838 read privileges. 1840 >> Request << 1842 ACL /top/container/ HTTP/1.1 1843 Host: www.foo.org 1844 Content-Type: text/xml; charset="utf-8" 1845 Content-Length: xxxx 1846 Authorization: Digest username="fielding", 1847 realm="users@foo.org", nonce="...", 1848 uri="/top/container/", response="...", opaque="..." 1850 1851 1852 1853 1854 http://www.foo.org/users/esedlar 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1877 >> Response << 1879 HTTP/1.1 200 OK 1881 8.1.3 Example: ACL method failure due to protected ACE conflict 1883 In the following request, user "fielding", authenticated by 1884 information in the Authorization header, attempts to deny the 1885 principal identified by the URL http://www.foo.org/users/esedlar 1886 (i.e., the user "esedlar") write privileges. Prior to the request, 1887 the DAV:acl property on the resource contained a protected ACE (see 1888 Section 5.4.3) granting DAV:owner the DAV:read and DAV:write 1889 privileges. The principal identified by URL 1890 http://www.foo.org/users/esedlar is the owner of the resource. The 1891 ACL method invocation fails because the submitted ACE conflicts 1892 with the protected ACE, thus violating the semantics of ACE 1893 protection. 1895 >> Request << 1897 ACL /top/container/ HTTP/1.1 1898 Host: www.foo.org 1899 Content-Type: text/xml; charset="utf-8" 1900 Content-Length: xxxx 1901 Authorization: Digest username="fielding", 1902 realm="users@foo.org", nonce="...", 1903 uri="/top/container/", response="...", opaque="..." 1905 1906 1907 1908 1909 http://www.foo.org/users/esedlar 1910 1911 1912 1913 1914 1915 1917 >> Response << 1919 HTTP/1.1 403 Forbidden 1920 Content-Type: text/xml; charset="utf-8" 1921 Content-Length: xxx 1923 1924 1925 1926 1928 8.1.4 Example: ACL method failure due to an inherited ACE conflict 1930 In the following request, user "ejw", authenticated by information 1931 in the Authorization header, tries to change the access control 1932 list on the resource http://www.foo.org/top/index.html. This 1933 resource has two inherited ACEs. 1935 Inherited ACE #1 grants the principal identified by URL 1936 http://www.foo.org/users/ejw (i.e., the user "ejw") 1937 http://www.foo.org/privs/write-all and DAV:read-acl privileges. On 1938 this server, http://www.foo.org/privs/write-all is an aggregate 1939 privilege containing DAV:write, and DAV:write-acl. 1941 Inherited ACE #2 grants principal DAV:all the DAV:read privilege. 1943 The request attempts to set a (non-inherited) ACE, denying the 1944 principal identified by the URL http://www.foo.org/users/ejw (i.e., 1945 the user "ejw") DAV:write permission. This conflicts with inherited 1946 ACE #1. Note that the decision to report an inherited ACE conflict 1947 is specific to this server implementation. Another server 1948 implementation could have allowed the new ACE to be set, and then 1949 used normal ACE evaluation rules to determine whether the new ACE 1950 has any impact on the privileges available to a principal. 1952 >> Request << 1954 ACL /top/index.html HTTP/1.1 1955 Host: www.foo.org 1956 Content-Type: text/xml; charset="utf-8" 1957 Content-Length: xxxx 1958 Authorization: Digest username="ejw", 1959 realm="users@foo.org", nonce="...", 1960 uri="/top/index.html", response="...", opaque="..." 1962 1963 1964 1965 1966 http://www.foo.org/users/ejw 1967 1968 1969 1970 1972 >> Response << 1974 HTTP/1.1 403 Forbidden 1975 Content-Type: text/xml; charset="utf-8" 1976 Content-Length: xxx 1978 1979 1980 1981 1983 8.1.5 Example: ACL method failure due to an attempt to set grant and 1984 deny in a single ACE. 1986 In this example, user "ygoland", authenticated by information in 1987 the Authorization header, tries to change the access control list 1988 on the resource http://www.foo.org/diamond/engagement-ring.gif. The 1989 ACL request includes a single, syntactically and semantically 1990 incorrect ACE, which attempts to grant the group identified by the 1991 URL http://www.foo.org/users/friends DAV:read privilege and deny 1992 the principal identified by URL http://www.foo.org/users/ygoland-so 1993 (i.e., the user "ygoland-so") DAV:read privilege. However, it is 1994 illegal to have multiple principal elements, as well as both a 1995 grant and deny element in the same ACE, so the request fails due to 1996 poor syntax. 1998 >> Request << 2000 ACL /diamond/engagement-ring.gif HTTP/1.1 2001 Host: www.foo.org 2002 Content-Type: text/xml; charset="utf-8" 2003 Content-Length: xxxx 2004 Authorization: Digest username="ygoland", 2005 realm="users@foo.org", nonce="...", 2006 uri="/diamond/engagement-ring.gif", response="...", opaque="..." 2008 2009 2010 2011 2012 http://www.foo.org/users/friends 2013 2014 2015 2016 http://www.foo.org/users/ygoland-so 2017 2018 2019 2020 2022 >> Response << 2024 HTTP/1.1 400 Bad Request 2025 Content-Length: 0 2027 Note that if the request had been divided into two ACEs, one to 2028 grant, and one to deny, the request would have been syntactically 2029 well formed. 2031 9 ACCESS CONTROL REPORTS 2033 9.1 REPORT Method 2035 The REPORT method (defined in Section 3.6 of [RFC3253]) provides an 2036 extensible mechanism for obtaining information about a resource. 2037 Unlike the PROPFIND method, which returns the value of one or more 2038 named properties, the REPORT method can involve more complex 2039 processing. REPORT is valuable in cases where the server has access 2040 to all of the information needed to perform the complex request 2041 (such as a query), and where it would require multiple requests for 2042 the client to retrieve the information needed to perform the same 2043 request. 2045 A server that supports the WebDAV Access Control Protocol MUST 2046 support the DAV:expand-property report (defined in Section 3.8 of 2047 [RFC3253]). 2049 9.2 DAV:acl-principal-prop-set Report 2051 The DAV:acl-principal-prop-set report returns, for all principals 2052 in the DAV:acl property (of the Request-URI) that are identified by 2053 http(s) URLs or by a DAV:property principal, the value of the 2054 properties specified in the REPORT request body. In the case where 2055 a principal URL appears multiple times, the DAV:acl-principal-prop- 2056 set report MUST return the properties for that principal only once. 2057 Support for this report is REQUIRED. 2059 One expected use of this report is to retrieve the human readable 2060 name (found in the DAV:displayname property) of each principal 2061 found in an ACL. This is useful for constructing user interfaces 2062 that show each ACE in a human readable form. 2064 Marshalling 2065 The request body MUST be a DAV:acl-principal-prop-set XML element. 2067 2068 ANY value: a sequence of one or more elements, with at most one 2069 DAV:prop element. 2070 prop: see RFC 2518, Section 12.11 2072 This report is only defined when the Depth header has value "0"; 2073 other values result in a 400 (Bad Request) error response. Note 2074 that [RFC3253], Section 3.6, states that if the Depth header is not 2075 present, it defaults to a value of "0". 2077 The response body for a successful request MUST be a 2078 DAV:multistatus XML element (i.e., the response uses the same 2079 format as the response for PROPFIND). 2081 multistatus: see RFC 2518, Section 12.9 2083 The response body for a successful DAV:acl-principal-prop-set 2084 REPORT request MUST contain a DAV:response element for each 2085 principal identified by an http(s) URL listed in a DAV:principal 2086 XML element of an ACE within the DAV:acl property of the resource 2087 identified by the Request-URI. 2089 9.2.1 Example: DAV:acl-principal-prop-set Report 2091 Resource http://www.webdav.org/index.html has an ACL with three 2092 ACEs: 2094 ACE #1: All principals (DAV:all) have DAV:read and DAV:read- 2095 current-user-privilege-set access. 2097 ACE #2: The principal identified by 2098 http://www.webdav.org/people/gstein (the user "gstein") is granted 2099 DAV:write, DAV:write-acl, DAV:read-acl privileges. 2101 ACE #3: The group identified by 2102 http://www.webdav.org/groups/authors (the "authors" group) is 2103 granted DAV:write and DAV:read-acl privileges. 2105 The following example shows a DAV:acl-principal-prop-set report 2106 requesting the DAV:displayname property. It returns the value of 2107 DAV:displayname for resources http://www.webdav.org/people/gstein 2108 and http://www.webdav.org/groups/authors , but not for DAV:all, 2109 since this is not an http(s) URL. 2111 >> Request << 2113 REPORT /index.html HTTP/1.1 2114 Host: www.webdav.org 2115 Content-Type: text/xml; charset="utf-8" 2116 Content-Length: xxxx 2117 Depth: 0 2119 2120 2121 2122 2123 2124 2126 >> Response << 2128 HTTP/1.1 207 Multi-Status 2129 Content-Type: text/xml; charset="utf-8" 2130 Content-Length: xxxx 2132 2133 2134 2135 http://www.webdav.org/people/gstein 2136 2137 2138 Greg Stein 2139 2140 HTTP/1.1 200 OK 2141 2142 2143 2144 http://www.webdav.org/groups/authors 2145 2146 2147 Site authors 2148 2149 HTTP/1.1 200 OK 2150 2151 2152 2154 9.3 DAV:principal-match REPORT 2156 The DAV:principal-match REPORT is used to identify all members (at 2157 any depth) of the collection identified by the Request-URI that 2158 match the current user. In particular, if the collection contains 2159 principals, the report can be used to identify all members of the 2160 collection that match the current user. Alternatively, if the 2161 collection contains resources that have a property that identifies 2162 a principal (e.g. DAV:owner), the report can be used to identify 2163 all members of the collection whose property identifies a principal 2164 that matches the current user. For example, this report can return 2165 all of the resources in a collection hierarchy that are owned by 2166 the current user. Support for this report is REQUIRED. 2168 Marshalling: 2169 The request body MUST be a DAV:principal-match XML element. 2171 2172 2173 ANY value: an element whose value identifies a property. The 2174 expectation is the value of the named property typically contains 2175 an href element that contains the URI of a principal 2176 2177 prop: see RFC 2518, Section 12.11 2179 This report is only defined when the Depth header has value "0"; 2180 other values result in a 400 (Bad Request) error response. Note 2181 that [RFC3253], Section 3.6, states that if the Depth header is not 2182 present, it defaults to a value of "0". 2184 The response body for a successful request MUST be a 2185 DAV:multistatus XML element. 2187 multistatus: see RFC 2518, Section 12.9 2189 The response body for a successful DAV:principal-match REPORT 2190 request MUST contain a DAV:response element for each member of the 2191 collection that matches the current user. When the DAV:principal- 2192 property element is used, a match occurs if the current user is 2193 matched by the principal identified by the URI found in the 2194 DAV:href element of the property identified by the DAV:principal- 2195 property element. When the DAV:self element is used in a 2196 DAV:principal-match report issued against a group, it matches a 2197 member of the group if that child (a principal resource) identifies 2198 the same principal as the current user. 2200 If DAV:prop is specified in the request body, the properties 2201 specified in the DAV:prop element MUST be reported in the 2202 DAV:response elements. 2204 9.3.1 Example: DAV:principal-match REPORT 2206 The following example identifies the members of the collection 2207 identified by the URL http://www.webdav.org/doc that are owned by 2208 the current user. The current user ("gclemm") is authenticated 2209 using Digest authentication. 2211 >> Request << 2213 REPORT /doc/ HTTP/1.1 2214 Host: www.webdav.org 2215 Authorization: Digest username="gclemm", 2216 realm="gclemm@webdav.org", nonce="...", 2217 uri="/papers/", response="...", opaque="..." 2218 Content-Type: text/xml; charset="utf-8" 2219 Content-Length: xxxx 2220 Depth: 0 2222 2223 2224 2225 2226 2227 2229 >> Response << 2231 HTTP/1.1 207 Multi-Status 2232 Content-Type: text/xml; charset="utf-8" 2233 Content-Length: xxxx 2235 2236 2237 2238 http://www.webdav.org/doc/foo.html 2239 HTTP/1.1 200 OK 2240 2241 2242 http://www.webdav.org/doc/img/bar.gif 2243 HTTP/1.1 200 OK 2244 2245 2247 9.4 DAV:principal-property-search REPORT 2249 The DAV:principal-property-search REPORT performs a search for all 2250 principals whose properties contain character data that matches the 2251 search criteria specified in the request. One expected use of this 2252 report is to discover the URL of a principal associated with a 2253 given person or group by searching for them by name. This is done 2254 by searching over DAV:displayname, which is defined on all 2255 principals. 2257 The actual search method (exact matching vs. substring matching vs, 2258 prefix-matching, case-sensitivity) deliberately is left to the 2259 server implementation to allow implementation on a wide set of 2260 possible user management systems. In cases where the implementation 2261 of DAV:principal-property-search is not constrained by the 2262 semantics of an underlying user management repository, preferred 2263 default semantics are caseless substring matches. 2265 For implementation efficiency, servers do not typically support 2266 searching on all properties. A client can discover the set of 2267 searchable properties by using the DAV:principal-search-property- 2268 set REPORT, defined in Section 9.5. 2270 Support for the DAV:principal-property-search report is REQUIRED. 2272 Implementation Note: The value of a WebDAV property is a 2273 sequence of well-formed XML, and hence can include any character 2274 in the Unicode/ISO-10646 standard, that is, most known 2275 characters in human languages. Due to the idiosyncrasies of case 2276 mapping across human languages, implementation of case- 2277 insensitive matching is non-trivial. Implementors of servers 2278 that do perform substring matching are strongly encouraged to 2279 consult [CaseMap], especially Section 2.3 ("Caseless Matching"), 2280 for guidance when implementing their case-insensitive matching 2281 algorithms. 2283 Implementation Note: Some implementations of this protocol will 2284 use an LDAP repository for storage of principal metadata. The 2285 schema describing each attribute (akin to a WebDAV property) in 2286 an LDAP repository specifies whether it supports case-sensitive 2287 or caseless searching. One of the benefits of leaving the search 2288 method to the discretion of the server implementation is the 2289 default LDAP attribute search behavior can be used when 2290 implementing the DAV:principal-property-search report. 2292 Marshalling: 2293 The request body MUST be a DAV:principal-property-search XML 2294 element containing a search specification and an optional list of 2295 properties. For every principal that matches the search 2296 specification, the response will contain the value of the requested 2297 properties on that principal. 2299 2301 By default, the report searches all members (at any depth) of the 2302 collection identified by the Request-URI. If DAV:apply-to- 2303 principal-collection-set is specified in the request body, the 2304 request is applied instead to each collection identified by the 2305 DAV:prinicipal-collection-set property of the resource identified 2306 by the Request-URI. 2308 The DAV:property-search element contains a prop element enumerating 2309 the properties to be searched and a match element, containing the 2310 search string. 2312 2313 prop: see RFC 2518, Section 12.11 2315 2317 Multiple property-search elements or multiple elements within a 2318 DAV:prop element will be interpreted with a logical AND. 2320 This report is only defined when the Depth header has value "0"; 2321 other values result in a 400 (Bad Request) error response. Note 2322 that [RFC3253], Section 3.6, states that if the Depth header is not 2323 present, it defaults to a value of "0". 2325 The response body for a successful request MUST be a 2326 DAV:multistatus XML element. 2328 multistatus: see RFC 2518, Section 12.9 2330 The response body for a successful DAV:principal-property-search 2331 REPORT request MUST contain a DAV:response element for each 2332 principal whose property values satisfy the search specification 2333 given in DAV:principal-property-search. 2335 The response body for an unsuccessful DAV:principal-property-search 2336 REPORT request MUST contain, after the XML element indicating the 2337 failed precondition or postcondition, a DAV:prop element containing 2338 the property that caused the pre/postcondition to fail. 2340 If DAV:prop is specified in the request body, the properties 2341 specified in the DAV:prop element MUST be reported in the 2342 DAV:response elements. 2344 Preconditions: 2345 (DAV:property-must-be-searchable): All properties specified in the 2346 DAV:principal-property-search REPORT must be searchable. 2348 9.4.1 Matching 2350 There are several cases to consider when matching strings. The 2351 easiest case is when a property value is "simple" and has only 2352 character information item content (see [REC-XML-INFOSET]). For 2353 example, the search string "julian" would match the DAV:displayname 2354 property with value "Julian Reschke". Note that the on-the-wire 2355 marshalling of DAV:displayname in this case is: 2357 Julian Reschke 2359 The name of the property is encoded into the XML element 2360 information item, and the character information item content of the 2361 property is "Julian Reschke". 2363 A more complicated case occurs when properties have mixed content 2364 (that is, compound values consisting of multiple child element 2365 items, other types of information items, and character information 2366 item content). Consider the property "aprop" in the namespace 2367 "http://www.webdav.org/props/", marshalled as: 2369 2370 {cdata 0}{cdata 1} 2371 {cdata 2}{cdata 3} 2372 2374 In this case, matching is performed on each individual contiguous 2375 sequence of character information items. In the example above, a 2376 search string would be compared to the four following strings: 2378 {cdata 0} 2379 {cdata 1} 2380 {cdata 2} 2381 {cdata 3} 2383 That is, four individual matches would be performed, one each for 2384 {cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}. 2386 9.4.2 Example: successful DAV:principal-property-search REPORT 2388 In this example, the client requests the principal URLs of all 2389 users whose DAV:displayname property contains the substring "doE" 2390 and whose "title" property in the namespace 2391 "http://BigCorp.com/ns/" (that is, their professional title) 2392 contains "Sales". In addition, the client requests five properties 2393 to be returned with the matching principals: 2395 In the DAV: namespace: displayname 2396 In the http://www.BigCorp.com/ns/ namespace: department, phone, 2397 office, salary 2399 The response shows that two principal resources meet the search 2400 specification, "John Doe" and "Zygdoebert Smith". The property 2401 "salary" in namespace "http://www.BigCorp.com/ns/" is not returned, 2402 since the principal making the request does not have sufficient 2403 access permissions to read this property. 2405 >> Request << 2407 REPORT /users/ HTTP/1.1 2408 Host: www.BigCorp.com 2409 Content-Type: text/xml; charset=utf-8 2410 Content-Length: xxxx 2411 Depth: 0 2413 2414 2415 2416 2417 2418 2419 doE 2420 2421 2422 2423 2424 2425 Sales 2426 2427 2428 2429 2430 2431 2432 2433 2434 2436 >> Response << 2438 HTTP/1.1 207 Multi-Status 2439 Content-Type: text/xml; charset=utf-8 2440 Content-Length: xxxx 2441 2442 2443 2444 http://www.BigCorp.com/users/jdoe 2445 2446 2447 John Doe 2448 Widget Sales 2449 234-4567 2450 209 2451 2452 HTTP/1.1 200 OK 2453 2454 2455 2456 2457 2458 HTTP/1.1 403 Forbidden 2459 2460 2461 2462 http://www.BigCorp.com/users/zsmith 2463 2464 2465 Zygdoebert Smith 2466 Gadget Sales 2467 234-7654 2468 114 2469 2470 HTTP/1.1 200 OK 2471 2472 2473 2474 2475 2476 HTTP/1.1 403 Forbidden 2477 2478 2479 2481 9.4.3 Example: Unsuccessful DAV:principal-property-search REPORT 2483 In this example, the client requests a search on the non-searchable 2484 property "phone" in the namespace "http://www.BigCorp.com/ns/". 2485 The response is a 403 (Forbidden), with a response body containing 2486 a DAV:property-must-be-searchable XML element as the value of a 2487 DAV:error XML element. 2489 >> Request << 2491 REPORT /users/ HTTP/1.1 2492 Host: www.BigCorp.com 2493 Content-Type: text/xml; charset=utf-8 2494 Content-Length: xxxx 2495 Depth: 0 2497 2498 2499 2500 2501 2502 2503 232 2504 2505 2507 >> Response << 2509 HTTP/1.1 403 Forbidden 2510 Content-Type: text/xml; charset=utf-8 2511 Content-Length: xxxx 2513 2514 2515 2516 2517 2518 2519 2520 2522 9.5 DAV:principal-search-property-set REPORT 2524 The DAV:principal-search-property-set REPORT identifies those 2525 properties that may be searched using the DAV:principal-property- 2526 search REPORT (defined in Section 9.4). 2528 Servers MUST support the DAV:principal-search-property-set REPORT 2529 on all collections identified in the value of a DAV:principal- 2530 collection-set property. 2532 An access control protocol user agent could use the results of the 2533 DAV:principal-search-property-set REPORT to present a query 2534 interface to the user for retrieving principals. 2536 Support for this report is REQUIRED. 2538 Implementation Note: Some clients will have only limited screen 2539 real estate for the display of lists of searchable properties. 2540 In this case, a user might appreciate having the most frequently 2541 searched properties be displayed on-screen, rather than having 2542 to scroll through a long list of searchable properties. One 2543 mechanism for signaling the most frequently searched properties 2544 is to return them towards the start of a list of properties. A 2545 client can then preferentially display the list of properties in 2546 order, increasing the likelihood that the most frequently 2547 searched properties will appear on-screen, and will not require 2548 scrolling for their selection. 2550 Marshalling: 2551 The request body MUST be an empty DAV:principal-search-property-set 2552 XML element. 2554 This report is only defined when the Depth header has value "0"; 2555 other values result in a 400 (Bad Request) error response. Note 2556 that [RFC3253], Section 3.6, states that if the Depth header is not 2557 present, it defaults to a value of "0". 2559 The response body MUST be a DAV:principal-search-property-set XML 2560 element, containing a DAV:principal-search-property XML element for 2561 each property that may be searched with the DAV:principal-property- 2562 search REPORT. A server MAY limit its response to just a subset of 2563 the searchable properties, such as those likely to be useful to an 2564 interactive access control client. 2566 2569 Each DAV:principal-search-property XML element contains exactly one 2570 searchable property, and a description of the property. 2572 2574 The DAV:prop element contains one principal property on which the 2575 server is able to perform a DAV:principal-property-search REPORT. 2577 prop: see RFC 2518, Section 12.11 2578 The description element is a human-readable description of what 2579 information this property represents. Servers MUST indicate the 2580 human language of the description using the xml:lang attribute and 2581 SHOULD consider the HTTP Accept-Language request header when 2582 selecting one of multiple available languages. 2584 2586 9.5.1 Example: DAV:principal-search-property-set REPORT 2588 In this example, the client determines the set of searchable 2589 principal properties by requesting the DAV:principal-search- 2590 property-set REPORT on the root of the server's principal URL 2591 collection set, identified by http://www.BigCorp.com/users/. 2593 >> Request << 2595 REPORT /users/ HTTP/1.1 2596 Host: www.BigCorp.com 2597 Content-Type: text/xml; charset="utf-8" 2598 Content-Length: xxx 2599 Accept-Language: en, de 2600 Authorization: BASIC d2FubmFtYWs6cGFzc3dvcmQ= 2601 Depth: 0 2603 2604 2606 >> Response << 2608 HTTP/1.1 200 OK 2609 Content-Type: text/xml; charset="utf-8" 2610 Content-Length: xxx 2612 2613 2614 2615 2616 2617 2618 Full name 2619 2620 2621 2622 2623 2624 Job title 2625 2626 2628 10 XML PROCESSING 2630 Implementations of this specification MUST support the XML element 2631 ignore rule, as specified in Section 23.3.2 of [RFC2518], and the 2632 XML Namespacerecommendation [REC-XML-NAMES]. 2634 Note that use of the DAV namespace is reserved for XML elements and 2635 property names defined in a standards-track or Experimental IETF 2636 RFC. 2638 11 INTERNATIONALIZATION CONSIDERATIONS 2640 In this specification, the only human-readable content can be found 2641 in the description XML element, found within the DAV:supported- 2642 privilege-set property. This element contains a human-readable 2643 description of the capabilities controlled by a privilege. As a 2644 result, the description element must be capable of representing 2645 descriptions in multiple character sets. Since the description 2646 element is found within a WebDAV property, it is represented on- 2647 the-wire as XML [REC-XML], and hence can leverage XML's language 2648 tagging and character set encoding capabilities. Specifically, XML 2649 processors must, at minimum, be able to read XML elements encoded 2650 using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual 2651 plane. XML examples in this specification demonstrate use of the 2652 charset parameter of the Content-Type header, as defined in 2653 [RFC3023], as well as the XML "encoding" attribute, which together 2654 provide charset identification information for MIME and XML 2655 processors. Futhermore, this specification requires server 2656 implementations to tag description fields with the xml:lang 2657 attribute (see Section 2.12 of [REC-XML]), which specifies the 2658 human language of the description. Additionally, server 2659 implementations should take into account the value of the Accept- 2660 Language HTTP header to determine which description string to 2661 return. 2663 For XML elements other than the description element, it is expected 2664 that implementations will treat the property names, privilege 2665 names, and values as tokens, and convert these tokens into human- 2666 readable text in the user's language and character set when 2667 displayed to a person. Only a generic WebDAV property display 2668 utility would display these values in their raw form to a human 2669 user. 2671 For error reporting, we follow the convention of HTTP/1.1 status 2672 codes, including with each status code a short, English description 2673 of the code (e.g., 200 (OK)). While the possibility exists that a 2674 poorly crafted user agent would display this message to a user, 2675 internationalized applications will ignore this message, and 2676 display an appropriate message in the user's language and character 2677 set. 2679 Further internationalization considerations for this protocol are 2680 described in the WebDAV Distributed Authoring protocol 2681 specification [RFC2518]. 2683 12 SECURITY CONSIDERATIONS 2685 Applications and users of this access control protocol should be 2686 aware of several security considerations, detailed below. In 2687 addition to the discussion in this document, the security 2688 considerations detailed in the HTTP/1.1 specification [RFC2616], 2689 the WebDAV Distributed Authoring Protocol specification [RFC2518], 2690 and the XML Media Types specification [RFC3023] should be 2691 considered in a security analysis of this protocol. 2693 12.1 Increased Risk of Compromised Users 2695 In the absence of a mechanism for remotely manipulating access 2696 control lists, if a single user's authentication credentials are 2697 compromised, only those resources for which the user has access 2698 permission can be read, modified, moved, or deleted. With the 2699 introduction of this access control protocol, if a single 2700 compromised user has the ability to change ACLs for a broad range 2701 of other users (e.g., a super-user), the number of resources that 2702 could be altered by a single compromised user increases. This risk 2703 can be mitigated by limiting the number of people who have write- 2704 acl privileges across a broad range of resources. 2706 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set 2707 Privileges 2709 The ability to read the access privileges (stored in the DAV:acl 2710 property), or the privileges permitted the currently authenticated 2711 user (stored in the DAV:current-user-privilege-set property) on a 2712 resource may seem innocuous, since reading an ACL cannot possibly 2713 affect the resource's state. However, if all resources have world- 2714 readable ACLs, it is possible to perform an exhaustive search for 2715 those resources that have inadvertently left themselves in a 2716 vulnerable state, such as being world-writeable. In particular, the 2717 property retrieval method PROPFIND, executed with Depth infinity on 2718 an entire hierarchy, is a very efficient way to retrieve the 2719 DAV:acl or DAV:current-user-privilege-set properties. Once found, 2720 this vulnerability can be exploited by a denial of service attack 2721 in which the open resource is repeatedly overwritten. Alternately, 2722 writeable resources can be modified in undesirable ways. 2724 To reduce this risk, read-acl privileges should not be granted to 2725 unauthenticated principals, and restrictions on read-acl and read- 2726 current-user-privilege-set privileges for authenticated principals 2727 should be carefully analyzed when deploying this protocol. Access 2728 to the current-user-privilege-set property will involve a tradeoff 2729 of usability versus security. When the current-user-privilege-set 2730 is visible, user interfaces are expected to provide enhanced 2731 information concerning permitted and restricted operations, yet 2732 this information may also indicate a vulnerability that could be 2733 exploited. Deployment of this protocol will need to evaluate this 2734 tradeoff in light of the requirements of the deployment 2735 environment. 2737 12.3 No Foreknowledge of Initial ACL 2739 In an effort to reduce protocol complexity, this protocol 2740 specification intentionally does not address the issue of how to 2741 manage or discover the initial ACL that is placed upon a resource 2742 when it is created. The only way to discover the initial ACL is to 2743 create a new resource, then retrieve the value of the DAV:acl 2744 property. This assumes the principal creating the resource also has 2745 been granted the DAV:read-acl privilege. 2747 As a result, it is possible that a principal could create a 2748 resource, and then discover that its ACL grants privileges that are 2749 undesirable. Furthermore, this protocol makes it possible (though 2750 unlikely) that the creating principal could be unable to modify the 2751 ACL, or even delete the resource. Even when the ACL can be 2752 modified, there will be a short period of time when the resource 2753 exists with the initial ACL before its new ACL can be set. 2755 Several factors mitigate this risk. Human principals are often 2756 aware of the default access permissions in their editing 2757 environments and take this into account when writing information. 2758 Furthermore, default privilege policies are usually very 2759 conservative, limiting the privileges granted by the initial ACL. 2761 13 AUTHENTICATION 2763 Authentication mechanisms defined for use with HTTP and WebDAV also 2764 apply to this WebDAV Access Control Protocol, in particular the 2765 Basic and Digest authentication mechanisms defined in [RFC2617]. 2767 14 IANA CONSIDERATIONS 2769 This document uses the namespace defined by [RFC2518] for XML 2770 elements. All other IANA considerations mentioned in [RFC2518] also 2771 applicable to this specification. 2773 15 INTELLECTUAL PROPERTY 2775 The following notice is copied from RFC 2026, section 10.4, and 2776 describes the position of the IETF concerning intellectual property 2777 claims made against this document. 2779 The IETF takes no position regarding the validity or scope of any 2780 intellectual property or other rights that might be claimed to 2781 pertain to the implementation or use other technology described in 2782 this document or the extent to which any license under such rights 2783 might or might not be available; neither does it represent that it 2784 has made any effort to identify any such rights. Information on 2785 the IETF's procedures with respect to rights in standards-track and 2786 standards-related documentation can be found in BCP-11. Copies of 2787 claims of rights made available for publication and any assurances 2788 of licenses to be made available, or the result of an attempt made 2789 to obtain a general license or permission for the use of such 2790 proprietary rights by implementers or users of this specification 2791 can be obtained from the IETF Secretariat. 2793 The IETF invites any interested party to bring to its attention any 2794 copyrights, patents or patent applications, or other proprietary 2795 rights that may cover technology that may be required to practice 2796 this standard. Please address the information to the IETF 2797 Executive Director. 2799 16 ACKNOWLEDGEMENTS 2801 This protocol is the collaborative product of the WebDAV ACL design 2802 team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry Lind, Sean 2803 Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead. The authors 2804 are grateful for the detailed review and comments provided by Jim 2805 Amsden, Dylan Barrell, Gino Basso, Murthy Chintalapati, Lisa 2806 Dusseault, Stefan Eissing, Tim Ellison, Yaron Goland, Dennis 2807 Hamilton, Laurie Harper, Eckehard Hermann, Ron Jacobs, Chris 2808 Knight, Remy Maucherat, Larry Masinter, Joe Orton, Peter Raymond, 2809 Julian Reschke, and Keith Wannamaker. We thank Keith Wannamaker for 2810 the initial text of the principal property search sections. Prior 2811 work on WebDAV access control protocols has been performed by Yaron 2812 Goland, Paul Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff. 2813 We would like to acknowledge the foundation laid for us by the 2814 authors of the DeltaV, WebDAV and HTTP protocols upon which this 2815 protocol is layered, and the invaluable feedback from the WebDAV 2816 working group. 2818 17 REFERENCES 2820 17.1 Normative References 2822 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 2823 Requirement Levels." RFC 2119, BCP 14, March, 1997. 2825 [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible 2826 Markup Language (XML)." World Wide Web Consortium Recommendation 2827 REC-xml.http://www.w3.org/TR/REC-xml 2829 [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Name Spaces in 2830 XML" World Wide Web Consortium Recommendation REC-xml-names. 2831 http://www.w3.org/TR/REC-xml-names/ 2833 [RFC3253] G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead, 2834 "Versioning Extensions to WebDAV." RFC 3253, March 2002. 2836 [REC-XML-INFOSET] J. Cowan, R. Tobin, "XML Information Set." World 2837 Wide Web Consortium Recommendation REC-xml-infoset. 2838 http://www.w3.org/TR/xml-infoset/ 2840 [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. 2841 Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer 2842 Protocol -- HTTP/1.1." RFC 2616, June, 1999. 2844 [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. 2845 Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and 2846 Digest Access Authentication." RFC 2617, June, 1999. 2848 [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D. 2849 Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV." RFC 2850 2518, February, 1999. 2852 [RFC2368] P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL 2853 scheme." RFC 2368, July, 1998. 2855 [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types." RFC 2856 3023, January, 2001. 2858 [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and 2859 ISO 10646." RFC 2279, January, 1998. 2861 17.2 Informational References 2863 [RFC2026] S.Bradner, "The Internet Standards Process - Revision 3." 2864 RFC 2026, BCP 9. Harvard, October, 1996. 2866 [RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255. 2867 Netscape, December, 1997. 2869 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory 2870 Access Protocol (v3)." RFC 2251. Critical Angle, Netscape, Isode, 2871 December, 1997. 2873 [CaseMap] M. Davis, "Case Mappings", Unicode Standard Annex #21, 2874 March 26, 2001. http://www.unicode.org/unicode/reports/tr21 2876 18 AUTHORS' ADDRESSES 2878 Geoffrey Clemm 2879 Rational Software 2880 20 Maguire Road 2881 Lexington, MA 02421 2882 Email: geoffrey.clemm@rational.com 2884 Anne Hopkins 2885 Microsoft Corporation 2886 One Microsoft Way 2887 Redmond, WA 98052 2888 Email: annehop@microsoft.com 2890 Eric Sedlar 2891 Oracle Corporation 2892 500 Oracle Parkway 2893 Redwood Shores, CA 94065 2894 Email: esedlar@us.oracle.com 2896 Jim Whitehead 2897 U.C. Santa Cruz 2898 Dept. of Computer Science 2899 Baskin Engineering 2900 1156 High Street 2901 Santa Cruz, CA 95064 2902 Email: ejw@cse.ucsc.edu 2903 19 APPENDICES 2905 19.1 WebDAV XML Document Type Definition Addendum 2907 All XML elements defined in this Document Type Definition (DTD) 2908 belong to the DAV namespace. This DTD should be viewed as an 2909 addendum to the DTD provided in [RFC2518], section 23.1. 2911 2913 2914 2915 2916 2917 2918 2919 2920 2921 2923 2925 2927 2928 2929 2930 2932 2934 2936 2937 2939 2941 2942 2945 2946 2947 2948 2949 2951 2953 2955 2956 2958 2960 2964 2965 2966 2967 2968 2969 2971 2972 2973 2975 2977 2979 2981 2983 2985 2987 2989 2991 2994 2995 2996 2998 2999 3001 3003 3004 3005 3006 3008 3012 3014 3015 3016 3017 3018 3019 3020 3021 3022 3024 3026 3027 ANY value: a sequence of one or more elements, with at most one 3028 DAV:prop element. 3030 3031 3032 ANY value: an element whose value identifies a property. The 3033 expectation is the value of the named property typically contains 3034 an href element that contains the URI of a principal 3035 3037 3038 3039 3041 3043