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?