idnits 2.17.1 draft-ietf-webdav-acl-01.txt: -(489): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 6) being 69 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 83 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 1, 2000) is 8761 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: 'OPTIONAL' is mentioned on line 328, but not defined == Missing Reference: 'REQUIRED' is mentioned on line 341, but not defined == Missing Reference: 'WEBDAV' is mentioned on line 267, but not defined == Unused Reference: 'RFC2026' is defined on line 681, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Eric Sedlar, Oracle Corporation 2 draft-ietf-webdav-acl-01.txt Geoffrey Clemm, Rational Software 4 Expires November 1, 2000 May 1, 2000 6 Access Control Extensions to WebDAV 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 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. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document specifies a set of methods, headers, and resource-types 31 that define the WebDAV Access Control extensions to the HTTP/1.1 32 protocol. 34 Table of Contents 36 1 INTRODUCTION............................................3 37 1.1 Notational Conventions................................3 39 2 PRINCIPALS..............................................3 41 3 RIGHTS..................................................4 42 3.1 RIGHTS-DISCOVERY method...............................5 43 3.2 Rights defined by WebDAV..............................6 44 3.2.1 read Right........................................6 45 3.2.2 write Right.......................................6 46 3.2.3 readacl Right.....................................6 47 3.2.4 writeacl Right....................................6 48 3.2.5 all Right.........................................6 50 4 ACCESS CONTROL PROPERTIES...............................7 51 4.1 Example 1 - Retrieving Access Control information.....8 53 5 USING ACLS..............................................9 55 6 ACL METHOD.............................................10 56 6.1 Example 1 - Setting ACLs.............................10 58 7 ACL INHERITANCE / DEFAULT ACLS.........................11 60 8 XML SCHEMA FOR DEFINED ELEMENTS........................12 62 9 INTERNATIONALIZATION CONSIDERATIONS....................13 64 10 SECURITY CONSIDERATIONS..............................13 66 11 SCALABILITY..........................................13 68 12 AUTHENTICATION.......................................13 70 13 IANA CONSIDERATIONS..................................13 72 14 INTELLECTUAL PROPERTY................................13 74 15 ACKNOWLEDGEMENTS.....................................14 76 16 INDEX................................................14 78 17 REFERENCES...........................................14 80 18 AUTHORS' ADDRESSES...................................15 82 19 STILL TO DO :........................................15 83 1 INTRODUCTION 85 The underlying principle of access control is that who you are 86 determines how you can access a resource. The "who you are" is 87 defined by a "principal" identifier; users, client software, 88 servers, and groups of the previous have principal identifiers. 89 The "how" is determined by an "access control list" (ACL) 90 associated with a resource. An ACL contains a set of "access 91 control entries" (ACEs), where each ACE specifies a principal and 92 a set of rights that are either granted or denied to that 93 principal. 95 1.1 Notational Conventions 97 The augmented BNF used by this document to describe protocol 98 elements is described in Section 2.1 of [RFC2068]. Because this 99 augmented BNF uses the basic production rules provided in Section 100 2.2 of [RFC2068], those rules apply to this document as well. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 103 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in 105 [RFC2119]. 107 2 PRINCIPALS 109 A principal identifies an entity that can be given access rights 110 to HTTP resources. On many implementations, a user or a group 111 will be examples of principals, but other types of principals are 112 possible. For the most part, any classification or other 113 information about the entity identified by a principal is opaque 114 with respect to this specification, and is dependent on the 115 implementation. 117 Principals are manifested to clients as a HTTP resource, 118 identified by a URL. The set of properties exposed by that 119 resource are implementation dependent, although certain 120 properties are required by this specification. Those properties 121 include: 123 @ : A "live" property containing the 124 name used to authenticate this principal 125 (typically typed into a login prompt/dialog). 126 [OPTIONAL] 128 @ : A property containing a human-readable 129 description of this principal. This property 130 may be "live" and not settable via PROPPATCH. 131 [REQUIRED] 133 @ : A "live" property containing a 134 classification word for this principal. The 135 values and are 136 choices for value of this property 137 recommended by this spec. The presence of 138 this property can be used to distinguish it 139 as a principal from other resources on a 140 WebDAV server. (Note that 141 may not be used, as all collections must use 142 the value "collection" for , 143 which wouldn't distinguish normal collections 144 from principal collections.) [REQUIRED] 146 Server implementations may include any other descriptive 147 information for a principal via properties. 149 A principal resource may or may not be a collection. A 150 collection principal may only contain other principals (not other 151 types of resources). Servers that support aggregation of 152 principals (e.g. groups of users or other groups) MUST manifest 153 them as collection principals. The WebDAV methods for examining 154 maintaining collections (e.g. BIND, DELETE, PROPFIND) may be used 155 to maintain collection principals. Membership in a collection 156 principal is recusive, so a principal in a collection principal A 157 contained by collection principal B is a member of both 158 collection principals. Implementations not supporting recursive 159 membership in principal collections can return an error if the 160 client attempts to bind collection principals into other 161 collection principals. Using WebDAV methods to alter the content 162 of a principal (e.g. using PROPPATCH or PUT) is outside the scope 163 of this specification, and is not required, recommended, or 164 forbidden by this spec. 166 3 RIGHTS 168 A right controls access to a particular set of HTTP operations on 169 a resource. The set of rights that apply to a particular 170 resource may vary with the of the resource, as 171 well as between different server implementations. To promote 172 interoperability, however, WebDAV defines a set of well-known 173 rights (e.g. and ), which can at least be 174 used to set some context to the other rights defined on a 175 particular resource. 177 Rights may be aggregates of other rights. For example, one 178 implementation may split out a right controlling the ability to 179 BIND children into a collection from the right allowing a 180 resource to be removed from a collection. Since these rights 181 control the ability to write to a collection, these rights would 182 be aggregated by the right. The relationships 183 between atomic rights and aggregate rights can be discovered via 184 the RIGHTS-DISCOVERY HTTP method on a particular resource. 185 Servers may specify some rights as abstract, which means that it 186 may not appear in an ACL, but is described in the RIGHTS- 187 DISCOVERY method to aid in setting context. Server 188 implementations must return the same response to the RIGHTS- 189 DISCOVERY method on all of the resources with the same 190 value. 192 3.1 RIGHTS-DISCOVERY method 194 Rights discovery is a method with no arguments, that returns the 195 rights aggregation tree. Each right appears as an XML element, 196 where aggregate rights list all of their children as sub- 197 elements. Each right element can contain the following 198 attributes: 200 @ abstract (Boolean): "true" if this right cannot be used in 201 an ACL/ACE. Defaults to "false" 203 @ description (string): a human readable description of what 204 this right controls access to. Required. 206 For example, the following response might be generated to a 207 RIGHTS-DISCOVERY request on a WebDAV server implemented by a 208 relational database (where the resource in this case corresponds 209 to a table): 211 Request 212 RIGHTS-DISCOVERY /schemas/scott/emp HTTP/1.1 213 Host: www.foo.bar 214 Content-type: text/xml; charset="utf-8" 215 Content-Length: 0 217 Response 218 HTTP/1.1 200 Success 219 Content-Type: text/xml 220 Content-Length: xxxxx 222 223 224 225 226 227 228 229 230 231 232 233 235 236 238 It is envisioned that a WebDAV ACL-aware administrative client 239 would list the available in a dialog box, and allow the user to 240 choose non-abstract rights to apply in an ACE. The rights tree 241 is useful programmatically to map well-known rights (defined by 242 WebDAV or other standards groups) into rights that are supported 243 by any particular server implementation. 245 3.2 Rights defined by WebDAV 247 The rights defined by WebDAV access control MUST be present in 248 the response to the RIGHTS-DISCOVERY method, although they may be 249 abstract (and not usable within an ACE on a particular 250 implementation). 252 3.2.1read Right 254 Name: 256 Purpose: The read right provides and restricts access to 257 information regarding the state of the resource, including the 258 resource's properties. Affected methods include GET and PROPFIND. 259 The read right does not affect the OPTIONS method since it 260 reflects capabilities rather than state. 262 3.2.2write Right 264 Name: 266 Purpose: The right affects the same methods as 267 the Write Lock. Please refer to [WEBDAV] section 5.3 for the list 268 of affected methods. Note however, that a write lock is a 269 different mechanism than a write access change, although they 270 affect the same methods, they have independent methods to set 271 them and independent error codes. 273 3.2.3readacl Right 275 Name: 277 Purpose: The right provides and restricts 278 access to the property of this resource, rather than 279 the right. If a user has the right and not 280 the right, the property ONLY is accessible via 281 PROPFIND, and the GET method is not authorized. If a user has 282 the right and not the right, the 283 property will not be included in any PROPFIND requests on the 284 associated resource. 286 3.2.4writeacl Right 288 Name: 290 Purpose: The (Access Control ADMINistration) 291 right provides and restricts access to ACL method, which is the 292 only means of altering the (and indirectly, 293 ) property of a resource. 295 3.2.5all Right 297 Name: 298 Purpose: The right controls all other rights on 299 this resource. If the right appears in an ACE, it is 300 an error to have any other right in that ACE. This right is 301 merely shorthand for all of the rights enumerated in the RIGHTS- 302 DISCOVERY method, and should not control access to rights not 303 exposed via that route. 305 4 ACCESS CONTROL PROPERTIES 307 This specification defines a number of new properties for WebDAV 308 resources. Access control properties may be retrieved just like 309 other WebDAV properties, using the PROPFIND method. An HTTP 310 resource on a WebDAV ACL-compliant server MUST contain the 311 following properties: 313 @ : A property containing the principal 314 information identifying a particular user as 315 the owner of the resource. This property is 316 readable by anyone with read access to the 317 resource. There is no provision for a client 318 updating this property in this spec, however 319 it is recommended that any authenticated user 320 with appropriate administrative privileges be 321 allowed to issue a PROPPATCH to update its 322 value. Normally, an attempt to PROPPATCH this 323 property will result in a 401 (Not 324 Authorized) error. [REQUIRED] 326 @ : A "live" property containing a human- 327 readable description of the 328 [OPTIONAL] 330 @ : A "live" property containing the list of 331 rights of the currently authenticated HTTP 332 user. Read access to this property is 333 controlled by the right. This 334 property can NEVER be set directly. 335 [REQUIRED] 337 @ : A "live" property containing one or more 338 tags, which specify which 339 principals are to get access to what rights, 340 for the resource with this ACL property. 341 [REQUIRED] 343 The element (property) contains 0 or more of the 344 following XML elements: 346 @ : An access control entry, which specifies the 347 set of rights to be granted to a single 348 principal. 350 The element contains the following XML elements: 352 @ : Contains the set of XML elements 353 corresponding to the rights being granted via 354 this ACE. Must contain at least one right 356 @ : Contains the set of XML elements 357 corresponding to the rights being denied via 358 this ACE. Must contain at least one right, 359 if present. 361 @ : A URL of the principal resource this ACE 362 applies to, or one of the tags or 363 . Always present. The 364 value of this element must be unique within 365 an ACL. 367 @ : Contains properties of the principal 368 resource (made available here to avoid the 369 need for a separate PROPFIND request). 370 Optional. 372 A PROPFIND on a resource on a WebDAV ACL server might produce the 373 following XML output: 375 4.1 Example 1 - Retrieving Access Control information 377 Request 378 PROPFIND /top/container HTTP/1.1 379 Host: www.foo.bar 380 Content-type: text/xml; charset="utf-8" 381 Content-Length: 0 382 Depth: 0 384 385 386 387 389 Response 390 HTTP/1.1 200 Success 391 Content-Type: text/xml 392 Content-Length: xxxxx 394 395 397 398 399 1997-12-01T17:42:21-08:00 400 Example collection 401 402 XXXXX 404 http://www.rational.com/principals/users/gclemm 406 Geoffrey Clemm 407 408 409 410 411 412 413 414 http://www.foo.com/users/esedlar 415 416 417 User 418 esedlar 419 Eric Sedlar 420 421 422 423 424 425 426 http://www.foo.com/groups/marketing 427 428 429 Group 430 Foo.Com marketing 431 department 432 mktdept 433 434 435 436 437 438 439 440 441 443 5 USING ACLS 445 By default, a principal has no access rights to an object 446 protected by an ACL. A particular ACE may either grant or deny a 447 set of rights to a single principal. It is illegal for an ACL to 448 have two ACEs applying to the same principal. However, since a 449 server may match the currently authenticated HTTP user with 450 multiple principals, it is possible for multiple ACEs to apply to 451 the current user. In this case, if a particular right is denied 452 to the current user by any ACE, this supercedes any ACE that 453 might grant that right. This is the case regardless if a ("more 454 specific") ACE granting access applied to a principal identifying 455 the user directly, while the ACE denying access applied to a 456 collection principal containing that user. The particular order 457 of the ACEs within an ACL is irrelevant. The tag 458 can also contain the following special tags: , , 459 . These tags have the following meaning: 461 @ owner: The principal identified by the owner property on 462 this resource is granted or denied the rights specified in 463 this ACE. 465 @ all: The current user always matches this ACE, whether or 466 not s/he is authenticated. 468 @ unauthenticated: The current user matches this ACE if not 469 authenticated 471 Server implementations may limit the number of ACEs in an ACL. 472 However, ACL-compliant servers are required to support at least 473 one ACE granting rights to a single principal, and one ACE 474 granting rights to a collection principal. The server should 475 return an error "Too many ACEs" in this case. 477 6 ACL METHOD 479 The ACL Method provides a mechanism to set ACL information. Its 480 request body is used to define alterations to the ACL of the 481 resource identified by the request-URI. Its response body 482 contains the current ACL for that resource. The ACL method 483 replaces the and properties on the specified 484 resource with the properties in the request. All readable ACEs 485 previously stored in the ACL on the indicated resource are 486 removed, so an ACL method on a resource with an unreadable 487 property will be ignored. (If the server implements rights 488 outside of those defined in this specification, they might allow 489 only some ACEs to be visible�in this case, only part of the ACL 490 will be replaced). 492 Change requests through the ACL method MUST be atomic. If any 493 part of the change request fails then all changes MUST fail. The 494 presence of an empty ACL causes all ACEs in the ACL, including 495 ACEs for associated properties, to be deleted. An empty request 496 body will cause no change to the ACL or associated values. If 497 the element (specifying properties of the resource 498 identified by the ACE's ) is specified, it (and its 499 children) is ignored. 501 6.1 Example 1 - Setting ACLs 503 An ACL request body is an acl-info XML element. The element contains properties that can be set by the ACL 505 method (currently just ). 507 Request 508 ACL /top/container HTTP/1.1 509 Host: www.foo.com 510 Content-Type: text/xml 511 Content-Length: xxxx 512 514 515 516 517 518 519 http://www.foo.com/users/esedlar 520 521 522 523 524 525 http://www.foo.com/groups/marketing 526 527 528 529 531 Response 532 HTTP/1.1 200 Success 533 Content-Length: 0 535 This request changes the group ACE to disallow read access to the 536 ACL for the marketing group. The other information had to be 537 recopied from the ACL retrieved in the previous example. 539 7 ACL INHERITANCE / DEFAULT ACLS 541 To be added 542 8 XML SCHEMA FOR DEFINED ELEMENTS 544 545 546 548 554 555 556 558 561 562 563 564 566 568 569 570 571 572 573 574 576 577 579 581 582 583 584 585 586 587 588 589 590 591 592 593 595 597 598 599 601 602 603 605 606 608 609 610 611 612 613 614 615 617 9 INTERNATIONALIZATION CONSIDERATIONS 619 To be supplied. 621 10 SECURITY CONSIDERATIONS 623 To be supplied. 625 11 SCALABILITY 627 To be supplied. 629 12 AUTHENTICATION 631 Authentication mechanisms defined in WebDAV will also apply to 632 WebDAV ACL. 634 13 IANA CONSIDERATIONS 636 This document uses the namespace defined by [RFC2518] for XML 637 elements. All other IANA considerations mentioned in [RFC2518] 638 also applicable to WebDAV ACL. 640 14 INTELLECTUAL PROPERTY 642 The following notice is copied from RFC 2026, section 10.4, and 643 describes the position of the IETF concerning intellectual 644 property claims made against this document. 646 The IETF takes no position regarding the validity or scope of any 647 intellectual property or other rights that might be claimed to 648 pertain to the implementation or use other technology described 649 in this document or the extent to which any license under such 650 rights might or might not be available; neither does it represent 651 that it has made any effort to identify any such rights. 652 Information on the IETF's procedures with respect to rights in 653 standards-track and standards-related documentation can be found 654 in BCP-11. Copies of claims of rights made available for 655 publication and any assurances of licenses to be made available, 656 or the result of an attempt made to obtain a general license or 657 permission for the use of such proprietary rights by implementers 658 or users of this specification can be obtained from the IETF 659 Secretariat. 661 The IETF invites any interested party to bring to its attention 662 any copyrights, patents or patent applications, or other 663 proprietary rights that may cover technology that may be required 664 to practice this standard. Please address the information to the 665 IETF Executive Director. 667 15 ACKNOWLEDGEMENTS 669 This protocol is the collaborative product of the WebDAV ACL 670 design team: xxx, yyy, zzz. We would like to acknowledge the 671 foundation laid for us by the authors of the WebDAV and HTTP 672 protocols upon which this protocol is layered, and the invaluable 673 feedback from the WebDAV working group. 675 16 INDEX 677 To be supplied. 679 17 REFERENCES 681 [RFC2026] S.Bradner, "The Internet Standards Process", Harvard, 682 1996, . 684 [RFC2068] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and 685 T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 686 2068, U.C. Irvine, DEC, MIT/LCS, 1997, 687 . 689 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 690 Requirement Levels", Harvard, 1997, 691 . 693 [RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen, 694 "HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft, 695 U.C.Irvine, Netscape, Novell, 1999 696 . 698 18 AUTHORS' ADDRESSES 700 Eric Sedlar 701 Oracle Corporation 702 500 Oracle Parkway 703 Redwood Shores, CA 94065 704 Email: esedlar@us.oracle.com 706 Geoffrey Clemm 707 Rational Software 708 20 Maguire Road 709 Lexington, MA 710 Email: geoffrey.clemm@rational.com 712 19 STILL TO DO : 714 @ Describe the interactions with resource locking. I'm not 715 clear what the resolution was as far as locking the ACL 716 separately from locking the resource.