idnits 2.17.1
draft-ietf-webdav-acl-02.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:
----------------------------------------------------------------------------
** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand
corner of the first page
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity.
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 26
longer pages, the longest (page 2) being 64 lines
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 27 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Introduction section.
(A line matching the expected section header was found, but with an
unexpected indentation:
' 1 INTRODUCTION' )
** The document seems to lack a Security Considerations section.
(A line matching the expected section header was found, but with an
unexpected indentation:
' 9 SECURITY CONSIDERATIONS' )
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
(A line matching the expected section header was found, but with an
unexpected indentation:
' 12 IANA CONSIDERATIONS' )
** The document seems to lack an Authors' Addresses Section.
** There are 488 instances of too long lines in the document, the longest
one being 10 characters in excess of 72.
** The abstract seems to contain references ([SEANLYND], [RFC2518],
[GCLEMM], [CKNIGHT], [RFC2026], [RFC2119], [ANNEHOP], [REQUIRED],
[WEBDAV], [OPTIONAL], [RFC2068]), which it shouldn't. Please replace
those with straight textual mentions of the documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 365 has weird spacing: '...ner' of the r...'
== Line 907 has weird spacing: '...se, the optio...'
== Line 1147 has weird spacing: '...gregate a ri...'
== Line 1158 has weird spacing: '...es that hav...'
== Line 1160 has weird spacing: '...ht make memb...'
== (9 more instances...)
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
A right controls access to a particular set of HTTP operations on a
resource. The set of rights that apply to a particular resource may vary
with the DAV:resourcetype of the resource, as well as between different
server implementations. To promote interoperability, however, WebDAV
defines a set of well-known rights (e.g. DAV:read and DAV:write), which
can at least be used to set some context to the other rights defined on a
particular resource. Rights may be aggregates of other rights. For
example, one implementation may split out a right controlling the ability
to add children to a collection from the right allowing a resource to be
removed from a collection. Since these rights control the ability to
write to a collection, these rights would be aggregated by the DAV:write
right. The relationships between atomic rights and aggregate rights can
be discovered via the DAV:access-rights property on a particular
resource. Servers may specify some rights as abstract, which means that
it MUST not appear in an ACL, but is described in the DAV:access-rights
property to aid in setting context. Server implementations must return
the same response to the DAV:access-rights property on all of the
resources with the same DAV:resourcetype value.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 14, 2000) is 8681 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 section? 'RFC2068' on line 1071 looks like a reference
-- Missing reference section? 'RFC2119' on line 1075 looks like a reference
-- Missing reference section? 'OPTIONAL' on line 492 looks like a reference
-- Missing reference section? 'REQUIRED' on line 486 looks like a reference
-- Missing reference section? 'WEBDAV' on line 607 looks like a reference
-- Missing reference section? 'RFC2518' on line 1078 looks like a reference
-- Missing reference section? 'RFC2026' on line 1069 looks like a reference
-- Missing reference section? 'CKNIGHT' on line 1194 looks like a reference
-- Missing reference section? 'GCLEMM' on line 1206 looks like a reference
-- Missing reference section? 'ANNEHOP' on line 1258 looks like a reference
-- Missing reference section? 'SEANLYND' on line 1244 looks like a reference
Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 13 comments
(--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 INTERNET-DRAFT Geoffrey Clemm, Rational Software
3 draft-ietf-webdav-acl-02 Anne Hopkins, Microsoft Corporation
4 Eric Sedlar, Oracle Corporation
6 Expires January 14, 2001 July 14, 2000
8 Access Control Extensions to WebDAV
10 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with all
12 provisions of Section 10 of RFC2026.
13 Internet-Drafts are working documents of the Internet Engineering Task
14 Force (IETF), its areas, and its working groups. Note that other
15 groups may also distribute working documents as Internet-Drafts.
16 Internet-Drafts are draft documents valid for a maximum of six months
17 and may be updated, replaced, or obsoleted by other documents at any
18 time. It is inappropriate to use Internet- Drafts as reference
19 material or to cite them other than as "work in progress."
20 The list of current Internet-Drafts can be accessed at
21 http://www.ietf.org/ietf/1id-abstracts.txt
22 The list of Internet-Draft Shadow Directories can be accessed at
23 http://www.ietf.org/shadow.html.
25 Abstract
26 This document specifies a set of methods, headers, and resource-types
27 that define the WebDAV Access Control extensions to the HTTP/1.1
28 protocol.
30 Table of Contents
32 1 INTRODUCTION............................................3
33 1.1 Notational Conventions................................3
35 2 PRINCIPALS..............................................3
37 3 RIGHTS..................................................4
38 3.1 DAV:access-rights property............................5
39 3.2 Rights defined by WebDAV..............................6
40 3.2.1 read Right........................................6
41 3.2.2 write Right.......................................7
42 3.2.3 readacl Right.....................................7
43 3.2.4 writeacl Right....................................7
44 3.2.5 all Right.........................................7
46 4 ACCESS CONTROL PROPERTIES...............................7
47 4.1 Retrieving Access Control Information................11
48 4.1.1 Example: Retrieving Access Control information...11
49 4.2 Setting Access Control Information...................12
50 4.2.1 Example: Setting Access Control information......13
52 5 USING ACLS.............................................14
53 5.1 System Controlled Rights.............................14
54 5.2 Special Principal Identifiers........................15
55 5.3 ACL Semantics Options................................15
56 5.3.1 FirstSpecific....................................16
57 5.3.2 ExplicitDenyPrecedence...........................16
59 6 ACL INHERITANCE........................................18
60 6.1 Inheritable ACEs.....................................18
61 6.2 Propagate ACE but do not use for Access Check on this resource....19
62 6.3 Propagate to immediate children only.................19
63 6.4 Protect ACL from inheritance.........................19
65 7 XML SCHEMA FOR DEFINED ELEMENTS........................20
67 8 INTERNATIONALIZATION CONSIDERATIONS....................21
69 9 SECURITY CONSIDERATIONS................................21
71 10 SCALABILITY..........................................21
73 11 AUTHENTICATION.......................................21
75 12 IANA CONSIDERATIONS..................................21
77 13 INTELLECTUAL PROPERTY................................21
79 14 ACKNOWLEDGEMENTS.....................................22
81 15 INDEX................................................22
82 16 REFERENCES...........................................22
84 17 AUTHORS' ADDRESSES...................................23
86 18 STILL TO DO :........................................23
88 19 OPEN ISSUES:.........................................25
90 1 INTRODUCTION
92 The underlying principle of access control is that who you are
93 determines how you can access a resource. The "who you are" is
94 defined by a "principal" identifier; users, client software,
95 servers, and groups of the previous have principal identifiers.
96 The "how" is determined by an "access control list" (ACL)
97 associated with a resource. An ACL contains a set of "access
98 control entries" (ACEs), where each ACE specifies a principal and
99 a set of rights that are either granted or denied to that
100 principal.
102 1.1 Notational Conventions
104 The augmented BNF used by this document to describe protocol
105 elements is described in Section 2.1 of [RFC2068]. Because this
106 augmented BNF uses the basic production rules provided in Section
107 2.2 of [RFC2068], those rules apply to this document as well.
108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
109 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
110 "OPTIONAL" in this document are to be interpreted as described in
111 [RFC2119].
113 2 PRINCIPALS
115 A principal identifies an entity that can be given access rights
116 to HTTP resources. On many implementations, a user or a group
117 will be examples of principals, but other types of principals are
118 possible. For the most part, any classification or other
119 information about the entity identified by a principal is opaque
120 with respect to this specification, and is dependent on the
121 implementation.
122 Principals are manifested to clients as a HTTP resource,
123 identified by a URL. The set of properties exposed by that
124 resource are implementation dependent, although certain
125 properties are required by this specification. Those properties
126 include:
127 . DAV:principalname: A 'live' property containing the name
128 used to authenticate this principal (typically typed into a
129 login prompt/dialog). [OPTIONAL]
131 . DAV:displayname: A property containing a human-readable
132 description of this principal. This property may be "live"
133 and not settable via PROPPATCH. [REQUIRED]
135 . DAV:principal-type: A 'live' property containing a
136 classification word for this principal. The values DAV:user
137 and DAV:group are choices for value of this property
138 recommended by this spec. The presence of this property can be
139 used to distinguish it as a principal from other resources on
140 a WebDAV server. (Note that DAV:resourcetype may not be used,
141 as all collections must use the value "collection" for
142 DAV:resourcetype, which wouldn't distinguish normal
143 collections from principal collections.) [REQUIRED]
145 Server implementations may include any other descriptive
146 information for a principal via properties.
147 A principal resource may or may not be a collection. A
148 collection principal may only contain other principals (not other
149 types of resources). Servers that support aggregation of
150 principals (e.g. groups of users or other groups) MUST manifest
151 them as collection principals. The WebDAV methods for examining
152 maintaining collections (e.g. DELETE, PROPFIND) may be used to
153 maintain collection principals. Membership in a collection
154 principal is recursive, so a principal in a collection principal
155 A contained by collection principal B is a member of both
156 collection principals. Implementations not supporting recursive
157 membership in principal collections can return an error if the
158 client attempts to bind collection principals into other
159 collection principals. Using WebDAV methods to alter the content
160 of a principal (e.g. using PROPPATCH or PUT) is outside the scope
161 of this specification, and is not required, recommended, or
162 forbidden by this spec.
164 3 RIGHTS
166 A right controls access to a particular set of HTTP operations on
167 a resource. The set of rights that apply to a particular
168 resource may vary with the DAV:resourcetype of the resource, as
169 well as between different server implementations. To promote
170 interoperability, however, WebDAV defines a set of well-known
171 rights (e.g. DAV:read and DAV:write), which can at least be used
172 to set some context to the other rights defined on a particular
173 resource.
174 Rights may be aggregates of other rights. For example, one
175 implementation may split out a right controlling the ability to
176 add children to a collection from the right allowing a resource
177 to be removed from a collection. Since these rights control the
178 ability to write to a collection, these rights would be
179 aggregated by the DAV:write right. The relationships between
180 atomic rights and aggregate rights can be discovered via the
181 DAV:access-rights property on a particular resource. Servers may
182 specify some rights as abstract, which means that it MUST not
183 appear in an ACL, but is described in the DAV:access-rights
184 property to aid in setting context. Server implementations must
185 return the same response to the DAV:access-rights property on all
186 of the resources with the same DAV:resourcetype value.
188 3.1 DAV:access-rights property
190 The DAV:access-rights property is a live property that contains
191 the rights aggregation tree. The DAV:access-rights property MUST
192 be available on every resource available via a WebDAV Access
193 Control-compliant server. Each right appears as an XML element,
194 where aggregate rights list all of their children as sub-
195 elements. Each right element can contain the following
196 attributes:
197 . abstract (Boolean): 'true' if this right MUST NOT be used in
198 an ACL/ACE. Defaults to 'false.' Note: an abstract right need
199 not be an aggregate right.
201 . Description (string): a human-readable description of what
202 this right controls access to. [REQUIRED]. The server MAY
203 localize this description, based on the Accept-Language header
204 of the request.
206 For example, the following response might be generated to a
207 request on a WebDAV server.
208 Request
209 PROPFIND /file HTTP/1.1
210 Host: www.foo.bar
211 Content-type: text/xml; charset="utf-8"
212 Accept-Language: en-us
213 Depth: 0
214 Content-Length: xxx
216
217
218
219
220
221
223 Response
224 HTTP/1.1 207 Multi-Status
225 Content-Type: text/xml
226 Content-Length: xxx
228
229
231
232 http://www.foo.bar/file
233
234 HTTP/1.1 200 OK
235
236
237
238
240
242
244
246
247
249
251
253
254
255
256
257
258
260 It is envisioned that a WebDAV ACL-aware administrative client
261 would list the available rights in a dialog box, and allow the
262 user to choose non-abstract rights to apply in an ACE. The
263 rights tree is useful programmatically to map well-known rights
264 (defined by WebDAV or other standards groups) into rights that
265 are supported by any particular server implementation.
267 3.2 Rights defined by WebDAV
269 The rights defined by WebDAV access control MUST be present in
270 the DAV:access-rights property, although they may be abstract
271 (and not usable within an ACE on a particular implementation).
272 Ability to perform a given method on a resource MUST be
273 controlled by some right. Authors of Internet drafts that define
274 new methods must specify which right (by defining a new right, or
275 mapping to one below) is required to perform the method. A
276 principal with no rights to a resource should be denied any HTTP
277 access to that resource.
279 3.2.1read Right
281 Name: DAV:read
282 Purpose: The read right provides and restricts access to
283 information regarding the state of the resource, including the
284 resource's properties. Affected methods include GET and PROPFIND.
285 The read right does not affect the OPTIONS method since it
286 reflects capabilities rather than state.
288 3.2.2write Right
290 Name: DAV:write
291 Purpose: The write right affects the same methods as the
292 Write Lock. Please refer to [WEBDAV] section 5.3 for the list of
293 affected methods. Note however, that a write lock is a different
294 mechanism than a write access change, although they affect the
295 same methods, they have independent methods to set them and
296 independent error codes.
298 3.2.3readacl Right
300 Name: DAV:readacl
301 Purpose: The readacl right provides and restricts access
302 to the DAV:acl property of this resource, rather than the
303 DAV:read right. If a user has the readacl right and not the read
304 right, the DAV:acl and DAV:access-rights properties MUST be
305 accessible via PROPFIND, and the GET method is not authorized.
306 If a user has the read right and not the readacl right, the
307 DAV:acl and DAV:access-rights properties will not be included in
308 any PROPFIND requests on the associated resource.
310 3.2.4writeacl Right
312 Name: DAV:writeacl
313 Purpose: The writeacl right provides and restricts access
314 to the DAV:acl and DAV:owner properties.
316 3.2.5all Right
318 Name: DAV:all
319 Purpose: The DAV:all right controls all other rights on
320 this resource. If the DAV:all right appears in an ACE, it is an
321 error to have any other right in that ACE. This right is merely
322 shorthand for all of the rights enumerated in the access-rights
323 property, and should not control access to rights not exposed via
324 that route.
326 4 ACCESS CONTROL PROPERTIES
328 This specification defines a number of new properties for WebDAV
329 resources. Access control properties may be set and retrieved
330 just like other WebDAV properties, using the PROPFIND and
331 PROPPATCH method (subject to permissions and 'liveness.' An HTTP
332 resource on a WebDAV Access Control-compliant server MUST contain
333 the following properties:
334 . DAV:owner: A property containing the principal information
335 identifying a particular user as the owner of the resource.
337 This property is readable by anyone with read access to the
338 resource. [REQUIRED]
340 . DAV:rights: A 'live' readonly property containing the list of
341 rights of the currently authenticated HTTP user. The read
342 right controls read access to this property. [REQUIRED]
344 . DAV:acl: A 'live' property containing one or more DAV:ace
345 tags, which specify which principals are to get access to what
346 rights, for the resource with this ACL property. [REQUIRED]
348 . DAV:aclsemantics: A readonly property indicating the ACL
349 semantics model supported by the system. [REQUIRED]
351 . DAV:protectaclfrominheritance: A "live" property indicating
352 that the ACL does not inherit any ACEs. If this property is
353 present, the ACL should contain no ACEs with the DAV:inherited
354 element present. If this property is not present and the
355 system supports ACL inheritance, then the ACL will contain
356 inheritable ACEs from its parent resource. If a resource
357 without this property present is updated with this property,
358 it is a client choice whether to remove the inherited ACEs or
359 retain them but remove the DAV:inherited element from the
360 ACEs. [OPTIONAL]
362 The DAV:owner element contains one or more of the following XML
363 elements:
364 . DAV:href: This contains the URI to the principal resource
365 that is the 'owner' of the resource. Normally, an attempt to
366 PROPPATCH this property will result in a 401 (Not Authorized)
367 error. The principal indicated by the owner property is
368 implicitly granted readacl and writeacl rights. This enables
369 the owner to restore an appropriate ACL in the case that it
370 becomes maliciously or accidently corrupted such that no
371 principal is granted the writeacl right by any ACE.
372 [REQUIRED]
374 . DAV:principalname, DAV:displayname, DAV:principal-type: These
375 are the same as the properties that can exist on the principal
376 URI. In this context they are considered 'live.' [OPTIONAL]
378 The DAV:acl element (property) contains 0 or more of the
379 following XML elements:
380 . DAV:ace: A "live" property representing an access control
381 entry, which specifies the set of rights to be either granted
382 or denied to a single principal.
384 The DAV:ace element contains the following XML elements:
385 . DAV:grant: Contains the set of XML elements corresponding to
386 the rights being granted via this ACE. MUST contain at least
387 one right. MUST NOT be present if the DAV:deny element is
388 present.
390 . DAV:deny: Contains the set of XML elements corresponding to
391 the rights being denied via this ACE. MUST contain at least
392 one right, if present. MUST NOT be present if the DAV:grant
393 element is present.
395 . DAV:principal: Contains information about the principal
396 resource this ACE applies to. [REQUIRED].
398 . DAV:acepropertytypes: A "live" property containing one or more
399 elements, each of which is an XML tag identifying either a
400 property on this resource or a property on a child resource
401 that may inherit this ACE. Presence of DAV:acepropertytypes
402 distinguishes this ACE as a "Property ACE." The rights
403 associated with a "Property ACE" control access to only the
404 property(ies) contained in DAV:acepropertytypes, and do not
405 control access to the resource as a whole. The set of access
406 rights supported on Property ACEs may be all or a subset of
407 the DAV:access-rights present on this resource. This spec
408 does not provide a mechanism to specify a different set of
409 access-rights for a property, than for the resource. An
410 implementation that supports a different set of access-rights
411 for a property than for the resource, must return an error
412 "Unsupported Right" on an attempt to write a Property ACE with
413 rights not supported by the server. [OPTIONAL]
415 . DAV:inherittochildtype: A "live" property containing one or
416 more elements, each of which is an XML tag identifying the
417 type of child object that will inherit this ACE. This
418 property is only present if DAV:inheritanceflags contains at
419 least one of the following: DAV:inheritonly,
420 DAV:containerinherit, or DAV:objectinherit. A child of the
421 current resource will only inherit this ACE if the type of the
422 child object is present in DAV:inherittochildtype.
424 . DAV:inheritanceflags: A "live" property containing flags
425 indicating the inheritance features of this ACE. For an ACE
426 that is neither inherited, nor inheritable, this element may
427 be either not present, or present but empty. [OPTIONAL]
429 . DAV:inheritancesource: A readonly property containing the URL
430 of the resource from which this ACE was inherited (contained
431 within an DAV:href element). In other words, the ACL on the
432 resource referred to by this URI contains the inheritable
433 explicit ACE which, when propagated to the current resource,
434 resulted in the current ACE. This element may contain the
435 special value of DAV:system-ace to indicate that the ACE is
436 read-only and represents rights granted implicitly by the
437 system. This element may contain the special value of
438 DAV:unknown if the server is unable to generate a valid URI to
439 the resource from which this element was inherited. This
440 element MUST be present if DAV:inheritanceflags contains the
441 DAV:inherited flag for inherited ACEs and MUST NOT be present
442 for explicit ACEs.
444 The DAV:principal element contains the following elements:
445 . DAV:href: This is a URI representing the resource to which
446 the ACE applies, or one of the special principal identifier
447 tags (e.g., DAV:owner) described in the "Special Principal
448 Identifiers" section of this spec. [REQUIRED]
450 . DAV:principalname, DAV:displayname, DAV:principal-type: These
451 are the same as the properties that can exist on the principal
452 URI. In this context they are considered 'live.' [OPTIONAL]
454 The DAV:inheritanceflags element contains 0 or more of the
455 following XML elements:
456 . DAV:inherited: This flag indicates the ACE is inherited from
457 the ACL on a different resource, identified in
458 DAV:inheritancesource. This flag MUST be present for an
459 inherited ACE and MUST NOT be present for an explicit ACE.
460 This flag must not be present if the
461 DAV:protectaclfrominheritance element is present on this
462 resource unless the DAV:inheritancesource element contains the
463 special value DAV:system-ace, indicating that this ACE wasn't
464 really inherited, but reflects implicit system-granted rights.
465 [REQUIRED]
467 . DAV:inheritonly: This flag indicates the ACE should be ignored
468 during access check. The ACE is present for the purposes of
469 inheritance only and does not affect the security of the
470 current resource. [OPTIONAL]
472 . DAV:containerinherit: This flag indicates that container
473 objects inherit this ACE as an effective ACE. The
474 DAV:inheritonly flag, if also present on this ACE, will be
475 removed from the inherited effective ACE on the container. If
476 the DAV:nopropagateinheritance flag is present on the current
477 ACE, the DAV: containerinherit flag is removed from the
478 inherited ACE on the container. [REQUIRED]
480 . DAV:objectinherit: This flag indicates that non-container
481 resources inherit this ACE as an effective ACE. The
482 DAV:inheritonly flag, if also present on this ACE, will be
483 removed from the inherited effective ACE on the non-container
484 resource. If the DAV:nopropagateinheritance> flag is not
485 present, then container resources will also inherit this ACE
486 with the addition of the DAV:inheritonly> flag. [REQUIRED]
488 . DAV:nopropagateinheritance: This flag indicates the ACE should
489 be inherited one level only. If an object inherits this ACE,
490 the DAV:containerinherit and DAV:objectinherit flags are
491 removed from the resultant inherited ACE, preventing further
492 propagation of this ACE. [OPTIONAL]
494 The DAV:aclsemantics element MUST contain exactly one of the
495 following XML elements:
496 . DAV:firstspecific: This element is present if the ACL
497 conforms to the FirstSpecific semantics described in this
498 spec.
500 . DAV:explicitdenyprecedence: This element is present if the ACL
501 conforms to the ExplicitDenyPrecedence semantics described in
502 this spec.
504 4.1 Retrieving Access Control Information
506 Retrieving Access Control information is done via PROPFIND on the
507 resource in question. All ACL properties are also returned as
508 part of the response to PROPFIND allprop request.
510 4.1.1Example: Retrieving Access Control information
512 The following example shows how access control information could
513 be retrieved using PROPFIND method.
514 Request
515 PROPFIND /top/container/ HTTP/1.1
516 Host: www.foo.bar
517 Content-type: text/xml; charset="utf-8"
518 Content-Length: 0
519 Depth: 0
521
522
523
524
526 Response
527 HTTP/1.1 207 Multi-Status
528 Content-Type: text/xml
529 Content-Length: xxx
531
532
533
534
535 HTTP/1.1 200 OK
536
537 1997-12-01T17:42:21-08:00
538 Example collection
539
540 XXXXX
541
542 http://www.foo.bar/users/gclemm
543 Geoffrey Clemm
544
545
546
547
548
549
550
551
552 http://www.foo.bar/users/esedlar
553
554 esedlar
555 Eric Sedlar
556
557
558
559
560
561 http://www.foo.bar/groups/marketing
562
563 Foo.Bar marketing
564 department
565 mktdept
566
567
568
569
570
572 http://www.foo.bar/groups/marketing
573
574 Foo.Bar marketing
575 department
576 mktdept
577
578
579
580
581
582
583
584
585
586
587
589 4.2 Setting Access Control Information
591 An ACL is set by executing a PROPPATCH against the resource that
592 contains the DAV:acl property. An ACL must be written in its
593 entirety. All ACEs (readable by the current user) previously
594 stored in the ACL on the indicated resource are removed. (If the
595 server implements rights outside of those defined in this
596 specification, they might allow only some ACEs to be visible=97
597 behaviour on a PROPPATCH is undefined with respect to this
598 specification).
599 Setting an empty ACL property causes all ACEs in the ACL,
600 including ACEs for associated properties, to be deleted.
601 Since permission to set an ACL is typically controlled by a
602 different right from permission to set other properties, it is
603 recommended that ACL-setting PROPPATCHes be executed
604 independently from PROPPATCHes of other properties. PROPATCH as
605 defined in [WEBDAV] is an atomic operation, so failure to set the
606 ACL will result in a failure to set all other properties.
607 [WEBDAV] also defines that operations must be performed from top
608 to bottom, so multiple instances of the DAV:acl element in a
609 single PROPPATCH result in only the last being set.
610 Changing ownership of a resource requires setting the DAV:href
611 element of the DAV:owner property.
613 4.2.1Example: Setting Access Control information
615 The following example follows from the previous example and
616 changes the group ACE to disallow read access to the ACL for the
617 marketing group. The other information had to be copied from the
618 ACL retrieved in the previous example.
619 Request
620 PROPPATCH /top/container HTTP/1.1
621 Host: www.foo.bar
622 Content-Type: text/xml
623 Content-Length: xxxx
625
626
627
628
629
630
631
632
633 http://www.foo.bar/users/esedlar
634
635
636
637
638
639 http://www.foo.bar/groups/marketing
640
641
642
643
644
645
647 Response
648 HTTP/1.1 207 Multi-Status
649 Content-Type: text/xml
650 Content-Length: xxx
652
653
654
655 http://www.foo.bar/top/container/
656
657 HTTP/1.1 200 OK
658
659
660
661
662
663
665 5 USING ACLS
667 An ACL contains zero or more ACEs that express the rights granted
668 or denied to the principal specified in the ACE. An ACL with
669 zero ACEs implies that no principal is granted any rights. A
670 particular ACE may either grant or deny a set of rights to a
671 single principal. However, since a server may match the
672 currently authenticated HTTP user with multiple principals (for
673 instance, in the case where one principal refers to the user and
674 another principal refers to a group to which the user belongs),
675 it is possible for multiple ACEs to "match" the current user. A
676 user has no access rights to an object protected by an ACL unless
677 that user matches one or more of the principals specified in the
678 ACEs.
679 Server implementations may limit the number of ACEs in an ACL.
680 However, ACL-compliant servers are required to support at least
681 one ACE granting rights to a single principal, and one ACE
682 granting rights to a collection principal. If a client tries to
683 write an ACL containing more ACEs than the server supports, the
684 server should return an error "Too many ACEs."
686 5.1 System Controlled Rights
688 Some implementations may grant certain rights implicitly. For
689 example, some systems grant the resource owner DAV:readacl and
690 DAV:writeacl implicitly to prevent an ACL from becoming
691 irrevocably locked by an update that grants no one the
692 DAV:writeacl right. Any rights granted implicitly by the system
693 should be reflected as standard ACEs in the ACL returned to the
694 client. Since these implicit permissions are read-only, they
695 should be reflected as "system controlled" ACEs where
696 DAV:inheritanceflags contains DAV:inherited and the
697 DAV:inheritancesource element contains DAV:system-ace.
699 5.2 Special Principal Identifiers
701 The DAV:principal element in an ACE may contain, instead of a
702 specific security principal identifier, one of the following
703 special tags:
704 . DAV:owner: The principal identified by the owner property on
705 this resource is granted or denied the rights specified in
706 this ACE.
708 . DAV:all: The current user always matches this ACE, whether or
709 not s/he is authenticated.
711 . DAV:authenticated: The current user matches this ACE if
712 authenticated.
714 . DAV:unauthenticated: The current user matches this ACE if not
715 authenticated
717 . DAV:selfprincipal: The current user matches this ACE if the
718 resource (for example, a user information object or security
719 principal account) associated with this ACL is a
720 representation of the current user.
722 5.3 ACL Semantics Options
724 In order to accommodate the different semantics of multiple
725 existing server implementations, we define a number of ACL
726 Semantics options. The tag associated with each option is used
727 to indicate what semantics to apply to the ACL. A client may use
728 this tag to display information that helps an ACL author
729 understand the implications of his updates. The client must also
730 use this tag to determine the legal semantics for ordering ACEs
731 prior to updating the ACL property.
732 The following ACL Semantics options have been defined to
733 indicate:
734 . restrictions, if any, on the ordering of ACEs within a stored
735 ACL,
737 . how to determine during access check which ACE(s) apply to a
738 user that matches multiple principals,
740 . how to combine the rights granted or denied by multiple
741 matching ACEs during access check.
743 Additional ACL models may be accommodated by defining and
744 registering additional ACL Semantics tags. [How is this done?
745 TBD].
746 Requested Rights: Some access check algorithms are based on not
747 just the user identity and the ACEs, but also on the "requested
748 rights," which is the set of rights required by the operation for
749 which the access check is being performed.
751 Effective Rights: The "effective rights" of a user is the set of
752 all rights that would be granted to a user by a given ACL. This
753 set, which is exposed via the DAV:rights property, is independent
754 of any operation "requested rights" and may be generated by a
755 different algorithm than the access check algorithm that
756 determines whether a user has specific requested rights. Each
757 right in the Effective Rights set applies to the user whether the
758 right is requested individually, or in combination with other
759 rights, in the requested rights for an operation.
761 5.3.1FirstSpecific
763 The FirstSpecific semantic model has the following
764 characteristics:
765 Order of ACEs: ACEs are ordered from "most specific" to "least
766 specific." Typically, the "most specific" ACEs identify
767 principals that refer to a single user. ACEs with "intermediate"
768 specificity have principals that refer to a collection or group
769 of users or other entities. The "least specific" ACEs contain
770 principals, like "World" or "Everyone," that indicate an
771 unbounded set of users. If multiple ACEs with the same level of
772 specificity are present, their order relative to each other is
773 not defined here. Implementations of the FirstSpecific model are
774 unlikely to have multiple ACEs in the intermediate and least
775 specific categories (where multiple ACE matches are possible),
776 making it unimportant to define a rule for relative ordering of
777 ACEs within these two specificity levels.
778 ACE Matching Algorithm: ACEs are evaluated in the order in which
779 they appear in the ACL, from first to last. When a match is
780 found, the algorithm is complete. This first matching ACE alone
781 is used to determine the effective rights of the user. If it is
782 a Grant ACE, then the user is granted all rights in the ACE. If
783 it is a Deny ACE, then the user is denied all rights in the ACE.
784 Requested rights may be compared with the effective rights to
785 determine if access should be granted.
786 ACE Combining Algorithm: The FirstSpecific model never matches
787 more than one ACE to a user, thus there's no need to combine the
788 rights of multiple ACEs.
789 Example Implementation: UNIX rights (rwx for user:group:world) is
790 an example of the FirstSpecific model.
792 5.3.2ExplicitDenyPrecedence
794 The ExplicitDenyPrecedence model has the following
795 characteristics:
796 Order of ACEs: All Explicit ACEs must precede all Inherited ACEs.
797 Within the group of Explicit ACEs, all Deny ACEs must precede all
798 Grant ACEs. Inherited ACEs are placed in the order in which they
799 are inherited. ACEs inherited from the resource's parent come
800 first, then ACEs from the grandparent, and so on.
802 ACE Matching and Combining Algorithm: The ACE matching and
803 combining algorithms are not distinct in this model and must be
804 described together. A set of "Granted rights" and a set of
805 "Denied rights", both initialized with zero rights, are
806 maintained in the algorithms to check for Requested Rights and to
807 calculate Effective Rights. In both cases, ACEs are evaluated in
808 the order in which they appear in the ACL, from first to last.
809 Checking for Requested Rights: For each ACE evaluated, if the ACE
810 matches the current user, then:
811 . if it is a Grant ACE, any rights in the ACE that are not
812 already in the "Granted rights" or "Denied rights" sets are
813 added to the "Granted rights" set
815 . if it is a Deny ACE, any rights in the ACE that are not
816 already in the "Granted rights" or "Denied rights" sets are
817 added to the "Denied rights" set
819 If the "Granted rights" set now contains all rights in the set of
820 "requested rights," then no more ACEs are evaluated and the
821 algorithm completes with "Requested Access Granted."
822 If the "Denied rights" set now contains any right that is in the
823 set of "requested rights," then no more ACEs are evaluated and
824 the algorithm completes with "Requested Access Denied."
825 If neither of these cases is true, then the next ACE is
826 evaluated. If there are no more ACEs present in the ACL, then
827 the algorithm completes with "Requested Access Denied" since the
828 accumulated Granted rights did not contain all of the requested
829 rights.
830 Calculating the effective rights of a user: As in the check for
831 requested rights, for each ACE evaluated, if the ACE matches the
832 current user, then:
833 . if it is a Grant ACE, any rights in the ACE that are not
834 already in the "Granted rights" or "Denied rights" sets are
835 added to the "Granted rights" set
837 . if it is a Deny ACE, any rights in the ACE that are not
838 already in the "Granted rights" or "Denied rights" sets are
839 added to the "Denied rights" set
841 If the union of the "Granted rights" and "Denied rights" now
842 contains all possible rights, then no more ACEs are evaluated and
843 the algorithm returns the Granted rights as the set of Effective
844 Rights.
845 Otherwise, the next ACE is evaluated. If there are no more ACEs
846 present in the ACL, then all rights present in the "Granted
847 rights" set are returned as Effective Rights.
848 Example Implementation: Microsoft Windows NT canonical ACLs are
849 an example of this model.
851 6 ACL INHERITANCE
853 To support a more scalable administration model for configuration
854 of access control information, the spec defines an ACL
855 inheritance model that enables an ACL, or elements of an ACL, to
856 be inherited and reused by other resources. An ACL-compliant
857 implementation is not required to support inheritance.
858 Typically, an ACL defined on a container resource may be
859 inherited by children of that container, grandchildren if they
860 exist, and so on down the tree. Although this hierarchical tree
861 model of inheritance is popular, this spec does not require an
862 implementation's ACL inheritance model to follow a tree structure
863 where child resource inherits from parent resource. Nonetheless,
864 for convenience, this description of inheritance assumes that a
865 child resource would inherit access control information from its
866 parent.
868 6.1 Inheritable ACEs
870 Access control information is inherited at the granularity of an
871 ACE. An inherited ace is identified by the presence of the
872 DAV:inherited element in the DAV:inheritanceflags property. An
873 "Explicit" ACE is an ACE defined directly on a resource, rather
874 than inherited from a different resource. An ACE without the
875 DAV:inherited element is by definition an Explicit ACE. Only
876 Explicit ACEs may updated by the client.
877 To indicate that an ACE should be inherited by child resources,
878 the DAV:inheritanceflags should contain:
879 . DAV:objectinherit to indicate that non-container children
880 should inherit the ACE,
882 . DAV:containerinherit to indicate that container children
883 should inherit the ACE, or
885 . both to indicate that all child resources should inherit the
886 ACE.
888 6.2 Updating an inherited ACE
890 When a child resource ACL inherits an ACE, the DAV:inherited
891 flag is present on the ACE to indicate that this ACE is read-
892 only (it may only be edited on the resource where the ACE was
893 explicitly defined). To assist users who want to make changes
894 to the rights that appear in an inherited ACE, the resource from
895 which the ACE was inherited (and therefore, on which the
896 explicit ACE is defined and editable) is identified in the
897 DAV:inheritancesource property. If the inheritance source
898 cannot be determined or if the system is unable to generate a
899 valid URI to the resource from which the ACE was inherited,
900 DAV:inheritancesource contains the special tag DAV:unknown.
902 6.3 Propagate ACE but do not use for Access Check on this resource
904 In some cases, an ACE (whether explicit or inherited) may be
905 present on a container ACL purely for the sake of propagating
906 the ACE to child objects and NOT to be used for access control
907 on the container itself. In this case, the optional
908 DAV:inheritonly flag is present on the ACE to indicate it should
909 not be used for access check on this container.
911 6.4 Propagate to immediate children only
913 To indicate that an ACE should be inherited by children, but not
914 by grandchildren or any further down the tree, the optional
915 DAV:nopropagateinheritance flag is present on the ACE. This
916 flag indicates that when this ACE is inherited by child objects,
917 the DAV:objectinherit and/or DAV:containerinherit elements must
918 be removed from the inherited ACE.
920 6.5 Protect ACL from inheritance
922 To prevent an ACL from inheriting any ACEs, the optional
923 DAV:protectaclfrominheritance property is set on the resource.
924 If this property is present on a resource, the DAV:inherited
925 element must not be present on any ACEs in that resource's ACL.
926 Other inheritance flags may be present on the ACEs of this
927 resource, since this ACL may be the source of inheritable ACEs
928 for the subtree under this resource.
930 7 XML SCHEMA FOR DEFINED ELEMENTS
932
933
934
936
942
943
944
946
949
950
951
952
954
956
957
958
959
960
961
962
964
965
967
969
970
971
972
973
974
975
976
977
978
979
980
981
983
985
986
987
989
990
991
993
994
996
997
998
999
1000
1001
1002
1003
1005 8 INTERNATIONALIZATION CONSIDERATIONS
1007 To be supplied.
1009 9 SECURITY CONSIDERATIONS
1011 To be supplied.
1013 10 SCALABILITY
1015 To be supplied.
1017 11 AUTHENTICATION
1019 Authentication mechanisms defined in WebDAV will also apply to
1020 WebDAV ACL.
1022 12 IANA CONSIDERATIONS
1024 This document uses the namespace defined by [RFC2518] for XML
1025 elements. All other IANA considerations mentioned in [RFC2518]
1026 also applicable to WebDAV ACL.
1028 13 INTELLECTUAL PROPERTY
1030 The following notice is copied from RFC 2026, section 10.4, and
1031 describes the position of the IETF concerning intellectual
1032 property claims made against this document.
1034 The IETF takes no position regarding the validity or scope of any
1035 intellectual property or other rights that might be claimed to
1036 pertain to the implementation or use other technology described
1037 in this document or the extent to which any license under such
1038 rights might or might not be available; neither does it represent
1039 that it has made any effort to identify any such rights.
1040 Information on the IETF's procedures with respect to rights in
1041 standards-track and standards-related documentation can be found
1042 in BCP-11. Copies of claims of rights made available for
1043 publication and any assurances of licenses to be made available,
1044 or the result of an attempt made to obtain a general license or
1045 permission for the use of such proprietary rights by implementers
1046 or users of this specification can be obtained from the IETF
1047 Secretariat.
1049 The IETF invites any interested party to bring to its attention
1050 any copyrights, patents or patent applications, or other
1051 proprietary rights that may cover technology that may be required
1052 to practice this standard. Please address the information to the
1053 IETF Executive Director.
1055 14 ACKNOWLEDGEMENTS
1057 This protocol is the collaborative product of the WebDAV ACL
1058 design team: xxx, yyy, zzz. We would like to acknowledge the
1059 foundation laid for us by the authors of the WebDAV and HTTP
1060 protocols upon which this protocol is layered, and the invaluable
1061 feedback from the WebDAV working group.
1063 15 INDEX
1065 To be supplied.
1067 16 REFERENCES
1069 [RFC2026] S.Bradner, "The Internet Standards Process", Harvard,
1070 1996, .
1071 [RFC2068] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and
1072 T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
1073 2068, U.C. Irvine, DEC, MIT/LCS, 1997,
1074 .
1075 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
1076 Requirement Levels", Harvard, 1997,
1077 .
1078 [RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
1079 "HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft,
1080 U.C.Irvine, Netscape, Novell, 1999
1081 .
1083 17 AUTHORS' ADDRESSES
1085 Geoffrey Clemm
1086 Rational Software
1087 20 Maguire Road
1088 Lexington, MA
1089 Email: geoffrey.clemm@rational.com
1091 Anne Hopkins
1092 Microsoft Corporation
1093 One Microsoft Way
1094 Redmond, WA
1095 Email: annehop@microsoft.com
1097 Eric Sedlar
1098 Oracle Corporation
1099 500 Oracle Parkway
1100 Redwood Shores, CA 94065
1101 Email: esedlar@us.oracle.com
1103 18 STILL TO DO :
1105 . Describe the interactions with resource locking. I'm not
1106 clear what the resolution was as far as locking the ACL
1107 separately from locking the resource.
1109 . Add a section defining new error codes/messages? Or should we
1110 make a pass through the doc and ensure all possible error
1111 conditions are mapped to existing errors?
1113 . Articulate that the required DAV:principal property should be
1114 able to be used for equality checks. Equality checks were
1115 mentioned as one reason why this property should be mandatory,
1116 even if the URI is fake.
1118 . Update "Setting Access Control Information" and to address
1119 whether read-only (ie, inherited) ACEs should be stripped out
1120 by the client prior to PROPPATCH. Fix, if necessary, comments
1121 on editing inherited ACEs in ACL Inheritance section.
1123 . Renaming DAV:rights to DAV:effectiverights? and update sample
1125 . Revisit description of Property ACEs to reflect group
1126 agreement. Add sample code. Anne will need to update
1127 Semantics descriptions to address property ACEs.
1129 . Update the self, ownergroup stuff according to eventual
1130 agreements.
1132 . Make document consistent:
1134 o Ensure all property descriptions indicate whether the
1135 property is:
1137 . "live" or "dead"
1138 . read-only or writable
1139 . REQUIRED or OPTIONAL
1140 o Ensure sample XML exists for all new properties, tags,
1141 etc.
1142 o Complete empty sections, like Scalability
1144 19 OPEN ISSUES:
1146 Issue Description Status
1147 1. Aggregate a right, if granted, that Now addressed in
1148 rights grants access to a set of spec.
1149 subsidiary rights
1150 2. Rights How do we find out what Now addressed in
1151 discovery rights are applicable to a spec.
1152 given resource? Can this be
1153 done by resource type, to
1154 avoid the need to ask each
1155 resource this question?
1156 3. Defined Should we define a 'group' Collection
1157 list of principal type which principals will
1158 "principal- specifically requires that have semantic
1159 types" principal membership be meaning (recursive
1160 recursive? This might make membership applies)
1161 administrative client
1162 implementation easier.
1163 Should this be a
1164 recommendation rather than a
1165 requirement?
1166 4. Reserved Is the list of 'reserved' Discussed in 4/28
1167 principals principals complete ( conference call.
1168 'owner', 'all', or Still Open.
1169 'unauthenticated', 'all-
1170 authenticated', etc.)
1171 5. Standard Is the list of standard Discussed on
1172 rights rights complete? conference call and
1173 updated once in
1174 draft.
1175 6. XML Do we need to scope the Use DAV namespace,
1176 namespace namespace of our XML like other working
1177 for ACL elements via , or can
1181 we use the regular DAV
1182 namespace (shared by both
1183 versioning and RFC 2518)?
1184 7. Rights What is the method for Not a method.
1185 discovery figuring out the list of DAV:Access-Rights
1186 rights? property available.
1187 Closed.
1188 8. Multiple Are we sure we don't want to Requires an
1189 principals/A allow multiple explicit vote
1190 CE [CKNIGHT] principals/ACE?
1191 9. Grant & Are we sure we don't want to Added to spec.
1192 Deny allow grant & deny in the Decision reversed
1194 [CKNIGHT] same ACE? Note that this per 6/23 call and
1195 simplifies the ACE rule to added to spec 01.3.
1196 disallow two ACEs for the Closed.
1197 same principal.
1198 10. Semantic Do we need to specify stuff Yes. Added to
1199 meaning of like whether or not spec.
1200 principal collection principal
1201 colls. membership is recursive?
1202 [GCLEMM]
1203 11. principa The semantic meaning of Added to spec=97
1204 l-name vs. principal-name should be principal-name
1205 display-name defined, or display-name holds
1206 [GCLEMM] should be used "authentication"
1207 string and
1208 displayname holds
1209 readable string
1210 12. ChangeOw Can servers disallow PROPPATCH support
1211 ner [GCLEMM/ changing the owner? for owner is
1212 CKNIGHT] optional in the
1213 spec.
1214 13. Local What text is needed Open
1215 principal regarding principal URLs
1216 URLs without hostname:port
1217 14. ACL as To what extent should ACLs ACLs are
1218 properties be treated as properties? properties. Closed.
1219 15. Semantic Would it be more appropriate Open
1220 s Model to identify these semantic
1221 names models by their
1222 [ANNEHOP] implementation names, ie,
1223 UNIX, NT Canonical? Could
1224 be easier for developers and
1225 users. Neither of these
1226 models is likely to be re-
1227 used by another
1228 implementation.
1229 16. Addition Do we need to include Open
1230 al Semantics additional ACL semantics
1231 models models? What other systems
1232 [ANNEHOP] (.htaccess?) do we need to
1233 support?
1234 17. Detectin How are WebDAV Access Open
1235 g a WebDAV Control compliant servers
1236 Access detected? Define acl
1237 Control extension for the DAV:
1238 server header?
1239 [SEANLYND]
1240 18. DAV:user If we're going to be Open
1241 /group or treating users as resources,
1242 DAV:resource then we should go all the
1243 /collection way.
1244 [SEANLYND]
1245 19. Per- ability to specify rights on Open
1246 property a per-property basis could
1247 ACEs be very useful for webdav.
1248 [ANNEHOP] consider adding an optional
1249 propertytype-id to the ace?
1250 20. Register Need to describe process for Open
1251 ing registering a new ACL
1252 Semantics semantics model option.
1253 Models
1254 [ANNEHOP]
1255 21. Strip Should the client strip all Agreed to strip
1256 Inherited Inherited (read-only) ACEs inherited ACEs in
1257 ACEs? prior to setting an ACL? Do 6/23 call. Anne
1258 [ANNEHOP] we need a flag that re-opening issue.
1259 indicates whether the server
1260 accepts a client update of
1261 inherited ACEs (to support
1262 client-side propagation of
1263 inheritance)? And/or a flag
1264 to indicate that the client
1265 WANTs to set inherited ACEs?