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