idnits 2.17.1
draft-ietf-webdav-acl-10.txt:
-(487): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(500): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(1596): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
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 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
== There are 4 instances of lines with non-ascii characters in the document.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 60
longer pages, the longest (page 2) being 61 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Authors' Addresses Section.
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 388 instances of too long lines in the document, the longest
one being 10 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 2327 has weird spacing: '...contain a DAV...'
== Line 2565 has weird spacing: '...MUST be a DAV...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 15, 2003) is 7704 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 470, but not defined
== Missing Reference: 'RFC2589' is mentioned on line 628, but not defined
== Missing Reference: 'NFSV4' is mentioned on line 1580, but not defined
== Unused Reference: 'RFC2368' is defined on line 2860, but no explicit
reference was found in the text
== Unused Reference: 'RFC3010' is defined on line 2866, but no explicit
reference was found in the text
== Unused Reference: 'RFC2026' is defined on line 2875, but no explicit
reference was found in the text
== Unused Reference: 'RFC2251' is defined on line 2881, 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 3010 (Obsoleted by RFC 3530)
** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC
3629)
** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516)
** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511,
RFC 4512, RFC 4513)
-- Possible downref: Non-RFC (?) normative reference: ref. 'CaseMap'
Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 INTERNET-DRAFT Geoffrey Clemm, IBM
3 draft-ietf-webdav-acl-10 Anne Hopkins, Microsoft Corporation
4 Eric Sedlar, Oracle Corporation
5 Jim Whitehead, U.C. Santa Cruz
7 Expires September 15, 2003 March 15, 2003
9 WebDAV Access Control Protocol
11 Status of this Memo
12 This document is an Internet-Draft and is subject to all provisions of
13 Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering Task
16 Force (IETF), its areas, and its working groups. Note that other groups
17 may also distribute working documents as Internet-Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six months
20 and may be updated, replaced, or obsoleted by other documents at any
21 time. It is inappropriate to use Internet- Drafts as reference material
22 or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 Abstract
31 This document specifies a set of methods, headers, message bodies,
32 properties, and reports that define Access Control extensions to the
33 WebDAV Distributed Authoring Protocol. This protocol permits a client to
34 read and modify access control lists that instruct a server whether to
35 allow or deny operations upon a resource (such as HyperText Transfer
36 Protocol (HTTP) method invocations) by a given principal. A lightweight
37 representation of principals as Web resources supports integration of a
38 wide range of user management repositories. Search operations allow
39 discovery and manipulation of principals using human names.
41 This document is a product of the Web Distributed Authoring and
42 Versioning (WebDAV) working group of the Internet Engineering Task
43 Force. Comments on this draft are welcomed, and should be addressed to
44 the acl@webdav.org mailing list. Other related documents can be found at
45 http://www.example.com/acl/, and
46 http://www.ics.uci.edu/pub/ietf/webdav/.
48 Table of Contents
50 WEBDAV ACCESS CONTROL PROTOCOL............................1
52 STATUS OF THIS MEMO.......................................1
54 ABSTRACT..................................................1
56 TABLE OF CONTENTS.........................................2
58 1 INTRODUCTION...........................................4
59 1.1 Terms.................................................6
60 1.2 Notational Conventions................................7
62 2 PRINCIPALS.............................................7
64 3 PRIVILEGES.............................................8
65 3.1 DAV:read Privilege....................................9
66 3.2 DAV:write Privilege...................................9
67 3.3 DAV:write-properties.................................10
68 3.4 DAV:write-content....................................10
69 3.5 DAV:unlock...........................................10
70 3.6 DAV:read-acl Privilege...............................11
71 3.7 DAV:read-current-user-privilege-set Privilege........11
72 3.8 DAV:write-acl Privilege..............................11
73 3.9 DAV:delete Privilege.................................11
74 3.10 DAV:all Privilege..................................11
75 3.11 Aggregation of Predefined Privileges...............12
77 4 PRINCIPAL PROPERTIES..................................12
78 4.1 DAV:alternate-URI-set................................12
79 4.2 DAV:principal-URL....................................13
80 4.3 DAV:group-member-set.................................13
81 4.4 DAV:group-membership.................................13
83 5 ACCESS CONTROL PROPERTIES.............................13
84 5.1 DAV:owner............................................14
85 5.1.1 Example: Retrieving DAV:owner....................14
86 5.1.2 Example: An Attempt to Set DAV:owner.............15
87 5.2 DAV:supported-privilege-set..........................16
88 5.2.1 Example: Retrieving a List of Privileges Supported on a Resource
89 16
90 5.3 DAV:current-user-privilege-set.......................19
91 5.3.1 Example: Retrieving the User's Current Set of Assigned
92 Privileges..............................................19
93 5.4 DAV:acl..............................................20
94 5.4.1 ACE Principal....................................20
95 5.4.2 ACE Grant and Deny...............................21
96 5.4.3 ACE Protection...................................22
97 5.4.4 ACE Inheritance..................................22
98 5.4.5 Example: Retrieving a Resource's Access Control List 22
99 5.5 DAV: acl-restrictions................................24
100 5.5.1 DAV:grant-only...................................24
101 5.5.2 DAV:no-invert ACE Constraint.....................24
102 5.5.3 DAV:deny-before-grant............................24
103 5.5.4 Required Principals..............................24
104 Example: Retrieving DAV:acl-restrictions................25
105 5.6 DAV:inherited-acl-set................................26
106 5.7 DAV:principal-collection-set.........................26
107 5.7.1 Example: Retrieving DAV:principal-collection-set.27
108 5.8 Example: PROPFIND to retrieve access control properties28
110 6 ACL EVALUATION........................................31
112 7 ACCESS CONTROL AND EXISTING METHODS...................32
113 7.1 OPTIONS..............................................32
114 7.1.1 Example - OPTIONS................................32
115 7.2 MOVE.................................................33
116 7.3 COPY.................................................33
117 7.4 LOCK.................................................33
119 8 ACCESS CONTROL METHODS................................33
120 8.1 ACL..................................................33
121 8.1.1 ACL Preconditions................................34
122 8.1.2 Example: the ACL method..........................35
123 8.1.3 Example: ACL method failure due to protected ACE conflict 36
124 8.1.4 Example: ACL method failure due to an inherited ACE conflict 37
125 8.1.5 Example: ACL method failure due to an attempt to set grant and
126 deny in a single ACE....................................38
128 9 ACCESS CONTROL REPORTS................................39
129 9.1 REPORT Method........................................39
130 9.2 DAV:acl-principal-prop-set Report....................40
131 9.2.1 Example: DAV:acl-principal-prop-set Report.......41
132 9.3 DAV:principal-match REPORT...........................42
133 9.3.1 Example: DAV:principal-match REPORT..............43
134 9.4 DAV:principal-property-search REPORT.................44
135 9.4.1 Matching.........................................46
136 9.4.2 Example: successful DAV:principal-property-search REPORT 46
137 9.4.3 Example: Unsuccessful DAV:principal-property-search REPORT 48
138 9.5 DAV:principal-search-property-set REPORT.............49
139 9.5.1 Example: DAV:principal-search-property-set REPORT50
141 10 XML PROCESSING.......................................51
143 11 INTERNATIONALIZATION CONSIDERATIONS..................51
145 12 SECURITY CONSIDERATIONS..............................52
146 12.1 Increased Risk of Compromised Users................52
147 12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set
148 Privileges...............................................53
149 12.3 No Foreknowledge of Initial ACL....................53
151 13 AUTHENTICATION.......................................54
153 14 IANA CONSIDERATIONS..................................54
154 15 INTELLECTUAL PROPERTY................................54
156 16 ACKNOWLEDGEMENTS.....................................55
158 17 REFERENCES...........................................55
159 17.1 Normative References...............................55
160 17.2 Informational References...........................56
162 18 AUTHORS' ADDRESSES...................................57
164 19 APPENDICES...........................................58
165 19.1 WebDAV XML Document Type Definition Addendum.......58
166 19.2 WebDAV Method Privilege Table (Normative)..........60
168 1 INTRODUCTION
170 The goal of the WebDAV access control extensions is to provide an
171 interoperable mechanism for handling discretionary access control
172 for content and metadata managed by WebDAV servers. WebDAV access
173 control can be implemented on content repositories with security as
174 simple as that of a UNIX file system, as well as more sophisticated
175 models. The underlying principle of access control is that who you
176 are determines what operations you can perform on a resource. The
177 "who you are" is defined by a "principal" identifier; users, client
178 software, servers, and groups of the previous have principal
179 identifiers. The "operations you can perform" are determined by a
180 single "access control list" (ACL) associated with a resource. An
181 ACL contains a set of "access control entries" (ACEs), where each
182 ACE specifies a principal and a set of privileges that are either
183 granted or denied to that principal. When a principal submits an
184 operation (such as an HTTP or WebDAV method) to a resource for
185 execution, the server evaluates the ACEs in the ACL to determine if
186 the principal has permission for that operation.
188 Since every ACE contains the identifier of a principal, client
189 software operated by a human must provide a mechanism for selecting
190 this principal. This specification uses http(s) scheme URLs to
191 identify principals, which are represented as WebDAV-capable
192 resources. There is no guarantee that the URLs identifying
193 principals will be meaningful to a human. For example,
194 http://www.example.com/u/256432 and
195 http://www.example.com/people/Greg.Stein are both valid URLs that
196 could be used to identify the same principal. To remedy this, every
197 principal resource has the DAV:displayname property containing a
198 human-readable name for the principal.
200 Since a principal can be identified by multiple URLs, it raises the
201 problem of determining exactly which principal is being referenced
202 in a given ACE. It is impossible for a client to determine that an
203 ACE granting the read privilege to
204 http://www.example.com/people/Greg.Stein also affects the principal
205 at http://www.example.com/u/256432. That is, a client has no
206 mechanism for determining that two URLs identify the same principal
207 resource. As a result, this specification requires clients to use
208 just one of the many possible URLs for a principal when creating
209 ACEs. A client can discover which URL to use by retrieving the
210 DAV:principal-URL property (Section 4.2) from a principal resource.
211 No matter which of the principal's URLs is used with PROPFIND, the
212 property always returns the same URL.
214 With a system having hundreds to thousands of principals, the
215 problem arises of how to allow a human operator of client software
216 to select just one of these principals. One approach is to use
217 broad collection hierarchies to spread the principals over a large
218 number of collections, yielding few principals per collection. An
219 example of this is a two level hierarchy with the first level
220 containing 36 collections (a-z, 0-9), and the second level being
221 another 36, creating collections /a/a/, /a/b/, ..., /a/z/, such
222 that a principal with last name "Stein" would appear at /s/t/Stein.
223 In effect, this pre-computes a common query, search on last name,
224 and encodes it into a hierarchy. The drawback with this scheme is
225 that it handles only a small set of predefined queries, and
226 drilling down through the collection hierarchy adds unnecessary
227 steps (navigate down/up) when the user already knows the
228 principal's name. While organizing principal URLs into a hierarchy
229 is a valid namespace organization, users should not be forced to
230 navigate this hierarchy to select a principal.
232 This specification provides the capability to perform substring
233 searches over a small set of properties on the resources
234 representing principals. This permits searches based on last name,
235 first name, user name, job title, etc. Two separate searches are
236 supported, both via the REPORT method, one to search principal
237 resources (DAV:principal-property-search, Section 9.4), the other
238 to determine which properties may be searched at all
239 (DAV:principal-search-property-set, Section 9.5).
241 Once a principal has been identified in an ACE, a server evaluating
242 that ACE must know the identity of the principal making a protocol
243 request, and must validate that that principal is who they claim to
244 be, a process known as authentication. This specification
245 intentionally omits discussion of authentication, as the HTTP
246 protocol already has a number of authentication mechanisms
247 [RFC2617]. Some authentication mechanism (such as HTTP Digest
248 Authentication, which all WebDAV compliant implementations are
249 required to support) must be available to validate the identity of
250 a principal.
252 The following issues are out of scope for this document:
254 Access control that applies only to a particular property on a
255 resource (excepting the access control properties DAV:acl and
256 DAV:current-user-privilege-set), rather than the entire resource,
258 Role-based security (where a role can be seen as a dynamically
259 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 resources,
263 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 ways ACLs are to be evaluated is
274 described in section 6. Client discovery of access control
275 capability using OPTIONS is described in Section 7.1. Interactions
276 between access control functionality and existing HTTP and WebDAV
277 methods are described in the remainder of Section 7. The access
278 control setting method, ACL, is specified in Section 8. Four
279 reports that provide limited server-side searching capabilities are
280 described in Section 9. Sections on XML processing (Section 10),
281 Internationalization considerations (Section 11), security
282 considerations (Section 12), and authentication (Section 13) round
283 out the specification. An appendix (Section 19.1) provides an XML
284 Document Type Definition (DTD) for the XML elements defined in the
285 specification.
287 1.1 Terms
289 This draft uses the terms defined in HTTP [RFC2616] and WebDAV
290 [RFC2518]. In addition, the following terms are defined:
292 principal
294 A "principal" is a distinct human or computational actor that
295 initiates access to network resources. In this protocol, a
296 principal is an HTTP resource that represents such an actor.
298 group
300 A "group" is a principal that represents a set of other principals.
302 privilege
304 A "privilege" controls access to a particular set of HTTP
305 operations on a resource.
307 aggregate privilege
309 An "aggregate privilege" is a privilege that contains a set of
310 other privileges.
312 abstract privilege
313 The modifier "abstract", when applied to a privilege on a resource,
314 means the privilege cannot be set in an access control element
315 (ACE) on that resource .
317 access control list (ACL)
319 An "ACL" is a list of access control elements that define access
320 control to a particular resource.
322 access control element (ACE)
324 An "ACE" either grants or denies a particular set of (non-abstract)
325 privileges for a particular principal.
327 inherited ACE
329 An "inherited ACE" is an ACE that is dynamically shared from the
330 ACL of another resource. When a shared ACE changes on the primary
331 resource, it is also changed on inheriting resources.
333 protected property
335 A "protected property" is one whose value cannot be updated except
336 by a method explicitly defined as updating that specific property.
337 In particular, a protected property cannot be updated with a
338 PROPPATCH request.
340 1.2 Notational Conventions
342 The augmented BNF used by this document to describe protocol
343 elements is described in Section 2.1 of [RFC2616]. Because this
344 augmented BNF uses the basic production rules provided in Section
345 2.2 of [RFC2616], those rules apply to this document as well.
347 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
348 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
349 this document are to be interpreted as described in [RFC2119].
351 Definitions of XML elements in this document use XML element type
352 declarations (as found in XML Document Type Declarations),
353 described in Section 3.2 of [REC-XML]. When an XML element type in
354 the "DAV:" namespace is referenced in this document outside of the
355 context of an XML fragment, the string "DAV:" will be prefixed to
356 the element name.
358 2 PRINCIPALS
360 A principal is a network resource that represents a distinct human
361 or computational actor that initiates access to network resources.
362 Users and groups are represented as principals in many
363 implementations; other types of principals are also possible. A URI
364 of any scheme MAY be used to identify a principal resource.
366 However, servers implementing this specification MUST expose
367 principal resources at an http(s) URL, which is a privileged scheme
368 that points to resources that have additional properties, as
369 described in Section 4. So, a principal resource can have multiple
370 URIs, one of which has to be an http(s) scheme URL. Although an
371 implementation SHOULD support PROPFIND and MAY support PROPPATCH to
372 access and modify information about a principal, it is not required
373 to do so.
375 A principal resource may be a group, where a group is a principal
376 that represents a set of other principals, called the members of
377 the group. If a person or computational agent matches a principal
378 resource that is a member of a group, they also match the group.
379 Membership in a group is recursive, so if a principal is a member
380 of group GRPA, and GRPA is a member of group GRPB, then the
381 principal is also a member of GRPB.
383 3 PRIVILEGES
385 Ability to perform a given method on a resource MUST be controlled
386 by one or more privileges. Authors of protocol extensions that
387 define new HTTP methods SHOULD specify which privileges (by
388 defining new privileges, or mapping to ones below) are required to
389 perform the method. A principal with no privileges to a resource
390 MUST be denied any HTTP access to that resource, unless the
391 principal matches an ACE constructed using the DAV:all,
392 DAV:authenticated, or DAV:unauthenticated pseudo-principals (see
393 Section 5.4.1). Servers MUST report a 403 "Forbidden" error if
394 access is denied, except in the case where the privilege restricts
395 the ability to know the resource exists, in which case 404 "Not
396 Found" may be returned.
398 Privileges may be containers of other privileges, in which case
399 they are termed "aggregate privileges". If a principal is granted
400 or denied an aggregate privilege, it is semantically equivalent to
401 granting or denying each of the aggregated privileges individually.
402 For example, an implementation may define add-member and remove-
403 member privileges that control the ability to add and remove a
404 member of a group. Since these privileges control the ability to
405 update the state of a group, these privileges would be aggregated
406 by the DAV:write privilege on a group, and granting the DAV:write
407 privilege on a group would also grant the add-member and remove-
408 member privileges.
410 Privileges may be declared to be "abstract" for a given resource,
411 in which case they cannot be set in an ACE on that resource.
412 Aggregate and non-aggregate privileges are both capable of being
413 abstract. Abstract privileges are useful for modeling privileges
414 that otherwise would not be exposed via the protocol. Abstract
415 privileges also provide server implementations with flexibility in
416 implementing the privileges defined in this specification. For
417 example, if a server is incapable of separating the read resource
418 capability from the read ACL capability, it can still model the
419 DAV:read and DAV:read-acl privileges defined in this specification
420 by declaring them abstract, and containing them within a non-
421 abstract aggregate privilege (say, read-all) that holds DAV:read,
422 and DAV:read-acl. In this way, it is possible to set the aggregate
423 privilege, read-all, thus coupling the setting of DAV:read and
424 DAV:read-acl, but it is not possible to set DAV:read, or DAV:read-
425 acl individually. Since aggregate privileges can be abstract, it is
426 also possible to use abstract privileges to group or organize non-
427 abstract privileges. Privilege containment loops are not allowed;
428 therefore, a privilege MUST NOT contain itself. For example,
429 DAV:read cannot contain DAV:read.
431 The set of privileges that apply to a particular resource may vary
432 with the DAV:resourcetype of the resource, as well as between
433 different server implementations. To promote interoperability,
434 however, this specification defines a set of well-known privileges
435 (e.g. DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, DAV:read-
436 current-user-privilege-set, and DAV:all), which can at least be
437 used to classify the other privileges defined on a particular
438 resource. The access permissions on null resources (defined in
439 [RFC2518], Section 3) are solely those they inherit (if any), and
440 they are not discoverable (i.e., the access control properties
441 specified in Section 5 are not defined on null resources). On the
442 transition from null to stateful resource, the initial access
443 control list is set by the server's default ACL value policy (if
444 any).
446 Server implementations MAY define new privileges beyond those
447 defined in this specification. Privileges defined by individual
448 implementations MUST NOT use the DAV: namespace, and instead should
449 use a namespace that they control, such as an http scheme URL.
451 3.1 DAV:read Privilege
453 The read privilege controls methods that return information about
454 the state of the resource, including the resource's properties.
455 Affected methods include GET and PROPFIND. Any implementation-
456 defined privilege that also controls access to GET and PROPFIND
457 must be aggregated under DAV:read�if an ACL grants access to
458 DAV:read, the client may expect that no other privilege needs to be
459 granted to have access to GET and PROPFIND. Additionally, the read
460 privilege MUST control the OPTIONS method.
462
464 3.2 DAV:write Privilege
466 The write privilege controls methods that lock a resource or modify
467 the content, dead properties, or (in the case of a collection)
468 membership of the resource, such as PUT and PROPPATCH. Note that
469 state modification is also controlled via locking (see section 5.3
470 of [WEBDAV]), so effective write access requires that both write
471 privileges and write locking requirements are satisfied. Any
472 implementation-defined privilege that also controls access to
473 methods modifying content, dead properties or collection membership
474 must be aggregated under DAV:write, e.g. if an ACL grants access to
475 DAV:write, the client may expect that no other privilege needs to
476 be granted to have access to PUT and PROPPATCH.
478
480 3.3 DAV:write-properties
482 The DAV:write-properties privilege controls methods that modify the
483 dead properties of the resource, such as PROPPATCH. Whether this
484 privilege may be used to control access to any live properties is
485 determined by the implementation. Any implementation-defined
486 privilege that also controls access to methods modifying dead
487 properties must be aggregated under DAV:write-properties�e.g. if an
488 ACL grants access to DAV:write-properties, the client can safely
489 expect that no other privilege needs to be granted to have access
490 to PROPPATCH.
492
494 3.4 DAV:write-content
496 The DAV:write-content privilege controls methods that modify the
497 content or (in the case of a collection) membership of the
498 resource, such as PUT and DELETE. Any implementation-defined
499 privilege that also controls access to content or alteration of
500 collection membership must be aggregated under DAV:write-content�
501 e.g. if an ACL grants access to DAV:write-content, the client can
502 safely expect that no other privilege needs to be granted to have
503 access to PUT or DELETE.
505
507 3.5 DAV:unlock
509 The DAV:unlock privilege controls the use of the UNLOCK method by a
510 principal other than the lock owner (the principal that created a
511 lock can always perform an UNLOCK). While the set of users who may
512 lock a resource is most commonly the same set of users who may
513 modify a resource, servers may allow various kinds of
514 administrators to unlock resources locked by others. Any privilege
515 controlling access by non-lock owners to UNLOCK MUST be aggregated
516 under DAV:unlock.
518 A lock owner can always remove a lock by issuing an UNLOCK with the
519 correct lock token and authentication credentials. That is, even if
520 a principal does not have DAV:unlock privilege, they can still
521 remove locks they own. Principals other than the lock owner can
522 remove a lock only if they have DAV:unlock privilege and they issue
523 an UNLOCK with the correct lock token. Lock timeout is not affected
524 by the DAV:unlock privilege.
526
528 3.6 DAV:read-acl Privilege
530 The DAV:read-acl privilege controls the use of PROPFIND to retrieve
531 the DAV:acl property of the resource.
533
535 3.7 DAV:read-current-user-privilege-set Privilege
537 The DAV:read-current-user-privilege-set privilege controls the use
538 of PROPFIND to retrieve the DAV:current-user-privilege-set property
539 of the resource.
541 Clients are intended to use this property to visually indicate in
542 their UI items that are dependent on the permissions of a resource,
543 for example, by graying out resources that are not writeable.
545 This privilege is separate from DAV:read-acl because there is a
546 need to allow most users access to the privileges permitted the
547 current user (due to its use in creating the UI), while the full
548 ACL contains information that may not be appropriate for the
549 current authenticated user. As a result, the set of users who can
550 view the full ACL is expected to be much smaller than those who can
551 read the current user privilege set, and hence distinct privileges
552 are needed for each.
554
556 3.8 DAV:write-acl Privilege
558 The DAV:write-acl privilege controls use of the ACL method to
559 modify the DAV:acl property of the resource.
561
563 3.9 DAV:delete Privilege
565 The DAV:delete privilege controls use of the DELETE method on the
566 specified resource. You must also have DAV:write-content on the
567 collection containing the resource for the DELETE to succeed.
569
571 3.10DAV:all Privilege
573 DAV:all is an aggregate privilege that contains the entire set of
574 privileges that can be applied to the resource.
576
577 3.11Aggregation of Predefined Privileges
579 Server implementations are free to aggregate the predefined
580 privileges (defined above in Sections 3.1-3.9) subject to the
581 following limitations:
583 DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-acl,
584 DAV:write-properties, DAV:write-content, or DAV:read-current-user-
585 privilege-set.
587 DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-acl,
588 or DAV:read-current-user-privilege-set.
590 DAV:read-current-user-privilege-set MUST NOT contain DAV:write,
591 DAV:read, DAV:read-acl, or DAV:write-acl.
593 DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-
594 current-user-privilege-set.
596 DAV:read MUST NOT contain DAV:write, DAV:write-acl, DAV:write-
597 properties, or DAV:write-content.
599 DAV:write MUST contain DAV:write-properties and DAV:write-content.
601 4 PRINCIPAL PROPERTIES
603 Principals are manifested to clients as a WebDAV resource,
604 identified by a URL. A principal MUST have a non-empty
605 DAV:displayname property (defined in Section 13.2 of [RFC2518]),
606 and a DAV:resourcetype property (defined in Section 13.9 of
607 [RFC2518]). Additionally, a principal MUST report the
608 DAV:principal XML element in the value of the DAV:resourcetype
609 property. The element type declaration for DAV:principal is:
611
613 This protocol defines the following additional properties for a
614 principal. Since it can be expensive for a server to retrieve
615 access control information, the name and value of these properties
616 SHOULD NOT be returned by a PROPFIND allprop request (as defined in
617 Section 12.14.1 of [RFC2518]).
619 4.1 DAV:alternate-URI-set
621 This protected property, if non-empty, contains the URIs of network
622 resources with additional descriptive information about the
623 principal. This property identifies additional network resources
624 (i.e., it contains one or more URIs) that may be consulted by a
625 client to gain additional knowledge concerning a principal. One
626 expected use for this property is the storage of an LDAP [RFC2255]
627 scheme URL. A user-agent encountering an LDAP URL could use LDAP
628 [RFC2589] to retrieve additional machine-readable directory
629 information about the principal, and display that information in
630 its user interface. Support for this property is REQUIRED, and the
631 value is empty if no alternate URI exists for the principal.
633
635 4.2 DAV:principal-URL
637 A principal may have many URLs, but there must be one "principal
638 URL" that clients can use to uniquely identify a principal. This
639 protected property contains the URL that MUST be used to identify
640 this principal in an ACL request. Support for this property is
641 REQUIRED.
643
645 4.3 DAV:group-member-set
647 This property of a group principal identifies the principals that
648 are direct members of this group. Since a group may be a member of
649 another group, a group may also have indirect members (i.e. the
650 members of its direct members). A URL in the DAV:group-member-set
651 for a principal MUST be the DAV:principal-URL of that principal.
653
655 4.4 DAV:group-membership
657 This protected property identifies the groups in which the
658 principal is directly a member. Note that a server may allow a
659 group to be a member of another group, in which case the DAV:group-
660 membership of those other groups would need to be queried in order
661 to determine the groups in which the principal is indirectly a
662 member. Support for this property is REQUIRED.
664
666 5 ACCESS CONTROL PROPERTIES
668 This specification defines a number of new properties for WebDAV
669 resources. Access control properties may be retrieved just like
670 other WebDAV properties, using the PROPFIND method. Since it is
671 expensive, for many servers, to retrieve access control
672 information, a PROPFIND allprop request (as defined in Section
673 12.14.1 of [RFC2518]) SHOULD NOT return the names and values of the
674 properties defined in this section.
676 Access control properties (especially DAV:acl and DAV:inherited-
677 acl-set) are defined on the resource identified by the Request-URI
678 of a PROPFIND request. A direct consequence is that if the resource
679 is accessible via multiple URI, the value of access control
680 properties is the same across these URI.
682 HTTP resources that support the WebDAV Access Control Protocol MUST
683 contain the following properties. Null resources (described in
684 Section 3 of [RFC2518]) MUST NOT contain the following properties.
686 5.1 DAV:owner
688 This protected property identifies a particular principal as being
689 the "owner" of the resource. Since the owner of a resource often
690 has special access control capabilities (e.g., the owner frequently
691 has permanent DAV:write-acl privilege), clients might display the
692 resource owner in their user interface.
694
696 5.1.1Example: Retrieving DAV:owner
698 This example shows a client request for the value of the DAV:owner
699 property from a collection resource with URL
700 http://www.example.com/papers/. The principal making the request is
701 authenticated using Digest authentication. The value of DAV:owner
702 is the URL http://www.example.com/acl/users/gstein, wrapped in the
703 DAV:href XML element.
705 >> Request <<
707 PROPFIND /papers/ HTTP/1.1
708 Host: www.example.com
709 Content-type: text/xml; charset="utf-8"
710 Content-Length: xxx
711 Depth: 0
712 Authorization: Digest username="jim",
713 realm="jim@webdav.org", nonce="...",
714 uri="/papers/", response="...", opaque="..."
716
717
718
719
720
721
723 >> Response <<
725 HTTP/1.1 207 Multi-Status
726 Content-Type: text/xml; charset="utf-8"
727 Content-Length: xxx
729
730
731
732 http://www.example.com/papers/
733
734
735
736 http://www.example.com/acl/users/gstein
737
738
739 HTTP/1.1 200 OK
740
741
742
744 5.1.2Example: An Attempt to Set DAV:owner
746 The following example shows a client request to modify the value of
747 the DAV:owner property on the resource with URL
748 . Since DAV:owner is a protected
749 property, the server responds with a 207 (Multi-Status) response
750 that contains a 403 (Forbidden) status code for the act of setting
751 DAV:owner. Section 8.2.1 of [RFC2518] describes PROPPATCH status
752 code information, and Section 11 of [RFC2518] describes the Multi-
753 Status response.
755 >> Request <<
757 PROPPATCH /papers/ HTTP/1.1
758 Host: www.example.com
759 Content-type: text/xml; charset="utf-8"
760 Content-Length: xxx
761 Depth: 0
762 Authorization: Digest username="jim",
763 realm="jim@webdav.org", nonce="...",
764 uri="/papers/", response="...", opaque="..."
766
767
768
769
770
771 http://www.example.com/acl/users/jim
772
773
774
775
777 >> Response <<
779 HTTP/1.1 207 Multi-Status
780 Content-Type: text/xml; charset="utf-8"
781 Content-Length: xxx
783
784
785
786 http://www.example.com/papers/
787
788
789 HTTP/1.1 403 Forbidden
790
791 Failure to set protected property (DAV:owner)
792
793
794
795
797 5.2 DAV:supported-privilege-set
799 This is a protected property that identifies the privileges defined
800 for the resource.
802
804 Each privilege appears as an XML element, where aggregate
805 privileges list as sub-elements all of the privileges that they
806 aggregate.
808
810
812 An abstract privilege MUST NOT be used in an ACE for that resource.
813 Servers MUST fail an attempt to set an abstract privilege.
815
817 A description is a human-readable description of what this
818 privilege controls access to. Servers MUST indicate the human
819 language of the description using the xml:lang attribute and SHOULD
820 consider the HTTP Accept-Language request header when selecting one
821 of multiple available languages.
823
825 It is envisioned that a WebDAV ACL-aware administrative client
826 would list the supported privileges in a dialog box, and allow the
827 user to choose non-abstract privileges to apply in an ACE. The
828 privileges tree is useful programmatically to map well-known
829 privileges (defined by WebDAV or other standards groups) into
830 privileges that are supported by any particular server
831 implementation. The privilege tree also serves to hide complexity
832 in implementations allowing large number of privileges to be
833 defined by displaying aggregates to the user.
835 5.2.1Example: Retrieving a List of Privileges Supported on a Resource
837 This example shows a client request for the DAV:supported-
838 privilege-set property on the resource
839 http://www.example.com/papers/. The value of the DAV:supported-
840 privilege-set property is a tree of supported privileges (using
841 "[XML Namespace , localname]" to identify each privilege):
843 [DAV:, all] (aggregate, abstract)
844 |
845 +-- [DAV:, read] (aggregate)
846 |
847 +-- [DAV:, read-acl] (abstract)
848 +-- [DAV:, read-current-user-privilege-set] (abstract)
849 |
850 +-- [DAV:, write] (aggregate)
851 |
852 +-- [DAV:, write-acl] (abstract)
853 +-- [DAV:, write-properties]
854 +-- [DAV:, write-content]
855 |
856 +-- [DAV:, unlock]
858 This privilege tree is not normative (except that it reflects the
859 normative aggregation rules given in Section 3.11), and many
860 possible privilege trees are possible.
862 >> Request <<
864 PROPFIND /papers/ HTTP/1.1
865 Host: www.example.com
866 Content-type: text/xml; charset="utf-8"
867 Content-Length: xxx
868 Depth: 0
869 Authorization: Digest username="gclemm",
870 realm="gclemm@webdav.org", nonce="...",
871 uri="/papers/", response="...", opaque="..."
873
874
875
876
877
878
880 >> Response <<
882 HTTP/1.1 207 Multi-Status
883 Content-Type: text/xml; charset="utf-8"
884 Content-Length: xxx
886
887
888
889 http://www.example.com/papers/
890
891
892
893
894
895
896 Any operation
897
898
899 Read any object
900
901
902
903 Read ACL
904
905
906
907
908
909
910 Read current user privilege
911 set property
912
913
914
915
916 Write any object
917
918
919 Write ACL
920
921
922
923
924 Write
925 properties
926
927
928
929 Write resource
930 content
931
932
933
934
935 Unlock
936 resource
937
938
939
940
941 HTTP/1.1 200 OK
942
943
944
946 5.3 DAV:current-user-privilege-set
948 DAV:current-user-privilege-set is a protected property containing
949 the exact set of privileges (as computed by the server) granted to
950 the currently authenticated HTTP user. Aggregate privileges and
951 their contained privileges are listed. A user-agent can use the
952 value of this property to adjust its user interface to make actions
953 inaccessible (e.g., by graying out a menu item or button) for which
954 the current principal does not have permission. This property is
955 also useful for determining what operations the current principal
956 can perform, without having to actually execute an operation.
958
959
961 If the current user is granted a specific privilege, that privilege
962 must belong to the set of privileges that may be set on this
963 resource. Therefore, each element in the DAV:current-user-
964 privilege-set property MUST identify a non-abstract privilege from
965 the DAV:supported-privilege-set property.
967 5.3.1Example: Retrieving the User's Current Set of Assigned Privileges
969 Continuing the example from Section 5.2.1, this example shows a
970 client requesting the DAV:current-user-privilege-set property from
971 the resource with URL http://www.example.com/papers/. The username
972 of the principal making the request is "khare", and Digest
973 authentication is used in the request. The principal with username
974 "khare" has been granted the DAV:read privilege. Since the DAV:read
975 privilege contains the DAV:read-acl and DAV:read-current-user-
976 privilege-set privileges (see Section 5.2.1), the principal with
977 username "khare" can read the ACL property, and the DAV:current-
978 user-privilege-set property. However, the DAV:all, DAV:read-acl,
979 DAV:write-acl and DAV:read-current-user-privilege-set privileges
980 are not listed in the value of DAV:current-user-privilege-set,
981 since (for this example) they are abstract privileges. DAV:write is
982 not listed since the principal with username "khare" is not listed
983 in an ACE granting that principal write permission.
985 >> Request <<
987 PROPFIND /papers/ HTTP/1.1
988 Host: www.example.com
989 Content-type: text/xml; charset="utf-8"
990 Content-Length: xxx
991 Depth: 0
992 Authorization: Digest username="khare",
993 realm="khare@webdav.org", nonce="...",
994 uri="/papers/", response="...", opaque="..."
996
997
998
999
1000
1001
1003 >> Response <<
1005 HTTP/1.1 207 Multi-Status
1006 Content-Type: text/xml; charset="utf-8"
1007 Content-Length: xxx
1009
1010
1011
1012 http://www.example.com/papers/
1013
1014
1015
1016
1017
1018
1019 HTTP/1.1 200 OK
1020
1021
1022
1024 5.4 DAV:acl
1026 This is a protected property that specifies the list of access
1027 control entries (ACEs), which define what principals are to get
1028 what privileges for this resource.
1030
1032 Each DAV:ace element specifies the set of privileges to be either
1033 granted or denied to a single principal. If the DAV:acl property
1034 is empty, no principal is granted any privilege.
1036
1038 5.4.1ACE Principal
1040 The DAV:principal element identifies the principal to which this
1041 ACE applies.
1043
1047 The current user matches DAV:href only if that user is
1048 authenticated as being (or being a member of) the principal
1049 identified by the URL contained by that DAV:href.
1051 The current user always matches DAV:all.
1053
1055 The current user matches DAV:authenticated only if authenticated.
1057
1059 The current user matches DAV:unauthenticated only if not
1060 authenticated.
1062
1064 DAV:all is the union of DAV:authenticated, and DAV:unauthenticated.
1065 For a given request, the user matches either DAV:authenticated, or
1066 DAV:unauthenticated, but not both (that is, DAV:authenticated and
1067 DAV:unauthenticated are disjoint sets).
1069 The current user matches a DAV:property principal in a DAV:acl
1070 property of a resource only if the value of the identified property
1071 of that resource contains at most one DAV:href XML element, the URI
1072 value of DAV:href identifies a principal, and the current user is
1073 authenticated as being (or being a member of) that principal. For
1074 example, if the DAV:property element contained , the
1075 current user would match the DAV:property principal only if the
1076 current user is authenticated as matching the principal identified
1077 by the DAV:owner property of the resource.
1079
1081 Alternately, some servers may support ACEs applying to those users
1082 NOT matching the current principal, e.g. all users not in a
1083 particular group. This can be done by wrapping the DAV:principal
1084 element with DAV:invert.
1086
1088 The current user matches DAV:self in a DAV:acl property of the
1089 resource only if that resource is a principal and that principal
1090 matches the current user or, if the principal is a group, a member
1091 of that group matches the current user.
1093
1095 5.4.2ACE Grant and Deny
1097 Each DAV:grant or DAV:deny element specifies the set of privileges
1098 to be either granted or denied to the specified principal. A
1099 DAV:grant or DAV:deny element of the DAV:acl of a resource MUST
1100 only contain non-abstract elements specified in the DAV:supported-
1101 privilege-set of that resource.
1103
1104
1105
1107 5.4.3ACE Protection
1109 A server indicates an ACE is protected by including the
1110 DAV:protected element in the ACE. If the ACL of a resource contains
1111 an ACE with a DAV:protected element, an attempt to remove that ACE
1112 from the ACL MUST fail.
1114
1116 5.4.4ACE Inheritance
1118 The presence of a DAV:inherited element indicates that this ACE is
1119 inherited from another resource that is identified by the URL
1120 contained in a DAV:href element. An inherited ACE cannot be
1121 modified directly, but instead the ACL on the resource from which
1122 it is inherited must be modified.
1124 Note that ACE inheritance is not the same as ACL initialization.
1125 ACL initialization defines the ACL that a newly created resource
1126 will use (if not specified). ACE inheritance refers to an ACE that
1127 is logically shared - where an update to the resource containing an
1128 ACE will affect the ACE of each resource that inherits that ACE.
1129 The method by which ACLs are initialized or by which ACEs are
1130 inherited is not defined by this document.
1132
1134 5.4.5Example: Retrieving a Resource's Access Control List
1136 Continuing the example from Sections 5.2.1 and 5.3.1, this example
1137 shows a client requesting the DAV:acl property from the resource
1138 with URL http://www.example.com/papers/. There are two ACEs defined
1139 in this ACL:
1141 ACE #1: The group identified by URL
1142 http://www.example.com/acl/groups/maintainers (the group of site
1143 maintainers) is granted DAV:write privilege. Since (for this
1144 example) DAV:write contains the DAV:write-acl privilege (see
1145 Section 5.2.1), this means the "maintainers" group can also modify
1146 the access control list.
1148 ACE #2: All principals (DAV:all) are granted the DAV:read
1149 privilege. Since (for this example) DAV:read contains DAV:read-acl
1150 and DAV:read-current-user-privilege-set, this means all users
1151 (including all members of the "maintainers" group) can read the
1152 DAV:acl property and the DAV:current-user-privilege-set property.
1154 >> Request <<
1156 PROPFIND /papers/ HTTP/1.1
1157 Host: www.example.com
1158 Content-type: text/xml; charset="utf-8"
1159 Content-Length: xxx
1160 Depth: 0
1161 Authorization: Digest username="masinter",
1162 realm="webdav.org", nonce="...",
1163 uri="/papers/", response="...", opaque="..."
1165
1166
1167
1168
1169
1170
1172 >> Response <<
1174 HTTP/1.1 207 Multi-Status
1175 Content-Type: text/xml; charset="utf-8"
1176 Content-Length: xxx
1178
1179
1180
1181 http://www.example.com/papers/
1182
1183
1184
1185
1186
1187 http://www.example.com/acl/groups/maintainers
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203 HTTP/1.1 200 OK
1204
1205
1206
1207 5.5 DAV: acl-restrictions
1209 This protected property defines the types of ACLs supported by this
1210 server, to avoid clients needlessly getting errors. When a client
1211 tries to set an ACL via the ACL method, the server may reject the
1212 attempt to set the ACL as specified. The following properties
1213 indicate the restrictions the client must observe before setting an
1214 ACL:
1216 Deny ACEs are not supported
1218 Inverted ACEs are not supported
1220 All deny ACEs must occur before any grant
1221 ACEs
1223 Indicates which principals are
1224 required to be present
1226
1229 5.5.1DAV:grant-only
1231 This element indicates that ACEs with deny clauses are not allowed.
1233
1235 5.5.2DAV:no-invert ACE Constraint
1237 This element indicates that ACEs with the element are not
1238 allowed.
1240
1242 5.5.3DAV:deny-before-grant
1244 This element indicates that all deny ACEs must precede all grant
1245 ACEs.
1247
1249 5.5.4Required Principals
1251 The required principal elements identify which principals must have
1252 an ACE defined in the ACL.
1254
1256 For example, the following element requires that the ACL contain a
1257 DAV:owner property ACE:
1259
1260
1261
1263 Example: Retrieving DAV:acl-restrictions
1265 In this example, the client requests the value of the DAV:acl-
1266 restrictions property. Digest authentication provides credentials
1267 for the principal operating the client.
1269 >> Request <<
1271 PROPFIND /papers/ HTTP/1.1
1272 Host: www.example.com
1273 Content-type: text/xml; charset="utf-8"
1274 Content-Length: xxx
1275 Depth: 0
1276 Authorization: Digest username="srcarter",
1277 realm="srcarter@webdav.org", nonce="...",
1278 uri="/papers/", response="...", opaque="..."
1280
1281
1282
1283
1284
1285
1287 >> Response <<
1289 HTTP/1.1 207 Multi-Status
1290 Content-Type: text/xml; charset="utf-8"
1291 Content-Length: xxx
1293
1294
1295
1296 http://www.example.com/papers/
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306 HTTP/1.1 200 OK
1307
1308
1309
1311 5.6 DAV:inherited-acl-set
1313 This protected property contains a set of URLs that identify other
1314 resources that also control the access to this resource. To have a
1315 privilege on a resource, not only must the ACL on that resource
1316 (specified in the DAV:acl property of that resource) grant the
1317 privilege, but so must the ACL of each resource identified in the
1318 DAV:inherited-acl-set property of that resource. Effectively, the
1319 privileges granted by the current ACL are ANDed with the privileges
1320 granted by each inherited ACL.
1322
1324 5.7 DAV:principal-collection-set
1326 This protected property of a resource contains a set of URLs that
1327 identify the root collections that contain the principals that are
1328 available on the server that implements this resource. A WebDAV
1329 Access Control Protocol user agent could use the contents of
1330 DAV:principal-collection-set to retrieve the DAV:displayname
1331 property (specified in Section 13.2 of [RFC2518]) of all principals
1332 on that server, thereby yielding human-readable names for each
1333 principal that could be displayed in a user interface.
1335
1336 Since different servers can control different parts of the URL
1337 namespace, different resources on the same host MAY have different
1338 DAV:principal-collection-set values. The collections specified in
1339 the DAV:principal-collection-set MAY be located on different hosts
1340 from the resource. The URLs in DAV:principal-collection-set SHOULD
1341 be http or https scheme URLs. For security and scalability reasons,
1342 a server MAY report only a subset of the entire set of known
1343 principal collections, and therefore clients should not assume they
1344 have retrieved an exhaustive listing. Additionally, a server MAY
1345 elect to report none of the principal collections it knows about,
1346 in which case the property value would be empty.
1348 The value of DAV:principal-collection-set gives the scope of the
1349 DAV:principal-property-search REPORT (defined in Section 9.4).
1350 Clients use the DAV:principal-property-search REPORT to populate
1351 their user interface with a list of principals. Therefore, servers
1352 that limit a client's ability to obtain principal information will
1353 interfere with the client's ability to manipulate access control
1354 lists, due to the difficulty of getting the URL of a principal for
1355 use in an ACE.
1357 5.7.1Example: Retrieving DAV:principal-collection-set
1359 In this example, the client requests the value of the
1360 DAV:principal-collection-set property on the collection resource
1361 identified by URL http://www.example.com/papers/. The property
1362 contains the two URLs, http://www.example.com/acl/users/ and
1363 http://www.example.com/acl/groups/, both wrapped in DAV:href XML
1364 elements. Digest authentication provides credentials for the
1365 principal operating the client.
1367 The client might reasonably follow this request with two separate
1368 PROPFIND requests to retrieve the DAV:displayname property of the
1369 members of the two collections (/acl/users and /acl/groups). This
1370 information could be used when displaying a user interface for
1371 creating access control entries.
1373 >> Request <<
1375 PROPFIND /papers/ HTTP/1.1
1376 Host: www.example.com
1377 Content-type: text/xml; charset="utf-8"
1378 Content-Length: xxx
1379 Depth: 0
1380 Authorization: Digest username="yarong",
1381 realm="yarong@webdav.org", nonce="...",
1382 uri="/papers/", response="...", opaque="..."
1384
1385
1386
1387
1388
1389
1391 >> Response <<
1393 HTTP/1.1 207 Multi-Status
1394 Content-Type: text/xml; charset="utf-8"
1395 Content-Length: xxx
1397
1398
1399
1400 http://www.example.com/papers/
1401
1402
1403
1404 http://www.example.com/acl/users/
1405 http://www.example.com/acl/groups/
1406
1407
1408 HTTP/1.1 200 OK
1409
1410
1411
1413 5.8 Example: PROPFIND to retrieve access control properties
1415 The following example shows how access control information can be
1416 retrieved by using the PROPFIND method to fetch the values of the
1417 DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege-
1418 set, and DAV:acl properties.
1420 >> Request <<
1422 PROPFIND /top/container/ HTTP/1.1
1423 Host: www.example.com
1424 Content-type: text/xml; charset="utf-8"
1425 Content-Length: xxx
1426 Depth: 0
1427 Authorization: Digest username="ejw",
1428 realm="users@foo.org", nonce="...",
1429 uri="/top/container/", response="...", opaque="..."
1431
1432
1433
1434
1435
1436
1437
1438
1439
1441 >> Response <<
1443 HTTP/1.1 207 Multi-Status
1444 Content-Type: text/xml; charset="utf-8"
1445 Content-Length: xxx
1447
1448
1451 http://www.example.com/top/container/
1452
1453
1454
1455 http://www.example.com/users/gclemm
1456
1457
1458
1459
1460 Any operation
1461
1462
1463 Read any object
1464
1465
1466
1467
1468 Write any object
1469
1470
1471 Create an object
1472
1473
1474
1475 Update an object
1476
1477
1478
1479 Delete an object
1480
1481
1482
1483
1484 Read the ACL
1485
1486
1487
1488 Write the ACL
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499 http://www.example.com/users/esedlar
1500
1501
1502
1503
1504
1505
1506
1507
1508 http://www.example.com/groups/marketing
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525 http://www.example.com/top
1526
1527
1528 HTTP/1.1 200 OK
1529
1531 The value of the DAV:owner property is a single DAV:href XML
1532 element containing the URL of the principal that owns this
1533 resource.
1535 The value of the DAV:supported-privilege-set property is a tree of
1536 supported privileges (using "[XML Namespace , localname]" to
1537 identify each privilege):
1539 [DAV:, all] (aggregate, abstract)
1540 |
1541 +-- [DAV:, read]
1542 +-- [DAV:, write] (aggregate, abstract)
1543 |
1544 +-- [http://www.example.com/acl, create]
1545 +-- [http://www.example.com/acl, update]
1546 +-- [http://www.example.com/acl, delete]
1547 +-- [DAV:, read-acl]
1548 +-- [DAV:, write-acl]
1550 The DAV:current-user-privilege-set property contains two
1551 privileges, DAV:read, and DAV:read-acl. This indicates that the
1552 current authenticated user only has the ability to read the
1553 resource, and read the DAV:acl property on the resource.
1555 The DAV:acl property contains a set of four ACEs:
1557 ACE #1: The principal identified by the URL
1558 http://www.example.com/users/esedlar is granted the DAV:read,
1559 DAV:write, and DAV:read-acl privileges.
1561 ACE #2: The principals identified by the URL
1562 http://www.example.com/groups/marketing are denied the DAV:read
1563 privilege. In this example, the principal URL identifies a group.
1565 ACE #3: In this ACE, the principal is a property principal,
1566 specifically the DAV:owner property. When evaluating this ACE, the
1567 value of the DAV:owner property is retrieved, and is examined to
1568 see if it contains a DAV:href XML element. If so, the URL within
1569 the DAV:href element is read, and identifies a principal. In this
1570 ACE, the owner is granted DAV:read-acl, and DAV:write-acl
1571 privileges.
1573 ACE #4: This ACE grants the DAV:all principal (all users) the
1574 DAV:read privilege. This ACE is inherited from the resource
1575 http://www.example.com/top, the parent collection of this resource.
1577 6 ACL EVALUATION
1579 WebDAV ACLs are evaluated in similar manner as ACLs on Windows NT
1580 and in NFSv4 [NFSV4]). An ACL is evaluated to determine whether or
1581 not access will be granted for a WebDAV request. ACEs are
1582 maintained in a particular order, and are evaluated until all of
1583 the permissions required by the current request have been granted,
1584 at which point the ACL evaluation is terminated and access is
1585 granted. If, during ACL evaluation, a ACE (matching the
1586 current user) is encountered for a privilege which has not yet been
1587 granted, the ACL evaluation is terminated and access is denied.
1588 Failure to have all required privileges granted results in access
1589 being denied.
1591 Note that the semantics of many other existing ACL systems may be
1592 represented via this mechanism, by mixing deny and grant ACEs. For
1593 example, consider the standard "rwx" privilege scheme used by UNIX.
1594 In this scheme, if the current user is the owner of the file,
1595 access is granted if the corresponding privilege bit is set and
1596 denied if not set, regardless of the permissions set on the file�s
1597 group and for the world. An ACL for UNIX permissions of "r--rw-r--
1598 "might be constructed like:
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623 and the would be defined as:
1625
1626
1627
1628
1629
1630
1632 Note that the client can still get errors from a UNIX server in
1633 spite of obeying the , including (adding an ACE specifying a principal other than the
1635 ones in the ACL above) or (by trying to reorder
1636 the ACEs in the example above), as these particular implementation
1637 semantics are too complex to be captured with the simple (but
1638 general) declarative restrictions.
1640 7 ACCESS CONTROL AND EXISTING METHODS
1642 This section defines the impact of access control functionality on
1643 existing methods.
1645 7.1 OPTIONS
1647 If the server supports access control, it MUST return "access-
1648 control" as a field in the DAV response header from an OPTIONS
1649 request on any resource implemented by that server. A value of
1650 "access-control" in the DAV header MUST indicate that the server
1651 supports all MUST level requirements and REQUIRED features
1652 specified in this document.
1654 7.1.1Example - OPTIONS
1656 >> Request <<
1658 OPTIONS /foo.html HTTP/1.1
1659 Host: www.example.com
1660 Content-Length: 0
1662 >> Response <<
1663 HTTP/1.1 200 OK
1664 DAV: 1, 2, access-control
1665 Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL
1667 In this example, the OPTIONS response indicates that the server
1668 supports access control and that /foo.html can have its access
1669 control list modified by the ACL method.
1671 7.2 MOVE
1673 When a resource is moved from one location to another due to a MOVE
1674 request, the non-inherited and non-protected ACEs in the DAV:acl
1675 property of the resource MUST NOT be modified, or the MOVE request
1676 fails. Handling of inherited and protected ACEs is intentionally
1677 undefined to give server implementations flexibility in how they
1678 implement ACE inheritance and protection.
1680 7.3 COPY
1682 The DAV:acl property on the resource at the destination of a COPY
1683 MUST be the same as if the resource was created by an individual
1684 resource creation request (e.g. MKCOL, PUT). Clients wishing to
1685 preserve the DAV:acl property across a copy need to read the
1686 DAV:acl property prior to the COPY, then perform an ACL operation
1687 on the new resource at the destination to restore, insofar as this
1688 is possible, the original access control list.
1690 7.4 LOCK
1692 A lock on a resource ensures that only the lock owner can modify
1693 ACEs that are not inherited and not protected (these are the only
1694 ACEs that a client can modify with an ACL request). A lock does not
1695 protect inherited or protected ACEs, since a client cannot modify
1696 them with an ACL request on that resource.
1698 8 ACCESS CONTROL METHODS
1700 8.1 ACL
1702 The ACL method modifies the access control list (which can be read
1703 via the DAV:acl property) of a resource. Specifically, the ACL
1704 method only permits modification to ACEs that are not inherited,
1705 and are not protected. An ACL method invocation modifies all non-
1706 inherited and non-protected ACEs in a resource's access control
1707 list to exactly match the ACEs contained within in the DAV:acl XML
1708 element (specified in Section 5.4) of the request body. An ACL
1709 request body MUST contain only one DAV:acl XML element. Unless the
1710 non-inherited and non-protected ACEs of the DAV:acl property of the
1711 resource can be updated to be exactly the value specified in the
1712 ACL request, the ACL request MUST fail.
1714 It is possible that the ACEs visible to the current user in the
1715 DAV:acl property may only be a portion of the complete set of ACEs
1716 on that resource. If this is the case, an ACL request only modifies
1717 the set of ACEs visible to the current user, and does not affect
1718 any non-visible ACE.
1720 In order to avoid overwriting DAV:acl changes by another client, a
1721 client SHOULD acquire a WebDAV lock on the resource before
1722 retrieving the DAV:acl property of a resource that it intends on
1723 updating.
1725 Implementation Note: Two common operations are to add or remove an
1726 ACE from an existing access control list. To accomplish this, a
1727 client uses the PROPFIND method to retrieve the value of the
1728 DAV:acl property, then parses the returned access control list to
1729 remove all inherited and protected ACEs (these ACEs are tagged with
1730 the DAV:inherited and DAV:protected XML elements). In the remaining
1731 set of non-inherited, non-protected ACEs, the client can add or
1732 remove one or more ACEs before submitting the final ACE set in the
1733 request body of the ACL method.
1735 8.1.1ACL Preconditions
1737 An implementation MUST enforce the following constraints on an ACL
1738 request. If the constraint is violated, a 403 (Forbidden) or 409
1739 (Conflict) response MUST be returned and the indicated XML element
1740 MUST be returned as a child of a top level DAV:error element in an
1741 XML response body.
1743 Though these status elements are generally expressed as empty XML
1744 elements (and are defined as EMPTY in the DTD), implementations MAY
1745 return additional descriptive XML elements as children of the
1746 status element. Clients MUST be able to accept children of these
1747 status elements. Clients that do not understand the additional XML
1748 elements should ignore them.
1750 (DAV:no-ace-conflict): The ACEs submitted in the ACL request MUST
1751 NOT conflict with each other. This is a catchall error code
1752 indicating that an implementation-specific ACL restriction has been
1753 violated.
1755 (DAV:no-protected-ace-conflict): The ACEs submitted in the ACL
1756 request MUST NOT conflict with the protected ACEs on the resource.
1757 For example, if the resource has a protected ACE granting DAV:write
1758 to a given principal, then it would not be consistent if the ACL
1759 request submitted an ACE denying DAV:write to the same principal.
1761 (DAV:no-inherited-ace-conflict): The ACEs submitted in the ACL
1762 request MUST NOT conflict with the inherited ACEs on the resource.
1763 For example, if the resource inherits an ACE from its parent
1764 collection granting DAV:write to a given principal, then it would
1765 not be consistent if the ACL request submitted an ACE denying
1766 DAV:write to the same principal. Note that reporting of this error
1767 will be implementation-dependent. Implementations MUST either
1768 report this error or allow the ACE to be set, and then let normal
1769 ACE evaluation rules determine whether the new ACE has any impact
1770 on the privileges available to a specific principal.
1772 (DAV:limited-number-of-aces): The number of ACEs submitted in the
1773 ACL request MUST NOT exceed the number of ACEs allowed on that
1774 resource. However, ACL-compliant servers MUST support at least one
1775 ACE granting privileges to a single principal, and one ACE granting
1776 privileges to a group.
1778 (DAV:deny-before-grant): All non-inherited deny ACEs MUST precede
1779 all non-inherited grant ACEs.
1781 (DAV:grant-only): The ACEs submitted in the ACL request MUST NOT
1782 include a deny ACE. This precondition applies only when the ACL
1783 restrictions of the resource include the DAV:grant-only constraint
1784 (defined in Section 5.5.1).
1786 (DAV:no-invert): The ACL request MUST NOT include a DAV:invert
1787 element. This precondition applies only when the ACL semantics of
1788 the resource includes the DAV:no-invert constraint (defined in
1789 Section 6.3.4).
1791 (DAV:no-abstract): The ACL request MUST NOT attempt to grant or
1792 deny an abstract privilege (see Section 5.2).
1794 (DAV:not-supported-privilege): The ACEs submitted in the ACL
1795 request MUST be supported by the resource.
1797 (DAV:missing-required-principal): The result of the ACL request
1798 MUST have at least one ACE for each principal identified in a
1799 DAV:required-principal XML element in the ACL semantics of that
1800 resource (see Section 5.5.4).
1802 (DAV:recognized-principal): Every principal URL in the ACL request
1803 MUST identify a principal resource.
1805 (DAV:allowed-principal): The principals specified in the ACEs
1806 submitted in the ACL request MUST be allowed as principals for the
1807 resource. For example, a server where only authenticated principals
1808 can access resources would not allow the DAV:all or
1809 DAV:unauthenticated principals to be used in an ACE, since these
1810 would allow unauthenticated access to resources.
1812 8.1.2Example: the ACL method
1814 In the following example, user "fielding", authenticated by
1815 information in the Authorization header, grants the principal
1816 identified by the URL http://www.example.com/users/esedlar (i.e.,
1817 the user "esedlar") read and write privileges, grants the owner of
1818 the resource read-acl and write-acl privileges, and grants everyone
1819 read privileges.
1821 >> Request <<
1823 ACL /top/container/ HTTP/1.1
1824 Host: www.example.com
1825 Content-Type: text/xml; charset="utf-8"
1826 Content-Length: xxxx
1827 Authorization: Digest username="fielding",
1828 realm="users@foo.org", nonce="...",
1829 uri="/top/container/", response="...", opaque="..."
1831
1832
1833
1834
1835 http://www.example.com/users/esedlar
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1858 >> Response <<
1860 HTTP/1.1 200 OK
1862 8.1.3Example: ACL method failure due to protected ACE conflict
1864 In the following request, user "fielding", authenticated by
1865 information in the Authorization header, attempts to deny the
1866 principal identified by the URL
1867 http://www.example.com/users/esedlar (i.e., the user "esedlar")
1868 write privileges. Prior to the request, the DAV:acl property on the
1869 resource contained a protected ACE (see Section 5.4.3) granting
1870 DAV:owner the DAV:read and DAV:write privileges. The principal
1871 identified by URL http://www.example.com/users/esedlar is the owner
1872 of the resource. The ACL method invocation fails because the
1873 submitted ACE conflicts with the protected ACE, thus violating the
1874 semantics of ACE protection.
1876 >> Request <<
1878 ACL /top/container/ HTTP/1.1
1879 Host: www.example.com
1880 Content-Type: text/xml; charset="utf-8"
1881 Content-Length: xxxx
1882 Authorization: Digest username="fielding",
1883 realm="users@foo.org", nonce="...",
1884 uri="/top/container/", response="...", opaque="..."
1886
1887
1888
1889
1890 http://www.example.com/users/esedlar
1891
1892
1893
1894
1895
1896
1898 >> Response <<
1900 HTTP/1.1 403 Forbidden
1901 Content-Type: text/xml; charset="utf-8"
1902 Content-Length: xxx
1904
1905
1906
1907
1909 8.1.4Example: ACL method failure due to an inherited ACE conflict
1911 In the following request, user "ejw", authenticated by information
1912 in the Authorization header, tries to change the access control
1913 list on the resource http://www.example.com/top/index.html. This
1914 resource has two inherited ACEs.
1916 Inherited ACE #1 grants the principal identified by URL
1917 http://www.example.com/users/ejw (i.e., the user "ejw")
1918 http://www.example.com/privs/write-all and DAV:read-acl privileges.
1919 On this server, http://www.example.com/privs/write-all is an
1920 aggregate privilege containing DAV:write, and DAV:write-acl.
1922 Inherited ACE #2 grants principal DAV:all the DAV:read privilege.
1924 The request attempts to set a (non-inherited) ACE, denying the
1925 principal identified by the URL http://www.example.com/users/ejw
1926 (i.e., the user "ejw") DAV:write permission. This conflicts with
1927 inherited ACE #1. Note that the decision to report an inherited ACE
1928 conflict is specific to this server implementation. Another server
1929 implementation could have allowed the new ACE to be set, and then
1930 used normal ACE evaluation rules to determine whether the new ACE
1931 has any impact on the privileges available to a principal.
1933 >> Request <<
1935 ACL /top/index.html HTTP/1.1
1936 Host: www.example.com
1937 Content-Type: text/xml; charset="utf-8"
1938 Content-Length: xxxx
1939 Authorization: Digest username="ejw",
1940 realm="users@foo.org", nonce="...",
1941 uri="/top/index.html", response="...", opaque="..."
1943
1944
1945
1946
1947 http://www.example.com/users/ejw
1948
1949
1950
1951
1953 >> Response <<
1955 HTTP/1.1 403 Forbidden
1956 Content-Type: text/xml; charset="utf-8"
1957 Content-Length: xxx
1959
1960
1961
1962
1964 8.1.5Example: ACL method failure due to an attempt to set grant and deny in a
1965 single ACE.
1967 In this example, user "ygoland", authenticated by information in
1968 the Authorization header, tries to change the access control list
1969 on the resource http://www.example.com/diamond/engagement-ring.gif.
1970 The ACL request includes a single, syntactically and semantically
1971 incorrect ACE, which attempts to grant the group identified by the
1972 URL http://www.example.com/users/friends DAV:read privilege and
1973 deny the principal identified by URL
1974 http://www.example.com/users/ygoland-so (i.e., the user "ygoland-
1975 so") DAV:read privilege. However, it is illegal to have multiple
1976 principal elements, as well as both a grant and deny element in the
1977 same ACE, so the request fails due to poor syntax.
1979 >> Request <<
1981 ACL /diamond/engagement-ring.gif HTTP/1.1
1982 Host: www.example.com
1983 Content-Type: text/xml; charset="utf-8"
1984 Content-Length: xxxx
1985 Authorization: Digest username="ygoland",
1986 realm="users@foo.org", nonce="...",
1987 uri="/diamond/engagement-ring.gif", response="...", opaque="..."
1989
1990
1991
1992
1993 http://www.example.com/users/friends
1994
1995
1996
1997 http://www.example.com/users/ygoland-so
1998
1999
2000
2001
2003 >> Response <<
2005 HTTP/1.1 400 Bad Request
2006 Content-Length: 0
2008 Note that if the request had been divided into two ACEs, one to
2009 grant, and one to deny, the request would have been syntactically
2010 well formed.
2012 9 ACCESS CONTROL REPORTS
2014 9.1 REPORT Method
2016 The REPORT method (defined in Section 3.6 of [RFC3253]) provides an
2017 extensible mechanism for obtaining information about a resource.
2018 Unlike the PROPFIND method, which returns the value of one or more
2019 named properties, the REPORT method can involve more complex
2020 processing. REPORT is valuable in cases where the server has access
2021 to all of the information needed to perform the complex request
2022 (such as a query), and where it would require multiple requests for
2023 the client to retrieve the information needed to perform the same
2024 request.
2026 A server that supports the WebDAV Access Control Protocol MUST
2027 support the DAV:expand-property report (defined in Section 3.8 of
2028 [RFC3253]).
2030 9.2 DAV:acl-principal-prop-set Report
2032 The DAV:acl-principal-prop-set report returns, for all principals
2033 in the DAV:acl property (of the Request-URI) that are identified by
2034 http(s) URLs or by a DAV:property principal, the value of the
2035 properties specified in the REPORT request body. In the case where
2036 a principal URL appears multiple times, the DAV:acl-principal-prop-
2037 set report MUST return the properties for that principal only once.
2038 Support for this report is REQUIRED.
2040 One expected use of this report is to retrieve the human readable
2041 name (found in the DAV:displayname property) of each principal
2042 found in an ACL. This is useful for constructing user interfaces
2043 that show each ACE in a human readable form.
2045 Marshalling
2047 The request body MUST be a DAV:acl-principal-prop-set XML element.
2049
2050 ANY value: a sequence of one or more elements, with at most one DAV:prop
2051 element.
2052 prop: see RFC 2518, Section 12.11
2054 This report is only defined when the Depth header has value "0";
2055 other values result in a 400 (Bad Request) error response. Note
2056 that [RFC3253], Section 3.6, states that if the Depth header is not
2057 present, it defaults to a value of "0".
2059 The response body for a successful request MUST be a
2060 DAV:multistatus XML element (i.e., the response uses the same
2061 format as the response for PROPFIND). In the case where there are
2062 no response elements, the returned multistatus XML element is
2063 empty.
2065 multistatus: see RFC 2518, Section 12.9
2067 The response body for a successful DAV:acl-principal-prop-set
2068 REPORT request MUST contain a DAV:response element for each
2069 principal identified by an http(s) URL listed in a DAV:principal
2070 XML element of an ACE within the DAV:acl property of the resource
2071 identified by the Request-URI.
2073 Postconditions:
2075 (DAV:number-of-matches-within-limits): The number of matching
2076 principals must fall within server-specific, predefined limits. For
2077 example, this condition might be triggered if a search
2078 specification would cause the return of an extremely large number
2079 of responses.
2081 9.2.1Example: DAV:acl-principal-prop-set Report
2083 Resource http://www.example.com/index.html has an ACL with three
2084 ACEs:
2086 ACE #1: All principals (DAV:all) have DAV:read and DAV:read-
2087 current-user-privilege-set access.
2089 ACE #2: The principal identified by
2090 http://www.example.com/people/gstein (the user "gstein") is granted
2091 DAV:write, DAV:write-acl, DAV:read-acl privileges.
2093 ACE #3: The group identified by
2094 http://www.example.com/groups/authors (the "authors" group) is
2095 granted DAV:write and DAV:read-acl privileges.
2097 The following example shows a DAV:acl-principal-prop-set report
2098 requesting the DAV:displayname property. It returns the value of
2099 DAV:displayname for resources http://www.example.com/people/gstein
2100 and http://www.example.com/groups/authors , but not for DAV:all,
2101 since this is not an http(s) URL.
2103 >> Request <<
2105 REPORT /index.html HTTP/1.1
2106 Host: www.example.com
2107 Content-Type: text/xml; charset="utf-8"
2108 Content-Length: xxxx
2109 Depth: 0
2111
2112
2113
2114
2115
2116
2118 >> Response <<
2120 HTTP/1.1 207 Multi-Status
2121 Content-Type: text/xml; charset="utf-8"
2122 Content-Length: xxxx
2124
2125
2126
2127 http://www.example.com/people/gstein
2128
2129
2130 Greg Stein
2131
2132 HTTP/1.1 200 OK
2133
2134
2135
2136 http://www.example.com/groups/authors
2137
2138
2139 Site authors
2140
2141 HTTP/1.1 200 OK
2142
2143
2144
2146 9.3 DAV:principal-match REPORT
2148 The DAV:principal-match REPORT is used to identify all members (at
2149 any depth) of the collection identified by the Request-URI that
2150 match the current user. In particular, if the collection contains
2151 principals, the report can be used to identify all members of the
2152 collection that match the current user. Alternatively, if the
2153 collection contains resources that have a property that identifies
2154 a principal (e.g. DAV:owner), the report can be used to identify
2155 all members of the collection whose property identifies a principal
2156 that matches the current user. For example, this report can return
2157 all of the resources in a collection hierarchy that are owned by
2158 the current user. Support for this report is REQUIRED.
2160 Marshalling:
2162 The request body MUST be a DAV:principal-match XML element.
2164
2165
2166 ANY value: an element whose value identifies a property. The expectation is
2167 the value of the named property typically contains an href element that
2168 contains the URI of a principal
2169
2170 prop: see RFC 2518, Section 12.11
2172 This report is only defined when the Depth header has value "0";
2173 other values result in a 400 (Bad Request) error response. Note
2174 that [RFC3253], Section 3.6, states that if the Depth header is not
2175 present, it defaults to a value of "0".
2177 The response body for a successful request MUST be a
2178 DAV:multistatus XML element. In the case where there are no
2179 response elements, the returned multistatus XML element is empty.
2181 multistatus: see RFC 2518, Section 12.9
2183 The response body for a successful DAV:principal-match REPORT
2184 request MUST contain a DAV:response element for each member of the
2185 collection that matches the current user. When the DAV:principal-
2186 property element is used, a match occurs if the current user is
2187 matched by the principal identified by the URI found in the
2188 DAV:href element of the property identified by the DAV:principal-
2189 property element. When the DAV:self element is used in a
2190 DAV:principal-match report issued against a group, it matches the
2191 group if a member identifies the same principal as the current
2192 user.
2194 If DAV:prop is specified in the request body, the properties
2195 specified in the DAV:prop element MUST be reported in the
2196 DAV:response elements.
2198 9.3.1Example: DAV:principal-match REPORT
2200 The following example identifies the members of the collection
2201 identified by the URL http://www.example.com/doc that are owned by
2202 the current user. The current user ("gclemm") is authenticated
2203 using Digest authentication.
2205 >> Request <<
2207 REPORT /doc/ HTTP/1.1
2208 Host: www.example.com
2209 Authorization: Digest username="gclemm",
2210 realm="gclemm@webdav.org", nonce="...",
2211 uri="/papers/", response="...", opaque="..."
2212 Content-Type: text/xml; charset="utf-8"
2213 Content-Length: xxxx
2214 Depth: 0
2216
2217
2218
2219
2220
2221
2223 >> Response <<
2225 HTTP/1.1 207 Multi-Status
2226 Content-Type: text/xml; charset="utf-8"
2227 Content-Length: xxxx
2229
2230
2231
2232 http://www.example.com/doc/foo.html
2233 HTTP/1.1 200 OK
2234
2235
2236 http://www.example.com/doc/img/bar.gif
2237 HTTP/1.1 200 OK
2238
2239
2241 9.4 DAV:principal-property-search REPORT
2243 The DAV:principal-property-search REPORT performs a search for all
2244 principals whose properties contain character data that matches the
2245 search criteria specified in the request. One expected use of this
2246 report is to discover the URL of a principal associated with a
2247 given person or group by searching for them by name. This is done
2248 by searching over DAV:displayname, which is defined on all
2249 principals.
2251 The actual search method (exact matching vs. substring matching vs,
2252 prefix-matching, case-sensitivity) deliberately is left to the
2253 server implementation to allow implementation on a wide set of
2254 possible user management systems. In cases where the implementation
2255 of DAV:principal-property-search is not constrained by the
2256 semantics of an underlying user management repository, preferred
2257 default semantics are caseless substring matches.
2259 For implementation efficiency, servers do not typically support
2260 searching on all properties. A client can discover the set of
2261 searchable properties by using the DAV:principal-search-property-
2262 set REPORT, defined in Section 9.5.
2264 Support for the DAV:principal-property-search report is REQUIRED.
2266 Implementation Note: The value of a WebDAV property is a sequence
2267 of well-formed XML, and hence can include any character in the
2268 Unicode/ISO-10646 standard, that is, most known characters in human
2269 languages. Due to the idiosyncrasies of case mapping across human
2270 languages, implementation of case-insensitive matching is non-
2271 trivial. Implementors of servers that do perform substring matching
2272 are strongly encouraged to consult [CaseMap], especially Section
2273 2.3 ("Caseless Matching"), for guidance when implementing their
2274 case-insensitive matching algorithms.
2276 Implementation Note: Some implementations of this protocol will use
2277 an LDAP repository for storage of principal metadata. The schema
2278 describing each attribute (akin to a WebDAV property) in an LDAP
2279 repository specifies whether it supports case-sensitive or caseless
2280 searching. One of the benefits of leaving the search method to the
2281 discretion of the server implementation is the default LDAP
2282 attribute search behavior can be used when implementing the
2283 DAV:principal-property-search report.
2285 Marshalling:
2287 The request body MUST be a DAV:principal-property-search XML
2288 element containing a search specification and an optional list of
2289 properties. For every principal that matches the search
2290 specification, the response will contain the value of the requested
2291 properties on that principal.
2293
2296 By default, the report searches all members (at any depth) of the
2297 collection identified by the Request-URI. If DAV:apply-to-
2298 principal-collection-set is specified in the request body, the
2299 request is applied instead to each collection identified by the
2300 DAV:prinicipal-collection-set property of the resource identified
2301 by the Request-URI.
2303 The DAV:property-search element contains a prop element enumerating
2304 the properties to be searched and a match element, containing the
2305 search string.
2307
2308 prop: see RFC 2518, Section 12.11
2310
2312 Multiple property-search elements or multiple elements within a
2313 DAV:prop element will be interpreted with a logical AND.
2315 This report is only defined when the Depth header has value "0";
2316 other values result in a 400 (Bad Request) error response. Note
2317 that [RFC3253], Section 3.6, states that if the Depth header is not
2318 present, it defaults to a value of "0".
2320 The response body for a successful request MUST be a
2321 DAV:multistatus XML element. In the case where there are no
2322 response elements, the returned multistatus XML element is empty.
2324 multistatus: see RFC 2518, Section 12.9
2326 The response body for a successful DAV:principal-property-search
2327 REPORT request MUST contain a DAV:response element for each
2328 principal whose property values satisfy the search specification
2329 given in DAV:principal-property-search.
2331 The response body for an unsuccessful DAV:principal-property-search
2332 REPORT request MUST contain, after the XML element indicating the
2333 failed precondition or postcondition, a DAV:prop element containing
2334 the property that caused the pre/postcondition to fail.
2336 If DAV:prop is specified in the request body, the properties
2337 specified in the DAV:prop element MUST be reported in the
2338 DAV:response elements.
2340 Preconditions:
2342 (DAV:property-must-be-searchable): All properties specified in the
2343 DAV:principal-property-search REPORT must be searchable.
2345 Postconditions:
2347 (DAV:number-of-matches-within-limits): The number of matching
2348 principals must fall within server-specific, predefined limits. For
2349 example, this condition might be triggered if a search
2350 specification would cause the return of an extremely large number
2351 of responses.
2353 9.4.1Matching
2355 There are several cases to consider when matching strings. The
2356 easiest case is when a property value is "simple" and has only
2357 character information item content (see [REC-XML-INFOSET]). For
2358 example, the search string "julian" would match the DAV:displayname
2359 property with value "Julian Reschke". Note that the on-the-wire
2360 marshalling of DAV:displayname in this case is:
2362 Julian Reschke
2364 The name of the property is encoded into the XML element
2365 information item, and the character information item content of the
2366 property is "Julian Reschke".
2368 A more complicated case occurs when properties have mixed content
2369 (that is, compound values consisting of multiple child element
2370 items, other types of information items, and character information
2371 item content). Consider the property "aprop" in the namespace
2372 "http://www.example.com/props/", marshalled as:
2374
2375 {cdata 0}{cdata 1}
2376 {cdata 2}{cdata 3}
2377
2379 In this case, matching is performed on each individual contiguous
2380 sequence of character information items. In the example above, a
2381 search string would be compared to the four following strings:
2383 {cdata 0}
2384 {cdata 1}
2385 {cdata 2}
2386 {cdata 3}
2388 That is, four individual matches would be performed, one each for
2389 {cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}.
2391 9.4.2Example: successful DAV:principal-property-search REPORT
2393 In this example, the client requests the principal URLs of all
2394 users whose DAV:displayname property contains the substring "doE"
2395 and whose "title" property in the namespace
2396 "http://BigCorp.com/ns/" (that is, their professional title)
2397 contains "Sales". In addition, the client requests five properties
2398 to be returned with the matching principals:
2400 In the DAV: namespace: displayname
2401 In the http://www.example.com/ns/ namespace: department, phone,
2402 office, salary
2404 The response shows that two principal resources meet the search
2405 specification, "John Doe" and "Zygdoebert Smith". The property
2406 "salary" in namespace "http://www.example.com/ns/" is not returned,
2407 since the principal making the request does not have sufficient
2408 access permissions to read this property.
2410 >> Request <<
2412 REPORT /users/ HTTP/1.1
2413 Host: www.example.com
2414 Content-Type: text/xml; charset=utf-8
2415 Content-Length: xxxx
2416 Depth: 0
2418
2419
2420
2421
2422
2423
2424 doE
2425
2426
2427
2428
2429
2430 Sales
2431
2432
2433
2434
2435
2436
2437
2438
2439
2441 >> Response <<
2443 HTTP/1.1 207 Multi-Status
2444 Content-Type: text/xml; charset=utf-8
2445 Content-Length: xxxx
2446
2447
2448
2449 http://www.example.com/users/jdoe
2450
2451
2452 John Doe
2453 Widget Sales
2454 234-4567
2455 209
2456
2457 HTTP/1.1 200 OK
2458
2459
2460
2461
2462
2463 HTTP/1.1 403 Forbidden
2464
2465
2466
2467 http://www.example.com/users/zsmith
2468
2469
2470 Zygdoebert Smith
2471 Gadget Sales
2472 234-7654
2473 114
2474
2475 HTTP/1.1 200 OK
2476
2477
2478
2479
2480
2481 HTTP/1.1 403 Forbidden
2482
2483
2484
2486 9.4.3Example: Unsuccessful DAV:principal-property-search REPORT
2488 In this example, the client requests a search on the non-searchable
2489 property "phone" in the namespace "http://www.example.com/ns/".
2490 The response is a 403 (Forbidden), with a response body containing
2491 a DAV:property-must-be-searchable XML element as the value of a
2492 DAV:error XML element.
2494 >> Request <<
2496 REPORT /users/ HTTP/1.1
2497 Host: www.example.com
2498 Content-Type: text/xml; charset=utf-8
2499 Content-Length: xxxx
2500 Depth: 0
2502
2503
2504
2505
2506
2507
2508 232
2509
2510
2512 >> Response <<
2514 HTTP/1.1 403 Forbidden
2515 Content-Type: text/xml; charset=utf-8
2516 Content-Length: xxxx
2518
2519
2520
2521
2522
2523
2524
2525
2527 9.5 DAV:principal-search-property-set REPORT
2529 The DAV:principal-search-property-set REPORT identifies those
2530 properties that may be searched using the DAV:principal-property-
2531 search REPORT (defined in Section 9.4).
2533 Servers MUST support the DAV:principal-search-property-set REPORT
2534 on all collections identified in the value of a DAV:principal-
2535 collection-set property.
2537 An access control protocol user agent could use the results of the
2538 DAV:principal-search-property-set REPORT to present a query
2539 interface to the user for retrieving principals.
2541 Support for this report is REQUIRED.
2543 Implementation Note: Some clients will have only limited screen
2544 real estate for the display of lists of searchable properties. In
2545 this case, a user might appreciate having the most frequently
2546 searched properties be displayed on-screen, rather than having to
2547 scroll through a long list of searchable properties. One mechanism
2548 for signaling the most frequently searched properties is to return
2549 them towards the start of a list of properties. A client can then
2550 preferentially display the list of properties in order, increasing
2551 the likelihood that the most frequently searched properties will
2552 appear on-screen, and will not require scrolling for their
2553 selection.
2555 Marshalling:
2557 The request body MUST be an empty DAV:principal-search-property-set
2558 XML element.
2560 This report is only defined when the Depth header has value "0";
2561 other values result in a 400 (Bad Request) error response. Note
2562 that [RFC3253], Section 3.6, states that if the Depth header is not
2563 present, it defaults to a value of "0".
2565 The response body MUST be a DAV:principal-search-property-set XML
2566 element, containing a DAV:principal-search-property XML element for
2567 each property that may be searched with the DAV:principal-property-
2568 search REPORT. A server MAY limit its response to just a subset of
2569 the searchable properties, such as those likely to be useful to an
2570 interactive access control client.
2572
2574 Each DAV:principal-search-property XML element contains exactly one
2575 searchable property, and a description of the property.
2577
2579 The DAV:prop element contains one principal property on which the
2580 server is able to perform a DAV:principal-property-search REPORT.
2582 prop: see RFC 2518, Section 12.11
2584 The description element is a human-readable description of what
2585 information this property represents. Servers MUST indicate the
2586 human language of the description using the xml:lang attribute and
2587 SHOULD consider the HTTP Accept-Language request header when
2588 selecting one of multiple available languages.
2590
2592 9.5.1Example: DAV:principal-search-property-set REPORT
2594 In this example, the client determines the set of searchable
2595 principal properties by requesting the DAV:principal-search-
2596 property-set REPORT on the root of the server's principal URL
2597 collection set, identified by http://www.example.com/users/.
2599 >> Request <<
2600 REPORT /users/ HTTP/1.1
2601 Host: www.example.com
2602 Content-Type: text/xml; charset="utf-8"
2603 Content-Length: xxx
2604 Accept-Language: en, de
2605 Authorization: BASIC d2FubmFtYWs6cGFzc3dvcmQ=
2606 Depth: 0
2608
2609
2611 >> Response <<
2613 HTTP/1.1 200 OK
2614 Content-Type: text/xml; charset="utf-8"
2615 Content-Length: xxx
2617
2618
2619
2620
2621
2622
2623 Full name
2624
2625
2626
2627
2628
2629 Job title
2630
2631
2633 10 XML PROCESSING
2635 Implementations of this specification MUST support the XML element
2636 ignore rule, as specified in Section 23.3.2 of [RFC2518], and the
2637 XML Namespace recommendation [REC-XML-NAMES].
2639 Note that use of the DAV namespace is reserved for XML elements and
2640 property names defined in a standards-track or Experimental IETF
2641 RFC.
2643 11 INTERNATIONALIZATION CONSIDERATIONS
2645 In this specification, the only human-readable content can be found
2646 in the description XML element, found within the DAV:supported-
2647 privilege-set property. This element contains a human-readable
2648 description of the capabilities controlled by a privilege. As a
2649 result, the description element must be capable of representing
2650 descriptions in multiple character sets. Since the description
2651 element is found within a WebDAV property, it is represented on the
2652 wire as XML [REC-XML], and hence can leverage XML's language
2653 tagging and character set encoding capabilities. Specifically, XML
2654 processors at minimum must be able to read XML elements encoded
2655 using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual
2656 plane. XML examples in this specification demonstrate use of the
2657 charset parameter of the Content-Type header, as defined in
2658 [RFC3023], as well as the XML "encoding" attribute, which together
2659 provide charset identification information for MIME and XML
2660 processors. Futhermore, this specification requires server
2661 implementations to tag description fields with the xml:lang
2662 attribute (see Section 2.12 of [REC-XML]), which specifies the
2663 human language of the description. Additionally, server
2664 implementations should take into account the value of the Accept-
2665 Language HTTP header to determine which description string to
2666 return.
2668 For XML elements other than the description element, it is expected
2669 that implementations will treat the property names, privilege
2670 names, and values as tokens, and convert these tokens into human-
2671 readable text in the user's language and character set when
2672 displayed to a person. Only a generic WebDAV property display
2673 utility would display these values in their raw form to a human
2674 user.
2676 For error reporting, we follow the convention of HTTP/1.1 status
2677 codes, including with each status code a short, English description
2678 of the code (e.g., 200 (OK)). While the possibility exists that a
2679 poorly crafted user agent would display this message to a user,
2680 internationalized applications will ignore this message, and
2681 display an appropriate message in the user's language and character
2682 set.
2684 Further internationalization considerations for this protocol are
2685 described in the WebDAV Distributed Authoring protocol
2686 specification [RFC2518].
2688 12 SECURITY CONSIDERATIONS
2690 Applications and users of this access control protocol should be
2691 aware of several security considerations, detailed below. In
2692 addition to the discussion in this document, the security
2693 considerations detailed in the HTTP/1.1 specification [RFC2616],
2694 the WebDAV Distributed Authoring Protocol specification [RFC2518],
2695 and the XML Media Types specification [RFC3023] should be
2696 considered in a security analysis of this protocol.
2698 12.1Increased Risk of Compromised Users
2700 In the absence of a mechanism for remotely manipulating access
2701 control lists, if a single user's authentication credentials are
2702 compromised, only those resources for which the user has access
2703 permission can be read, modified, moved, or deleted. With the
2704 introduction of this access control protocol, if a single
2705 compromised user has the ability to change ACLs for a broad range
2706 of other users (e.g., a super-user), the number of resources that
2707 could be altered by a single compromised user increases. This risk
2708 can be mitigated by limiting the number of people who have write-
2709 acl privileges across a broad range of resources.
2711 12.2Risks of the DAV:read-acl and DAV:current-user-privilege-set Privileges
2713 The ability to read the access privileges (stored in the DAV:acl
2714 property), or the privileges permitted the currently authenticated
2715 user (stored in the DAV:current-user-privilege-set property) on a
2716 resource may seem innocuous, since reading an ACL cannot possibly
2717 affect the resource's state. However, if all resources have world-
2718 readable ACLs, it is possible to perform an exhaustive search for
2719 those resources that have inadvertently left themselves in a
2720 vulnerable state, such as being world-writeable. In particular, the
2721 property retrieval method PROPFIND, executed with Depth infinity on
2722 an entire hierarchy, is a very efficient way to retrieve the
2723 DAV:acl or DAV:current-user-privilege-set properties. Once found,
2724 this vulnerability can be exploited by a denial of service attack
2725 in which the open resource is repeatedly overwritten. Alternately,
2726 writeable resources can be modified in undesirable ways.
2728 To reduce this risk, read-acl privileges should not be granted to
2729 unauthenticated principals, and restrictions on read-acl and read-
2730 current-user-privilege-set privileges for authenticated principals
2731 should be carefully analyzed when deploying this protocol. Access
2732 to the current-user-privilege-set property will involve a tradeoff
2733 of usability versus security. When the current-user-privilege-set
2734 is visible, user interfaces are expected to provide enhanced
2735 information concerning permitted and restricted operations, yet
2736 this information may also indicate a vulnerability that could be
2737 exploited. Deployment of this protocol will need to evaluate this
2738 tradeoff in light of the requirements of the deployment
2739 environment.
2741 12.3No Foreknowledge of Initial ACL
2743 In an effort to reduce protocol complexity, this protocol
2744 specification intentionally does not address the issue of how to
2745 manage or discover the initial ACL that is placed upon a resource
2746 when it is created. The only way to discover the initial ACL is to
2747 create a new resource, then retrieve the value of the DAV:acl
2748 property. This assumes the principal creating the resource also has
2749 been granted the DAV:read-acl privilege.
2751 As a result, it is possible that a principal could create a
2752 resource, and then discover that its ACL grants privileges that are
2753 undesirable. Furthermore, this protocol makes it possible (though
2754 unlikely) that the creating principal could be unable to modify the
2755 ACL, or even delete the resource. Even when the ACL can be
2756 modified, there will be a short period of time when the resource
2757 exists with the initial ACL before its new ACL can be set.
2759 Several factors mitigate this risk. Human principals are often
2760 aware of the default access permissions in their editing
2761 environments and take this into account when writing information.
2762 Furthermore, default privilege policies are usually very
2763 conservative, limiting the privileges granted by the initial ACL.
2765 13 AUTHENTICATION
2767 Authentication mechanisms defined for use with HTTP and WebDAV also
2768 apply to this WebDAV Access Control Protocol, in particular the
2769 Basic and Digest authentication mechanisms defined in [RFC2617].
2770 Implementation of the ACL spec requires that Basic authentication,
2771 if used, MUST only be supported over secure transport such as TLS.
2773 14 IANA CONSIDERATIONS
2775 This document uses the namespace defined by [RFC2518] for XML
2776 elements. That is, this specification uses the "DAV:" URI
2777 namespace, previously registered in the URI schemes registry. All
2778 other IANA considerations mentioned in [RFC2518] are also
2779 applicable to this specification.
2781 15 INTELLECTUAL PROPERTY
2783 The following notice is copied from RFC 2026, section 10.4, and
2784 describes the position of the IETF concerning intellectual property
2785 claims made against this document.
2787 The IETF takes no position regarding the validity or scope of any
2788 intellectual property or other rights that might be claimed to
2789 pertain to the implementation or use other technology described in
2790 this document or the extent to which any license under such rights
2791 might or might not be available; neither does it represent that it
2792 has made any effort to identify any such rights. Information on
2793 the IETF's procedures with respect to rights in standards-track and
2794 standards-related documentation can be found in BCP-11. Copies of
2795 claims of rights made available for publication and any assurances
2796 of licenses to be made available, or the result of an attempt made
2797 to obtain a general license or permission for the use of such
2798 proprietary rights by implementers or users of this specification
2799 can be obtained from the IETF Secretariat.
2801 The IETF invites any interested party to bring to its attention any
2802 copyrights, patents or patent applications, or other proprietary
2803 rights that may cover technology that may be required to practice
2804 this standard. Please address the information to the IETF
2805 Executive Director.
2807 16 ACKNOWLEDGEMENTS
2809 This protocol is the collaborative product of the WebDAV ACL design
2810 team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry Lind, Sean
2811 Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead. The authors
2812 are grateful for the detailed review and comments provided by Jim
2813 Amsden, Dylan Barrell, Gino Basso, Murthy Chintalapati, Lisa
2814 Dusseault, Stefan Eissing, Tim Ellison, Yaron Goland, Dennis
2815 Hamilton, Laurie Harper, Eckehard Hermann, Ron Jacobs, Chris
2816 Knight, Remy Maucherat, Larry Masinter, Joe Orton, Peter Raymond,
2817 Julian Reschke, and Keith Wannamaker. We thank Keith Wannamaker for
2818 the initial text of the principal property search sections. Prior
2819 work on WebDAV access control protocols has been performed by Yaron
2820 Goland, Paul Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff.
2821 We would like to acknowledge the foundation laid for us by the
2822 authors of the DeltaV, WebDAV and HTTP protocols upon which this
2823 protocol is layered, and the invaluable feedback from the WebDAV
2824 working group.
2826 17 REFERENCES
2828 17.1Normative References
2830 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
2831 Requirement Levels." RFC 2119, BCP 14, March, 1997.
2833 [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible
2834 Markup Language (XML)." World Wide Web Consortium Recommendation
2835 REC-xml.http://www.w3.org/TR/REC-xml
2837 [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Name Spaces in
2838 XML" World Wide Web Consortium Recommendation REC-xml-names.
2839 http://www.w3.org/TR/REC-xml-names/
2841 [RFC3253] G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead,
2842 "Versioning Extensions to WebDAV." RFC 3253, March 2002.
2844 [REC-XML-INFOSET] J. Cowan, R. Tobin, "XML Information Set." World
2845 Wide Web Consortium Recommendation REC-xml-infoset.
2846 http://www.w3.org/TR/xml-infoset/
2848 [RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L.
2849 Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer
2850 Protocol -- HTTP/1.1." RFC 2616, June, 1999.
2852 [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P.
2853 Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and
2854 Digest Access Authentication." RFC 2617, June, 1999.
2856 [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D.
2857 Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV." RFC
2858 2518, February, 1999.
2860 [RFC2368] P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL
2861 scheme." RFC 2368, July, 1998.
2863 [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types." RFC
2864 3023, January, 2001.
2866 [RFC3010] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C.
2867 Beame, M. Eisler, D.Noveck "NFS version 4 Protocol." RFC 3010,
2868 December 2000.
2870 [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and
2871 ISO 10646." RFC 2279, January, 1998.
2873 17.2Informational References
2875 [RFC2026] S.Bradner, "The Internet Standards Process - Revision 3."
2876 RFC 2026, BCP 9. Harvard, October, 1996.
2878 [RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255.
2879 Netscape, December, 1997.
2881 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
2882 Access Protocol (v3)." RFC 2251. Critical Angle, Netscape, Isode,
2883 December, 1997.
2885 [CaseMap] M. Davis, "Case Mappings", Unicode Standard Annex #21,
2886 March 26, 2001. http://www.unicode.org/unicode/reports/tr21
2887 18 AUTHORS' ADDRESSES
2889 Geoffrey Clemm
2891 IBM
2893 20 Maguire Road
2895 Lexington, MA 02421
2897 Email: geoffrey.clemm@us.ibm.com
2899 Anne Hopkins
2901 Microsoft Corporation
2903 One Microsoft Way
2905 Redmond, WA 98052
2907 Email: annehop@microsoft.com
2909 Eric Sedlar
2911 Oracle Corporation
2913 500 Oracle Parkway
2915 Redwood Shores, CA 94065
2917 Email: eric.sedlar@oracle.com
2919 Jim Whitehead
2920 U.C. Santa Cruz
2921 Dept. of Computer Science
2922 Baskin Engineering
2923 1156 High Street
2924 Santa Cruz, CA 95064
2925 Email: ejw@cse.ucsc.edu
2926 19 APPENDICES
2928 19.1WebDAV XML Document Type Definition Addendum
2930 All XML elements defined in this Document Type Definition (DTD)
2931 belong to the DAV namespace. This DTD should be viewed as an
2932 addendum to the DTD provided in [RFC2518], section 23.1.
2934
2936
2937
2938
2939
2940
2941
2942
2943
2944
2946
2948
2950
2951
2952
2953
2955
2957
2959
2960
2962
2964
2965
2968
2969
2970
2971
2973
2974
2976
2978
2979
2980
2982
2986
2987
2988
2989
2990
2991
2993
2994
2995
2997
2999
3001
3003
3005
3007
3009
3011
3014
3016
3017
3018
3020
3021
3023
3025
3026
3028
3031
3033
3034
3035
3036
3037
3038
3039
3040
3041
3043
3045
3046 ANY value: a sequence of one or more elements, with at most one DAV:prop
3047 element.
3049
3050
3051 ANY value: an element whose value identifies a property. The expectation is
3052 the value of the named property typically contains an href element that
3053 contains the URI of a principal
3054
3056
3057
3058
3060
3061
3063 19.2WebDAV Method Privilege Table (Normative)
3065 The following table of WebDAV methods (as defined in RFC 2518, 2616, and
3066 3253) clarifies which privileges are required for access for each
3067 method. Note that the privileges listed, if denied, MUST cause access
3068 to be denied. However, given that a specific implementation MAY define
3069 an additional custom privilege to control access to existing methods,
3070 having all of the indicated privileges does not mean that access will be
3071 granted. Note that lack of the indicated privileges does not imply that
3072 access will be denied, since a particular implementation may use a sub-
3073 privilege aggregated under the indicated privilege to control access.
3075 Privileges required refer to the current resource being processed unless
3076 otherwise specified.
3078 METHOD PRIVILEGES
3079 GET
3080 HEAD
3081 OPTIONS
3082 PUT (on parent coll if resource
3083 doesn't already exist, or on existing resource
3084 otherwise)
3085 PROPPATCH
3086 ACL
3087 PROPFIND (plus and
3088 as needed)
3089 COPY , on target collection
3090 MOVE (no target exists) on source&target coll, plus
3091
3092 on the resource being moved MAY be required
3093 MOVE (target exists) As above, plus on the resource to be
3094 overwritten
3095 DELETE , on parent collection
3096 LOCK
3097 MKCOL (on parent coll)
3098 UNLOCK
3099 CHECKOUT
3100 CHECKIN
3101 REPORT (on all referenced resources)
3102 VERSION-CONTROL
3103 MERGE
3104 MKWORKSPACE on parent collection
3105 BASELINE-CONTROL
3106 MKACTIVITY on parent collection