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