idnits 2.17.1
draft-ietf-webdav-acl-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-03-29) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last 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 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 1
longer page, the longest (page 9) being 59 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** 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.)
== There are 2 instances of lines with non-RFC2606-compliant FQDNs in the
document.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 105: '... for a principal MUST be denied. Right...'
RFC 2119 keyword, line 116: '...cessed in order, MUST be used to resol...'
RFC 2119 keyword, line 120: '... specified by the child MUST override....'
RFC 2119 keyword, line 125: '... MUST override....'
RFC 2119 keyword, line 171: '...An inherited ACL MUST be applied to th...'
(22 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 22 has weird spacing: '...listing conta...'
-- 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 (November 10, 1997) is 9636 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? 'WEBDAV' on line 242 looks like a reference
-- Missing reference section? 'RFC2068' on line 639 looks like a reference
-- Missing reference section? 'WebDAV' on line 643 looks like a reference
-- Missing reference section? 'XML' on line 649 looks like a reference
Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 INTERNET-DRAFT P. J. Leach
2 Expires: April 1998 Y. Y. Goland
3 Standards Track Microsoft Corporation
4 WebDAV Working Group November 10, 1997
6 WebDAV ACL Protocol
7 draft-ietf-webdav-acl-00.txt
9 Status of this Memo
11 This document is an Internet-Draft. Internet-Drafts are working
12 documents of the Internet Engineering Task Force (IETF), its areas,
13 and its working groups. Note that other groups may also distribute
14 working documents as Internet-Drafts.
16 Internet-Drafts are draft documents valid for a maximum of six
17 months and may be updated, replaced, or obsoleted by other documents
18 at any time. It is inappropriate to use Internet-Drafts as
19 reference material or to cite them other than as "work in progress."
21 To learn the current status of any Internet-Draft, please check the
22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
23 Directories on ds.internic.net (US East Coast), nic.nordu.net
24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
25 Rim).
27 Abstract
29 This memo specifies the format and manipulation mechanisms for
30 access control lists (ACLs) for WebDAV objects.
32 Contents
34 Status of this Memo................................................1
35 Abstract...........................................................1
36 Contents...........................................................1
37 1. Introduction....................................................2
38 2. Principals Identifiers..........................................2
39 3. Granting and Denying Rights.....................................3
40 4. ACL Inheritance.................................................4
41 5. Properties and ACLs.............................................4
42 6. Rights Definitions..............................................5
43 7. Default Principal Types.........................................7
44 8. ACL Method......................................................7
45 9. Examples.......................................................11
46 10.Authors' Addresses.............................................13
47 11.Bibliography...................................................14
49 1. Introduction
51 The basic model for access control, informally expressed, is that
52 who you are determines how you can access a resource. The "who you
53 are" is defined by a principal identifier; users, client software,
54 servers and groups of the previous have principal identifiers. The
55 "how" is determined by an "access control list" (ACL) associated
56 with a resource.
58 An ACL contains Access Control Elements (ACE). An ACE specifies a
59 set of principals, a set of granted rights, and a set of denied
60 rights.
62 Rights may be generic, such as "read", "write", or "delete", or they
63 might be specific to the kind of resource protected by that ACL,
64 such as (perhaps) "send-to", "unsubscribe", and "administer" for
65 mailing lists.
67 When a resource is created it inherits a set of default ACL
68 properties from a designated resource, referred to as an ACL source.
69 The inheritance can be "static", so that subsequent changes to the
70 ACL source do not effect the new resources ACL properties; or it can
71 be "dynamic", so that subsequent changes are reflected in the new
72 resource's ACL properties.
74 Properties on a resource, by default, dynamically inherit from the
75 ACL on the resource. In other words, the resource is the ACL source
76 for the properties. However individual properties can be given their
77 own ACL.
79 2. Principals Identifiers
81 A principal identifier can identify a single principal or a compound
82 principal. A single principal identifier refers to a single
83 principal, such as a person or a program. A compound principal
84 identifier specifies one or more principals. A compound principal
85 may not necessarily just be a list of other principals. It may in
86 fact be a program that accepts a principal identifier as input and
87 output true or false to indicate membership.
89 This specification relies upon the underlying authentication
90 mechanism(s) to provide the syntax of principal identifiers. Thus,
91 for the purposes of this specification, principal identifiers are
92 opaque.
94 3. Granting and Denying Rights
96 An ACL can both grant and deny rights. The reason both types of
97 grants are required is because of compound principals.
99 The consequence of the existence of compound principals is that
100 there are times when a compound principal may be granted a right but
101 a particular member of the compound principal may need to be denied
102 access. In order to make this possible an ACL must be able to list
103 principals both allowed and denied a right.
105 By default all rights for a principal MUST be denied. Rights MAY
106 only be granted to a principal by an explicit listing of that
107 principal in a "grant" section of an ACL.
109 Additionally it is possible for access rights to collide in scope.
110 For example, a container may have an access right which specifies
111 the ability of principals to delete the children of that container.
112 This would affect a principal's ability to use the DELETE method.
113 However a particular internal child may have granted access rights
114 to DELETE. As such, the two rights could collide.
116 The following rules, processed in order, MUST be used to resolve
117 scope conflicts between rights.
119 1) In a conflict between a right granted by a parent and a right
120 granted by a child, the right specified by the child MUST override.
122 2) In a conflict between a right granted or denied to a compound
123 principal and a right granted or denied to a member of the compound
124 principal, the reference to the member of the compound principal
125 MUST override.
127 Note that rule 2 is conceptually identical to rule 1. The concept
128 represented by rules 1 and 2, stated generally, is that a specific
129 references always overrides a more general reference.
131 3.1. Examples
133 The following examples demonstrate a situation where the specified
134 conflict resolution rule would be applied.
136 3.1.1. Rule 1
138 A resource specifies that principal A is granted the right to delete
139 the resource. A property on the resource specifies that principal A
140 is denied the right to delete the property. The conflict is resolved
141 by rule 1, the resource is the parent and the property is the child.
142 As such the child's declaration overrides and principal A is denied
143 the right to delete the resource.
145 Note, however, that if other properties do not deny principal A the
146 right to delete them then principal A could delete all properties
147 but the one mentioned above and could PUT an empty body to the
148 resource. However it could not successfully execute a DELETE on the
149 resource, as this would have the effect of deleting the property
150 along with the resource.
152 3.1.2. Rule 2
154 A resource specifies that principal A is denied the read right. The
155 same resource also specifies that principal B is granted the read
156 right. Principal A, however, is a compound principal of which
157 Principal B is a member. Rule 1 does not apply because the rights in
158 question are defined on the same resource. The conflict is resolved
159 by rule 2 as the conflict is between a compound principal and one of
160 its members. In that case principal B has the right to read the
161 resource.
163 4. ACL Inheritance
165 When a new resource is created it may inherit its ACL from its
166 containing resource. If no inheritance method is specified then the
167 resource has no ACL. Note, however, that the owner value is
168 automatically set when a resource is created, so even without
169 inheritance, there will always be an owner.
171 An inherited ACL MUST be applied to the resource before it is
172 available for manipulation. Thus, if inheritance is used, the
173 resource will never be in a state where it does not have access
174 control protection.
176 Inheritance can either be static or dynamic.
178 Static inheritance means that the ACL specified by the parent will
179 be used to define the ACL for the child. Any subsequent changes made
180 to the parent will not cause the child's ACL to be altered.
182 Dynamic inheritance means that the ACL specified by the parent is
183 used to define the ACL for the child but any changes on the parent's
184 ACL MUST automatically be made to any inheriting children. The child
185 is still allowed to define its own ACL values that MUST override any
186 conflicting inherited ACL.
188 5. Properties and ACLs
190 Properties MAY have their own ACL independent of the associated
191 resource. By default a property's ACL MUST be dynamically inherited
192 from the associated resource. Note that properties can only inherit
193 from their associated resource.
195 It is legal for a property to carry a setting for what sort of
196 inheritance its children will have. Currently this value has no
197 meaning as properties can not have children, but it is expected in
198 the future that hierarchical properties will be adopted, so this
199 setting will then have meaning. For now compliant resources MUST
200 record this value but do not have to do anything with it.
202 For purposes of applying scoping conflict resolution rules the
203 resource is the parent and the property is the child.
205 Compliant resources are not required to support setting ACLs
206 directly on properties.
208 6. Rights Definitions
210 The following define a variety of rights. A compliant resource MUST
211 support all of the rights contained herein.
213 6.1. all Right
215 Name: all
216 Namespace: http://www.ietf.org/standards/acl/
217 Purpose: The all right provides all rights.
218 Values: None
219 Description: In a conflict between the "all" right and other
220 rights, the "all" right is considered a parent and the other rights
221 a "child." Thus one ACE could provide the ALL right for a particular
222 principal but another ACE in the same ACL could deny the same
223 principal a particular right. The conflict would be resolved by
224 denying the specified principal the more specific right.
226 6.2. read Right
228 Name: read
229 Namespace: http://www.ietf.org/standards/acl/
230 Purpose: The read right provides and restricts access to
231 information regarding the state of the resource, including the
232 resource's properties. Effected methods are GET, INDEX, and
233 PROPFIND. OPTIONS is not covered by a Read ACL as it reflects
234 capabilities rather than state.
235 Values: None
237 6.3. write Right
239 Name: write
240 Namespace: http://www.ietf.org/standards/acl/
241 Purpose: The Write right affects the same methods as the
242 Write Lock. Please refer to [WEBDAV] section 5.3 for the list of
243 affected methods. Note however, that a write lock is a different
244 mechanism than a write access change, although they affect the same
245 methods, they have independent methods to set them and independent
246 error codes.
247 Values: None
249 6.4. delete Right
251 Name: delete
252 Namespace: http://www.ietf.org/standards/acl/
253 Purpose: The delete right controls access to the DELETE
254 method. This method does not affect the ability to remove
255 properties.
256 Values: None
258 6.5. createchild Right
260 Name: createchild
261 Namespace: http://www.ietf.org/standards/acl/
262 Purpose: This right controls the ability to PUT internal
263 members of a collection and ADDREF external members of a collection.
264 This ACL has no affect if set on non-collections.
265 Values: None
267 6.6. deletechild Right
269 Name: deletechild
270 Namespace: http://www.ietf.org/standards/acl/
271 Purpose: The deletechild right controls the ability to the
272 DELETE internal members of a collection and DELREF external members
273 of a collection. This ACL has no affect if set on non-collections.
274 Values: None
276 6.7. writeowner Right
278 Name: writeowner
279 Namespace: http://www.ietf.org/standards/acl/
280 Purpose: The writeowner right controls the ability to change
281 the value of the owner right.
282 Values: None
284 6.8. readacl Right
286 Name: readacl
287 Namespace: http://www.ietf.org/standards/acl/
288 Purpose: The readacl right controls the ability to read the
289 ACL property.
290 Values: None
292 6.9. writeacl Right
294 Name: writeacl
295 Namespace: http://www.ietf.org/standards/acl/
296 Purpose: The writeacl right controls the ability to alter
297 the ACL property.
298 Values: None
300 7. Default Principal Types
302 The following two XML elements are defined principal types.
304 7.1. allprincipals XML Element
306 Name: allprincipals
307 Namespace: http://www.ietf.org/standards/acl/
308 Purpose: The allprincipals XML element represents all
309 principals. It is used to specify rights belonging to all
310 principals, regardless of authentication.
311 Values: None
313 7.2. allauthprincipals XML Element
315 Name: allauthprincipals
316 Namespace: http://www.ietf.org/standards/acl/
317 Purpose: The allauthprincipals XML element represents all
318 authenticated principals. It is used to specify rights belonging to
319 all authenticated principals.
320 Values: None
322 8. ACL Method
324 The ACL Method serves two distinct purposes. Its request body is
325 used to define alterations to the ACL of the resource and its
326 properties. The response contains the ACL for the associated
327 resource and its properties.
329 The Request-URI of the ACL method identifies the resource whose ACL
330 information is to be retrieved and possibly altered.
332 Change requests through the ACL method MUST be atomic, additionally
333 changes are all or nothing. If any part of the change request fails
334 then all changes MUST fail.
336 8.1. Request
338 The request may contain up to four XML elements, owner,
339 aclinheritance, and ACL. The presence of an element, except as
340 otherwise specified, in the request body causes the associated value
341 to change.
343 The presence of an empty ACL causes all ACEs in the ACL, including
344 ACEs for associated properties, to be deleted.
346 If an ACE is specified in a request it completely replaces the ACE
347 currently use for the same principal, if it exists. If an ACE is
348 submitted with empty grant and deny lists then the ACE is deleted.
349 It is a syntax error for two ACEs to reference the same principal.
350 Additionally, although an ACE can be submitted which references
351 multiple principals, this is primarily a convenience feature.
353 Strictly speaking, what the user has done is specify an ACE for
354 every principal specified. The same logic applies to results that
355 aggregate principals into a single ACE.
357 It is illegal to delete any value, ACE, owner, aclinheritance, etc.
358 with a redundant value. For example, if one ACE grants all
359 principals read rights and another ACE grants a single principal
360 read rights, both ACEs MUST be maintained. The reason being that in
361 the future all principals may have their read rights removed but the
362 single principal will retain the read right because the more
363 specific ACE will override the more general ACE. Additionally if the
364 currently inherited value of owner is "someuser" and the principal
365 explicitly requests that the owner by set to "someuser", the
366 information MUST be recorded on the resource. That way if owner on
367 the source ACL is changed, the proper value as requested by the
368 client will remain on the inheriting ACL.
370 An empty request body will cause no change to the ACL or associated
371 values.
373 8.2. Response
375 If the request body was empty or if the changes were successful a
376 200 Success response MUST be returned with a response body
377 containing the owner, aclinheritance, and the acl XML elements with
378 values for all properties.
380 [Ed Note - I am not dealing with error conditions yet as the error
381 reporting format is going to have to be pretty complex and I want to
382 get buy off on the ACL model and the request format before I write
383 up a couple of pages on how to do errors for that format.]
385 8.3. acl XML element
387 Name: acl
388 Namespace: http://www.ietf.org/standards/acl/
389 Purpose: Defines an ACL.
390 Parent: Any
391 Values= (inheritance [owner] [aclinheritance] *ACE
392 *property)
393 Description: An empty ACL element will delete all ACEs contained
394 in an ACL, including the ACEs of any properties. Note, however, that
395 there MUST always be an ACL value defined on a resource, even if it
396 is empty.
398 8.4. owner XML Element
400 Name: owner
401 Namespace: http://www.ietf.org/standards/acl/
402 Purpose: Specifies the owner of the resource.
403 Parent= acl
405 Values= Principal
406 Description: The owner XML element specifies the principal who
407 owns the resource. The default value for owner MUST be the principal
408 who created the resource. The owner always retains the right to
409 alter the ACL. So, for example, an owner who was not granted the
410 right to read the resource could not read the resource. However the
411 owner could alter the ACL so as to grant the read right to
412 themselves. A principal MUST have the writeowner right to change the
413 owner property's value. An empty Owner element submitted in a
414 request will not cause a change in the Onwer value. Owner MUST
415 always have a value. All compliant resources MUST support the owner
416 value.
418 8.5. aclinheritance XML Element
420 Name: aclinheritance
421 Namespace: http://www.ietf.org/standards/acl/
422 Parent= acl
423 Purpose: The aclinheritance XML element identifies the type
424 of inheritance to be used with children of the associated resource.
425 The AclInheritance value MUST default to Dynamic. An empty
426 AclInheritance submitted in a request will not cause a change in the
427 AclInheritance value. This element has no meaning on non-
428 collections. However, collections MUST provide this property.
429 Values= ("Dynamic" | "Static" | "None" | Extension)
430 ;Extension is defined, somewhere in DAV. URL is defined, someplace,
431 somewhere.
432 Description: Although this element has no meaning when defined
433 on a property, resources MUST record its value.
435 8.6. inheritance XML Element
437 Name: inheritance
438 Namespace: http://www.ietf.org/standards/acl/
439 Purpose: Defines the inheritance used for a particular ACL.
440 Parent: acl
441 Values= ("Dynamic" | "None" | Extension)
442 Description: Specifies if the ACL is inheriting its value
443 dynamically or not at all. Static is not an option since static
444 inheritance can only occur when the ACL was created and so was
445 controlled by the ACL source.
447 8.7. principal XML Element
449 Name: principal
450 Namespace: http://www.ietf.org/standards/acl/
451 Purpose: To identify a principal.
452 Parent: any
453 Values= *cdata
455 8.8. ace XML Element
457 Name: ace
458 Namespace: http://www.ietf.org/standards/acl/
459 Purpose: Contains access right information associated with
460 one or more principals.
461 Parent: acl
462 Values= Principal Allow Deny
463 Description: A principal MUST NOT be directly referred to in
464 more than one ACE on a resource. That is, each principal has a
465 particular ACE which specifies all of its directly granted rights.
466 Thus specifying two ACEs which directly reference the same principal
467 in a request is a syntax error.
469 8.9. grant XML Element
471 Name: grant
472 Namespace: http://www.ietf.org/standards/acl/
473 Purpose: Identifies the rights the associated principals are
474 granted.
475 Parent: ACE
476 Values: Right Identifiers
478 8.10. deny XML Element
480 Name: deny
481 Namespace: http://www.ietf.org/standards/acl/
482 Purpose: Identifies the rights the associated principals are
483 denied.
484 Parent: ACE
485 Values: Right Identifiers
487 8.11. property XML Element
489 Name: property
490 Namespace: http://www.ietf.org/standards/acl/
491 Purpose: Provides ACL for properties.
492 Parent: ACL
493 Values= Prop ACL
494 Description: The properties in the Prop XML element MUST be
495 empty.
497 9. Examples
499 9.1. Example 1 - Retrieving ACL information
501 ACL /top/container/ HTTP/1.1
502 Host: www.foo.bar
503 Content-Length: xxxx
504 Content-Type: text/xml
506 HTTP/1.1 200 Success
507 Content-Type: text/xml
508 Content-Length: xxxxx
510
511
512
513 dynamic
514 someonesomewhere
515
516 domain/joebob
517
518
519
520
521
522
523 dynamic
524 blah
525
526 domain/joebob
527
528
529
530
531
532
533
534
538
539
540 dynamic
541
542
543
545 The request was empty so no changes will be made, rather the
546 response will just contain all the relevant values. The resource
547 gets its own ACL dynamically from its parent, top. However this
548 resource does override the inherited ACL. Specifically, it defines
549 its owner, someonesomewhere, rather than inheriting it. However, the
550 absence of an aclinheritance element indicates that the resource
551 inherits that value. Additional the principal domain/joebob is
552 denied all rights. So regardless of what rights domain/joebob may
553 have been granted in top's ACL, all those rights are denied in
554 relation to top/container. While the ACL for creationdate is also
555 inherited it has its own owner, blah, and has an additional ACE for
556 joebob. All the rest of the properties have their ACLs inherited
557 from the resource. Therefore the denial of all rights to
558 domain/joebob would also apply to the resource's properties but
559 creationdate..
561 9.2. Example 2 - Setting ACLs
563 ACL /top/container.html HTTP/1.1
564 Host: www.foo.com
565 Content-Type: text/xml
566 Content-Length: xxxx
568
569
570
571
572 none
573
574
575
576
577
578 domain/joebob
579
580
581
582
583
584 HTTP/1.1 200 Success
585 Content-Type: text/xml
586 Content-Length: xxxxx
588
589
590
591 dynamic
592 someonesomewhere
593 none
594
595 domain/joebob
596
597
598
599
600
601
602 dynamic
603 blah
604
605
606
607
608
612
613
614 dynamic
615
616
617
619 This example assumes the state left from example 1. In the request
620 the user asks that the aclinheritance value be set to none and that
621 the ACE on the property creationdate for the principal domain/joebob
622 be removed. Even if the inherited aclinheritance value is none, the
623 resource MUST still record the redundant value as the value on the
624 source ACL may change.
626 10. Authors' Addresses
628 Paul J. Leach
629 Yaron Y. Goland
630 Microsoft
631 1 Microsoft Way
632 Redmond, WA 98052
633 Phone: (425)936-4765
635 Email: {paulle, yarong}@microsoft.com
637 11. Bibliography
639 [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-
640 Lee, 'Hypertext Transfer Protocol -- HTTP/1.1', RFC 2068, January
641 1997,
643 [WebDAV] Y. Goland, E. J. Whitehead, Jr., Asad Faizi, Stephen R.
644 Carter, Del Jensen 'Extensions for Distributed Authoring and
645 Versioning on the World Wide Web -- WEBDAV', October 1997, WORK
646 IN PROGRESS,
649 [XML] W3C, 'Extensible Markup Language - Part1. Syntax', March 1997
650