7Network Working Group G. Clemm
8Request for Comments: 3744 IBM
9Category: Standards Track J. Reschke
18 Web Distributed Authoring and Versioning (WebDAV)
19 Access Control Protocol
23 This document specifies an Internet standards track protocol for the
24 Internet community, and requests discussion and suggestions for
25 improvements. Please refer to the current edition of the "Internet
26 Official Protocol Standards" (STD 1) for the standardization state
27 and status of this protocol. Distribution of this memo is unlimited.
31 Copyright (C) The Internet Society (2004). All Rights Reserved.
35 This document specifies a set of methods, headers, message bodies,
36 properties, and reports that define Access Control extensions to the
37 WebDAV Distributed Authoring Protocol. This protocol permits a
38 client to read and modify access control lists that instruct a server
39 whether to allow or deny operations upon a resource (such as
40 HyperText Transfer Protocol (HTTP) method invocations) by a given
41 principal. A lightweight representation of principals as Web
42 resources supports integration of a wide range of user management
43 repositories. Search operations allow discovery and manipulation of
44 principals using human names.
58Clemm, et al. Standards Track [Page 1]
60RFC 3744 WebDAV Access Control Protocol May 2004
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
66 1.1. Terms. . . . . . . . . . . . . . . . . . . . . . . . . . 6
67 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 8
68 2. Principals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
69 3. Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . 8
70 3.1. DAV:read Privilege . . . . . . . . . . . . . . . . . . . 10
71 3.2. DAV:write Privilege. . . . . . . . . . . . . . . . . . . 10
72 3.3. DAV:write-properties Privilege . . . . . . . . . . . . . 10
73 3.4. DAV:write-content Privilege. . . . . . . . . . . . . . . 11
74 3.5. DAV:unlock Privilege . . . . . . . . . . . . . . . . . . 11
75 3.6. DAV:read-acl Privilege . . . . . . . . . . . . . . . . . 11
76 3.7. DAV:read-current-user-privilege-set Privilege. . . . . . 12
77 3.8. DAV:write-acl Privilege. . . . . . . . . . . . . . . . . 12
78 3.9. DAV:bind Privilege . . . . . . . . . . . . . . . . . . . 12
79 3.10. DAV:unbind Privilege . . . . . . . . . . . . . . . . . . 12
80 3.11. DAV:all Privilege. . . . . . . . . . . . . . . . . . . . 13
81 3.12. Aggregation of Predefined Privileges . . . . . . . . . . 13
82 4. Principal Properties . . . . . . . . . . . . . . . . . . . . . 13
83 4.1. DAV:alternate-URI-set. . . . . . . . . . . . . . . . . . 14
84 4.2. DAV:principal-URL. . . . . . . . . . . . . . . . . . . . 14
85 4.3. DAV:group-member-set . . . . . . . . . . . . . . . . . . 14
86 4.4. DAV:group-membership . . . . . . . . . . . . . . . . . . 14
87 5. Access Control Properties. . . . . . . . . . . . . . . . . . . 15
88 5.1. DAV:owner. . . . . . . . . . . . . . . . . . . . . . . . 15
89 5.1.1. Example: Retrieving DAV:owner . . . . . . . . . . 15
90 5.1.2. Example: An Attempt to Set DAV:owner. . . . . . . 16
91 5.2. DAV:group. . . . . . . . . . . . . . . . . . . . . . . . 18
92 5.3. DAV:supported-privilege-set. . . . . . . . . . . . . . . 18
93 5.3.1. Example: Retrieving a List of Privileges
94 Supported on a Resource . . . . . . . . . . . . . 19
95 5.4. DAV:current-user-privilege-set . . . . . . . . . . . . . 21
96 5.4.1. Example: Retrieving the User's Current Set of
97 Assigned Privileges . . . . . . . . . . . . . . . 22
98 5.5. DAV:acl. . . . . . . . . . . . . . . . . . . . . . . . . 23
99 5.5.1. ACE Principal . . . . . . . . . . . . . . . . . . 23
100 5.5.2. ACE Grant and Deny. . . . . . . . . . . . . . . . 25
101 5.5.3. ACE Protection. . . . . . . . . . . . . . . . . . 25
102 5.5.4. ACE Inheritance . . . . . . . . . . . . . . . . . 25
103 5.5.5. Example: Retrieving a Resource's Access Control
104 List. . . . . . . . . . . . . . . . . . . . . . . 25
105 5.6. DAV:acl-restrictions . . . . . . . . . . . . . . . . . . 27
106 5.6.1. DAV:grant-only. . . . . . . . . . . . . . . . . . 27
107 5.6.2. DAV:no-invert ACE Constraint. . . . . . . . . . . 28
108 5.6.3. DAV:deny-before-grant . . . . . . . . . . . . . . 28
109 5.6.4. Required Principals . . . . . . . . . . . . . . . 28
110 5.6.5. Example: Retrieving DAV:acl-restrictions. . . . . 28
114Clemm, et al. Standards Track [Page 2]
116RFC 3744 WebDAV Access Control Protocol May 2004
119 5.7. DAV:inherited-acl-set. . . . . . . . . . . . . . . . . . 29
120 5.8. DAV:principal-collection-set . . . . . . . . . . . . . . 30
121 5.8.1. Example: Retrieving DAV:principal-collection-set. 30
122 5.9. Example: PROPFIND to retrieve access control properties. 32
123 6. ACL Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 36
124 7. Access Control and existing methods. . . . . . . . . . . . . . 37
125 7.1. Any HTTP method. . . . . . . . . . . . . . . . . . . . . 37
126 7.1.1. Error Handling. . . . . . . . . . . . . . . . . . 37
127 7.2. OPTIONS. . . . . . . . . . . . . . . . . . . . . . . . . 38
128 7.2.1. Example - OPTIONS . . . . . . . . . . . . . . . . 39
129 7.3. MOVE . . . . . . . . . . . . . . . . . . . . . . . . . . 39
130 7.4. COPY . . . . . . . . . . . . . . . . . . . . . . . . . . 39
131 7.5. LOCK . . . . . . . . . . . . . . . . . . . . . . . . . . 39
132 8. Access Control Methods . . . . . . . . . . . . . . . . . . . . 40
133 8.1. ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . 40
134 8.1.1. ACL Preconditions . . . . . . . . . . . . . . . . 40
135 8.1.2. Example: the ACL method . . . . . . . . . . . . . 42
136 8.1.3. Example: ACL method failure due to protected
137 ACE conflict. . . . . . . . . . . . . . . . . . . 43
138 8.1.4. Example: ACL method failure due to an
139 inherited ACE conflict. . . . . . . . . . . . . . 44
140 8.1.5. Example: ACL method failure due to an attempt
141 to set grant and deny in a single ACE . . . . . . 45
142 9. Access Control Reports . . . . . . . . . . . . . . . . . . . . 46
143 9.1. REPORT Method. . . . . . . . . . . . . . . . . . . . . . 46
144 9.2. DAV:acl-principal-prop-set Report. . . . . . . . . . . . 47
145 9.2.1. Example: DAV:acl-principal-prop-set Report. . . . 48
146 9.3. DAV:principal-match REPORT . . . . . . . . . . . . . . . 49
147 9.3.1. Example: DAV:principal-match REPORT . . . . . . . 50
148 9.4. DAV:principal-property-search REPORT . . . . . . . . . . 51
149 9.4.1. Matching. . . . . . . . . . . . . . . . . . . . . 53
150 9.4.2. Example: successful DAV:principal-property-search
151 REPORT. . . . . . . . . . . . . . . . . . . . . . 54
152 9.5. DAV:principal-search-property-set REPORT . . . . . . . . 56
153 9.5.1. Example: DAV:principal-search-property-set
154 REPORT. . . . . . . . . . . . . . . . . . . . . . 58
155 10. XML Processing . . . . . . . . . . . . . . . . . . . . . . . . 59
156 11. Internationalization Considerations. . . . . . . . . . . . . . 59
157 12. Security Considerations. . . . . . . . . . . . . . . . . . . . 60
158 12.1. Increased Risk of Compromised Users. . . . . . . . . . . 60
159 12.2. Risks of the DAV:read-acl and
160 DAV:current-user-privilege-set Privileges. . . . . . . . 60
161 12.3. No Foreknowledge of Initial ACL. . . . . . . . . . . . . 61
162 13. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 61
163 14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 62
164 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
170Clemm, et al. Standards Track [Page 3]
172RFC 3744 WebDAV Access Control Protocol May 2004
175 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
176 16.1. Normative References . . . . . . . . . . . . . . . . . . 62
177 16.2. Informative References . . . . . . . . . . . . . . . . . 63
179 A. WebDAV XML Document Type Definition Addendum . . . . . . . . . 64
180 B. WebDAV Method Privilege Table (Normative). . . . . . . . . . . 67
181 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
182 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71
183 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 72
187 The goal of the WebDAV access control extensions is to provide an
188 interoperable mechanism for handling discretionary access control for
189 content and metadata managed by WebDAV servers. WebDAV access
190 control can be implemented on content repositories with security as
191 simple as that of a UNIX file system, as well as more sophisticated
192 models. The underlying principle of access control is that who you
193 are determines what operations you can perform on a resource. The
194 "who you are" is defined by a "principal" identifier; users, client
195 software, servers, and groups of the previous have principal
196 identifiers. The "operations you can perform" are determined by a
197 single "access control list" (ACL) associated with a resource. An
198 ACL contains a set of "access control entries" (ACEs), where each ACE
199 specifies a principal and a set of privileges that are either granted
200 or denied to that principal. When a principal submits an operation
201 (such as an HTTP or WebDAV method) to a resource for execution, the
202 server evaluates the ACEs in the ACL to determine if the principal
203 has permission for that operation.
205 Since every ACE contains the identifier of a principal, client
206 software operated by a human must provide a mechanism for selecting
207 this principal. This specification uses http(s) scheme URLs to
208 identify principals, which are represented as WebDAV-capable
209 resources. There is no guarantee that the URLs identifying
210 principals will be meaningful to a human. For example,
211 http://www.example.com/u/256432 and
212 http://www.example.com/people/Greg.Stein are both valid URLs that
213 could be used to identify the same principal. To remedy this, every
214 principal resource has the DAV:displayname property containing a
215 human-readable name for the principal.
217 Since a principal can be identified by multiple URLs, it raises the
218 problem of determining exactly which principal is being referenced in
219 a given ACE. It is impossible for a client to determine that an ACE
220 granting the read privilege to http://www.example.com/people/
221 Greg.Stein also affects the principal at http://www.example.com/u/
222 256432. That is, a client has no mechanism for determining that two
226Clemm, et al. Standards Track [Page 4]
228RFC 3744 WebDAV Access Control Protocol May 2004
231 URLs identify the same principal resource. As a result, this
232 specification requires clients to use just one of the many possible
233 URLs for a principal when creating ACEs. A client can discover which
234 URL to use by retrieving the DAV:principal-URL property (Section 4.2)
235 from a principal resource. No matter which of the principal's URLs
236 is used with PROPFIND, the property always returns the same URL.
238 With a system having hundreds to thousands of principals, the problem
239 arises of how to allow a human operator of client software to select
240 just one of these principals. One approach is to use broad
241 collection hierarchies to spread the principals over a large number
242 of collections, yielding few principals per collection. An example
243 of this is a two level hierarchy with the first level containing 36
244 collections (a-z, 0-9), and the second level being another 36,
245 creating collections /a/a/, /a/b/, ..., /a/z/, such that a principal
246 with last name "Stein" would appear at /s/t/Stein. In effect, this
247 pre-computes a common query, search on last name, and encodes it into
248 a hierarchy. The drawback with this scheme is that it handles only a
249 small set of predefined queries, and drilling down through the
250 collection hierarchy adds unnecessary steps (navigate down/up) when
251 the user already knows the principal's name. While organizing
252 principal URLs into a hierarchy is a valid namespace organization,
253 users should not be forced to navigate this hierarchy to select a
256 This specification provides the capability to perform substring
257 searches over a small set of properties on the resources representing
258 principals. This permits searches based on last name, first name,
259 user name, job title, etc. Two separate searches are supported, both
260 via the REPORT method, one to search principal resources
261 (DAV:principal-property-search, Section 9.4), the other to determine
262 which properties may be searched at all (DAV:principal-search-
263 property-set, Section 9.5).
265 Once a principal has been identified in an ACE, a server evaluating
266 that ACE must know the identity of the principal making a protocol
267 request, and must validate that that principal is who they claim to
268 be, a process known as authentication. This specification
269 intentionally omits discussion of authentication, as the HTTP
270 protocol already has a number of authentication mechanisms [RFC2617].
271 Some authentication mechanism (such as HTTP Digest Authentication,
272 which all WebDAV compliant implementations are required to support)
273 must be available to validate the identity of a principal.
282Clemm, et al. Standards Track [Page 5]
284RFC 3744 WebDAV Access Control Protocol May 2004
287 The following issues are out of scope for this document:
289 o Access control that applies only to a particular property on a
290 resource (excepting the access control properties DAV:acl and
291 DAV:current-user-privilege-set), rather than the entire resource,
293 o Role-based security (where a role can be seen as a dynamically
294 defined group of principals),
296 o Specification of the ways an ACL on a resource is initialized,
298 o Specification of an ACL that applies globally to all resources,
299 rather than to a particular resource.
301 o Creation and maintenance of resources representing people or
302 computational agents (principals), and groups of these.
304 This specification is organized as follows. Section 1.1 defines key
305 concepts used throughout the specification, and is followed by a more
306 in-depth discussion of principals (Section 2), and privileges
307 (Section 3). Properties defined on principals are specified in
308 Section 4, and access control properties for content resources are
309 specified in Section 5. The ways ACLs are to be evaluated is
310 described in Section 6. Client discovery of access control
311 capability using OPTIONS is described in Section 7.2. Interactions
312 between access control functionality and existing HTTP and WebDAV
313 methods are described in the remainder of Section 7. The access
314 control setting method, ACL, is specified in Section 8. Four reports
315 that provide limited server-side searching capabilities are described
316 in Section 9. Sections on XML processing (Section 10),
317 Internationalization considerations (Section 11), security
318 considerations (Section 12), and authentication (Section 13) round
319 out the specification. An appendix (Appendix A) provides an XML
320 Document Type Definition (DTD) for the XML elements defined in the
325 This document uses the terms defined in HTTP [RFC2616] and WebDAV
326 [RFC2518]. In addition, the following terms are defined:
330 A "principal" is a distinct human or computational actor that
331 initiates access to network resources. In this protocol, a
332 principal is an HTTP resource that represents such an actor.
338Clemm, et al. Standards Track [Page 6]
340RFC 3744 WebDAV Access Control Protocol May 2004
345 A "group" is a principal that represents a set of other
350 A "privilege" controls access to a particular set of HTTP
351 operations on a resource.
355 An "aggregate privilege" is a privilege that contains a set of
360 The modifier "abstract", when applied to a privilege on a
361 resource, means the privilege cannot be set in an access control
362 element (ACE) on that resource.
364 access control list (ACL)
366 An "ACL" is a list of access control elements that define access
367 control to a particular resource.
369 access control element (ACE)
371 An "ACE" either grants or denies a particular set of (non-
372 abstract) privileges for a particular principal.
376 An "inherited ACE" is an ACE that is dynamically shared from the
377 ACL of another resource. When a shared ACE changes on the primary
378 resource, it is also changed on inheriting resources.
382 A "protected property" is one whose value cannot be updated except
383 by a method explicitly defined as updating that specific property.
384 In particular, a protected property cannot be updated with a
394Clemm, et al. Standards Track [Page 7]
396RFC 3744 WebDAV Access Control Protocol May 2004
3991.2. Notational Conventions
401 The augmented BNF used by this document to describe protocol elements
402 is described in Section 2.1 of [RFC2616]. Because this augmented BNF
403 uses the basic production rules provided in Section 2.2 of [RFC2616],
404 those rules apply to this document as well.
406 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
407 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
408 document are to be interpreted as described in [RFC2119].
410 Definitions of XML elements in this document use XML element type
411 declarations (as found in XML Document Type Declarations), described
412 in Section 3.2 of [REC-XML]. When an XML element type in the "DAV:"
413 namespace is referenced in this document outside of the context of an
414 XML fragment, the string "DAV:" will be prefixed to the element name.
418 A principal is a network resource that represents a distinct human or
419 computational actor that initiates access to network resources.
420 Users and groups are represented as principals in many
421 implementations; other types of principals are also possible. A URI
422 of any scheme MAY be used to identify a principal resource. However,
423 servers implementing this specification MUST expose principal
424 resources at an http(s) URL, which is a privileged scheme that points
425 to resources that have additional properties, as described in Section
426 4. So, a principal resource can have multiple URIs, one of which has
427 to be an http(s) scheme URL. Although an implementation SHOULD
428 support PROPFIND and MAY support PROPPATCH to access and modify
429 information about a principal, it is not required to do so.
431 A principal resource may be a group, where a group is a principal
432 that represents a set of other principals, called the members of the
433 group. If a person or computational agent matches a principal
434 resource that is a member of a group, they also match the group.
435 Membership in a group is recursive, so if a principal is a member of
436 group GRPA, and GRPA is a member of group GRPB, then the principal is
437 also a member of GRPB.
441 Ability to perform a given method on a resource MUST be controlled by
442 one or more privileges. Authors of protocol extensions that define
443 new HTTP methods SHOULD specify which privileges (by defining new
444 privileges, or mapping to ones below) are required to perform the
445 method. A principal with no privileges to a resource MUST be denied
446 any HTTP access to that resource, unless the principal matches an ACE
450Clemm, et al. Standards Track [Page 8]
452RFC 3744 WebDAV Access Control Protocol May 2004
455 constructed using the DAV:all, DAV:authenticated, or
456 DAV:unauthenticated pseudo-principals (see Section 5.5.1). Servers
457 MUST report a 403 "Forbidden" error if access is denied, except in
458 the case where the privilege restricts the ability to know the
459 resource exists, in which case 404 "Not Found" may be returned.
461 Privileges may be containers of other privileges, in which case they
462 are termed "aggregate privileges". If a principal is granted or
463 denied an aggregate privilege, it is semantically equivalent to
464 granting or denying each of the aggregated privileges individually.
465 For example, an implementation may define add-member and remove-
466 member privileges that control the ability to add and remove a member
467 of a group. Since these privileges control the ability to update the
468 state of a group, these privileges would be aggregated by the
469 DAV:write privilege on a group, and granting the DAV:write privilege
470 on a group would also grant the add-member and remove-member
473 Privileges may be declared to be "abstract" for a given resource, in
474 which case they cannot be set in an ACE on that resource. Aggregate
475 and non-aggregate privileges are both capable of being abstract.
476 Abstract privileges are useful for modeling privileges that otherwise
477 would not be exposed via the protocol. Abstract privileges also
478 provide server implementations with flexibility in implementing the
479 privileges defined in this specification. For example, if a server
480 is incapable of separating the read resource capability from the read
481 ACL capability, it can still model the DAV:read and DAV:read-acl
482 privileges defined in this specification by declaring them abstract,
483 and containing them within a non-abstract aggregate privilege (say,
484 read-all) that holds DAV:read, and DAV:read-acl. In this way, it is
485 possible to set the aggregate privilege, read-all, thus coupling the
486 setting of DAV:read and DAV:read-acl, but it is not possible to set
487 DAV:read, or DAV:read-acl individually. Since aggregate privileges
488 can be abstract, it is also possible to use abstract privileges to
489 group or organize non-abstract privileges. Privilege containment
490 loops are not allowed; therefore, a privilege MUST NOT contain
491 itself. For example, DAV:read cannot contain DAV:read.
493 The set of privileges that apply to a particular resource may vary
494 with the DAV:resourcetype of the resource, as well as between
495 different server implementations. To promote interoperability,
496 however, this specification defines a set of well-known privileges
497 (e.g., DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, DAV:read-
498 current-user-privilege-set, and DAV:all), which can at least be used
499 to classify the other privileges defined on a particular resource.
500 The access permissions on null resources (defined in [RFC2518],
501 Section 3) are solely those they inherit (if any), and they are not
502 discoverable (i.e., the access control properties specified in
506Clemm, et al. Standards Track [Page 9]
508RFC 3744 WebDAV Access Control Protocol May 2004
511 Section 5 are not defined on null resources). On the transition from
512 null to stateful resource, the initial access control list is set by
513 the server's default ACL value policy (if any).
515 Server implementations MAY define new privileges beyond those defined
516 in this specification. Privileges defined by individual
517 implementations MUST NOT use the DAV: namespace, and instead should
518 use a namespace that they control, such as an http scheme URL.
5203.1. DAV:read Privilege
522 The read privilege controls methods that return information about the
523 state of the resource, including the resource's properties. Affected
524 methods include GET and PROPFIND. Any implementation-defined
525 privilege that also controls access to GET and PROPFIND must be
526 aggregated under DAV:read - if an ACL grants access to DAV:read, the
527 client may expect that no other privilege needs to be granted to have
528 access to GET and PROPFIND. Additionally, the read privilege MUST
529 control the OPTIONS method.
531 <!ELEMENT read EMPTY>
5333.2. DAV:write Privilege
535 The write privilege controls methods that lock a resource or modify
536 the content, dead properties, or (in the case of a collection)
537 membership of the resource, such as PUT and PROPPATCH. Note that
538 state modification is also controlled via locking (see section 5.3 of
539 [RFC2518]), so effective write access requires that both write
540 privileges and write locking requirements are satisfied. Any
541 implementation-defined privilege that also controls access to methods
542 modifying content, dead properties or collection membership must be
543 aggregated under DAV:write, e.g., if an ACL grants access to
544 DAV:write, the client may expect that no other privilege needs to be
545 granted to have access to PUT and PROPPATCH.
547 <!ELEMENT write EMPTY>
5493.3. DAV:write-properties Privilege
551 The DAV:write-properties privilege controls methods that modify the
552 dead properties of the resource, such as PROPPATCH. Whether this
553 privilege may be used to control access to any live properties is
554 determined by the implementation. Any implementation-defined
555 privilege that also controls access to methods modifying dead
556 properties must be aggregated under DAV:write-properties - e.g., if
562Clemm, et al. Standards Track [Page 10]
564RFC 3744 WebDAV Access Control Protocol May 2004
567 an ACL grants access to DAV:write-properties, the client can safely
568 expect that no other privilege needs to be granted to have access to
571 <!ELEMENT write-properties EMPTY>
5733.4. DAV:write-content Privilege
575 The DAV:write-content privilege controls methods that modify the
576 content of an existing resource, such as PUT. Any implementation-
577 defined privilege that also controls access to content must be
578 aggregated under DAV:write-content - e.g., if an ACL grants access to
579 DAV:write-content, the client can safely expect that no other
580 privilege needs to be granted to have access to PUT. Note that PUT -
581 when applied to an unmapped URI - creates a new resource and
582 therefore is controlled by the DAV:bind privilege on the parent
585 <!ELEMENT write-content EMPTY>
5873.5. DAV:unlock Privilege
589 The DAV:unlock privilege controls the use of the UNLOCK method by a
590 principal other than the lock owner (the principal that created a
591 lock can always perform an UNLOCK). While the set of users who may
592 lock a resource is most commonly the same set of users who may modify
593 a resource, servers may allow various kinds of administrators to
594 unlock resources locked by others. Any privilege controlling access
595 by non-lock owners to UNLOCK MUST be aggregated under DAV:unlock.
597 A lock owner can always remove a lock by issuing an UNLOCK with the
598 correct lock token and authentication credentials. That is, even if
599 a principal does not have DAV:unlock privilege, they can still remove
600 locks they own. Principals other than the lock owner can remove a
601 lock only if they have DAV:unlock privilege and they issue an UNLOCK
602 with the correct lock token. Lock timeout is not affected by the
603 DAV:unlock privilege.
605 <!ELEMENT unlock EMPTY>
6073.6. DAV:read-acl Privilege
609 The DAV:read-acl privilege controls the use of PROPFIND to retrieve
610 the DAV:acl property of the resource.
612 <!ELEMENT read-acl EMPTY>
618Clemm, et al. Standards Track [Page 11]
620RFC 3744 WebDAV Access Control Protocol May 2004
6233.7. DAV:read-current-user-privilege-set Privilege
625 The DAV:read-current-user-privilege-set privilege controls the use of
626 PROPFIND to retrieve the DAV:current-user-privilege-set property of
629 Clients are intended to use this property to visually indicate in
630 their UI items that are dependent on the permissions of a resource,
631 for example, by graying out resources that are not writable.
633 This privilege is separate from DAV:read-acl because there is a need
634 to allow most users access to the privileges permitted the current
635 user (due to its use in creating the UI), while the full ACL contains
636 information that may not be appropriate for the current authenticated
637 user. As a result, the set of users who can view the full ACL is
638 expected to be much smaller than those who can read the current user
639 privilege set, and hence distinct privileges are needed for each.
641 <!ELEMENT read-current-user-privilege-set EMPTY>
6433.8. DAV:write-acl Privilege
645 The DAV:write-acl privilege controls use of the ACL method to modify
646 the DAV:acl property of the resource.
648 <!ELEMENT write-acl EMPTY>
6503.9. DAV:bind Privilege
652 The DAV:bind privilege allows a method to add a new member URL to the
653 specified collection (for example via PUT or MKCOL). It is ignored
654 for resources that are not collections.
656 <!ELEMENT bind EMPTY>
6583.10. DAV:unbind Privilege
660 The DAV:unbind privilege allows a method to remove a member URL from
661 the specified collection (for example via DELETE or MOVE). It is
662 ignored for resources that are not collections.
664 <!ELEMENT unbind EMPTY>
674Clemm, et al. Standards Track [Page 12]
676RFC 3744 WebDAV Access Control Protocol May 2004
6793.11. DAV:all Privilege
681 DAV:all is an aggregate privilege that contains the entire set of
682 privileges that can be applied to the resource.
6863.12. Aggregation of Predefined Privileges
688 Server implementations are free to aggregate the predefined
689 privileges (defined above in Sections 3.1-3.10) subject to the
690 following limitations:
692 DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-acl,
693 DAV:write-properties, DAV:write-content, or DAV:read-current-user-
696 DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-acl, or
697 DAV:read-current-user-privilege-set.
699 DAV:read-current-user-privilege-set MUST NOT contain DAV:write,
700 DAV:read, DAV:read-acl, or DAV:write-acl.
702 DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-
703 current-user-privilege-set.
705 DAV:read MUST NOT contain DAV:write, DAV:write-acl, DAV:write-
706 properties, or DAV:write-content.
708 DAV:write MUST contain DAV:bind, DAV:unbind, DAV:write-properties and
7114. Principal Properties
713 Principals are manifested to clients as a WebDAV resource, identified
714 by a URL. A principal MUST have a non-empty DAV:displayname property
715 (defined in Section 13.2 of [RFC2518]), and a DAV:resourcetype
716 property (defined in Section 13.9 of [RFC2518]). Additionally, a
717 principal MUST report the DAV:principal XML element in the value of
718 the DAV:resourcetype property. The element type declaration for
721 <!ELEMENT principal EMPTY>
730Clemm, et al. Standards Track [Page 13]
732RFC 3744 WebDAV Access Control Protocol May 2004
735 This protocol defines the following additional properties for a
736 principal. Since it can be expensive for a server to retrieve access
737 control information, the name and value of these properties SHOULD
738 NOT be returned by a PROPFIND allprop request (as defined in Section
739 12.14.1 of [RFC2518]).
7414.1. DAV:alternate-URI-set
743 This protected property, if non-empty, contains the URIs of network
744 resources with additional descriptive information about the
745 principal. This property identifies additional network resources
746 (i.e., it contains one or more URIs) that may be consulted by a
747 client to gain additional knowledge concerning a principal. One
748 expected use for this property is the storage of an LDAP [RFC2255]
749 scheme URL. A user-agent encountering an LDAP URL could use LDAP
750 [RFC2251] to retrieve additional machine-readable directory
751 information about the principal, and display that information in its
752 user interface. Support for this property is REQUIRED, and the value
753 is empty if no alternate URI exists for the principal.
755 <!ELEMENT alternate-URI-set (href*)>
7574.2. DAV:principal-URL
759 A principal may have many URLs, but there must be one "principal URL"
760 that clients can use to uniquely identify a principal. This
761 protected property contains the URL that MUST be used to identify
762 this principal in an ACL request. Support for this property is
765 <!ELEMENT principal-URL (href)>
7674.3. DAV:group-member-set
769 This property of a group principal identifies the principals that are
770 direct members of this group. Since a group may be a member of
771 another group, a group may also have indirect members (i.e., the
772 members of its direct members). A URL in the DAV:group-member-set
773 for a principal MUST be the DAV:principal-URL of that principal.
775 <!ELEMENT group-member-set (href*)>
7774.4. DAV:group-membership
779 This protected property identifies the groups in which the principal
780 is directly a member. Note that a server may allow a group to be a
781 member of another group, in which case the DAV:group-membership of
786Clemm, et al. Standards Track [Page 14]
788RFC 3744 WebDAV Access Control Protocol May 2004
791 those other groups would need to be queried in order to determine the
792 groups in which the principal is indirectly a member. Support for
793 this property is REQUIRED.
795 <!ELEMENT group-membership (href*)>
7975. Access Control Properties
799 This specification defines a number of new properties for WebDAV
800 resources. Access control properties may be retrieved just like
801 other WebDAV properties, using the PROPFIND method. Since it is
802 expensive, for many servers, to retrieve access control information,
803 a PROPFIND allprop request (as defined in Section 12.14.1 of
804 [RFC2518]) SHOULD NOT return the names and values of the properties
805 defined in this section.
807 Access control properties (especially DAV:acl and DAV:inherited-acl-
808 set) are defined on the resource identified by the Request-URI of a
809 PROPFIND request. A direct consequence is that if the resource is
810 accessible via multiple URI, the value of access control properties
811 is the same across these URI.
813 HTTP resources that support the WebDAV Access Control Protocol MUST
814 contain the following properties. Null resources (described in
815 Section 3 of [RFC2518]) MUST NOT contain the following properties.
819 This property identifies a particular principal as being the "owner"
820 of the resource. Since the owner of a resource often has special
821 access control capabilities (e.g., the owner frequently has permanent
822 DAV:write-acl privilege), clients might display the resource owner in
823 their user interface.
825 Servers MAY implement DAV:owner as protected property and MAY return
826 an empty DAV:owner element as property value in case no owner
827 information is available.
829 <!ELEMENT owner (href?)>
8315.1.1. Example: Retrieving DAV:owner
833 This example shows a client request for the value of the DAV:owner
834 property from a collection resource with URL http://www.example.com/
835 papers/. The principal making the request is authenticated using
836 Digest authentication. The value of DAV:owner is the URL http://
837 www.example.com/acl/users/gstein, wrapped in the DAV:href XML
842Clemm, et al. Standards Track [Page 15]
844RFC 3744 WebDAV Access Control Protocol May 2004
849 PROPFIND /papers/ HTTP/1.1
850 Host: www.example.com
851 Content-type: text/xml; charset="utf-8"
854 Authorization: Digest username="jim",
855 realm="users@example.com", nonce="...",
856 uri="/papers/", response="...", opaque="..."
858 <?xml version="1.0" encoding="utf-8" ?>
859 <D:propfind xmlns:D="DAV:">
867 HTTP/1.1 207 Multi-Status
868 Content-Type: text/xml; charset="utf-8"
871 <?xml version="1.0" encoding="utf-8" ?>
872 <D:multistatus xmlns:D="DAV:">
874 <D:href>http://www.example.com/papers/</D:href>
878 <D:href>http://www.example.com/acl/users/gstein</D:href>
881 <D:status>HTTP/1.1 200 OK</D:status>
8865.1.2. Example: An Attempt to Set DAV:owner
888 The following example shows a client request to modify the value of
889 the DAV:owner property on the resource with URL <http://
890 www.example.com/papers>. Since DAV:owner is a protected property on
891 this particular server, it responds with a 207 (Multi-Status)
892 response that contains a 403 (Forbidden) status code for the act of
893 setting DAV:owner. Section 8.2.1 of [RFC2518] describes PROPPATCH
894 status code information, Section 11 of [RFC2518] describes the
898Clemm, et al. Standards Track [Page 16]
900RFC 3744 WebDAV Access Control Protocol May 2004
903 Multi-Status response and Sections 1.6 and 3.12 of [RFC3253] describe
904 additional error marshaling for PROPPATCH attempts on protected
909 PROPPATCH /papers/ HTTP/1.1
910 Host: www.example.com
911 Content-type: text/xml; charset="utf-8"
914 Authorization: Digest username="jim",
915 realm="users@example.com", nonce="...",
916 uri="/papers/", response="...", opaque="..."
918 <?xml version="1.0" encoding="utf-8" ?>
919 <D:propertyupdate xmlns:D="DAV:">
923 <D:href>http://www.example.com/acl/users/jim</D:href>
931 HTTP/1.1 207 Multi-Status
932 Content-Type: text/xml; charset="utf-8"
935 <?xml version="1.0" encoding="utf-8" ?>
936 <D:multistatus xmlns:D="DAV:">
938 <D:href>http://www.example.com/papers/</D:href>
940 <D:prop><D:owner/></D:prop>
941 <D:status>HTTP/1.1 403 Forbidden</D:status>
942 <D:responsedescription>
943 <D:error><D:cannot-modify-protected-property/></D:error>
944 Failure to set protected property (DAV:owner)
945 </D:responsedescription>
954Clemm, et al. Standards Track [Page 17]
956RFC 3744 WebDAV Access Control Protocol May 2004
961 This property identifies a particular principal as being the "group"
962 of the resource. This property is commonly found on repositories
963 that implement the Unix privileges model.
965 Servers MAY implement DAV:group as protected property and MAY return
966 an empty DAV:group element as property value in case no group
967 information is available.
969 <!ELEMENT group (href?)>
9715.3. DAV:supported-privilege-set
973 This is a protected property that identifies the privileges defined
976 <!ELEMENT supported-privilege-set (supported-privilege*)>
978 Each privilege appears as an XML element, where aggregate privileges
979 list as sub-elements all of the privileges that they aggregate.
981 <!ELEMENT supported-privilege
982 (privilege, abstract?, description, supported-privilege*)>
983 <!ELEMENT privilege ANY>
985 An abstract privilege MUST NOT be used in an ACE for that resource.
986 Servers MUST fail an attempt to set an abstract privilege.
988 <!ELEMENT abstract EMPTY>
990 A description is a human-readable description of what this privilege
991 controls access to. Servers MUST indicate the human language of the
992 description using the xml:lang attribute and SHOULD consider the HTTP
993 Accept-Language request header when selecting one of multiple
996 <!ELEMENT description #PCDATA>
998 It is envisioned that a WebDAV ACL-aware administrative client would
999 list the supported privileges in a dialog box, and allow the user to
1000 choose non-abstract privileges to apply in an ACE. The privileges
1001 tree is useful programmatically to map well-known privileges (defined
1002 by WebDAV or other standards groups) into privileges that are
1003 supported by any particular server implementation. The privilege
1004 tree also serves to hide complexity in implementations allowing large
1005 number of privileges to be defined by displaying aggregates to the
1010Clemm, et al. Standards Track [Page 18]
1012RFC 3744 WebDAV Access Control Protocol May 2004
10155.3.1. Example: Retrieving a List of Privileges Supported on a Resource
1017 This example shows a client request for the DAV:supported-privilege-
1018 set property on the resource http://www.example.com/papers/. The
1019 value of the DAV:supported-privilege-set property is a tree of
1020 supported privileges (using "[XML Namespace , localname]" to identify
1023 [DAV:, all] (aggregate, abstract)
1025 +-- [DAV:, read] (aggregate)
1027 +-- [DAV:, read-acl] (abstract)
1028 +-- [DAV:, read-current-user-privilege-set] (abstract)
1030 +-- [DAV:, write] (aggregate)
1032 +-- [DAV:, write-acl] (abstract)
1033 +-- [DAV:, write-properties]
1034 +-- [DAV:, write-content]
1038 This privilege tree is not normative (except that it reflects the
1039 normative aggregation rules given in Section 3.12), and many possible
1040 privilege trees are possible.
1044 PROPFIND /papers/ HTTP/1.1
1045 Host: www.example.com
1046 Content-type: text/xml; charset="utf-8"
1049 Authorization: Digest username="gclemm",
1050 realm="users@example.com", nonce="...",
1051 uri="/papers/", response="...", opaque="..."
1053 <?xml version="1.0" encoding="utf-8" ?>
1054 <D:propfind xmlns:D="DAV:">
1056 <D:supported-privilege-set/>
1066Clemm, et al. Standards Track [Page 19]
1068RFC 3744 WebDAV Access Control Protocol May 2004
1073 HTTP/1.1 207 Multi-Status
1075 Content-Type: text/xml; charset="utf-8"
1078 <?xml version="1.0" encoding="utf-8" ?>
1079 <D:multistatus xmlns:D="DAV:">
1081 <D:href>http://www.example.com/papers/</D:href>
1084 <D:supported-privilege-set>
1085 <D:supported-privilege>
1086 <D:privilege><D:all/></D:privilege>
1088 <D:description xml:lang="en">
1091 <D:supported-privilege>
1092 <D:privilege><D:read/></D:privilege>
1093 <D:description xml:lang="en">
1096 <D:supported-privilege>
1097 <D:privilege><D:read-acl/></D:privilege>
1099 <D:description xml:lang="en">Read ACL</D:description>
1100 </D:supported-privilege>
1101 <D:supported-privilege>
1103 <D:read-current-user-privilege-set/>
1106 <D:description xml:lang="en">
1107 Read current user privilege set property
1109 </D:supported-privilege>
1110 </D:supported-privilege>
1111 <D:supported-privilege>
1112 <D:privilege><D:write/></D:privilege>
1113 <D:description xml:lang="en">
1116 <D:supported-privilege>
1117 <D:privilege><D:write-acl/></D:privilege>
1118 <D:description xml:lang="en">
1122Clemm, et al. Standards Track [Page 20]
1124RFC 3744 WebDAV Access Control Protocol May 2004
1130 </D:supported-privilege>
1131 <D:supported-privilege>
1132 <D:privilege><D:write-properties/></D:privilege>
1133 <D:description xml:lang="en">
1136 </D:supported-privilege>
1137 <D:supported-privilege>
1138 <D:privilege><D:write-content/></D:privilege>
1139 <D:description xml:lang="en">
1140 Write resource content
1142 </D:supported-privilege>
1143 </D:supported-privilege>
1144 <D:supported-privilege>
1145 <D:privilege><D:unlock/></D:privilege>
1146 <D:description xml:lang="en">
1149 </D:supported-privilege>
1150 </D:supported-privilege>
1151 </D:supported-privilege-set>
1153 <D:status>HTTP/1.1 200 OK</D:status>
11585.4. DAV:current-user-privilege-set
1160 DAV:current-user-privilege-set is a protected property containing the
1161 exact set of privileges (as computed by the server) granted to the
1162 currently authenticated HTTP user. Aggregate privileges and their
1163 contained privileges are listed. A user-agent can use the value of
1164 this property to adjust its user interface to make actions
1165 inaccessible (e.g., by graying out a menu item or button) for which
1166 the current principal does not have permission. This property is
1167 also useful for determining what operations the current principal can
1168 perform, without having to actually execute an operation.
1170 <!ELEMENT current-user-privilege-set (privilege*)>
1171 <!ELEMENT privilege ANY>
1178Clemm, et al. Standards Track [Page 21]
1180RFC 3744 WebDAV Access Control Protocol May 2004
1183 If the current user is granted a specific privilege, that privilege
1184 must belong to the set of privileges that may be set on this
1185 resource. Therefore, each element in the DAV:current-user-
1186 privilege-set property MUST identify a non-abstract privilege from
1187 the DAV:supported-privilege-set property.
11895.4.1. Example: Retrieving the User's Current Set of Assigned
1192 Continuing the example from Section 5.3.1, this example shows a
1193 client requesting the DAV:current-user-privilege-set property from
1194 the resource with URL http://www.example.com/papers/. The username
1195 of the principal making the request is "khare", and Digest
1196 authentication is used in the request. The principal with username
1197 "khare" has been granted the DAV:read privilege. Since the DAV:read
1198 privilege contains the DAV:read-acl and DAV:read-current-user-
1199 privilege-set privileges (see Section 5.3.1), the principal with
1200 username "khare" can read the ACL property, and the DAV:current-
1201 user-privilege-set property. However, the DAV:all, DAV:read-acl,
1202 DAV:write-acl and DAV:read-current-user-privilege-set privileges are
1203 not listed in the value of DAV:current-user-privilege-set, since (for
1204 this example) they are abstract privileges. DAV:write is not listed
1205 since the principal with username "khare" is not listed in an ACE
1206 granting that principal write permission.
1210 PROPFIND /papers/ HTTP/1.1
1211 Host: www.example.com
1212 Content-type: text/xml; charset="utf-8"
1215 Authorization: Digest username="khare",
1216 realm="users@example.com", nonce="...",
1217 uri="/papers/", response="...", opaque="..."
1219 <?xml version="1.0" encoding="utf-8" ?>
1220 <D:propfind xmlns:D="DAV:">
1222 <D:current-user-privilege-set/>
1234Clemm, et al. Standards Track [Page 22]
1236RFC 3744 WebDAV Access Control Protocol May 2004
1241 HTTP/1.1 207 Multi-Status
1242 Content-Type: text/xml; charset="utf-8"
1245 <?xml version="1.0" encoding="utf-8" ?>
1246 <D:multistatus xmlns:D="DAV:">
1248 <D:href>http://www.example.com/papers/</D:href>
1251 <D:current-user-privilege-set>
1252 <D:privilege><D:read/></D:privilege>
1253 </D:current-user-privilege-set>
1255 <D:status>HTTP/1.1 200 OK</D:status>
1262 This is a protected property that specifies the list of access
1263 control entries (ACEs), which define what principals are to get what
1264 privileges for this resource.
1266 <!ELEMENT acl (ace*) >
1268 Each DAV:ace element specifies the set of privileges to be either
1269 granted or denied to a single principal. If the DAV:acl property is
1270 empty, no principal is granted any privilege.
1272 <!ELEMENT ace ((principal | invert), (grant|deny), protected?,
1277 The DAV:principal element identifies the principal to which this ACE
1280 <!ELEMENT principal (href | all | authenticated | unauthenticated
1283 The current user matches DAV:href only if that user is authenticated
1284 as being (or being a member of) the principal identified by the URL
1285 contained by that DAV:href.
1290Clemm, et al. Standards Track [Page 23]
1292RFC 3744 WebDAV Access Control Protocol May 2004
1295 The current user always matches DAV:all.
1297 <!ELEMENT all EMPTY>
1299 The current user matches DAV:authenticated only if authenticated.
1301 <!ELEMENT authenticated EMPTY>
1303 The current user matches DAV:unauthenticated only if not
1306 <!ELEMENT unauthenticated EMPTY>
1308 DAV:all is the union of DAV:authenticated, and DAV:unauthenticated.
1309 For a given request, the user matches either DAV:authenticated, or
1310 DAV:unauthenticated, but not both (that is, DAV:authenticated and
1311 DAV:unauthenticated are disjoint sets).
1313 The current user matches a DAV:property principal in a DAV:acl
1314 property of a resource only if the value of the identified property
1315 of that resource contains at most one DAV:href XML element, the URI
1316 value of DAV:href identifies a principal, and the current user is
1317 authenticated as being (or being a member of) that principal. For
1318 example, if the DAV:property element contained <DAV:owner/>, the
1319 current user would match the DAV:property principal only if the
1320 current user is authenticated as matching the principal identified by
1321 the DAV:owner property of the resource.
1323 <!ELEMENT property ANY>
1325 The current user matches DAV:self in a DAV:acl property of the
1326 resource only if that resource is a principal and that principal
1327 matches the current user or, if the principal is a group, a member of
1328 that group matches the current user.
1330 <!ELEMENT self EMPTY>
1332 Some servers may support ACEs applying to those users NOT matching
1333 the current principal, e.g., all users not in a particular group.
1334 This can be done by wrapping the DAV:principal element with
1337 <!ELEMENT invert principal>
1346Clemm, et al. Standards Track [Page 24]
1348RFC 3744 WebDAV Access Control Protocol May 2004
13515.5.2. ACE Grant and Deny
1353 Each DAV:grant or DAV:deny element specifies the set of privileges to
1354 be either granted or denied to the specified principal. A DAV:grant
1355 or DAV:deny element of the DAV:acl of a resource MUST only contain
1356 non-abstract elements specified in the DAV:supported-privilege-set of
1359 <!ELEMENT grant (privilege+)>
1360 <!ELEMENT deny (privilege+)>
1361 <!ELEMENT privilege ANY>
13635.5.3. ACE Protection
1365 A server indicates an ACE is protected by including the DAV:protected
1366 element in the ACE. If the ACL of a resource contains an ACE with a
1367 DAV:protected element, an attempt to remove that ACE from the ACL
1370 <!ELEMENT protected EMPTY>
13725.5.4. ACE Inheritance
1374 The presence of a DAV:inherited element indicates that this ACE is
1375 inherited from another resource that is identified by the URL
1376 contained in a DAV:href element. An inherited ACE cannot be modified
1377 directly, but instead the ACL on the resource from which it is
1378 inherited must be modified.
1380 Note that ACE inheritance is not the same as ACL initialization. ACL
1381 initialization defines the ACL that a newly created resource will use
1382 (if not specified). ACE inheritance refers to an ACE that is
1383 logically shared - where an update to the resource containing an ACE
1384 will affect the ACE of each resource that inherits that ACE. The
1385 method by which ACLs are initialized or by which ACEs are inherited
1386 is not defined by this document.
1388 <!ELEMENT inherited (href)>
13905.5.5. Example: Retrieving a Resource's Access Control List
1392 Continuing the example from Sections 5.3.1 and 5.4.1, this example
1393 shows a client requesting the DAV:acl property from the resource with
1394 URL http://www.example.com/papers/. There are two ACEs defined in
1402Clemm, et al. Standards Track [Page 25]
1404RFC 3744 WebDAV Access Control Protocol May 2004
1407 ACE #1: The group identified by URL http://www.example.com/acl/
1408 groups/maintainers (the group of site maintainers) is granted
1409 DAV:write privilege. Since (for this example) DAV:write contains the
1410 DAV:write-acl privilege (see Section 5.3.1), this means the
1411 "maintainers" group can also modify the access control list.
1413 ACE #2: All principals (DAV:all) are granted the DAV:read privilege.
1414 Since (for this example) DAV:read contains DAV:read-acl and
1415 DAV:read-current-user-privilege-set, this means all users (including
1416 all members of the "maintainers" group) can read the DAV:acl property
1417 and the DAV:current-user-privilege-set property.
1421 PROPFIND /papers/ HTTP/1.1
1422 Host: www.example.com
1423 Content-type: text/xml; charset="utf-8"
1426 Authorization: Digest username="masinter",
1427 realm="users@example.com", nonce="...",
1428 uri="/papers/", response="...", opaque="..."
1430 <D:propfind xmlns:D="DAV:">
1438 HTTP/1.1 207 Multi-Status
1439 Content-Type: text/xml; charset="utf-8"
1442 <D:multistatus xmlns:D="DAV:">
1444 <D:href>http://www.example.com/papers/</D:href>
1451 >http://www.example.com/acl/groups/maintainers</D:href>
1454 <D:privilege><D:write/></D:privilege>
1458Clemm, et al. Standards Track [Page 26]
1460RFC 3744 WebDAV Access Control Protocol May 2004
1470 <D:privilege><D:read/></D:privilege>
1475 <D:status>HTTP/1.1 200 OK</D:status>
14805.6. DAV:acl-restrictions
1482 This protected property defines the types of ACLs supported by this
1483 server, to avoid clients needlessly getting errors. When a client
1484 tries to set an ACL via the ACL method, the server may reject the
1485 attempt to set the ACL as specified. The following properties
1486 indicate the restrictions the client must observe before setting an
1489 <grant-only> Deny ACEs are not supported
1491 <no-invert> Inverted ACEs are not supported
1493 <deny-before-grant> All deny ACEs must occur before any grant ACEs
1495 <required-principal> Indicates which principals are required to be
1499 <!ELEMENT acl-restrictions (grant-only?, no-invert?,
1501 required-principal?)>
15035.6.1. DAV:grant-only
1505 This element indicates that ACEs with deny clauses are not allowed.
1507 <!ELEMENT grant-only EMPTY>
1514Clemm, et al. Standards Track [Page 27]
1516RFC 3744 WebDAV Access Control Protocol May 2004
15195.6.2. DAV:no-invert ACE Constraint
1521 This element indicates that ACEs with the <invert> element are not
1524 <!ELEMENT no-invert EMPTY>
15265.6.3. DAV:deny-before-grant
1528 This element indicates that all deny ACEs must precede all grant
1531 <!ELEMENT deny-before-grant EMPTY>
15335.6.4. Required Principals
1535 The required principal elements identify which principals must have
1536 an ACE defined in the ACL.
1538 <!ELEMENT required-principal
1539 (all? | authenticated? | unauthenticated? | self? | href* |
1542 For example, the following element requires that the ACL contain a
1544 DAV:owner property ACE:
1546 <D:required-principal xmlns:D="DAV:">
1547 <D:property><D:owner/></D:property>
1548 </D:required-principal>
15505.6.5. Example: Retrieving DAV:acl-restrictions
1552 In this example, the client requests the value of the DAV:acl-
1553 restrictions property. Digest authentication provides credentials
1554 for the principal operating the client.
1558 PROPFIND /papers/ HTTP/1.1
1559 Host: www.example.com
1560 Content-type: text/xml; charset="utf-8"
1563 Authorization: Digest username="srcarter",
1564 realm="users@example.com", nonce="...",
1565 uri="/papers/", response="...", opaque="..."
1570Clemm, et al. Standards Track [Page 28]
1572RFC 3744 WebDAV Access Control Protocol May 2004
1575 <?xml version="1.0" encoding="utf-8" ?>
1576 <D:propfind xmlns:D="DAV:">
1578 <D:acl-restrictions/>
1584 HTTP/1.1 207 Multi-Status
1585 Content-Type: text/xml; charset="utf-8"
1588 <?xml version="1.0" encoding="utf-8" ?>
1589 <D:multistatus xmlns:D="DAV:">
1591 <D:href>http://www.example.com/papers/</D:href>
1594 <D:acl-restrictions>
1596 <D:required-principal>
1598 </D:required-principal>
1599 </D:acl-restrictions>
1601 <D:status>HTTP/1.1 200 OK</D:status>
16065.7. DAV:inherited-acl-set
1608 This protected property contains a set of URLs that identify other
1609 resources that also control the access to this resource. To have a
1610 privilege on a resource, not only must the ACL on that resource
1611 (specified in the DAV:acl property of that resource) grant the
1612 privilege, but so must the ACL of each resource identified in the
1613 DAV:inherited-acl-set property of that resource. Effectively, the
1614 privileges granted by the current ACL are ANDed with the privileges
1615 granted by each inherited ACL.
1617 <!ELEMENT inherited-acl-set (href*)>
1626Clemm, et al. Standards Track [Page 29]
1628RFC 3744 WebDAV Access Control Protocol May 2004
16315.8. DAV:principal-collection-set
1633 This protected property of a resource contains a set of URLs that
1634 identify the root collections that contain the principals that are
1635 available on the server that implements this resource. A WebDAV
1636 Access Control Protocol user agent could use the contents of
1637 DAV:principal-collection-set to retrieve the DAV:displayname property
1638 (specified in Section 13.2 of [RFC2518]) of all principals on that
1639 server, thereby yielding human-readable names for each principal that
1640 could be displayed in a user interface.
1642 <!ELEMENT principal-collection-set (href*)>
1644 Since different servers can control different parts of the URL
1645 namespace, different resources on the same host MAY have different
1646 DAV:principal-collection-set values. The collections specified in
1647 the DAV:principal-collection-set MAY be located on different hosts
1648 from the resource. The URLs in DAV:principal-collection-set SHOULD be
1649 http or https scheme URLs. For security and scalability reasons, a
1650 server MAY report only a subset of the entire set of known principal
1651 collections, and therefore clients should not assume they have
1652 retrieved an exhaustive listing. Additionally, a server MAY elect to
1653 report none of the principal collections it knows about, in which
1654 case the property value would be empty.
1656 The value of DAV:principal-collection-set gives the scope of the
1657 DAV:principal-property-search REPORT (defined in Section 9.4).
1658 Clients use the DAV:principal-property-search REPORT to populate
1659 their user interface with a list of principals. Therefore, servers
1660 that limit a client's ability to obtain principal information will
1661 interfere with the client's ability to manipulate access control
1662 lists, due to the difficulty of getting the URL of a principal for
16655.8.1. Example: Retrieving DAV:principal-collection-set
1667 In this example, the client requests the value of the DAV:principal-
1668 collection-set property on the collection resource identified by URL
1669 http://www.example.com/papers/. The property contains the two URLs,
1670 http://www.example.com/acl/users/ and http://
1671 www.example.com/acl/groups/, both wrapped in DAV:href XML elements.
1672 Digest authentication provides credentials for the principal
1673 operating the client.
1682Clemm, et al. Standards Track [Page 30]
1684RFC 3744 WebDAV Access Control Protocol May 2004
1687 The client might reasonably follow this request with two separate
1688 PROPFIND requests to retrieve the DAV:displayname property of the
1689 members of the two collections (/acl/users and /acl/groups). This
1690 information could be used when displaying a user interface for
1691 creating access control entries.
1695 PROPFIND /papers/ HTTP/1.1
1696 Host: www.example.com
1697 Content-type: text/xml; charset="utf-8"
1700 Authorization: Digest username="yarong",
1701 realm="users@example.com", nonce="...",
1702 uri="/papers/", response="...", opaque="..."
1704 <?xml version="1.0" encoding="utf-8" ?>
1705 <D:propfind xmlns:D="DAV:">
1707 <D:principal-collection-set/>
1713 HTTP/1.1 207 Multi-Status
1714 Content-Type: text/xml; charset="utf-8"
1717 <?xml version="1.0" encoding="utf-8" ?>
1718 <D:multistatus xmlns:D="DAV:">
1720 <D:href>http://www.example.com/papers/</D:href>
1723 <D:principal-collection-set>
1724 <D:href>http://www.example.com/acl/users/</D:href>
1725 <D:href>http://www.example.com/acl/groups/</D:href>
1726 </D:principal-collection-set>
1728 <D:status>HTTP/1.1 200 OK</D:status>
1738Clemm, et al. Standards Track [Page 31]
1740RFC 3744 WebDAV Access Control Protocol May 2004
17435.9. Example: PROPFIND to retrieve access control properties
1745 The following example shows how access control information can be
1746 retrieved by using the PROPFIND method to fetch the values of the
1747 DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege-
1748 set, and DAV:acl properties.
1752 PROPFIND /top/container/ HTTP/1.1
1753 Host: www.example.com
1754 Content-type: text/xml; charset="utf-8"
1757 Authorization: Digest username="ejw",
1758 realm="users@example.com", nonce="...",
1759 uri="/top/container/", response="...", opaque="..."
1761 <?xml version="1.0" encoding="utf-8" ?>
1762 <D:propfind xmlns:D="DAV:">
1765 <D:supported-privilege-set/>
1766 <D:current-user-privilege-set/>
1773 HTTP/1.1 207 Multi-Status
1774 Content-Type: text/xml; charset="utf-8"
1777 <?xml version="1.0" encoding="utf-8" ?>
1778 <D:multistatus xmlns:D="DAV:"
1779 xmlns:A="http://www.example.com/acl/">
1781 <D:href>http://www.example.com/top/container/</D:href>
1785 <D:href>http://www.example.com/users/gclemm</D:href>
1787 <D:supported-privilege-set>
1788 <D:supported-privilege>
1789 <D:privilege><D:all/></D:privilege>
1794Clemm, et al. Standards Track [Page 32]
1796RFC 3744 WebDAV Access Control Protocol May 2004
1799 <D:description xml:lang="en">
1802 <D:supported-privilege>
1803 <D:privilege><D:read/></D:privilege>
1804 <D:description xml:lang="en">
1807 </D:supported-privilege>
1808 <D:supported-privilege>
1809 <D:privilege><D:write/></D:privilege>
1811 <D:description xml:lang="en">
1814 <D:supported-privilege>
1815 <D:privilege><A:create/></D:privilege>
1816 <D:description xml:lang="en">
1819 </D:supported-privilege>
1820 <D:supported-privilege>
1821 <D:privilege><A:update/></D:privilege>
1822 <D:description xml:lang="en">
1825 </D:supported-privilege>
1826 </D:supported-privilege>
1827 <D:supported-privilege>
1828 <D:privilege><A:delete/></D:privilege>
1829 <D:description xml:lang="en">
1832 </D:supported-privilege>
1833 <D:supported-privilege>
1834 <D:privilege><D:read-acl/></D:privilege>
1835 <D:description xml:lang="en">
1838 </D:supported-privilege>
1839 <D:supported-privilege>
1840 <D:privilege><D:write-acl/></D:privilege>
1841 <D:description xml:lang="en">
1844 </D:supported-privilege>
1845 </D:supported-privilege>
1846 </D:supported-privilege-set>
1850Clemm, et al. Standards Track [Page 33]
1852RFC 3744 WebDAV Access Control Protocol May 2004
1855 <D:current-user-privilege-set>
1856 <D:privilege><D:read/></D:privilege>
1857 <D:privilege><D:read-acl/></D:privilege>
1858 </D:current-user-privilege-set>
1862 <D:href>http://www.example.com/users/esedlar</D:href>
1865 <D:privilege><D:read/></D:privilege>
1866 <D:privilege><D:write/></D:privilege>
1867 <D:privilege><D:read-acl/></D:privilege>
1872 <D:href>http://www.example.com/groups/mrktng</D:href>
1875 <D:privilege><D:read/></D:privilege>
1880 <D:property><D:owner/></D:property>
1883 <D:privilege><D:read-acl/></D:privilege>
1884 <D:privilege><D:write-acl/></D:privilege>
1888 <D:principal><D:all/></D:principal>
1890 <D:privilege><D:read/></D:privilege>
1893 <D:href>http://www.example.com/top</D:href>
1898 <D:status>HTTP/1.1 200 OK</D:status>
1906Clemm, et al. Standards Track [Page 34]
1908RFC 3744 WebDAV Access Control Protocol May 2004
1911 The value of the DAV:owner property is a single DAV:href XML element
1912 containing the URL of the principal that owns this resource.
1914 The value of the DAV:supported-privilege-set property is a tree of
1915 supported privileges (using "[XML Namespace , localname]" to identify
1918 [DAV:, all] (aggregate, abstract)
1921 +-- [DAV:, write] (aggregate, abstract)
1923 +-- [http://www.example.com/acl, create]
1924 +-- [http://www.example.com/acl, update]
1925 +-- [http://www.example.com/acl, delete]
1926 +-- [DAV:, read-acl]
1927 +-- [DAV:, write-acl]
1929 The DAV:current-user-privilege-set property contains two privileges,
1930 DAV:read, and DAV:read-acl. This indicates that the current
1931 authenticated user only has the ability to read the resource, and
1932 read the DAV:acl property on the resource. The DAV:acl property
1933 contains a set of four ACEs:
1935 ACE #1: The principal identified by the URL http://www.example.com/
1936 users/esedlar is granted the DAV:read, DAV:write, and DAV:read-acl
1939 ACE #2: The principals identified by the URL http://www.example.com/
1940 groups/mrktng are denied the DAV:read privilege. In this example,
1941 the principal URL identifies a group.
1943 ACE #3: In this ACE, the principal is a property principal,
1944 specifically the DAV:owner property. When evaluating this ACE, the
1945 value of the DAV:owner property is retrieved, and is examined to see
1946 if it contains a DAV:href XML element. If so, the URL within the
1947 DAV:href element is read, and identifies a principal. In this ACE,
1948 the owner is granted DAV:read-acl, and DAV:write-acl privileges.
1950 ACE #4: This ACE grants the DAV:all principal (all users) the
1951 DAV:read privilege. This ACE is inherited from the resource http://
1952 www.example.com/top, the parent collection of this resource.
1962Clemm, et al. Standards Track [Page 35]
1964RFC 3744 WebDAV Access Control Protocol May 2004
1969 WebDAV ACLs are evaluated in similar manner as ACLs on Windows NT and
1970 in NFSv4 [RFC3530]). An ACL is evaluated to determine whether or not
1971 access will be granted for a WebDAV request. ACEs are maintained in
1972 a particular order, and are evaluated until all of the permissions
1973 required by the current request have been granted, at which point the
1974 ACL evaluation is terminated and access is granted. If, during ACL
1975 evaluation, a <deny> ACE (matching the current user) is encountered
1976 for a privilege which has not yet been granted, the ACL evaluation is
1977 terminated and access is denied. Failure to have all required
1978 privileges granted results in access being denied.
1980 Note that the semantics of many other existing ACL systems may be
1981 represented via this mechanism, by mixing deny and grant ACEs. For
1982 example, consider the standard "rwx" privilege scheme used by UNIX.
1983 In this scheme, if the current user is the owner of the file, access
1984 is granted if the corresponding privilege bit is set and denied if
1985 not set, regardless of the permissions set on the file's group and
1986 for the world. An ACL for UNIX permissions of "r--rw-r--" might be
1992 <D:property><D:owner/></D:property>
1995 <D:privilege><D:read/></D:privilege>
2000 <D:property><D:owner/></D:property>
2003 <D:privilege><D:all/></D:privilege>
2008 <D:property><D:group/></D:property>
2011 <D:privilege><D:read/></D:privilege>
2012 <D:privilege><D:write/></D:privilege>
2018Clemm, et al. Standards Track [Page 36]
2020RFC 3744 WebDAV Access Control Protocol May 2004
2025 <D:property><D:group/></D:property>
2028 <D:privilege><D:all/></D:privilege>
2032 <D:principal><D:all></D:principal>
2034 <D:privilege><D:read/></D:privilege>
2039 and the <acl-restrictions> would be defined as:
2042 <D:required-principal>
2044 <D:property><D:owner/></D:property>
2045 <D:property><D:group/><D:group/>
2046 </D:required-principal>
2048 Note that the client can still get errors from a UNIX server in spite
2049 of obeying the <acl-restrictions>, including <D:allowed-principal>
2050 (adding an ACE specifying a principal other than the ones in the ACL
2051 above) or <D:ace-conflict> (by trying to reorder the ACEs in the
2052 example above), as these particular implementation semantics are too
2053 complex to be captured with the simple (but general) declarative
20567. Access Control and existing methods
2058 This section defines the impact of access control functionality on
20637.1.1. Error Handling
2065 The WebDAV ACL mechanism requires the usage of HTTP method
2066 "preconditions" as described in section 1.6 of RFC3253 for ALL HTTP
2067 methods. All HTTP methods have an additional precondition called
2068 DAV:need-privileges. If an HTTP method fails due to insufficient
2069 privileges, the response body to the "403 Forbidden" error MUST
2070 contain the <DAV:error> element, which in turn contains the
2074Clemm, et al. Standards Track [Page 37]
2076RFC 3744 WebDAV Access Control Protocol May 2004
2079 <DAV:need-privileges> element, which contains one or more
2080 <DAV:resource> elements indicating which resource had insufficient
2081 privileges, and what the lacking privileges were:
2083 <!ELEMENT need-privileges (resource)* >
2084 <!ELEMENT resource ( href , privilege ) >
2086 Since some methods require multiple permissions on multiple
2087 resources, this information is needed to resolve any ambiguity.
2088 There is no requirement that all privilege violations be reported -
2089 for implementation reasons, some servers may only report the first
2090 privilege violation. For example:
2095 Host: www.example.com
2096 Destination: http://www.example.com/c/d
2100 HTTP/1.1 403 Forbidden
2101 Content-Type: text/xml; charset="utf-8"
2104 <D:error xmlns:D="DAV:">
2108 <D:privilege><D:unbind/></D:privilege>
2112 <D:privilege><D:bind/></D:privilege>
2114 </D:need-privileges>
2119 If the server supports access control, it MUST return "access-
2120 control" as a field in the DAV response header from an OPTIONS
2121 request on any resource implemented by that server. A value of
2122 "access-control" in the DAV header MUST indicate that the server
2123 supports all MUST level requirements and REQUIRED features specified
2130Clemm, et al. Standards Track [Page 38]
2132RFC 3744 WebDAV Access Control Protocol May 2004
21357.2.1. Example - OPTIONS
2139 OPTIONS /foo.html HTTP/1.1
2140 Host: www.example.com
2146 DAV: 1, 2, access-control
2147 Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL
2149 In this example, the OPTIONS response indicates that the server
2150 supports access control and that /foo.html can have its access
2151 control list modified by the ACL method.
2155 When a resource is moved from one location to another due to a MOVE
2156 request, the non-inherited and non-protected ACEs in the DAV:acl
2157 property of the resource MUST NOT be modified, or the MOVE request
2158 fails. Handling of inherited and protected ACEs is intentionally
2159 undefined to give server implementations flexibility in how they
2160 implement ACE inheritance and protection.
2164 The DAV:acl property on the resource at the destination of a COPY
2165 MUST be the same as if the resource was created by an individual
2166 resource creation request (e.g., MKCOL, PUT). Clients wishing to
2167 preserve the DAV:acl property across a copy need to read the DAV:acl
2168 property prior to the COPY, then perform an ACL operation on the new
2169 resource at the destination to restore, insofar as this is possible,
2170 the original access control list.
2174 A lock on a resource ensures that only the lock owner can modify ACEs
2175 that are not inherited and not protected (these are the only ACEs
2176 that a client can modify with an ACL request). A lock does not
2177 protect inherited or protected ACEs, since a client cannot modify
2178 them with an ACL request on that resource.
2186Clemm, et al. Standards Track [Page 39]
2188RFC 3744 WebDAV Access Control Protocol May 2004
21918. Access Control Methods
2195 The ACL method modifies the access control list (which can be read
2196 via the DAV:acl property) of a resource. Specifically, the ACL
2197 method only permits modification to ACEs that are not inherited, and
2198 are not protected. An ACL method invocation modifies all non-
2199 inherited and non-protected ACEs in a resource's access control list
2200 to exactly match the ACEs contained within in the DAV:acl XML element
2201 (specified in Section 5.5) of the request body. An ACL request body
2202 MUST contain only one DAV:acl XML element. Unless the non-inherited
2203 and non-protected ACEs of the DAV:acl property of the resource can be
2204 updated to be exactly the value specified in the ACL request, the ACL
2207 It is possible that the ACEs visible to the current user in the
2208 DAV:acl property may only be a portion of the complete set of ACEs on
2209 that resource. If this is the case, an ACL request only modifies the
2210 set of ACEs visible to the current user, and does not affect any
2213 In order to avoid overwriting DAV:acl changes by another client, a
2214 client SHOULD acquire a WebDAV lock on the resource before retrieving
2215 the DAV:acl property of a resource that it intends on updating.
2217 Implementation Note: Two common operations are to add or remove an
2218 ACE from an existing access control list. To accomplish this, a
2219 client uses the PROPFIND method to retrieve the value of the
2220 DAV:acl property, then parses the returned access control list to
2221 remove all inherited and protected ACEs (these ACEs are tagged
2222 with the DAV:inherited and DAV:protected XML elements). In the
2223 remaining set of non-inherited, non-protected ACEs, the client can
2224 add or remove one or more ACEs before submitting the final ACE set
2225 in the request body of the ACL method.
22278.1.1. ACL Preconditions
2229 An implementation MUST enforce the following constraints on an ACL
2230 request. If the constraint is violated, a 403 (Forbidden) or 409
2231 (Conflict) response MUST be returned and the indicated XML element
2232 MUST be returned as a child of a top level DAV:error element in an
2235 Though these status elements are generally expressed as empty XML
2236 elements (and are defined as EMPTY in the DTD), implementations MAY
2237 return additional descriptive XML elements as children of the status
2242Clemm, et al. Standards Track [Page 40]
2244RFC 3744 WebDAV Access Control Protocol May 2004
2247 element. Clients MUST be able to accept children of these status
2248 elements. Clients that do not understand the additional XML elements
2251 (DAV:no-ace-conflict): The ACEs submitted in the ACL request MUST NOT
2252 conflict with each other. This is a catchall error code indicating
2253 that an implementation-specific ACL restriction has been violated.
2255 (DAV:no-protected-ace-conflict): The ACEs submitted in the ACL
2256 request MUST NOT conflict with the protected ACEs on the resource.
2257 For example, if the resource has a protected ACE granting DAV:write
2258 to a given principal, then it would not be consistent if the ACL
2259 request submitted an ACE denying DAV:write to the same principal.
2261 (DAV:no-inherited-ace-conflict): The ACEs submitted in the ACL
2262 request MUST NOT conflict with the inherited ACEs on the resource.
2263 For example, if the resource inherits an ACE from its parent
2264 collection granting DAV:write to a given principal, then it would not
2265 be consistent if the ACL request submitted an ACE denying DAV:write
2266 to the same principal. Note that reporting of this error will be
2267 implementation-dependent. Implementations MUST either report this
2268 error or allow the ACE to be set, and then let normal ACE evaluation
2269 rules determine whether the new ACE has any impact on the privileges
2270 available to a specific principal.
2272 (DAV:limited-number-of-aces): The number of ACEs submitted in the ACL
2273 request MUST NOT exceed the number of ACEs allowed on that resource.
2274 However, ACL-compliant servers MUST support at least one ACE granting
2275 privileges to a single principal, and one ACE granting privileges to
2278 (DAV:deny-before-grant): All non-inherited deny ACEs MUST precede all
2279 non-inherited grant ACEs.
2281 (DAV:grant-only): The ACEs submitted in the ACL request MUST NOT
2282 include a deny ACE. This precondition applies only when the ACL
2283 restrictions of the resource include the DAV:grant-only constraint
2284 (defined in Section 5.6.1).
2286 (DAV:no-invert): The ACL request MUST NOT include a DAV:invert
2287 element. This precondition applies only when the ACL semantics of
2288 the resource includes the DAV:no-invert constraint (defined in
2291 (DAV:no-abstract): The ACL request MUST NOT attempt to grant or deny
2292 an abstract privilege (see Section 5.3).
2298Clemm, et al. Standards Track [Page 41]
2300RFC 3744 WebDAV Access Control Protocol May 2004
2303 (DAV:not-supported-privilege): The ACEs submitted in the ACL request
2304 MUST be supported by the resource.
2306 (DAV:missing-required-principal): The result of the ACL request MUST
2307 have at least one ACE for each principal identified in a
2308 DAV:required-principal XML element in the ACL semantics of that
2309 resource (see Section 5.5).
2311 (DAV:recognized-principal): Every principal URL in the ACL request
2312 MUST identify a principal resource.
2314 (DAV:allowed-principal): The principals specified in the ACEs
2315 submitted in the ACL request MUST be allowed as principals for the
2316 resource. For example, a server where only authenticated principals
2317 can access resources would not allow the DAV:all or
2318 DAV:unauthenticated principals to be used in an ACE, since these
2319 would allow unauthenticated access to resources.
23218.1.2. Example: the ACL method
2323 In the following example, user "fielding", authenticated by
2324 information in the Authorization header, grants the principal
2325 identified by the URL http://www.example.com/users/esedlar (i.e., the
2326 user "esedlar") read and write privileges, grants the owner of the
2327 resource read-acl and write-acl privileges, and grants everyone read
2332 ACL /top/container/ HTTP/1.1
2333 Host: www.example.com
2334 Content-Type: text/xml; charset="utf-8"
2335 Content-Length: xxxx
2336 Authorization: Digest username="fielding",
2337 realm="users@example.com", nonce="...",
2338 uri="/top/container/", response="...", opaque="..."
2340 <?xml version="1.0" encoding="utf-8" ?>
2341 <D:acl xmlns:D="DAV:">
2344 <D:href>http://www.example.com/users/esedlar</D:href>
2347 <D:privilege><D:read/></D:privilege>
2348 <D:privilege><D:write/></D:privilege>
2354Clemm, et al. Standards Track [Page 42]
2356RFC 3744 WebDAV Access Control Protocol May 2004
2361 <D:property><D:owner/></D:property>
2364 <D:privilege><D:read-acl/></D:privilege>
2365 <D:privilege><D:write-acl/></D:privilege>
2369 <D:principal><D:all/></D:principal>
2371 <D:privilege><D:read/></D:privilege>
23808.1.3. Example: ACL method failure due to protected ACE conflict
2382 In the following request, user "fielding", authenticated by
2383 information in the Authorization header, attempts to deny the
2384 principal identified by the URL http://www.example.com/users/esedlar
2385 (i.e., the user "esedlar") write privileges. Prior to the request,
2386 the DAV:acl property on the resource contained a protected ACE (see
2387 Section 5.5.3) granting DAV:owner the DAV:read and DAV:write
2388 privileges. The principal identified by URL http://www.example.com/
2389 users/esedlar is the owner of the resource. The ACL method
2390 invocation fails because the submitted ACE conflicts with the
2391 protected ACE, thus violating the semantics of ACE protection.
2395 ACL /top/container/ HTTP/1.1
2396 Host: www.example.com
2397 Content-Type: text/xml; charset="utf-8"
2398 Content-Length: xxxx
2399 Authorization: Digest username="fielding",
2400 realm="users@example.com", nonce="...",
2401 uri="/top/container/", response="...", opaque="..."
2403 <?xml version="1.0" encoding="utf-8" ?>
2404 <D:acl xmlns:D="DAV:">
2410Clemm, et al. Standards Track [Page 43]
2412RFC 3744 WebDAV Access Control Protocol May 2004
2415 <D:href>http://www.example.com/users/esedlar</D:href>
2418 <D:privilege><D:write/></D:privilege>
2425 HTTP/1.1 403 Forbidden
2426 Content-Type: text/xml; charset="utf-8"
2429 <?xml version="1.0" encoding="utf-8" ?>
2430 <D:error xmlns:D="DAV:">
2431 <D:no-protected-ace-conflict/>
24348.1.4. Example: ACL method failure due to an inherited ACE conflict
2436 In the following request, user "ejw", authenticated by information in
2437 the Authorization header, tries to change the access control list on
2438 the resource http://www.example.com/top/index.html. This resource
2439 has two inherited ACEs.
2441 Inherited ACE #1 grants the principal identified by URL http://
2442 www.example.com/users/ejw (i.e., the user "ejw") http://
2443 www.example.com/privs/write-all and DAV:read-acl privileges. On this
2444 server, http://www.example.com/privs/write-all is an aggregate
2445 privilege containing DAV:write, and DAV:write-acl.
2447 Inherited ACE #2 grants principal DAV:all the DAV:read privilege.
2449 The request attempts to set a (non-inherited) ACE, denying the
2450 principal identified by the URL http://www.example.com/users/ejw
2451 (i.e., the user "ejw") DAV:write permission. This conflicts with
2452 inherited ACE #1. Note that the decision to report an inherited ACE
2453 conflict is specific to this server implementation. Another server
2454 implementation could have allowed the new ACE to be set, and then
2455 used normal ACE evaluation rules to determine whether the new ACE has
2456 any impact on the privileges available to a principal.
2466Clemm, et al. Standards Track [Page 44]
2468RFC 3744 WebDAV Access Control Protocol May 2004
2473 ACL /top/index.html HTTP/1.1
2474 Host: www.example.com
2475 Content-Type: text/xml; charset="utf-8"
2476 Content-Length: xxxx
2477 Authorization: Digest username="ejw",
2478 realm="users@example.com", nonce="...",
2479 uri="/top/index.html", response="...", opaque="..."
2481 <?xml version="1.0" encoding="utf-8" ?>
2482 <D:acl xmlns:D="DAV:" xmlns:F="http://www.example.com/privs/">
2485 <D:href>http://www.example.com/users/ejw</D:href>
2487 <D:grant><D:write/></D:grant>
2493 HTTP/1.1 403 Forbidden
2494 Content-Type: text/xml; charset="utf-8"
2497 <?xml version="1.0" encoding="utf-8" ?>
2498 <D:error xmlns:D="DAV:">
2499 <D:no-inherited-ace-conflict/>
25028.1.5. Example: ACL method failure due to an attempt to set grant and
2503 deny in a single ACE
2505 In this example, user "ygoland", authenticated by information in the
2506 Authorization header, tries to change the access control list on the
2507 resource http://www.example.com/diamond/engagement-ring.gif. The ACL
2508 request includes a single, syntactically and semantically incorrect
2509 ACE, which attempts to grant the group identified by the URL http://
2510 www.example.com/users/friends DAV:read privilege and deny the
2511 principal identified by URL http://www.example.com/users/ygoland-so
2512 (i.e., the user "ygoland-so") DAV:read privilege. However, it is
2513 illegal to have multiple principal elements, as well as both a grant
2514 and deny element in the same ACE, so the request fails due to poor
2522Clemm, et al. Standards Track [Page 45]
2524RFC 3744 WebDAV Access Control Protocol May 2004
2529 ACL /diamond/engagement-ring.gif HTTP/1.1
2530 Host: www.example.com
2531 Content-Type: text/xml; charset="utf-8"
2532 Content-Length: xxxx
2533 Authorization: Digest username="ygoland",
2534 realm="users@example.com", nonce="...",
2535 uri="/diamond/engagement-ring.gif", response="...",
2538 <?xml version="1.0" encoding="utf-8" ?>
2539 <D:acl xmlns:D="DAV:">
2542 <D:href>http://www.example.com/users/friends</D:href>
2544 <D:grant><D:read/></D:grant>
2546 <D:href>http://www.example.com/users/ygoland-so</D:href>
2548 <D:deny><D:read/></D:deny>
2554 HTTP/1.1 400 Bad Request
2557 Note that if the request had been divided into two ACEs, one to
2558 grant, and one to deny, the request would have been syntactically
25619. Access Control Reports
2565 The REPORT method (defined in Section 3.6 of [RFC3253]) provides an
2566 extensible mechanism for obtaining information about a resource.
2567 Unlike the PROPFIND method, which returns the value of one or more
2568 named properties, the REPORT method can involve more complex
2569 processing. REPORT is valuable in cases where the server has access
2570 to all of the information needed to perform the complex request (such
2571 as a query), and where it would require multiple requests for the
2572 client to retrieve the information needed to perform the same
2578Clemm, et al. Standards Track [Page 46]
2580RFC 3744 WebDAV Access Control Protocol May 2004
2583 A server that supports the WebDAV Access Control Protocol MUST
2584 support the DAV:expand-property report (defined in Section 3.8 of
25879.2. DAV:acl-principal-prop-set Report
2589 The DAV:acl-principal-prop-set report returns, for all principals in
2590 the DAV:acl property (of the Request-URI) that are identified by
2591 http(s) URLs or by a DAV:property principal, the value of the
2592 properties specified in the REPORT request body. In the case where a
2593 principal URL appears multiple times, the DAV:acl-principal-prop-set
2594 report MUST return the properties for that principal only once.
2595 Support for this report is REQUIRED.
2597 One expected use of this report is to retrieve the human readable
2598 name (found in the DAV:displayname property) of each principal found
2599 in an ACL. This is useful for constructing user interfaces that show
2600 each ACE in a human readable form.
2604 The request body MUST be a DAV:acl-principal-prop-set XML element.
2606 <!ELEMENT acl-principal-prop-set ANY>
2607 ANY value: a sequence of one or more elements, with at most one
2609 prop: see RFC 2518, Section 12.11
2611 This report is only defined when the Depth header has value "0";
2612 other values result in a 400 (Bad Request) error response. Note
2613 that [RFC3253], Section 3.6, states that if the Depth header is
2614 not present, it defaults to a value of "0".
2616 The response body for a successful request MUST be a
2617 DAV:multistatus XML element (i.e., the response uses the same
2618 format as the response for PROPFIND). In the case where there are
2619 no response elements, the returned multistatus XML element is
2622 multistatus: see RFC 2518, Section 12.9
2624 The response body for a successful DAV:acl-principal-prop-set
2625 REPORT request MUST contain a DAV:response element for each
2626 principal identified by an http(s) URL listed in a DAV:principal
2627 XML element of an ACE within the DAV:acl property of the resource
2628 identified by the Request-URI.
2634Clemm, et al. Standards Track [Page 47]
2636RFC 3744 WebDAV Access Control Protocol May 2004
2641 (DAV:number-of-matches-within-limits): The number of matching
2642 principals must fall within server-specific, predefined limits.
2643 For example, this condition might be triggered if a search
2644 specification would cause the return of an extremely large number
26479.2.1. Example: DAV:acl-principal-prop-set Report
2649 Resource http://www.example.com/index.html has an ACL with three
2652 ACE #1: All principals (DAV:all) have DAV:read and DAV:read-current-
2653 user-privilege-set access.
2655 ACE #2: The principal identified by http://www.example.com/people/
2656 gstein (the user "gstein") is granted DAV:write, DAV:write-acl,
2657 DAV:read-acl privileges.
2659 ACE #3: The group identified by http://www.example.com/groups/authors
2660 (the "authors" group) is granted DAV:write and DAV:read-acl
2663 The following example shows a DAV:acl-principal-prop-set report
2664 requesting the DAV:displayname property. It returns the value of
2665 DAV:displayname for resources http://www.example.com/people/gstein
2666 and http://www.example.com/groups/authors , but not for DAV:all,
2667 since this is not an http(s) URL.
2671 REPORT /index.html HTTP/1.1
2672 Host: www.example.com
2673 Content-Type: text/xml; charset="utf-8"
2674 Content-Length: xxxx
2677 <?xml version="1.0" encoding="utf-8" ?>
2678 <D:acl-principal-prop-set xmlns:D="DAV:">
2682 </D:acl-principal-prop-set>
2690Clemm, et al. Standards Track [Page 48]
2692RFC 3744 WebDAV Access Control Protocol May 2004
2697 HTTP/1.1 207 Multi-Status
2698 Content-Type: text/xml; charset="utf-8"
2699 Content-Length: xxxx
2701 <?xml version="1.0" encoding="utf-8" ?>
2702 <D:multistatus xmlns:D="DAV:">
2704 <D:href>http://www.example.com/people/gstein</D:href>
2707 <D:displayname>Greg Stein</D:displayname>
2709 <D:status>HTTP/1.1 200 OK</D:status>
2713 <D:href>http://www.example.com/groups/authors</D:href>
2716 <D:displayname>Site authors</D:displayname>
2718 <D:status>HTTP/1.1 200 OK</D:status>
27239.3. DAV:principal-match REPORT
2725 The DAV:principal-match REPORT is used to identify all members (at
2726 any depth) of the collection identified by the Request-URI that are
2727 principals and that match the current user. In particular, if the
2728 collection contains principals, the report can be used to identify
2729 all members of the collection that match the current user.
2730 Alternatively, if the collection contains resources that have a
2731 property that identifies a principal (e.g., DAV:owner), the report
2732 can be used to identify all members of the collection whose property
2733 identifies a principal that matches the current user. For example,
2734 this report can return all of the resources in a collection hierarchy
2735 that are owned by the current user. Support for this report is
2740 The request body MUST be a DAV:principal-match XML element.
2741 <!ELEMENT principal-match ((principal-property | self), prop?)>
2742 <!ELEMENT principal-property ANY>
2746Clemm, et al. Standards Track [Page 49]
2748RFC 3744 WebDAV Access Control Protocol May 2004
2751 ANY value: an element whose value identifies a property. The
2752 expectation is the value of the named property typically contains
2753 an href element that contains the URI of a principal
2754 <!ELEMENT self EMPTY>
2755 prop: see RFC 2518, Section 12.11
2757 This report is only defined when the Depth header has value "0";
2758 other values result in a 400 (Bad Request) error response. Note
2759 that [RFC3253], Section 3.6, states that if the Depth header is
2760 not present, it defaults to a value of "0". The response body for
2761 a successful request MUST be a DAV:multistatus XML element. In
2762 the case where there are no response elements, the returned
2763 multistatus XML element is empty.
2765 multistatus: see RFC 2518, Section 12.9
2767 The response body for a successful DAV:principal-match REPORT
2768 request MUST contain a DAV:response element for each member of the
2769 collection that matches the current user. When the
2770 DAV:principal-property element is used, a match occurs if the
2771 current user is matched by the principal identified by the URI
2772 found in the DAV:href element of the property identified by the
2773 DAV:principal-property element. When the DAV:self element is used
2774 in a DAV:principal-match report issued against a group, it matches
2775 the group if a member identifies the same principal as the current
2778 If DAV:prop is specified in the request body, the properties
2779 specified in the DAV:prop element MUST be reported in the
2780 DAV:response elements.
27829.3.1. Example: DAV:principal-match REPORT
2784 The following example identifies the members of the collection
2785 identified by the URL http://www.example.com/doc that are owned by
2786 the current user. The current user ("gclemm") is authenticated using
2787 Digest authentication.
2791 REPORT /doc/ HTTP/1.1
2792 Host: www.example.com
2793 Authorization: Digest username="gclemm",
2794 realm="users@example.com", nonce="...",
2795 uri="/papers/", response="...", opaque="..."
2796 Content-Type: text/xml; charset="utf-8"
2797 Content-Length: xxxx
2802Clemm, et al. Standards Track [Page 50]
2804RFC 3744 WebDAV Access Control Protocol May 2004
2807 <?xml version="1.0" encoding="utf-8" ?>
2808 <D:principal-match xmlns:D="DAV:">
2809 <D:principal-property>
2811 </D:principal-property>
2812 </D:principal-match>
2816 HTTP/1.1 207 Multi-Status
2817 Content-Type: text/xml; charset="utf-8"
2818 Content-Length: xxxx
2820 <?xml version="1.0" encoding="utf-8" ?>
2821 <D:multistatus xmlns:D="DAV:">
2823 <D:href>http://www.example.com/doc/foo.html</D:href>
2824 <D:status>HTTP/1.1 200 OK</D:status>
2827 <D:href>http://www.example.com/doc/img/bar.gif</D:href>
2828 <D:status>HTTP/1.1 200 OK</D:status>
28329.4. DAV:principal-property-search REPORT
2834 The DAV:principal-property-search REPORT performs a search for all
2835 principals whose properties contain character data that matches the
2836 search criteria specified in the request. One expected use of this
2837 report is to discover the URL of a principal associated with a given
2838 person or group by searching for them by name. This is done by
2839 searching over DAV:displayname, which is defined on all principals.
2841 The actual search method (exact matching vs. substring matching vs,
2842 prefix-matching, case-sensitivity) deliberately is left to the server
2843 implementation to allow implementation on a wide set of possible user
2844 management systems. In cases where the implementation of
2845 DAV:principal-property-search is not constrained by the semantics of
2846 an underlying user management repository, preferred default semantics
2847 are caseless substring matches.
2849 For implementation efficiency, servers do not typically support
2850 searching on all properties. A search requesting properties that are
2851 not searchable for a particular principal will not match that
2854 Support for the DAV:principal-property-search report is REQUIRED.
2858Clemm, et al. Standards Track [Page 51]
2860RFC 3744 WebDAV Access Control Protocol May 2004
2863 Implementation Note: The value of a WebDAV property is a sequence
2864 of well-formed XML, and hence can include any character in the
2865 Unicode/ISO-10646 standard, that is, most known characters in
2866 human languages. Due to the idiosyncrasies of case mapping across
2867 human languages, implementation of case-insensitive matching is
2868 non-trivial. Implementors of servers that do perform substring
2869 matching are strongly encouraged to consult "The Unicode Standard"
2870 [UNICODE4], especially Section 5.18, Subsection "Caseless
2871 Matching", for guidance when implementing their case-insensitive
2872 matching algorithms.
2874 Implementation Note: Some implementations of this protocol will
2875 use an LDAP repository for storage of principal metadata. The
2876 schema describing each attribute (akin to a WebDAV property) in an
2877 LDAP repository specifies whether it supports case-sensitive or
2878 caseless searching. One of the benefits of leaving the search
2879 method to the discretion of the server implementation is the
2880 default LDAP attribute search behavior can be used when
2881 implementing the DAV:principal-property-search report.
2885 The request body MUST be a DAV:principal-property-search XML
2886 element containing a search specification and an optional list of
2887 properties. For every principal that matches the search
2888 specification, the response will contain the value of the
2889 requested properties on that principal.
2891 <!ELEMENT principal-property-search
2892 ((property-search+), prop?, apply-to-principal-collection-set?) >
2894 By default, the report searches all members (at any depth) of the
2895 collection identified by the Request-URI. If DAV:apply-to-
2896 principal-collection-set is specified in the request body, the
2897 request is applied instead to each collection identified by the
2898 DAV:principal-collection-set property of the resource identified
2901 The DAV:property-search element contains a prop element
2902 enumerating the properties to be searched and a match element,
2903 containing the search string.
2905 <!ELEMENT property-search (prop, match) >
2906 prop: see RFC 2518, Section 12.11
2908 <!ELEMENT match #PCDATA >
2914Clemm, et al. Standards Track [Page 52]
2916RFC 3744 WebDAV Access Control Protocol May 2004
2919 Multiple property-search elements or multiple elements within a
2920 DAV:prop element will be interpreted with a logical AND.
2922 This report is only defined when the Depth header has value "0";
2923 other values result in a 400 (Bad Request) error response. Note
2924 that [RFC3253], Section 3.6, states that if the Depth header is
2925 not present, it defaults to a value of "0".
2927 The response body for a successful request MUST be a
2928 DAV:multistatus XML element. In the case where there are no
2929 response elements, the returned multistatus XML element is empty.
2931 multistatus: see RFC 2518, Section 12.9
2933 The response body for a successful DAV:principal-property-search
2934 REPORT request MUST contain a DAV:response element for each
2935 principal whose property values satisfy the search specification
2936 given in DAV:principal-property-search.
2938 If DAV:prop is specified in the request body, the properties
2939 specified in the DAV:prop element MUST be reported in the
2940 DAV:response elements.
2948 (DAV:number-of-matches-within-limits): The number of matching
2949 principals must fall within server-specific, predefined limits.
2950 For example, this condition might be triggered if a search
2951 specification would cause the return of an extremely large number
2956 There are several cases to consider when matching strings. The
2957 easiest case is when a property value is "simple" and has only
2958 character information item content (see [REC-XML-INFOSET]). For
2959 example, the search string "julian" would match the DAV:displayname
2960 property with value "Julian Reschke". Note that the on-the-wire
2961 marshaling of DAV:displayname in this case is:
2963 <D:displayname xmlns:D="DAV:">Julian Reschke</D:displayname>
2970Clemm, et al. Standards Track [Page 53]
2972RFC 3744 WebDAV Access Control Protocol May 2004
2975 The name of the property is encoded into the XML element information
2976 item, and the character information item content of the property is
2979 A more complicated case occurs when properties have mixed content
2980 (that is, compound values consisting of multiple child element items,
2981 other types of information items, and character information item
2982 content). Consider the property "aprop" in the namespace "http://
2983 www.example.com/props/", marshaled as:
2985 <W:aprop xmlns:W="http://www.example.com/props/">
2986 {cdata 0}<W:elem1>{cdata 1}</W:elem1>
2987 <W:elem2>{cdata 2}</W:elem2>{cdata 3}
2990 In this case, matching is performed on each individual contiguous
2991 sequence of character information items. In the example above, a
2992 search string would be compared to the four following strings:
2999 That is, four individual matches would be performed, one each for
3000 {cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}.
30029.4.2. Example: successful DAV:principal-property-search REPORT
3004 In this example, the client requests the principal URLs of all users
3005 whose DAV:displayname property contains the substring "doE" and whose
3006 "title" property in the namespace "http://BigCorp.com/ns/" (that is,
3007 their professional title) contains "Sales". In addition, the client
3008 requests five properties to be returned with the matching principals:
3010 In the DAV: namespace: displayname
3012 In the http://www.example.com/ns/ namespace: department, phone,
3026Clemm, et al. Standards Track [Page 54]
3028RFC 3744 WebDAV Access Control Protocol May 2004
3031 The response shows that two principal resources meet the search
3032 specification, "John Doe" and "Zygdoebert Smith". The property
3033 "salary" in namespace "http://www.example.com/ns/" is not returned,
3034 since the principal making the request does not have sufficient
3035 access permissions to read this property.
3039 REPORT /users/ HTTP/1.1
3040 Host: www.example.com
3041 Content-Type: text/xml; charset=utf-8
3042 Content-Length: xxxx
3045 <?xml version="1.0" encoding="utf-8" ?>
3046 <D:principal-property-search xmlns:D="DAV:">
3051 <D:match>doE</D:match>
3052 </D:property-search>
3054 <D:prop xmlns:B="http://www.example.com/ns/">
3057 <D:match>Sales</D:match>
3058 </D:property-search>
3059 <D:prop xmlns:B="http://www.example.com/ns/">
3066 </D:principal-property-search>
3070 HTTP/1.1 207 Multi-Status
3071 Content-Type: text/xml; charset=utf-8
3072 Content-Length: xxxx
3074 <?xml version="1.0" encoding="utf-8" ?>
3075 <D:multistatus xmlns:D="DAV:" xmlns:B="http://BigCorp.com/ns/">
3077 <D:href>http://www.example.com/users/jdoe</D:href>
3082Clemm, et al. Standards Track [Page 55]
3084RFC 3744 WebDAV Access Control Protocol May 2004
3088 <D:displayname>John Doe</D:displayname>
3089 <B:department>Widget Sales</B:department>
3090 <B:phone>234-4567</B:phone>
3091 <B:office>209</B:office>
3093 <D:status>HTTP/1.1 200 OK</D:status>
3099 <D:status>HTTP/1.1 403 Forbidden</D:status>
3103 <D:href>http://www.example.com/users/zsmith</D:href>
3106 <D:displayname>Zygdoebert Smith</D:displayname>
3107 <B:department>Gadget Sales</B:department>
3108 <B:phone>234-7654</B:phone>
3109 <B:office>114</B:office>
3111 <D:status>HTTP/1.1 200 OK</D:status>
3117 <D:status>HTTP/1.1 403 Forbidden</D:status>
31229.5. DAV:principal-search-property-set REPORT
3124 The DAV:principal-search-property-set REPORT identifies those
3125 properties that may be searched using the DAV:principal-property-
3126 search REPORT (defined in Section 9.4).
3128 Servers MUST support the DAV:principal-search-property-set REPORT on
3129 all collections identified in the value of a DAV:principal-
3130 collection-set property.
3132 An access control protocol user agent could use the results of the
3133 DAV:principal-search-property-set REPORT to present a query interface
3134 to the user for retrieving principals.
3138Clemm, et al. Standards Track [Page 56]
3140RFC 3744 WebDAV Access Control Protocol May 2004
3143 Support for this report is REQUIRED.
3145 Implementation Note: Some clients will have only limited screen
3146 real estate for the display of lists of searchable properties. In
3147 this case, a user might appreciate having the most frequently
3148 searched properties be displayed on-screen, rather than having to
3149 scroll through a long list of searchable properties. One
3150 mechanism for signaling the most frequently searched properties is
3151 to return them towards the start of a list of properties. A
3152 client can then preferentially display the list of properties in
3153 order, increasing the likelihood that the most frequently searched
3154 properties will appear on-screen, and will not require scrolling
3155 for their selection.
3159 The request body MUST be an empty DAV:principal-search-property-
3162 This report is only defined when the Depth header has value "0";
3163 other values result in a 400 (Bad Request) error response. Note
3164 that [RFC3253], Section 3.6, states that if the Depth header is
3165 not present, it defaults to a value of "0".
3167 The response body MUST be a DAV:principal-search-property-set XML
3168 element, containing a DAV:principal-search-property XML element
3169 for each property that may be searched with the DAV:principal-
3170 property-search REPORT. A server MAY limit its response to just a
3171 subset of the searchable properties, such as those likely to be
3172 useful to an interactive access control client.
3174 <!ELEMENT principal-search-property-set
3175 (principal-search-property*) >
3177 Each DAV:principal-search-property XML element contains exactly
3178 one searchable property, and a description of the property.
3180 <!ELEMENT principal-search-property (prop, description) >
3182 The DAV:prop element contains one principal property on which the
3183 server is able to perform a DAV:principal-property-search REPORT.
3185 prop: see RFC 2518, Section 12.11
3194Clemm, et al. Standards Track [Page 57]
3196RFC 3744 WebDAV Access Control Protocol May 2004
3199 The description element is a human-readable description of what
3200 information this property represents. Servers MUST indicate the
3201 human language of the description using the xml:lang attribute and
3202 SHOULD consider the HTTP Accept-Language request header when
3203 selecting one of multiple available languages.
3205 <!ELEMENT description #PCDATA >
32079.5.1. Example: DAV:principal-search-property-set REPORT
3209 In this example, the client determines the set of searchable
3210 principal properties by requesting the DAV:principal-search-
3211 property-set REPORT on the root of the server's principal URL
3212 collection set, identified by http://www.example.com/users/.
3216 REPORT /users/ HTTP/1.1
3217 Host: www.example.com
3218 Content-Type: text/xml; charset="utf-8"
3220 Accept-Language: en, de
3221 Authorization: BASIC d2FubmFtYWs6cGFzc3dvcmQ=
3224 <?xml version="1.0" encoding="utf-8" ?>
3225 <D:principal-search-property-set xmlns:D="DAV:"/>
3230 Content-Type: text/xml; charset="utf-8"
3233 <?xml version="1.0" encoding="utf-8" ?>
3234 <D:principal-search-property-set xmlns:D="DAV:">
3235 <D:principal-search-property>
3239 <D:description xml:lang="en">Full name</D:description>
3240 </D:principal-search-property>
3241 <D:principal-search-property>
3242 <D:prop xmlns:B="http://BigCorp.com/ns/">
3250Clemm, et al. Standards Track [Page 58]
3252RFC 3744 WebDAV Access Control Protocol May 2004
3256 <D:description xml:lang="en">Job title</D:description>
3257 </D:principal-search-property>
3258 </D:principal-search-property-set>
3262 Implementations of this specification MUST support the XML element
3263 ignore rule, as specified in Section 23.3.2 of [RFC2518], and the XML
3264 Namespace recommendation [REC-XML-NAMES].
3266 Note that use of the DAV namespace is reserved for XML elements and
3267 property names defined in a standards-track or Experimental IETF RFC.
326911. Internationalization Considerations
3271 In this specification, the only human-readable content can be found
3272 in the description XML element, found within the DAV:supported-
3273 privilege-set property. This element contains a human-readable
3274 description of the capabilities controlled by a privilege. As a
3275 result, the description element must be capable of representing
3276 descriptions in multiple character sets. Since the description
3277 element is found within a WebDAV property, it is represented on the
3278 wire as XML [REC-XML], and hence can leverage XML's language tagging
3279 and character set encoding capabilities. Specifically, XML
3280 processors at minimum must be able to read XML elements encoded using
3281 the UTF-8 [RFC3629] encoding of the ISO 10646 multilingual plane.
3282 XML examples in this specification demonstrate use of the charset
3283 parameter of the Content-Type header, as defined in [RFC3023], as
3284 well as the XML "encoding" attribute, which together provide charset
3285 identification information for MIME and XML processors. Furthermore,
3286 this specification requires server implementations to tag description
3287 fields with the xml:lang attribute (see Section 2.12 of [REC-XML]),
3288 which specifies the human language of the description. Additionally,
3289 server implementations should take into account the value of the
3290 Accept-Language HTTP header to determine which description string to
3293 For XML elements other than the description element, it is expected
3294 that implementations will treat the property names, privilege names,
3295 and values as tokens, and convert these tokens into human-readable
3296 text in the user's language and character set when displayed to a
3297 person. Only a generic WebDAV property display utility would display
3298 these values in their raw form to a human user.
3300 For error reporting, we follow the convention of HTTP/1.1 status
3301 codes, including with each status code a short, English description
3302 of the code (e.g., 200 (OK)). While the possibility exists that a
3306Clemm, et al. Standards Track [Page 59]
3308RFC 3744 WebDAV Access Control Protocol May 2004
3311 poorly crafted user agent would display this message to a user,
3312 internationalized applications will ignore this message, and display
3313 an appropriate message in the user's language and character set.
3315 Further internationalization considerations for this protocol are
3316 described in the WebDAV Distributed Authoring protocol specification
331912. Security Considerations
3321 Applications and users of this access control protocol should be
3322 aware of several security considerations, detailed below. In
3323 addition to the discussion in this document, the security
3324 considerations detailed in the HTTP/1.1 specification [RFC2616], the
3325 WebDAV Distributed Authoring Protocol specification [RFC2518], and
3326 the XML Media Types specification [RFC3023] should be considered in a
3327 security analysis of this protocol.
332912.1. Increased Risk of Compromised Users
3331 In the absence of a mechanism for remotely manipulating access
3332 control lists, if a single user's authentication credentials are
3333 compromised, only those resources for which the user has access
3334 permission can be read, modified, moved, or deleted. With the
3335 introduction of this access control protocol, if a single compromised
3336 user has the ability to change ACLs for a broad range of other users
3337 (e.g., a super-user), the number of resources that could be altered
3338 by a single compromised user increases. This risk can be mitigated
3339 by limiting the number of people who have write-acl privileges across
3340 a broad range of resources.
334212.2. Risks of the DAV:read-acl and DAV:current-user-privilege-set
3345 The ability to read the access privileges (stored in the DAV:acl
3346 property), or the privileges permitted the currently authenticated
3347 user (stored in the DAV:current-user-privilege-set property) on a
3348 resource may seem innocuous, since reading an ACL cannot possibly
3349 affect the resource's state. However, if all resources have world-
3350 readable ACLs, it is possible to perform an exhaustive search for
3351 those resources that have inadvertently left themselves in a
3352 vulnerable state, such as being world-writable. In particular, the
3353 property retrieval method PROPFIND, executed with Depth infinity on
3354 an entire hierarchy, is a very efficient way to retrieve the DAV:acl
3355 or DAV:current-user-privilege-set properties. Once found, this
3356 vulnerability can be exploited by a denial of service attack in which
3357 the open resource is repeatedly overwritten. Alternately, writable
3358 resources can be modified in undesirable ways.
3362Clemm, et al. Standards Track [Page 60]
3364RFC 3744 WebDAV Access Control Protocol May 2004
3367 To reduce this risk, read-acl privileges should not be granted to
3368 unauthenticated principals, and restrictions on read-acl and read-
3369 current-user-privilege-set privileges for authenticated principals
3370 should be carefully analyzed when deploying this protocol. Access to
3371 the current-user-privilege-set property will involve a tradeoff of
3372 usability versus security. When the current-user-privilege-set is
3373 visible, user interfaces are expected to provide enhanced information
3374 concerning permitted and restricted operations, yet this information
3375 may also indicate a vulnerability that could be exploited.
3376 Deployment of this protocol will need to evaluate this tradeoff in
3377 light of the requirements of the deployment environment.
337912.3. No Foreknowledge of Initial ACL
3381 In an effort to reduce protocol complexity, this protocol
3382 specification intentionally does not address the issue of how to
3383 manage or discover the initial ACL that is placed upon a resource
3384 when it is created. The only way to discover the initial ACL is to
3385 create a new resource, then retrieve the value of the DAV:acl
3386 property. This assumes the principal creating the resource also has
3387 been granted the DAV:read-acl privilege.
3389 As a result, it is possible that a principal could create a resource,
3390 and then discover that its ACL grants privileges that are
3391 undesirable. Furthermore, this protocol makes it possible (though
3392 unlikely) that the creating principal could be unable to modify the
3393 ACL, or even delete the resource. Even when the ACL can be modified,
3394 there will be a short period of time when the resource exists with
3395 the initial ACL before its new ACL can be set.
3397 Several factors mitigate this risk. Human principals are often aware
3398 of the default access permissions in their editing environments and
3399 take this into account when writing information. Furthermore,
3400 default privilege policies are usually very conservative, limiting
3401 the privileges granted by the initial ACL.
3405 Authentication mechanisms defined for use with HTTP and WebDAV also
3406 apply to this WebDAV Access Control Protocol, in particular the Basic
3407 and Digest authentication mechanisms defined in [RFC2617].
3408 Implementation of the ACL spec requires that Basic authentication, if
3409 used, MUST only be supported over secure transport such as TLS.
3418Clemm, et al. Standards Track [Page 61]
3420RFC 3744 WebDAV Access Control Protocol May 2004
342314. IANA Considerations
3425 This document uses the namespace defined by [RFC2518] for XML
3426 elements. That is, this specification uses the "DAV:" URI namespace,
3427 previously registered in the URI schemes registry. All other IANA
3428 considerations mentioned in [RFC2518] are also applicable to this
3433 This protocol is the collaborative product of the WebDAV ACL design
3434 team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry Lind, Sean
3435 Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead. The authors
3436 are grateful for the detailed review and comments provided by Jim
3437 Amsden, Dylan Barrell, Gino Basso, Murthy Chintalapati, Lisa
3438 Dusseault, Stefan Eissing, Tim Ellison, Yaron Goland, Dennis
3439 Hamilton, Laurie Harper, Eckehard Hermann, Ron Jacobs, Chris Knight,
3440 Remy Maucherat, Larry Masinter, Joe Orton, Peter Raymond, and Keith
3441 Wannamaker. We thank Keith Wannamaker for the initial text of the
3442 principal property search sections. Prior work on WebDAV access
3443 control protocols has been performed by Yaron Goland, Paul Leach,
3444 Lisa Dusseault, Howard Palmer, and Jon Radoff. We would like to
3445 acknowledge the foundation laid for us by the authors of the DeltaV,
3446 WebDAV and HTTP protocols upon which this protocol is layered, and
3447 the invaluable feedback from the WebDAV working group.
345116.1. Normative References
3453 [REC-XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E.
3454 Maler, "Extensible Markup Language (XML) 1.0
3455 ((Third ed)", W3C REC REC-xml-20040204, February
3456 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.
3458 [REC-XML-INFOSET] Cowan, J. and R. Tobin, "XML Information Set
3459 (Second Edition)", W3C REC REC-xml-infoset-
3460 20040204, February 2004,
3461 <http://www.w3.org/TR/2004/REC-xml-infoset-
3464 [REC-XML-NAMES] Bray, T., Hollander, D. and A. Layman, "Namespaces
3465 in XML", W3C REC REC-xml-names-19990114, January
3466 1999, <http://www.w3.org/TR/1999/REC-xml-names-
3469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3470 Requirement Levels", BCP 14, RFC 2119, March 1997.
3474Clemm, et al. Standards Track [Page 62]
3476RFC 3744 WebDAV Access Control Protocol May 2004
3479 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S.
3480 and D. Jensen, "HTTP Extensions for Distributed
3481 Authoring -- WEBDAV", RFC 2518, February 1999.
3483 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3484 Masinter, L., Leach, P. and T. Berners-Lee,
3485 "Hypertext Transfer Protocol -- HTTP/1.1", RFC
3488 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J.,
3489 Lawrence, S., Leach, P., Luotonen, A. and L.
3490 Stewart, "HTTP Authentication: Basic and Digest
3491 Access Authentication", RFC 2617, June 1999.
3493 [RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media
3494 Types", RFC 3023, January 2001.
3496 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and
3497 J. Whitehead, "Versioning Extensions to WebDAV",
3498 RFC 3253, March 2002.
3500 [RFC3530] Shepler, S., Ed., Callaghan, B., Robinson, D.,
3501 Thurlow, R., Beame, C., Eisler, M. and D. Noveck,
3502 "Network File System (NFS) version 4 Protocol", RFC
3505 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
3506 10646", STD 63, RFC 3629 November 2003.
350816.2. Informative References
3510 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight
3511 Directory Access Protocol (v3)", RFC 2251, December
3514 [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC
3515 2255, December 1997.
3517 [UNICODE4] The Unicode Consortium, "The Unicode Standard -
3518 Version 4.0", Addison-Wesley , August 2003,
3519 <http://www.unicode.org/versions/Unicode4.0.0/>.
3530Clemm, et al. Standards Track [Page 63]
3532RFC 3744 WebDAV Access Control Protocol May 2004
3535Appendix A. WebDAV XML Document Type Definition Addendum
3537 All XML elements defined in this Document Type Definition (DTD)
3538 belong to the DAV namespace. This DTD should be viewed as an addendum
3539 to the DTD provided in [RFC2518], section 23.1.
3541 <!-- Privileges -- (Section 3)>
3543 <!ELEMENT read EMPTY>
3544 <!ELEMENT write EMPTY>
3545 <!ELEMENT write-properties EMPTY>
3546 <!ELEMENT write-content EMPTY>
3547 <!ELEMENT unlock EMPTY>
3548 <!ELEMENT read-acl EMPTY>
3549 <!ELEMENT read-current-user-privilege-set EMPTY>
3550 <!ELEMENT write-acl EMPTY>
3551 <!ELEMENT bind EMPTY>
3552 <!ELEMENT unbind EMPTY>
3553 <!ELEMENT all EMPTY>
3555 <!-- Principal Properties (Section 4) -->
3557 <!ELEMENT principal EMPTY>
3559 <!ELEMENT alternate-URI-set (href*)>
3560 <!ELEMENT principal-URL (href)>
3561 <!ELEMENT group-member-set (href*)>
3562 <!ELEMENT group-membership (href*)>
3564 <!-- Access Control Properties (Section 5) -->
3566 <!-- DAV:owner Property (Section 5.1) -->
3568 <!ELEMENT owner (href?)>
3570 <!-- DAV:group Property (Section 5.2) -->
3572 <!ELEMENT group (href?)>
3574 <!-- DAV:supported-privilege-set Property (Section 5.3) -->
3576 <!ELEMENT supported-privilege-set (supported-privilege*)>
3577 <!ELEMENT supported-privilege
3578 (privilege, abstract?, description, supported-privilege*)>
3580 <!ELEMENT privilege ANY>
3581 <!ELEMENT abstract EMPTY>
3582 <!ELEMENT description #PCDATA>
3586Clemm, et al. Standards Track [Page 64]
3588RFC 3744 WebDAV Access Control Protocol May 2004
3591 <!-- DAV:current-user-privilege-set Property (Section 5.4) -->
3593 <!ELEMENT current-user-privilege-set (privilege*)>
3595 <!-- DAV:acl Property (Section 5.5) -->
3597 <!ELEMENT acl (ace)* >
3598 <!ELEMENT ace ((principal | invert), (grant|deny), protected?,
3601 <!ELEMENT principal (href)
3602 | all | authenticated | unauthenticated
3605 <!ELEMENT all EMPTY>
3606 <!ELEMENT authenticated EMPTY>
3607 <!ELEMENT unauthenticated EMPTY>
3608 <!ELEMENT property ANY>
3609 <!ELEMENT self EMPTY>
3611 <!ELEMENT invert principal>
3613 <!ELEMENT grant (privilege+)>
3614 <!ELEMENT deny (privilege+)>
3615 <!ELEMENT privilege ANY>
3617 <!ELEMENT protected EMPTY>
3619 <!ELEMENT inherited (href)>
3621 <!-- DAV:acl-restrictions Property (Section 5.6) -->
3623 <!ELEMENT acl-restrictions (grant-only?, no-invert?,
3624 deny-before-grant?, required-principal?)>
3626 <!ELEMENT grant-only EMPTY>
3627 <!ELEMENT no-invert EMPTY>
3628 <!ELEMENT deny-before-grant EMPTY>
3630 <!ELEMENT required-principal
3631 (all? | authenticated? | unauthenticated? | self? | href*
3634 <!-- DAV:inherited-acl-set Property (Section 5.7) -->
3636 <!ELEMENT inherited-acl-set (href*)>
3638 <!-- DAV:principal-collection-set Property (Section 5.8) -->
3642Clemm, et al. Standards Track [Page 65]
3644RFC 3744 WebDAV Access Control Protocol May 2004
3647 <!ELEMENT principal-collection-set (href*)>
3649 <!-- Access Control and Existing Methods (Section 7) -->
3651 <!ELEMENT need-privileges (resource)* >
3652 <!ELEMENT resource ( href, privilege )
3654 <!-- ACL method preconditions (Section 8.1.1) -->
3656 <!ELEMENT no-ace-conflict EMPTY>
3657 <!ELEMENT no-protected-ace-conflict EMPTY>
3658 <!ELEMENT no-inherited-ace-conflict EMPTY>
3659 <!ELEMENT limited-number-of-aces EMPTY>
3660 <!ELEMENT grant-only EMPTY>
3661 <!ELEMENT no-invert EMPTY>
3662 <!ELEMENT deny-before-grant EMPTY>
3663 <!ELEMENT no-abstract EMPTY>
3664 <!ELEMENT not-supported-privilege EMPTY>
3665 <!ELEMENT missing-required-principal EMPTY>
3666 <!ELEMENT recognized-principal EMPTY>
3667 <!ELEMENT allowed-principal EMPTY>
3669 <!-- REPORTs (Section 9) -->
3671 <!ELEMENT acl-principal-prop-set ANY>
3672 ANY value: a sequence of one or more elements, with at most one
3675 <!ELEMENT principal-match ((principal-property | self), prop?)>
3676 <!ELEMENT principal-property ANY>
3677 ANY value: an element whose value identifies a property. The
3678 expectation is the value of the named property typically contains
3679 an href element that contains the URI of a principal
3680 <!ELEMENT self EMPTY>
3682 <!ELEMENT principal-property-search ((property-search+), prop?) >
3683 <!ELEMENT property-search (prop, match) >
3684 <!ELEMENT match #PCDATA >
3686 <!ELEMENT principal-search-property-set (
3687 principal-search-property*) >
3688 <!ELEMENT principal-search-property (prop, description) >
3689 <!ELEMENT description #PCDATA >
3698Clemm, et al. Standards Track [Page 66]
3700RFC 3744 WebDAV Access Control Protocol May 2004
3703Appendix B. WebDAV Method Privilege Table (Normative)
3705 The following table of WebDAV methods (as defined in RFC 2518, 2616,
3706 and 3253) clarifies which privileges are required for access for each
3707 method. Note that the privileges listed, if denied, MUST cause
3708 access to be denied. However, given that a specific implementation
3709 MAY define an additional custom privilege to control access to
3710 existing methods, having all of the indicated privileges does not
3711 mean that access will be granted. Note that lack of the indicated
3712 privileges does not imply that access will be denied, since a
3713 particular implementation may use a sub-privilege aggregated under
3714 the indicated privilege to control access. Privileges required refer
3715 to the current resource being processed unless otherwise specified.
3754Clemm, et al. Standards Track [Page 67]
3756RFC 3744 WebDAV Access Control Protocol May 2004
3759 +---------------------------------+---------------------------------+
3760 | METHOD | PRIVILEGES |
3761 +---------------------------------+---------------------------------+
3764 | OPTIONS | <D:read> |
3765 | PUT (target exists) | <D:write-content> on target |
3767 | PUT (no target exists) | <D:bind> on parent collection |
3769 | PROPPATCH | <D:write-properties> |
3770 | ACL | <D:write-acl> |
3771 | PROPFIND | <D:read> (plus <D:read-acl> and |
3772 | | <D:read-current-user-privilege- |
3773 | | set> as needed) |
3774 | COPY (target exists) | <D:read>, <D:write-content> and |
3775 | | <D:write-properties> on target |
3777 | COPY (no target exists) | <D:read>, <D:bind> on target |
3779 | MOVE (no target exists) | <D:unbind> on source collection |
3780 | | and <D:bind> on target |
3782 | MOVE (target exists) | As above, plus <D:unbind> on |
3783 | | the target collection |
3784 | DELETE | <D:unbind> on parent collection |
3785 | LOCK (target exists) | <D:write-content> |
3786 | LOCK (no target exists) | <D:bind> on parent collection |
3787 | MKCOL | <D:bind> on parent collection |
3788 | UNLOCK | <D:unlock> |
3789 | CHECKOUT | <D:write-properties> |
3790 | CHECKIN | <D:write-properties> |
3791 | REPORT | <D:read> (on all referenced |
3793 | VERSION-CONTROL | <D:write-properties> |
3794 | MERGE | <D:write-content> |
3795 | MKWORKSPACE | <D:write-content> on parent |
3797 | BASELINE-CONTROL | <D:write-properties> and |
3798 | | <D:write-content> |
3799 | MKACTIVITY | <D:write-content> on parent |
3801 +---------------------------------+---------------------------------+
3810Clemm, et al. Standards Track [Page 68]
3812RFC 3744 WebDAV Access Control Protocol May 2004
3822 DAV:allowed-principal (pre) 42
3823 DAV:deny-before-grant (pre) 41
3824 DAV:grant-only (pre) 41
3825 DAV:limited-number-of-aces (pre) 41
3826 DAV:missing-required-principal (pre) 42
3827 DAV:no-abstract (pre) 41
3828 DAV:no-ace-conflict (pre) 41
3829 DAV:no-inherited-ace-conflict (pre) 41
3830 DAV:no-invert (pre) 41
3831 DAV:no-protected-ace-conflict (pre) 41
3832 DAV:not-supported-privilege (pre) 42
3833 DAV:number-of-matches-within-limits (post) 48, 53
3834 DAV:recognized-principal (pre) 42
3838 compliance class 'access-control' 38
3840 DAV:acl-principal-prop-set report 48
3841 DAV:acl-restrictions property 27
3842 DAV:all privilege 13
3843 DAV:allowed-principal precondition 42
3844 DAV:alternate-URI-set property 14
3845 DAV:bind privilege 12
3846 DAV:current-user-privilege-set property 21
3847 DAV:deny-before-grant precondition 41
3848 DAV:grant-only precondition 41
3849 DAV:group property 18
3850 DAV:group-member-set property 14
3851 DAV:group-membership property 14
3852 DAV:inherited-acl-set property 29
3853 DAV:limited-number-of-aces precondition 41
3854 DAV:missing-required-principal precondition 42
3855 DAV:no-abstract precondition 41
3856 DAV:no-ace-conflict precondition 41
3857 DAV:no-inherited-ace-conflict precondition 41
3858 DAV:no-invert precondition 41
3859 DAV:no-protected-ace-conflict precondition 41
3860 DAV:not-supported-privilege precondition 42
3861 DAV:number-of-matches-within-limits postcondition 48, 53
3862 DAV:owner property 15
3866Clemm, et al. Standards Track [Page 69]
3868RFC 3744 WebDAV Access Control Protocol May 2004
3871 DAV:principal resource type 13
3872 DAV:principal-collection-set property 30
3873 DAV:principal-match report 50
3874 DAV:principal-property-search 51
3875 DAV:principal-search-property-set 56
3876 DAV:principal-URL property 14
3877 DAV:read privilege 10
3878 DAV:read-acl privilege 11
3879 DAV:read-current-user-privilege-set privilege 12
3880 DAV:recognized-principal precondition 42
3881 DAV:supported-privilege-set property 18
3882 DAV:unbind privilege 12
3883 DAV:unlock privilege 11
3884 DAV:write privilege 10
3885 DAV:write-acl privilege 12
3886 DAV:write-content privilege 10
3887 DAV:write-properties privilege 10
3899 DAV:read-current-user-privilege-set 12
3904 DAV:write-content 11
3905 DAV:write-properties 10
3908 DAV:acl-restrictions 27
3909 DAV:alternate-URI-set 14
3910 DAV:current-user-privilege-set 21
3912 DAV:group-member-set 14
3913 DAV:group-membership 14
3914 DAV:inherited-acl-set 29
3916 DAV:principal-collection-set 30
3917 DAV:principal-URL 14
3918 DAV:supported-privilege-set 18
3922Clemm, et al. Standards Track [Page 70]
3924RFC 3744 WebDAV Access Control Protocol May 2004
3929 DAV:acl-principal-prop-set 47
3930 DAV:principal-match 49
3931 DAV:principal-property-search 51
3932 DAV:principal-search-property-set 56
3943 EMail: geoffrey.clemm@us.ibm.com
3952 EMail: julian.reschke@greenbytes.de
3958 Redwood Shores, CA 94065
3960 EMail: eric.sedlar@oracle.com
3964 U.C. Santa Cruz, Dept. of Computer Science
3966 Santa Cruz, CA 95064
3968 EMail: ejw@cse.ucsc.edu
3978Clemm, et al. Standards Track [Page 71]
3980RFC 3744 WebDAV Access Control Protocol May 2004
3983Full Copyright Statement
3985 Copyright (C) The Internet Society (2004). This document is subject
3986 to the rights, licenses and restrictions contained in BCP 78, and
3987 except as set forth therein, the authors retain all their rights.
3989 This document and the information contained herein are provided on an
3990 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
3991 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
3992 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
3993 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
3994 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3995 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3997Intellectual Property
3999 The IETF takes no position regarding the validity or scope of any
4000 Intellectual Property Rights or other rights that might be claimed
4001 to pertain to the implementation or use of the technology
4002 described in this document or the extent to which any license
4003 under such rights might or might not be available; nor does it
4004 represent that it has made any independent effort to identify any
4005 such rights. Information on the procedures with respect to
4006 rights in RFC documents can be found in BCP 78 and BCP 79.
4008 Copies of IPR disclosures made to the IETF Secretariat and any
4009 assurances of licenses to be made available, or the result of an
4010 attempt made to obtain a general license or permission for the use
4011 of such proprietary rights by implementers or users of this
4012 specification can be obtained from the IETF on-line IPR repository
4013 at http://www.ietf.org/ipr.
4015 The IETF invites any interested party to bring to its attention
4016 any copyrights, patents or patent applications, or other
4017 proprietary rights that may cover technology that may be required
4018 to implement this standard. Please address the information to the
4019 IETF at ietf-ipr@ietf.org.
4023 Funding for the RFC Editor function is currently provided by the
4034Clemm, et al. Standards Track [Page 72]