[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 3744

    INTERNET-DRAFT                   Eric Sedlar, Oracle Corporation
    draft-ietf-webdav-acl-01.txt   Geoffrey Clemm, Rational Software
    Expires November 1, 2000         May 1, 2000
                     Access Control Extensions to WebDAV
    Status of this Memo
    This document is an Internet-Draft and is in full conformance with all
    provisions of Section 10 of RFC2026.
    Internet-Drafts are working documents of the Internet Engineering Task
    Force (IETF), its areas, and its working groups. Note that other
    groups may also distribute working documents as Internet-Drafts.
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time. It is inappropriate to use Internet- Drafts as reference
    material or to cite them other than as "work in progress."
    The list of current Internet-Drafts can be accessed at
    The list of Internet-Draft Shadow Directories can be accessed at
    This document specifies a set of methods, headers, and resource-types
    that define the WebDAV Access Control extensions to the HTTP/1.1
    Sedlar, Clemm                                       [Page 1]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
    Table of Contents
    1 INTRODUCTION............................................3
    1.1 Notational Conventions................................3
    2 PRINCIPALS..............................................3
    3 RIGHTS..................................................4
    3.1 RIGHTS-DISCOVERY method...............................5
    3.2 Rights defined by WebDAV..............................6
     3.2.1 read Right........................................6
     3.2.2 write Right.......................................6
     3.2.3 readacl Right.....................................6
     3.2.4 writeacl Right....................................6
     3.2.5 all Right.........................................6
    4 ACCESS CONTROL PROPERTIES...............................7
    4.1 Example 1 - Retrieving Access Control information.....8
    5 USING ACLS..............................................9
    6 ACL METHOD.............................................10
    6.1 Example 1 - Setting ACLs.............................10
    7 ACL INHERITANCE / DEFAULT ACLS.........................11
    8 XML SCHEMA FOR DEFINED ELEMENTS........................12
    10  SECURITY CONSIDERATIONS..............................13
    11  SCALABILITY..........................................13
    12  AUTHENTICATION.......................................13
    13  IANA CONSIDERATIONS..................................13
    14  INTELLECTUAL PROPERTY................................13
    15  ACKNOWLEDGEMENTS.....................................14
    16  INDEX................................................14
    17  REFERENCES...........................................14
    18  AUTHORS' ADDRESSES...................................15
    19  STILL TO DO :........................................15
    Sedlar, Clemm                                       [Page 2]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
         The underlying principle of access control is that who you are
         determines how you can access a resource. The "who you are" is
         defined by a "principal" identifier; users, client software,
         servers, and groups of the previous have principal identifiers.
         The "how" is determined by an "access control list" (ACL)
         associated with a resource.  An ACL contains a set of "access
         control entries" (ACEs), where each ACE specifies a principal and
         a set of rights that are either granted or denied to that
    1.1 Notational Conventions
         The augmented BNF used by this document to describe protocol
         elements is described in Section 2.1 of [RFC2068]. Because this
         augmented BNF uses the basic production rules provided in Section
         2.2 of [RFC2068], those rules apply to this document as well.
         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
         NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
         "OPTIONAL" in this document are to be interpreted as described in
         A principal identifies an entity that can be given access rights
         to HTTP resources.  On many implementations, a user or a group
         will be examples of principals, but other types of principals are
         possible.  For the most part, any classification or other
         information about the entity identified by a principal is opaque
         with respect to this specification, and is dependent on the
         Principals are manifested to clients as a HTTP resource,
         identified by a URL.  The set of properties exposed by that
         resource are implementation dependent, although certain
         properties are required by this specification.  Those properties
           @ <dav:principalname>:     A "live" property containing the
                             name used to authenticate this principal
                             (typically typed into a login prompt/dialog).
           @ <dav:displayname>:  A property containing a human-readable
                             description of this principal.  This property
                             may be "live" and not settable via PROPPATCH.
           @ <dav:principal-type>:    A "live" property containing a
                             classification word for this principal.  The
                             values <dav:user/> and <dav:group/> are
                             choices for value of this property
                             recommended by this spec. The presence of
    Sedlar, Clemm                                       [Page 3]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
                             this property can be used to distinguish it
                             as a principal from other resources on a
                             WebDAV server.  (Note that <dav:resourcetype>
                             may not be used, as all collections must use
                             the value "collection" for <resourcetype>,
                             which wouldn't distinguish normal collections
                             from principal collections.) [REQUIRED]
         Server implementations may include any other descriptive
         information for a principal via properties.
         A principal resource may or may not be a collection.  A
         collection principal may only contain other principals (not other
         types of resources).  Servers that support aggregation of
         principals (e.g. groups of users or other groups) MUST manifest
         them as collection principals.  The WebDAV methods for examining
         maintaining collections (e.g. BIND, DELETE, PROPFIND) may be used
         to maintain collection principals.  Membership in a collection
         principal is recusive, so a principal in a collection principal A
         contained by collection principal B is a member of both
         collection principals.  Implementations not supporting recursive
         membership in principal collections can return an error if the
         client attempts to bind collection principals into other
         collection principals.  Using WebDAV methods to alter the content
         of a principal (e.g. using PROPPATCH or PUT) is outside the scope
         of this specification, and is not required, recommended, or
         forbidden by this spec.
    3  RIGHTS
         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
         BIND children into 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 RIGHTS-DISCOVERY HTTP method on a particular resource.
         Servers may specify some rights as abstract, which means that it
         may not appear in an ACL, but is described in the RIGHTS-
         DISCOVERY method to aid in setting context.  Server
         implementations must return the same response to the RIGHTS-
         DISCOVERY method on all of the resources with the same
         <dav:resourcetype> value.
    Sedlar, Clemm                                       [Page 4]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
    3.1 RIGHTS-DISCOVERY method
         Rights discovery is a method with no arguments, that returns the
         rights aggregation tree.  Each right appears as an XML element,
         where aggregate rights list all of their children as sub-
         elements.  Each right element can contain the following
           @ abstract (Boolean):  "true" if this right cannot be used in
              an ACL/ACE.  Defaults to "false"
           @ description (string):  a human readable description of what
              this right controls access to.  Required.
         For example, the following response might be generated to a
         RIGHTS-DISCOVERY request on a WebDAV server implemented by a
         relational database (where the resource in this case corresponds
         to a table):
         RIGHTS-DISCOVERY /schemas/scott/emp HTTP/1.1
         Host: www.foo.bar
         Content-type: text/xml; charset="utf-8"
         Content-Length: 0
         HTTP/1.1 200 Success
         Content-Type: text/xml
         Content-Length: xxxxx
         <?xml version="1.0" encoding="utf-8" ?>
         <?namespace href = "http://www.oracle.com/webdav/ AS = ORA"?>
           <D:all abstract=true description="All access">
             <D:write abstract=true description="Write any database row">
               <ORA:insert abstract=false description="Insert a row"/>
               <ORA:update abstract=false description="Update a row"/>
               <ORA:delete abstract=false description="Delete a row"/>
             <D:read abstract=false description="SELECT data from a row"/>
             <D:readacl abstract=false description="Read the ACL"/>
             <D:acadmin abstract=false description="Update the ACL and
            It is envisioned that a WebDAV ACL-aware administrative client
         would list the available in a dialog box, and allow the user to
         choose non-abstract rights to apply in an ACE.  The rights tree
         is useful programmatically to map well-known rights (defined by
         WebDAV or other standards groups) into rights that are supported
         by any particular server implementation.
    Sedlar, Clemm                                       [Page 5]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
    3.2 Rights defined by WebDAV
         The rights defined by WebDAV access control MUST be present in
         the response to the RIGHTS-DISCOVERY method, although they may be
         abstract (and not usable within an ACE on a particular
    3.2.1read Right
         Name:            <dav:read>
         Purpose:         The read right provides and restricts access to
         information regarding the state of the resource, including the
         resource's properties. Affected methods include GET and PROPFIND.
         The read right does not affect the OPTIONS method since it
         reflects capabilities rather than state.
    3.2.2write Right
         Name:            <dav:write>
         Purpose:         The <write> right affects the same methods as
         the Write Lock. Please refer to [WEBDAV] section 5.3 for the list
         of affected methods. Note however, that a write lock is a
         different mechanism than a write access change, although they
         affect the same methods, they have independent methods to set
         them and independent error codes.
    3.2.3readacl Right
         Name:            <dav:readacl>
         Purpose:         The <readacl> right provides and restricts
         access to the <dav:acl> property of this resource, rather than
         the <dav:read> right.  If a user has the <readacl> right and not
         the <read> right, the <dav:acl> property ONLY is accessible via
         PROPFIND, and the GET method is not authorized.  If a user has
         the <read> right and not the <readacl> right, the <dav:acl>
         property will not be included in any PROPFIND requests on the
         associated resource.
    3.2.4writeacl Right
         Name:            <dav:writeacl>
         Purpose:         The <writeacl> (Access Control ADMINistration)
         right provides and restricts access to ACL method, which is the
         only means of altering the <dav:acl> (and indirectly,
         <dav:rights>) property of a resource.
    3.2.5all Right
         Name:            <dav:all>
    Sedlar, Clemm                                       [Page 6]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
         Purpose:         The <dav:all> right controls all other rights on
         this resource.  If the <dav:all> right appears in an ACE, it is
         an error to have any other right in that ACE.  This right is
         merely shorthand for all of the rights enumerated in the RIGHTS-
         DISCOVERY method, and should not control access to rights not
         exposed via that route.
         This specification defines a number of new properties for WebDAV
         resources.  Access control properties may be retrieved just like
         other WebDAV properties, using the PROPFIND method.  An HTTP
         resource on a WebDAV ACL-compliant server MUST contain the
         following properties:
           @ <dav:owner>:   A property containing the principal
                             information identifying a particular user as
                             the owner of the resource.  This property is
                             readable by anyone with read access to the
                             resource.  There is no provision for a client
                             updating this property in this spec, however
                             it is recommended that any authenticated user
                             with appropriate administrative privileges be
                             allowed to issue a PROPPATCH to update its
                             value. Normally, an attempt to PROPPATCH this
                             property will result in a 401 (Not
                             Authorized) error.  [REQUIRED]
           @ <dav:owner-name>:   A "live" property containing a human-
                             readable description of the <dav:owner>
           @ <dav:rights>:  A "live" property containing the list of
                             rights of the currently authenticated HTTP
                             user.  Read access to this property is
                             controlled by the <read> right.  This
                             property can NEVER be set directly.
           @ <dav:acl>:     A "live" property containing one or more
                             <dav:ace> tags, which specify which
                             principals are to get access to what rights,
                             for the resource with this ACL property.
         The <dav:acl> element (property) contains 0 or more of the
         following XML elements:
           @ <dav:ace>:     An access control entry, which specifies the
                             set of rights to be granted to a single
         The <dav:ace> element contains the following XML elements:
    Sedlar, Clemm                                       [Page 7]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
           @ <dav:grant>:   Contains the set of XML elements
                             corresponding to the rights being granted via
                             this ACE.  Must contain at least one right
           @ <dav:deny>:    Contains the set of XML elements
                             corresponding to the rights being denied via
                             this ACE.  Must contain at least one right,
                             if present.
           @ <dav:principal-id>: A URL of the principal resource this ACE
                             applies to, or one of the tags <dav:owner> or
                             <dav:all-principals>.  Always present.  The
                             value of this element must be unique within
                             an ACL.
           @ <dav:principal>:    Contains properties of the principal
                             resource (made available here to avoid the
                             need for a separate PROPFIND request).
         A PROPFIND on a resource on a WebDAV ACL server might produce the
         following XML output:
    4.1 Example 1 - Retrieving Access Control information
         PROPFIND /top/container HTTP/1.1
         Host: www.foo.bar
         Content-type: text/xml; charset="utf-8"
         Content-Length: 0
         Depth: 0
         <?xml version="1.0">
         <D:propfind xmlns:D="DAV:">
         HTTP/1.1 200 Success
         Content-Type: text/xml
         Content-Length: xxxxx
         <?xml version="1.0" encoding="utf-8" ?>
         <?namespace href = "http://www.ietf.org/standards/webdav/ AS =
             <D:displayname>Example collection</D:displayname>
             <D:supportedlock> XXXXX</D:supportedlock>
             <D:owner-name>Geoffrey Clemm</d:owner-name>
    Sedlar, Clemm                                       [Page 8]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
                    <D:displayname>Eric Sedlar</D:displayname>
                    <D:displayname>Foo.Com marketing
         By default, a principal has no access rights to an object
         protected by an ACL. A particular ACE may either grant or deny a
         set of rights to a single principal.  It is illegal for an ACL to
         have two ACEs applying to the same principal.  However, since a
         server may match the currently authenticated HTTP user with
         multiple principals, it is possible for multiple ACEs to apply to
         the current user.  In this case, if a particular right is denied
         to the current user by any ACE, this supercedes any ACE that
         might grant that right.  This is the case regardless if a ("more
         specific") ACE granting access applied to a principal identifying
         the user directly, while the ACE denying access applied to a
         collection principal containing that user.  The particular order
         of the ACEs within an ACL is irrelevant.  The <principal-id> tag
         can also contain the following special tags: <owner>, <all>,
         <unauthenticated>.  These tags have the following meaning:
    Sedlar, Clemm                                       [Page 9]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
           @ owner:  The principal identified by the owner property on
              this resource is granted or denied the rights specified in
              this ACE.
           @ all:  The current user always matches this ACE, whether or
              not s/he is authenticated.
           @ unauthenticated:  The current user matches this ACE if not
         Server implementations may limit the number of ACEs in an ACL.
         However, ACL-compliant servers are required to support at least
         one ACE granting rights to a single principal, and one ACE
         granting rights to a collection principal.  The server should
         return an error "Too many ACEs" in this case.
         The ACL Method provides a mechanism to set ACL information. Its
         request body is used to define alterations to the ACL of the
         resource identified by the request-URI. Its response body
         contains the current ACL for that resource.  The ACL method
         replaces the <acl> and <owner> properties on the specified
         resource with the properties in the request.  All readable ACEs
         previously stored in the ACL on the indicated resource are
         removed, so an ACL method on a resource with an unreadable <acl>
         property will be ignored.  (If the server implements rights
         outside of those defined in this specification, they might allow
         only some ACEs to be visibleĆ¹in this case, only part of the ACL
         will be replaced).
         Change requests through the ACL method MUST be atomic. If any
         part of the change request fails then all changes MUST fail.  The
         presence of an empty ACL causes all ACEs in the ACL, including
         ACEs for associated properties, to be deleted.  An empty request
         body will cause no change to the ACL or associated values.  If
         the <principal> element (specifying properties of the resource
         identified by the ACE's <principal-id>) is specified, it (and its
         children) is ignored.
    6.1 Example 1 - Setting ACLs
         An ACL request body is an acl-info XML element.  The <dav:acl-
         info> element contains properties that can be set by the ACL
         method (currently just <acl>).
         ACL /top/container HTTP/1.1
         Host: www.foo.com
         Content-Type: text/xml
         Content-Length: xxxx
         <?namespace href = "http://www.ietf.org/standards/webdav/ AS =
    Sedlar, Clemm                                      [Page 10]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
                  <D:grant><D:read/> </D:grant>
         HTTP/1.1 200 Success
         Content-Length: 0
         This request changes the group ACE to disallow read access to the
         ACL for the marketing group. The other information had to be
         recopied from the ACL retrieved in the previous example.
         To be added
    Sedlar, Clemm                                      [Page 11]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
           <?xml version='1.0'?>
           <!-- XML Schema for WebDAV ACLs -->
           <!DOCTYPE schema PUBLIC "-//IETF//DTD WEBDAVACL 20000420//EN"
           "WebDAVACL.dtd" >
           <schema xmlns="http://www.w3.org/1999/XMLSchema"
                   blockDefault="#all" elementFormDefault="qualified">
           <element name="right" abstract="true">
             <complexType content="empty">
           <!--For those folks not familiar with XML Schema, minOccurs
                defaults to 0, and maxOccurs defaults to 1 -->
           <element name="dav:read" base="right" equivClass="right"/>
           <element name="dav:write" base="right" equivClass="right"/>
           <element name="dav:readacl" base="right" equivClass="right"/>
           <element name="dav:writeacl" base="right"
           <element name="dav:all" base="right" equivClass="right"/>
           <complexType name="dav:rights-list">
             <choice minOccurs="1" maxOccurs="unbounded">
             <element ref="dav:right">
             <element name="dav:unauthenticated" content="empty"/>
             <element name="dav:all" content="empty"/>
             <element name="dav:owner" content="empty"/>
           <complexType name="dav:ace">
             <element name="dav:grant" type="dav:rights-list"
                      minOccurs="0" maxOccurs="1">
             <element name="dav:deny" type="dav:rights-list"
                      minOccurs="0" maxOccurs="1">
             <element name="dav:principal-id" minOccurs="1"/>
                 <choice minOccurs="1">
                   <element name="dav:owner" content="empty"/>
                   <element name="dav:all" content="empty"/>
                   <element name="dav:unauthenticated" content="empty"/>
                   <element name="dav:href" type="uri"/>
             <element name="dav:principal" minOccurs="0" maxOccurs="1">
                 <element name="dav:principal-name" type="string"
    Sedlar, Clemm                                      [Page 12]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
                 <element name="dav:principal-type" type="string"
           <element name="dav:acl">
               <element name="dav:ace" type="dav:ace"
                      minOccurs="0" maxOccurs="unbounded"/>
           <element name="dav:rights">
               <choice minOccurs="1" maxOccurs="unbounded">
                 <element ref="dav:right"/>
         To be supplied.
         To be supplied.
         To be supplied.
         Authentication mechanisms defined in WebDAV will also apply to
         WebDAV ACL.
         This document uses the namespace defined by [RFC2518] for XML
         elements.  All other IANA considerations mentioned in [RFC2518]
         also applicable to WebDAV ACL.
         The following notice is copied from RFC 2026, section 10.4, and
         describes the position of the IETF concerning intellectual
         property claims made against this document.
    Sedlar, Clemm                                      [Page 13]

    INTERNET-DRAFT           WebDAV ACL              May 1, 2000
         The IETF takes no position regarding the validity or scope of any
         intellectual property or other rights that might be claimed to
         pertain to the implementation or use other technology described
         in this document or the extent to which any license under such
         rights might or might not be available; neither does it represent
         that it has made any effort to identify any such rights.
         Information on the IETF's procedures with respect to rights in
         standards-track and standards-related documentation can be found
         in BCP-11.  Copies of claims of rights made available for
         publication and any assurances of licenses to be made available,
         or the result of an attempt made to obtain a general license or
         permission for the use of such proprietary rights by implementers
         or users of this specification can be obtained from the IETF
         The IETF invites any interested party to bring to its attention
         any copyrights, patents or patent applications, or other
         proprietary rights that may cover technology that may be required
         to practice this standard.  Please address the information to the
         IETF Executive Director.
         This protocol is the collaborative product of the WebDAV ACL
         design team: xxx, yyy, zzz.  We would like to acknowledge the
         foundation laid for us by the authors of the WebDAV and HTTP
         protocols upon which this protocol is layered, and the invaluable
         feedback from the WebDAV working group.
    16 INDEX
         To be supplied.
         [RFC2026] S.Bradner, "The Internet Standards Process", Harvard,
         1996, <http://www.ietf.org/rfc/rfc2026.txt>.
         [RFC2068] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and
         T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
         2068, U.C. Irvine, DEC, MIT/LCS, 1997,
         <http://www.ietf.org/rfc/rfc2068.txt >.
         [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
         Requirement Levels", Harvard, 1997,
         <http://www.ietf.org/rfc/rfc2119.txt >.
          [RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
         "HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft,
         U.C.Irvine, Netscape, Novell, 1999
    Sedlar, Clemm                                      [Page 14]

INTERNET-DRAFT           WebDAV ACL              May 1, 2000
         Eric Sedlar
         Oracle Corporation
         500 Oracle Parkway
         Redwood Shores, CA  94065
         Email: esedlar@us.oracle.com
         Geoffrey Clemm
         Rational Software
         20 Maguire Road
         Lexington, MA
         Email: geoffrey.clemm@rational.com
    19 STILL TO DO :
           @ Describe the interactions with resource locking.  I'm not
              clear what the resolution was as far as locking the ACL
              separately from locking the resource.

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/