INTERNET-DRAFT                  Geoffrey Clemm, Rational Software
          draft-ietf-webdav-acl-02
     draft-ietf-webdav-acl-03        Anne Hopkins, Microsoft
                                     Corporation
                                     Eric Sedlar, Oracle Corporation
                                     Jim Whitehead, U.C. Santa Cruz

     Expires January 14, May 24, 2001         July 14,            November 24, 2000

                       WebDAV Access Control Extensions to WebDAV Protocol

     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.

     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
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     Abstract

     This document specifies a set of methods, headers, and resource-types message
     bodies that define the WebDAV Access Control extensions to the
     HTTP/1.1 protocol. This protocol permits a client to remotely read
     and modify access control lists that instruct a server whether to
     grant or deny operations upon a resource (such as HTTP method
     invocations) by a given principal.

     This document is a product of the Web Distributed Authoring and
     Versioning (WebDAV) working group of the Internet Engineering Task
     Force. Comments on this draft are welcomed, and should be addressed
     to the acl@webdav.org mailing list. Other related documents can be
     found at http://www.webdav.org/acl/, and
     http://www.ics.uci.edu/pub/ietf/webdav/.

     Clemm, Hopkins, Sedlar, Whitehead                 [Page 1] 
     Table of Contents

     1 INTRODUCTION............................................3 INTRODUCTION ............................................3
     1.1 Terms .................................................3
     1.2 Notational Conventions................................3 Conventions ................................4

     2 PRINCIPALS..............................................3 PRINCIPALS ..............................................4

     3 RIGHTS..................................................4 PRIVILEGES ..............................................5
     3.1 DAV:access-rights property............................5 DAV:read Privilege ....................................5
     3.2 Rights defined by WebDAV..............................6
           3.2.1 read Right........................................6
           3.2.2 write Right.......................................7
           3.2.3 readacl Right.....................................7
           3.2.4 writeacl Right....................................7
           3.2.5 all Right.........................................7 DAV:write Privilege ...................................6
     3.3 DAV:read-acl Privilege ................................6
     3.4 DAV:write-acl Privilege ...............................6
     3.5 DAV:all Privilege .....................................6

     4 ACCESS CONTROL PROPERTIES...............................7 PRINCIPAL PROPERTIES ....................................6
     4.1 Retrieving Access Control Information................11
           4.1.1 Example: Retrieving Access Control information...11 DAV:is-principal ......................................6
     4.2 Setting Access Control Information...................12
           4.2.1 Example: Setting Access Control information......13 DAV:authentication-id .................................6

     5 USING ACLS.............................................14 ACCESS CONTROL PROPERTIES ...............................7
     5.1 System Controlled Rights.............................14 DAV:owner .............................................7
     5.2 Special Principal Identifiers........................15 DAV:supported-privilege-set ...........................7
     5.3 ACL DAV:current-user-privilege-set ........................8
     5.4 DAV:acl ...............................................8
      5.4.1  ACE Principal .....................................8
      5.4.2  ACE Grant and Deny ................................9
      5.4.3  ACE Protection ...................................10
      5.4.4  ACE Inheritance ..................................10
     5.5 DAV:acl-semantics ....................................10
      5.5.1  first-match Semantics ............................14
      5.5.2  all-grant-before-any-deny Semantics Options................................15
           5.3.1 FirstSpecific....................................16
           5.3.2 ExplicitDenyPrecedence...........................16 ..............14
      5.5.3  no-deny Semantics ................................14
     5.6 DAV:principal-collection-set .........................10
     5.7 Example: PROPFIND to retrieve access control properties11

     6 ACL INHERITANCE........................................18 ACCESS CONTROL AND EXISTING METHODS ....................14
     6.1 Inheritable ACEs.....................................18
          6.2 Propagate ACE but do not use for Access Check on this resource....19
          6.3 Propagate to immediate children only.................19
          6.4 Protect ACL from inheritance.........................19 OPTIONS ..............................................15
      6.1.1  Example - OPTIONS ................................15

     7 XML SCHEMA FOR DEFINED ELEMENTS........................20 ACCESS CONTROL METHODS .................................16
     7.1 ACL ..................................................16
      7.1.1  ACL Preconditions ................................16
      7.1.2  Example: the ACL method ..........................17
      7.1.3  Example: ACL method failure ......................17

     8 INTERNATIONALIZATION CONSIDERATIONS....................21 CONSIDERATIONS ....................18

     9 SECURITY CONSIDERATIONS................................21 CONSIDERATIONS ................................19

     10  SCALABILITY..........................................21  AUTHENTICATION .......................................20

     11  AUTHENTICATION.......................................21

          12  IANA CONSIDERATIONS..................................21

          13 CONSIDERATIONS ..................................20

     12  INTELLECTUAL PROPERTY................................21 PROPERTY ................................20

     13  ACKNOWLEDGEMENTS .....................................21

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 2] 
     14  ACKNOWLEDGEMENTS.....................................22  REFERENCES ...........................................21

     15  INDEX................................................22
          16  REFERENCES...........................................22

          17  AUTHORS' ADDRESSES...................................23

          18 ADDRESSES ...................................22

     16  STILL TO DO :........................................23

          19  OPEN ISSUES:.........................................25 ..........................................22

     1  INTRODUCTION

          The goal of the WebDAV access control extensions is to provide
          an interoperable mechanism for handling discretionary access
          control for content in WebDAV servers.  WebDAV access control
          can be implemented on content repositories with security as
          simple as that of a UNIX file system, as well as more
          sophisticated models.  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 a single "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 principal.

          1.1 Notational Conventions

               The augmented BNF used by this document
          When a principal submits an operation (such as an HTTP or
          WebDAV method) to describe protocol
               elements is described in Section 2.1 of [RFC2068]. Because this
               augmented BNF uses a resource for execution, the basic production rules provided server
          evaluates the ACEs in Section
               2.2 the ACL to determine if the principal
          has permission for that operation.

          This specification has intentionally omits discussion of
          authentication, as the HTTP protocol already has a number of
          authentication mechanisms[RFC2617] .  Some authentication
          mechanism (such as HTTP Digest Authentication, which all
          WebDAV compliant implementations are required to support) must
          be availableto validate the identity of a principal.

          In the interests of timeliness, the following set of security
          mechanisms is currently viewed as out of scope of this
          document:

            *  Access control that applies only to a particular property
               on a resource, rather than the entire resource.

            *  Role-based security (where a role can be seen as a
               dynamically defined collection of principals)

            *  Specification of the ways an ACL on a resource is
               initialized

            *  Specification of an ACL that applies globally to a
               method, rather than to a particular resource

     1.1 Terms

          This draft uses the terms defined in HTTP [RFC2616] and WebDAV
          [RFC2518].  In addition, the following terms are defined:

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 3] 
        principal

          A "principal" is a distinct human or computational actor that
          initiates access to network resources.  In this protocol, a
          principal is an HTTP resource that represents such an actor.

        privilege

          A "privilege" controls access to a particular set of HTTP
          operations on a resource.

        aggregate privilege

          An "aggregate privilege " is a privilege that comprises a set
          of other privileges.

        access control list (acl)

          An "acl " is a list of access control elements that define
          access control to a particular resource.

        access control element (ace)

          An "ace " either grants or denies a particular set of
          privileges for a particular principal.

        inherited ace

          An "inherited ace " is an ace that is shared from the acl of
          another resource.

     1.2 Notational Conventions

          The augmented BNF used by this document to describe protocol
          elements is described in Section 2.1 of [RFC2616]. Because
          this augmented BNF uses the basic production rules provided in
          Section 2.2 of [RFC2068], [RFC2616], 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 [RFC2119].

     2  PRINCIPALS

          A principal identifies is an entity HTTP resource that can be given represents a distinct
          human or computational actor that initiates access rights to HTTP network
          resources.  On many implementations, a user or a group
               will be examples of principals, but users and groups are
          represented as principals; other types of principals are also
          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
               implementation.
               Principals are manifested to clients as a HTTP resource,
               identified by a URL.  The set of properties exposed by that
               resource are   Although an implementation dependent, although certain
               properties are required by this specification.  Those properties
               include:
               . DAV:principalname:    A 'live' property containing the name
                 used MAY support PROPFIND
          and PROPPATCH to authenticate this principal (typically typed into a
                 login prompt/dialog).  [OPTIONAL]
               . DAV:displayname: A property containing a human-readable
                 description of this principal.  This property may be "live" access and not settable via PROPPATCH. [REQUIRED]

               . DAV:principal-type:   A 'live' property containing modify information about 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 this property can be
                 used to distinguish
          principal, it as a principal from other resources on
                 a WebDAV server.  (Note that DAV:resourcetype may is not be used,
                 as all collections must use the value "collection" for
                 DAV:resourcetype, which wouldn't distinguish normal
                 collections from principal collections.) [REQUIRED]

               Server implementations may include any other descriptive
               information for a principal via properties. required to do so.

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 4] 
          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 and maintaining collections (e.g. DELETE,
          PROPFIND) may MAY be used to maintain collection principals.
          Membership in a collection principal is recursive, so a
          principal in a collection principal
               A GRPA contained by
          collection principal B GRPB is a member of both
               collection principals. GRPA and GRPB.
          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  PRIVILEGES

          Ability to perform a particular set of HTTP operations given method on a resource.  The set resource SHOULD be
          controlled by one or more privileges.  Authors of rights protocol
          extensions 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), define new HTTP methods SHOULD specify which can at least be used
          privileges (by defining new privileges, or mapping to set some context ones
          below) are required to perform the other rights defined on method.  A principal with
          no privileges to a particular resource SHOULD be denied any HTTP access
          to that resource.
               Rights

          Privileges may be aggregates of other rights. privileges.  If a
          principal is granted or denied an aggregate privilege, it is
          semantically equivalent to granting or denying each of the
          aggregated privileges individually.  For example, one an
          implementation may split out a right controlling define add-member and remove-member
          privileges that control the ability to add children to a collection from the right allowing a resource
               to be removed from and remove an
          internal member of a collection.  Since these rights privileges
          control the ability to write to update the state of a collection, these rights
          privileges would be aggregated by the DAV:write right. privilege on a
          collection, and granting the DAV:write privilege on a
          collection would also grant the add-member and remove-member
          privileges.

          The relationships set of privileges that apply to a particular resource may
          vary with the DAV:resourcetype of the resource, as well as
          between
               atomic rights different server implementations.  To promote
          interoperability, however, WebDAV defines a set of well-known
          privileges (e.g. DAV:read and aggregate rights DAV:write), which can at least
          be discovered via used to classify the
               DAV:access-rights property other privileges defined on a
          particular resource.  Servers may
               specify some rights as abstract, which means

     3.1 DAV:read Privilege

          The read privilege controls methods 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 information
          about the same response to the DAV:access-rights property on all state of the resources with resource, including the same DAV:resourcetype value.

          3.1 DAV:access-rights property resource's
          properties. Affected methods include GET and PROPFIND.  The DAV:access-rights property is a live property that contains
          read privilege does not control the rights aggregation tree. The DAV:access-rights property MUST
               be available on every resource available via a WebDAV Access
               Control-compliant server. 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
               attributes:
               . abstract (Boolean): 'true' if this right MUST NOT be used in
                 an ACL/ACE. Defaults to 'false.' Note: an abstract right need
                 not be an aggregate right.

               . Description (string): a human-readable description of what
                 this right controls access to. [REQUIRED]. The server MAY
                 localize this description, based on the Accept-Language header
                 of the request.

               For example, the following response might be generated to a
               request on a WebDAV server.
               Request
               PROPFIND /file HTTP/1.1
               Host: www.foo.bar
               Content-type: text/xml; charset="utf-8"
               Accept-Language: en-us
               Depth: 0
               Content-Length: xxx

               <?xml version="1.0" encoding="utf-8"?>
               <D:propfind xmlns:D="DAV:">
                   <D:prop>
                         <D:access-rights/>
                    </D:prop>
               </D:propfind>

               Response
               HTTP/1.1 207 Multi-Status
               Content-Type: text/xml
               Content-Length: xxx

               <?xml version="1.0"?>
               <D:multistatus xmlns:D="DAV:"
               xlmns:A="http://www.foo.bar/schema/">
                 <D:response>
                   <D:href>http://www.foo.bar/file</D:href>
                   <D:propstat>
                     <D:status>HTTP/1.1 200 OK</D:status>
                     <D:prop>
                       <D:access-rights>
                         <D:all>
                          <D:write abstract="true" description="Write any
               object">
                            <A:create abstract="false" description="Create an
               object"/>
                            <A:update abstract="false" description="Update an
               object"/>
                            <A:delete abstract="false" description="Delete an
               object"/>
                          <D:write/>
                          <D:read abstract="false" description="Read any
               object"/>
                          <D:readacl abstract="false" description="Read the
               ACL"/>
                          <D:writeacl abstract="false" description="Write the
               ACL"/>
                        </D:all>
                       </D:access-rights>
                     </D:prop>
                   </D:propstat>
                 </D:response>
               </D:multistatus>

               It is envisioned that a WebDAV ACL-aware administrative client
               would list the available rights in a dialog box, and allow OPTIONS method since 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.
          OPTIONS method returns capabilities rather than state.

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 5] 
     3.2 Rights defined by WebDAV DAV:write Privilege

          The rights defined by WebDAV access control MUST be present in
               the DAV:access-rights property, although they may be abstract
               (and not usable within an ACE on a particular implementation).
               Ability to perform a given method on a resource MUST be
               controlled by some right.  Authors of Internet drafts that define
               new methods must specify which right (by defining a new right, or
               mapping to one below) is required to perform the method.  A
               principal with no rights to a resource should be denied any HTTP
               access to that resource.

          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 and DAV:access-rights properties MUST be
               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 and DAV:access-rights properties will not be included in
               any PROPFIND requests on the associated resource.

          3.2.4writeacl Right

               Name:            DAV:writeacl
               Purpose:         The writeacl right provides and restricts access
               to the DAV:acl and DAV:owner properties.

          3.2.5all Right

               Name:            DAV:all
               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 access-rights
               property, and should not control access to rights not exposed via
               that route.

          4  ACCESS CONTROL PROPERTIES

               This specification defines a number of new properties for WebDAV
               resources.  Access control properties may be set and retrieved
               just like other WebDAV properties, using the PROPFIND and
               PROPPATCH method (subject to permissions and 'liveness.'  An HTTP
               resource on a WebDAV Access Control-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.  [REQUIRED]

               . DAV:rights: A 'live' readonly property containing the list of
                 rights of the currently authenticated HTTP user.  The read
                 right controls read access to this property. [REQUIRED]

               . 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.  [REQUIRED]

               . DAV:aclsemantics: A readonly property indicating the ACL
                 semantics model supported by the system.  [REQUIRED]

               . DAV:protectaclfrominheritance:  A "live" property indicating
                 that the ACL does not inherit any ACEs.  If this property is
                 present, the ACL should contain no ACEs with the DAV:inherited
                 element present.  If this property is not present and the
                 system supports ACL inheritance, then the ACL will contain
                 inheritable ACEs from its parent resource.  If a resource
                 without this property present is updated with this property,
                 it is a client choice whether to remove the inherited ACEs or
                 retain them but remove the DAV:inherited element from the
                 ACEs.   [OPTIONAL]

               The DAV:owner element contains one or more of the following XML
               elements:
               . DAV:href:   This contains the URI to the principal resource
                 that is the 'owner' of  the resource.  Normally, an attempt to
                 PROPPATCH this property will result in a 401 (Not Authorized)
                 error.  The principal indicated by the owner property is
                 implicitly granted readacl and writeacl rights.  This enables
                 the owner to restore an appropriate ACL in the case that it
                 becomes maliciously or accidently corrupted such that no
                 principal is granted the writeacl right by any ACE.
                 [REQUIRED]

               . DAV:principalname, DAV:displayname, DAV:principal-type: These
                 are the same as the properties that can exist on the principal
                 URI. In this context they are considered 'live.' [OPTIONAL]

               The DAV:acl element (property) contains 0 or more of the
               following XML elements:
               . DAV:ace:    A "live" property representing an access control
                 entry, which specifies the set of rights to be either granted
                 or denied to a single principal.

               The DAV:ace element contains the following XML elements:
               . DAV:grant:  Contains the set of XML elements corresponding to
                 the rights being granted via this ACE.  MUST contain at least
                 one right.  MUST NOT be present if the DAV:deny element is
                 present.

               . 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.  MUST NOT be present if the DAV:grant
                 element is present.

               . DAV:principal:   Contains information about the principal
                 resource this ACE applies to. [REQUIRED].

               . DAV:acepropertytypes: A "live" property containing one or more
                 elements, each of which is an XML tag identifying either a
                 property on this resource or a property on a child resource
                 that may inherit this ACE.  Presence of DAV:acepropertytypes
                 distinguishes this ACE as a "Property ACE."  The rights
                 associated with a "Property ACE" control access to only the
                 property(ies) contained in DAV:acepropertytypes, and do not
                 control access to the resource as a whole.  The set of access
                 rights supported on Property ACEs may be all or a subset of
                 the DAV:access-rights present on this resource.  This spec
                 does not provide a mechanism to specify a different set of
                 access-rights for a property, than for the resource.  An
                 implementation that supports a different set of access-rights
                 for a property than for the resource, must return an error
                 "Unsupported Right" on an attempt to write a Property ACE with
                 rights not supported by the server.  [OPTIONAL]

               . DAV:inherittochildtype:    A "live" property containing one or
                 more elements, each of which is an XML tag identifying the
                 type of child object that will inherit this ACE.  This
                 property is only present if DAV:inheritanceflags contains at
                 least one of the following: DAV:inheritonly,
                 DAV:containerinherit, or DAV:objectinherit.  A child of the
                 current resource will only inherit this ACE if the type of the
                 child object is present in DAV:inherittochildtype.

               . DAV:inheritanceflags: A "live" property containing flags
                 indicating the inheritance features of this ACE.  For an ACE
                 that is neither inherited, nor inheritable, this element may
                 be either not present, or present but empty.  [OPTIONAL]

               . DAV:inheritancesource: A readonly property containing the URL
                 of the resource from which this ACE was inherited (contained
                 within an DAV:href element).  In other words, the ACL on the
                 resource referred to by this URI contains the inheritable
                 explicit ACE which, when propagated to the current resource,
                 resulted in the current ACE. This element may contain the
                 special value of DAV:system-ace to indicate that the ACE is
                 read-only and represents rights granted implicitly by the
                 system.  This element may contain the special value of
                 DAV:unknown if the server is unable to generate a valid URI to
                 the resource from which this element was inherited. This
                 element MUST be present if DAV:inheritanceflags contains the
                 DAV:inherited flag for inherited ACEs and MUST NOT be present
                 for explicit ACEs.

               The DAV:principal element contains the following elements:
               . DAV:href:   This is a URI representing the resource to which
                 the ACE applies, or one of the special principal identifier
                 tags (e.g.,  DAV:owner) described in the "Special Principal
                 Identifiers" section of this spec. [REQUIRED]

               . DAV:principalname, DAV:displayname, DAV:principal-type: These
                 are the same as the properties that can exist on the principal
                 URI. In this context they are considered 'live.' [OPTIONAL]

               The DAV:inheritanceflags element contains 0 or more of the
               following XML elements:
               . DAV:inherited:   This flag indicates the ACE is inherited from
                 the ACL on a different resource, identified in
                 DAV:inheritancesource.  This flag MUST be present for an
                 inherited ACE and MUST NOT be present for an explicit ACE.
                 This flag must not be present if the
                 DAV:protectaclfrominheritance element is present on this
                 resource unless the DAV:inheritancesource element contains the
                 special value DAV:system-ace, indicating that this ACE wasn't
                 really inherited, but reflects implicit system-granted rights.
                 [REQUIRED]

               . DAV:inheritonly: This flag indicates the ACE should be ignored
                 during access check.  The ACE is present for the purposes of
                 inheritance only and does not affect the security of the
                 current resource.  [OPTIONAL]

               . DAV:containerinherit: This flag indicates that container
                 objects inherit this ACE as an effective ACE.  The
                 DAV:inheritonly flag, if also present on this ACE, will be
                 removed from the inherited effective ACE on the container.  If
                 the DAV:nopropagateinheritance flag is present on the current
                 ACE, the DAV: containerinherit flag is removed from the
                 inherited ACE on the container.  [REQUIRED]

               . DAV:objectinherit:    This flag indicates that non-container
                 resources inherit this ACE as an effective ACE.  The
                 DAV:inheritonly flag, if also present on this ACE, will be
                 removed from the inherited effective ACE on the non-container
                 resource.  If the DAV:nopropagateinheritance> flag is not
                 present, then container resources will also inherit this ACE
                 with privilege controls methods that modify the addition state of
          the DAV:inheritonly> flag.  [REQUIRED]

               . DAV:nopropagateinheritance: This flag indicates the ACE should
                 be inherited one level only.  If an object inherits this ACE,
                 the DAV:containerinherit resource, such as PUT and DAV:objectinherit flags are
                 removed from the resultant inherited ACE, preventing further
                 propagation PROPPATCH.  Note that state
          modification is also controlled via locking (see section 5.3
          of this ACE.  [OPTIONAL] [WEBDAV]), so effective write access requires that both
          write privileges and write locking requirements are satisfied.

     3.3 DAV:read-acl Privilege

          The DAV:aclsemantics element MUST contain exactly one of the
               following XML elements:
               . DAV:firstspecific:    This element is present if the ACL
                 conforms to the FirstSpecific semantics described in this
                 spec.

               . DAV:explicitdenyprecedence: This element is present if the ACL
                 conforms to DAV:read-acl privilege controls the ExplicitDenyPrecedence semantics described in
                 this spec.

          4.1 Retrieving Access Control Information

               Retrieving Access Control information is done via use of PROPFIND on to
          retrieve the
               resource in question. All ACL DAV:acl, and DAV:current-user-privilege-set
          properties are also returned as
               part of the response to PROPFIND allprop request.

          4.1.1Example: Retrieving Access Control information resource.

     3.4 DAV:write-acl Privilege

          The following example shows how access control information could
               be retrieved using PROPFIND method.
               Request
               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:'>
                 <D:allprop/>
               </D:propfind>

               Response
               HTTP/1.1 207 Multi-Status
               Content-Type: text/xml
               Content-Length: xxx

               <?xml version="1.0" encoding="utf-8" ?>
               <D:multistatus xmlns:D="DAV">
               <D:response>
                 <D:propstat>
                   <D:status>HTTP/1.1 200 OK</D:status>
                   <D:prop>
                     <D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
                     <D:displayname>Example collection</D:displayname>
                     <D:resourcetype><D:collection/></D:resourcetype>
                     <D:supportedlock> XXXXX</D:supportedlock>
                     <D:owner>
                       <D:href>http://www.foo.bar/users/gclemm
                     <D:displayname>Geoffrey Clemm</D:displayname>
                     </D:owner>
                     <D:rights>
                       <D:read/><D:readacl/>
                     </D:rights>
                     <D:acl>
                        <D:ace>
                          <D:grant><D:read/><D:write/><D:readacl/></D:grant>
                          <D:principal>
                            <D:href>http://www.foo.bar/users/esedlar</D:href>
                            <D:principal-type><DAV:user/></D:principal-type>
                            <D:principalname>esedlar</D:principalname>
                            <D:displayname>Eric Sedlar</D:displayname>
                          </D:principal>
                        </D:ace>
                        <D:ace>
                          <D:grant><D:read/><D:readacl/></D:grant>
                          <D:principal>
                            <D:href>http://www.foo.bar/groups/marketing</d:href>
                            <D:principal-type><DAV:group/></D:principal-type>
                            <D:displayname>Foo.Bar marketing
               department</D:displayname>
                            <D:principalname>mktdept</D:principalname>
                          </D:principal>
                        </D:ace>
                        <D:ace>
                       <D:deny><D:writeacl/></D:deny>
                           <D:principal>

               <D:href>http://www.foo.bar/groups/marketing</d:href>
                             <D:principal-type><DAV:group/></D:principal-type>
                             <D:displayname>Foo.Bar marketing
               department</D:displayname>
                             <D:principalname>mktdept</D:principalname>
                           </D:principal>
                        <D:ace/>
                        <D:ace>
                        <D:grant><D:read/></D:grant>
                          <D:principal><d:all/></D:principal>
                        </D:ace>
                     </D:acl>
                   </D:prop>
                 <D:propstat>
               <D:response>
               <D:multistatus>

          4.2 Setting Access Control Information

               An ACL is set by executing a PROPPATCH against the resource that
               contains the DAV:acl property.  An ACL must be written in its
               entirety. All ACEs (readable by the current user)  previously
               stored in DAV:write-acl privilege controls use of the ACL on the indicated resource are removed. (If the
               server implements rights outside of those defined in this
               specification, they might allow only some ACEs to be visible=97
               behaviour on a PROPPATCH is undefined with respect method to this
               specification).
               Setting an empty ACL
          modify the DAV:acl property causes of the resource.

     3.5 DAV:all Privilege

          The DAV:all privilege controls all ACEs in privileges on the ACL,
               including ACEs for associated properties, to be deleted.
               Since permission resource.

     4  PRINCIPAL PROPERTIES

          Principals are manifested to set clients as an ACL is typically controlled HTTP resource,
          identified by a
               different right from permission to set other properties, it URL.  A principal MUST have a DAV:displayname
          property.  This protocol defines the following additional
          properties for a principal.

     4.1 DAV:is-principal

          This property indicates whether this resource is
               recommended that ACL-setting PROPPATCHes be executed
               independently from PROPPATCHes of other properties. PROPATCH as
               defined in [WEBDAV] a principal.
          A resource MUST have a non-empty DAV:is-principal property if
          and only if it is an atomic operation, so failure a principal resource.   (Note: If we can
          just add a DAV:principal element to set the
               ACL will result in DAV:resourcetype
          property, then we do not need a failure DAV:is-principal property.)

          <!ELEMENT is-principal (#PCDATA)>
          PCDATA value: any non-empty value ("T" is suggested)

     4.2 DAV:authentication-id

          A property containing the name used to set all other properties.
               [WEBDAV] also authenticate this
          principal (typically typed into a login prompt/dialog).

          <!ELEMENT authentication-id (#PCDATA)>
          PCDATA value: any string

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 6] 
     5  ACCESS CONTROL PROPERTIES

          This specification defines that operations must be performed from top
               to bottom, so multiple instances a number of new properties for
          WebDAV resources.  Access control properties may be retrieved
          just like other WebDAV properties, using the PROPFIND method.
          Some access control properties (such as DAV:owner) MAY be
          updated with the DAV:acl element in a
               single PROPPATCH result in only method.

          HTTP resources that support the WebDAV Access Control Protocol
          MUST contain the last following properties:

     5.1 DAV:owner

          This property identifies a particular principal as being set.
               Changing ownership the
          "owner" of the resource.

          <!ELEMENT owner (href prop?)>
          <!ELEMENT prop (see [RFC2518], section 12.11)>

          An implementation MAY include a resource requires setting list of selected properties of
          that principal resource.  Which properties (if any) are
          included is implementation defined.  An implementation MAY
          allow the DAV:href
               element use of PROPPATCH to update the DAV:owner property.

          4.2.1Example: Setting Access Control information

               The following example follows from the previous example and
               changes the group ACE to disallow read access to field.

     5.2 DAV:supported-privilege-set

          This is a read-only property that identifies the ACL privileges
          defined for the
               marketing group. The other information had to be copied from the
               ACL retrieved in resource.

          <!ELEMENT supported-privilege-set (supported-privilege*)>

          Each privilege appears as an XML element, where aggregate
          privileges list as sub-elements all of the previous example.
               Request
               PROPPATCH /top/container HTTP/1.1
               Host: www.foo.bar
               Content-Type: text/xml
               Content-Length: xxxx

               <?xml version="1.0"?>
               <D:propertyupdate xmlns:D="DAV:">
                  <D:set>
                     <D:prop>
                     <D:acl>
                          <D:ace>
                            <D:grant><D:read/><D:write/><D:readacl/></D:grant>
                            <D:principal>
                              <D:href>http://www.foo.bar/users/esedlar</D:href>
                          </D:principal>
                          </D:ace>
                          <D:ace>
                            <D:grant><D:read/></D:grant>
                            <D:principal>
                            <D:href>http://www.foo.bar/groups/marketing</D:href>
                          </D:principal>
                          </D:ace>
                     </D:acl>
                   </D:prop>
                 </D:set>
               </D:propertyupdate>

               Response
               HTTP/1.1 207 Multi-Status
               Content-Type: text/xml
               Content-Length: xxx

               <?xml version="1.0"?>
               <D:multistatus xmlns:a="DAV:">
                 <D:response>
                   <D:href>http://www.foo.bar/top/container/</D:href>
                   <D:propstat>
                     <D:status>HTTP/1.1 200 OK</D:status>
                     <D:prop>
                       <D:acl/>
                     </D:prop>
                   </D:propstat>
                 </D:response>
               </D:multistatus>

          5  USING ACLS

               An ACL contains zero or more ACEs privileges that express the rights granted
               or denied
          they aggregate.

          <!ELEMENT supported-privilege
           (privilege, abstract?, description, supported-privilege*)>
          <!ELEMENT privilege ANY>

          An abstract privilege is used to classify the principal specified in the ACE. non-abstract
          privilege elements.  An ACL with
               zero ACEs implies abstract privilege of a resource MUST
          NOT be used in an ACE for that no principal is granted any rights. resource. Servers MUST fail an
          attempt to set an abstract privilege.

          <!ELEMENT abstract EMPTY>

          A
               particular ACE may either grant or deny description is a set human-readable description of rights to what this
          privilege controls access to.

          <!ELEMENT description #PCDATA>

          It is envisioned that a
               single principal.  However, since WebDAV ACL-aware administrative client
          would list the supported privileges in a server may match dialog box, and allow
          the
               currently authenticated HTTP user with multiple principals (for
               instance, to choose non-abstract privileges to apply in the case where one principal refers an ACE.
          The privileges tree is useful programmatically to the user and
               another principal refers map well-

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 7] 
          known privileges (defined by WebDAV or other standards groups)
          into privileges that are supported by any particular server
          implementation.  The privilege tree also serves to a group hide
          complexity in implementations allowing large number of
          privileges to be defined by displaying aggregates to which the user belongs),
               it user.

     5.3 DAV:current-user-privilege-set

          This is possible for multiple ACEs a read-only property containing a list of privileges
          granted to "match" the current currently authenticated HTTP user.  A  The current
          user has no access rights privileges to an object protected by an ACL
          unless that user matches one or more of the principals
          specified in the ACEs.
               Server implementations may limit

          <!ELEMENT current-user-privilege-set (privilege*)>
          <!ELEMENT privilege ANY>

          Each element in the number DAV:current-user-privilege-set property
          MUST identify a privilege from the DAV:supported-privilege-set
          property.

     5.4 DAV:acl

          This property specifies the list of ACEs in an ACL.
               However, ACL-compliant servers access control entries
          (ACEs), which define what principals are required to support at least
               one ACE granting rights get what
          privileges for this resource.

          <!ELEMENT acl (ace*)>

          Each DAV:ace element specifies the set of privileges to a single principal, and one ACE
               granting rights be
          either granted or denied to a collection single principal.  If a client tries to
               write an ACL containing more ACEs than the server supports, the
               server should return an error "Too many ACEs."

          5.1 System Controlled Rights

               Some implementations may grant certain rights implicitly.  For
               example, some systems grant the resource owner DAV:readacl and
               DAV:writeacl implicitly to prevent an ACL from becoming
               irrevocably locked by an update that grants
          DAV:acl property is empty, no one the
               DAV:writeacl right.  Any rights principal is granted implicitly by the system
               should be reflected as standard ACEs in the ACL returned any
          privilege.

          <!ELEMENT ace (principal, (grant|deny), protected?,
          inherited?)>

          An attempt to update the
               client.  Since these implicit permissions are read-only, they
               should be reflected as "system controlled" ACEs where
               DAV:inheritanceflags contains DAV:inherited and the
               DAV:inheritancesource element contains DAV:system-ace.

          5.2 Special DAV:acl property with a PROPPATCH
          MUST fail.

     5.4.1 ACE Principal Identifiers

          The DAV:principal element in an identifies the principal to which
          this ACE may contain, instead of applies.

          <!ELEMENT principal ((href, prop?)
           | all | authenticated | unauthenticated
           | property | self)>

          The current user matches DAV:href only if that user is
          authenticated as being (or being a
               specific security member of) the principal identifier, one of
          identified by the following
               special tags:
               . DAV:owner:  The URL contained by that DAV:href.   An
          implementation MAY include a DAV:prop element after the
          DAV:href element, containing a list of selected properties of
          that principal identified by resource.  Which properties (if any) are

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 8] 
          included in the owner property on
                 this resource DAV:prop element is granted or denied implementation defined.
          The DAV:prop element is primarily intended for implementations
          that do not support PROPFIND requests on the rights specified in
                 this ACE.

               . DAV:all: principal URL.

          <!ELEMENT prop (see [RFC2518], section 12.11)>

          The current user always matches this ACE, whether or
                 not s/he is authenticated.

               . DAV:authenticated: DAV:all.

          <!ELEMENT all EMPTY>

          The current user matches this ACE DAV:authenticated only if
          authenticated.

               . DAV:unauthenticated:

          <!ELEMENT authenticated EMPTY>

          The current user matches this ACE DAV:unauthenticated only if not
                 authenticated

               . DAV:selfprincipal:
          authenticated.

          <!ELEMENT unauthenticated EMPTY>

          DAV:all is the union of DAV:authenticated, and
          DAV:unauthenticated. For a given request, the user matches
          either DAV:authenticated, or DAV:unauthenticated, but not
          both.

          The current user matches this ACE if the
                 resource (for example, a user information object or security DAV:property principal account) associated with this ACL is in a
                 representation of the current user.

          5.3 ACL Semantics Options

               In order to accommodate the different semantics DAV:acl
          property of multiple
               existing server implementations, we define a number of ACL
               Semantics options.  The tag associated with each option is used
               to indicate what semantics to apply to the ACL.  A client may use
               this tag to display information that helps an ACL author
               understand the implications of his updates.  The client must also
               use this tag to determine the legal semantics for ordering ACEs
               prior to updating the ACL property.
               The following ACL Semantics options have been defined to
               indicate:
               . restrictions, resource only if any, on the ordering identified property of ACEs within that
          resource contains a stored
                 ACL,

               . how to determine during access check which ACE(s) apply to DAV:href that identifies a principal, and
          the current user is authenticated as being (or being a member
          of) that matches multiple principals,

               . how to combine principal.  For example, if the rights granted or denied by multiple
                 matching ACEs during access check.

               Additional ACL models may be accommodated by defining and
               registering additional ACL Semantics tags.  [How is this done?
               TBD].
               Requested Rights: Some access check algorithms are based on not
               just DAV:property element
          contained <DAV:owner/>, the current user identity and would match the ACEs, but also on
          DAV:property principal only if the "requested
               rights," which current user is
          authenticated as matching the set of rights required principal identified by the operation for
               which
          DAV:owner property of the access check is being performed.

               Effective Rights: resource.

          <!ELEMENT property ANY>

          The "effective rights" current user matches DAV:self in a DAV:acl property of the
          resource only if that resource is a principal object and the
          current user is authenticated as being that principal.

          <!ELEMENT self EMPTY>

     5.4.2 ACE Grant and Deny

          Each DAV:grant or DAV:deny element specifies the set of
               all rights that would
          privileges to be either granted or denied to a user by a given ACL.  This
               set, which is exposed via the DAV:rights property, is independent specified
          principal.  A DAV:grant or DAV:deny element of the DAV:acl of any operation "requested rights" and may be generated by
          a
               different algorithm than resource MUST only contain elements specified in the access check algorithm
          DAV:supported-privilege-set of that
               determines whether resource.

          <!ELEMENT grant (privilege+)>
          <!ELEMENT deny (privilege+)>
          <!ELEMENT privilege ANY>

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 9] 
     5.4.3 ACE Protection

          If an ACE contains a user has specific requested rights.  Each
               right DAV:protected element, an ACL request
          without that ACE MUST fail.

          <!ELEMENT protected EMPTY>

     5.4.4 ACE Inheritance

          The presence of a DAV:inherited element indicates that this
          ACE is inherited from another resource that is identified by
          the URL contained in a DAV:href element.  An inherited ACE
          cannot be modified directly, but instead the Effective Rights set applies to ACL on the user whether
          resource from which it is inherited must be modified.

          Note that ACE inheritance is not the same as ACL
          initialization.  ACL initialization defines the
               right ACL that a
          newly created resource will use (if not specified).  ACE
          inheritance refers to an ACE that is requested individually, or in combination with other
               rights, in logically shared - where
          an update to the requested rights for resource containing an operation.

          5.3.1FirstSpecific ACE will affect the
          ACE of each resource that inherits that ACE.  The FirstSpecific semantic model has method by
          which ACLs are initialized or by which ACEs are inherited is
          not defined by this document.

          <!ELEMENT inherited (href)>

     5.5 DAV:acl-semantics

          This is a read-only property that defines the following
               characteristics:
               Order of ACEs: ACL semantics.
          These semantics define how multiple ACEs that match the
          current user are combined, what  are ordered from "most specific" to "least
               specific."  Typically, the "most specific" constraints on how
          ACEs identify can be ordered, and which principals that refer to a single user.  ACEs with "intermediate"
               specificity must have principals that refer to a collection or group
               of users or other entities.  The "least specific" ACEs contain
               principals, like "World" or "Everyone," that indicate an
               unbounded set of users.  If multiple ACEs with ACE.

          Since it is not practical to require all implementations to
          use the same level of
               specificity are present, their order relative ACL semantics, the DAV:acl-semantics property is
          used to each other identify the ACL semantics for a particular resource.
          The DAV:acl-semantics element is
               not defined here.  Implementations in section 6.

     5.6 DAV:principal-collection-set

          Often a versioning implementation constrains where a principal
          can be located in the URL space.  The DAV:principal-
          collection-set enumerates which collections may contain
          principals.

          <!ELEMENT principal-collection-set (href*)>

          Since different servers can control different parts of the FirstSpecific model are
               unlikely to URL
          namespace, different resources on the same host MAY have multiple ACEs
          different DAV:principal-collection-set values .  The
          collections specified in the intermediate and least
               specific categories (where multiple ACE matches are possible),
               making it unimportant DAV:principal-collection-set MAY
          be located on different hosts from the resource.

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 10] 
     5.7 Example: PROPFIND to define a rule for relative ordering retrieve access control properties

          The following example shows how access control information can
          be retrieved by using the PROPFIND method to fetch the values
          of the DAV:owner, DAV:supported-privilege-set, DAV:current-
          user-privilege-set, and DAV:acl properties.

          >> Request <<

          PROPFIND /top/container/ HTTP/1.1
          Host: www.foo.org
          Content-type: text/xml; charset="utf-8"
          Content-Length: xxx
          Depth: 0
          Authorization: Digest username="ejw",
             realm="users@foo.org", nonce="...",
             uri="/top/container/", response="...", opaque="..."

          <?xml version="1.0" encoding="utf-8">
          <D:propfind xmlns:D="DAV:">
            <D:owner/>
            <D:supported-privilege-set/>
            <D:current-user-privilege-set/>
            <D:acl/>
          </D:propfind>

          >> Response <<

          HTTP/1.1 207 Multi-Status
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxx

          <?xml version="1.0" encoding="utf-8" ?>
          <D:multistatus
             xmlns:D="DAV"
             xmlns:A="http://www.acl.org/"> <D:response> <D:propstat>
            <D:status>HTTP/1.1 200 OK</D:status>
            <D:prop>
              <D:owner>
                <D:href>http://www.foo.org/users/gclemm</D:href></D:owner>
              <D:supported-privilege-set>
                <D:supported-privilege>
                  <D:privilege> <D:all/> </D:privilege>
                  <D:abstract/>
                  <D:description>Any operation</D:description>
                  <D:supported-privilege>
                    <D:privilege> </D:read> </D:privilege>
                    <D:description>Read any object</D:description>
                  </D:supported-privilege>
                  <D:supported-privilege>
                    <D:privilege> <D:write/> </D:privilege>
                    <D:abstract/>
                    <D:description>Write any object</D:description>
                    <D:supported-privilege>
                      <D:privilege> <A:create/> </D:privilege>

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 11] 
                      <D:description>Create an object</D:description>
                    </D:supported-privilege>
                    <D:supported-privilege>
                      <D:privilege> <A:update> </D:privilege>
                      <D:description>Update an object</D:description>
                    </D:supported-privilege>
                    <D:supported-privilege>
                      <D:privilege> <A:delete> </D:privilege>
                      <D:description>Delete an object</D:description>
                    </D:supported-privilege>
                  </D:supported-privilege>
                  <D:supported-privilege>
                    <D:privilege> <D:read-acl/> </D:privilege>
                    <D:description>Read the ACL</D:privilege>
                  </D:supported-privilege>
                  <D:supported-privilege>
                    <D:privilege> <D:write-acl/> </D:privilege>
                    <D:description>Write the ACL</D:privilege>
                  </D:supported-privilege>
                </D:supported-privilege>
              </D:supported-privilege-set>
              <D:current-user-privilege-set>
                <D:privilege> <D:read/> </D:privilege>
                <D:privilege> <D:read-acl/> </D:privilege>
              </D:current-user-privilege-set>
              <D:acl>
                <D:ace>
                  <D:principal>
                    <D:href>http://www.foo.org/users/esedlar</D:href>
                    <D:prop>
                      <D:authentication-id>esedlar</D:authentication-id>
                      <D:displayname>Eric Sedlar</D:displayname>
                    </D:prop> </D:principal>
                  <D:grant>
                    <D:privilege> <D:read/> </D:privilege>
                    <D:privilege> <D:write/> </D:privilege>
                    <D:privilege> <D:read-acl/> </D:privilege></D:grant>
                </D:ace>
                <D:ace>
                  <D:principal>
                    <D:href>http://www.foo.org/groups/marketing/</d:href>
                  </D:principal>
                  <D:deny>
                    <D:privilege> <D:read/> </D:privilege> </D:deny>
                <D:ace/>
                <D:ace>
                  <D:principal>
                    <D:property> <D:owner/> </D:property> </D:principal>
                  <D:grant>
                    <D:privilege> <D:read-acl/> </D:privilege>
                    <D:privilege> <D:write-acl/> </D:privilege></D:grant>
                <D:ace/>
                <D:ace>

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 12] 
                  <D:principal> <D:all/> </D:principal>
                  <D:grant>
                    <D:privilege> <D:read/> </D:privilege> </D:grant>
                  <D:inherited>
                    <D:href>http://www.foo.org/top/</D:href></D:inheritied>
                </D:ace> </D:acl>
              </D:prop>
            </D:propstat> </D:response> </D:multistatus>

          The value of
               ACEs within these two specificity levels.
               ACE Matching Algorithm:  ACEs are evaluated in the order in which
               they appear in the ACL, from first to last.  When a match DAV:owner property is
               found, a single DAV:href XML
          element containing the algorithm is complete.  This first matching ACE alone
               is used to determine URL of the effective rights principal that owns this
          resource.

          The value of the user.  If it DAV:supported-privilege-set property is a Grant ACE, then
          tree of supported privileges:

            DAV:acl (abstract)
               |
               +-- DAV:read
               +-- DAV:write (abstract)
                     |
                     +-- http://www.acl.org/create
                     +-- http://www.acl.org/update
                     +-- http://www.acl.org/delete
                +-- DAV:read-acl
                +-- DAV:write-acl

          The DAV:current-user-privilege-set property contains two
          privileges, DAV:read, and DAV:read-acl. This indicates that
          the current authenticated user is granted all rights in only has the ACE.  If
               it is a Deny ACE, then ability to read
          the user is denied all rights in resource, and read the ACE.
               Requested rights may be compared with DAV:acl property on the effective rights to
               determine if access should be granted.
               ACE Combining Algorithm: resource.

          The FirstSpecific model never matches
               more than one ACE to DAV:acl property contains a user, thus there's no need to combine the
               rights of multiple ACEs.
               Example Implementation: UNIX rights (rwx for user:group:world) is
               an example of the FirstSpecific model.

          5.3.2ExplicitDenyPrecedence

               The ExplicitDenyPrecedence model has the following
               characteristics:
               Order set of four ACEs: All Explicit ACEs must precede all Inherited ACEs.
               Within the group of Explicit ACEs, all Deny ACEs must precede all
               Grant ACEs.  Inherited ACEs are placed in the order in which they
               are inherited.  ACEs inherited from

          ACE #1: The principal identified by the resource's parent come
               first, then ACEs from URL
          http://www.foo.org/users/esedlar is granted the grandparent, DAV:read,
          DAV:write, and so on. DAV:read-acl privileges.

          ACE Matching and Combining Algorithm: #2: The ACE matching and
               combining algorithms are not distinct in this model and must be
               described together.  A set of "Granted rights" and a set of
               "Denied rights", both initialized with zero rights, are
               maintained in principals identified by the algorithms to check for Requested Rights and to
               calculate Effective Rights.  In both cases, ACEs URL
          http://www.foo.org/groups/marketing/ are evaluated in
               the order in which they appear in the ACL, from first to last.
               Checking for Requested Rights: For each ACE evaluated, if denied the DAV:read
          privilege.  In this example, the principal URL identifies a
          group, which is represented by a collection principal.

          ACE
               matches #3: In this ACE, the current user, then:
               . if it principal is a Grant property principal,
          specifically the DAV:owner property. When evaluating this ACE, any rights in
          the ACE that are not
                 already in value of the "Granted rights" or "Denied rights" sets are
                 added DAV:owner property is retrieved, and is
          examined to the "Granted rights" set

               . see if it contains a DAV:href XML element. If so,
          the URL within the DAV:href element is read, and identifies a Deny
          principal. In this ACE, any rights in the owner is granted DAV:read-acl, and
          DAV:write-acl privileges.

          ACE that are not
                 already in #4: This ACE grants the "Granted rights" or "Denied rights" sets are
                 added to DAV:all principal (all users) the "Denied rights" set

               If
          DAV:read privilege. This ACE is inherited from the "Granted rights" set now contains all rights in resource

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 13] 
          http://www.foo.org/top/, the set parent collection of
               "requested rights," then no more this
          resource.

     6  ACL SEMANTICS

          The ACL semantics define how multiple ACEs are evaluated and the
               algorithm completes with "Requested Access Granted."
               If the "Denied rights" set now contains any right that is in match the
               set of "requested rights," then no more ACEs
          current user are combined, what are evaluated and the algorithm completes with "Requested Access Denied."
               If neither constraints on how
          ACEs can be ordered, and which principals must have an ACE.

          <!ELEMENT acl-semantics ANY>
           ANY value: zero or more of these cases is true, then the next ACL semantic elements

     6.1  ACE is
               evaluated.  If there are no more Combination

          The DAV:ace-combination element defines how privileges from
          multiple ACEs present in the ACL, then that match the algorithm completes with "Requested Access Denied" since current user will be combined to
          determine the
               accumulated Granted access rights did not contain all of for that user.  Multiple ACEs may
          match the requested
               rights.
               Calculating same user because the effective rights of same principal can appear in
          multiple ACEs, because multiple principals can identify the
          same user, and because one principal can be a user: As member of
          another principal.

          <!ELEMENT ace-combination
           (first-match | all-grant-before-any-deny | no-deny)>

     6.1.1 DAV:first-match ACE Combination

          The ACEs are evaluated in the order in which they appear in
          the check for
               requested rights, for each ACE evaluated, if ACL.  If the first ACE that matches the current user, then:
               . if it is a Grant ACE, any rights in the ACE that are user does
          not
                 already in grant all the "Granted rights" or "Denied rights" sets are
                 added to privileges needed for the "Granted rights" set

               . if it is a Deny ACE, any rights in request, the
          request MUST fail.

          <!ELEMENT first-match EMPTY>

     6.1.2 DAV:all-grant-before-any-deny ACE that Combination

          The ACEs are not
                 already evaluated in the "Granted rights" or "Denied rights" sets are
                 added to order in which they appear in
          the "Denied rights" set ACL.  If an evaluated ACE denies a privilege needed for
          the union of request, the "Granted rights" and "Denied rights" now
               contains request MUST fail.  If all possible rights, then no more ACEs are have been
          evaluated and
               the algorithm returns without the Granted rights as user being granted all privileges needed
          for the set of Effective
               Rights.
               Otherwise, request, the next request MUST fail.

          <!ELEMENT all-grant-before-any-deny EMPTY>

     6.1.3 DAV:no-deny ACE is evaluated.  If there are no more Combination

          All ACEs
               present in the ACL, then all rights present in the "Granted
               rights" set are returned as Effective Rights.
               Example Implementation: Microsoft Windows NT canonical ACLs are
               an example of this model.

          6  ACL INHERITANCE

               To support a more scalable administration model for configuration
               of access control information, the spec defines an ACL
               inheritance model that enables an ACL, or elements of an ACL, to
               be inherited and reused by other resources. are evaluated.  An ACL-compliant
               implementation "individual ACE" is not required to support inheritance.
               Typically, an ACL defined on a container resource may be
               inherited by children of that container, grandchildren if they
               exist, and so on down one
          whose principal identifies the tree.  Although this hierarchical tree
               model of inheritance current user.  A "group ACE" is
          one whose principal is popular, this spec does not require an
               implementation's ACL inheritance model to follow a tree structure
               where child resource inherits from parent resource.  Nonetheless,
               for convenience, this description of inheritance assumes collection that contains a
               child resource would inherit access control information from its
               parent.

          6.1 Inheritable ACEs

               Access control information is inherited at the granularity of an
               ACE.  An inherited ace is identified by the presence of the
               DAV:inherited element in principal
          that identifies the DAV:inheritanceflags property.  An
               "Explicit" ACE current user.  A privilege is granted if
          it is granted by an individual ACE defined directly on a resource, rather
               than inherited from and not denied by an
          individual ACE, or if it is granted by a different resource.  An group ACE without the
               DAV:inherited element is and not
          denied by definition an Explicit individual or group ACE.  Only
               Explicit  A request MUST fail if
          any of its needed privileges are not granted.

          <!ELEMENT no-deny EMPTY>

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 14] 
     6.2 ACE Ordering

          The DAV:ace-ordering element defines a constraint on how the
          ACEs may updated by can be ordered in the client.
               To indicate ACL.

     6.2.1 DAV:deny-before-grant ACE Ordering

          This element indicates that all deny ACEs must precede all
          grant ACEs.

          <!ELEMENT deny-before-grant EMPTY>

     6.3 Required Principals

          The required principal elements identify which principals must
          have an ACE should be inherited by child resources,
               the DAV:inheritanceflags should contain:
               . DAV:objectinherit to indicate that non-container children
                 should inherit defined in the ACE,

               . DAV:containerinherit to indicate that container children
                 should inherit ACL.

          <!ELEMENT required-principal
            (href | all | authenticated | unauthenticated | property |
          self)>

          For example, the ACE, or

               . both to indicate following element requires that all child resources should inherit the
                 ACE.

          6.2 Updating an inherited ACE

               When
          contain a child resource ACL inherits an ACE, DAV:owner property ACE:

          <D:required-principal xmlns:D="DAV:">
            <D:property> <D:owner/> </D:property>
          </D:required-principal>

     7  ACCESS CONTROL AND EXISTING METHODS

          This section defines the DAV:inherited
               flag is present impact of access control
          functionality on existing methods.

     7.1 OPTIONS

          If the ACE to indicate that this ACE is read-
               only (it may only be edited on server supports access control, it MUST return "access-
          control" as a field in the DAV response header from an OPTIONS
          request on any resource where implemented by that server.

     7.1.1 Example - OPTIONS

          >>REQUEST

            OPTIONS /foo.html HTTP/1.1
            Host: www.webdav.org
            Content-Length: 0

          >>RESPONSE

            HTTP/1.1 200 OK
            DAV: 1, 2, access-control

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 15] 
            Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL

          In this example, the ACE was
               explicitly defined).  To assist users who want to make changes
               to OPTIONS response indicates that the rights
          server supports access control and that appear /foo.html can have its
          access control list modified by the ACL method.

     8  ACCESS CONTROL METHODS

     8.1 ACL

          A DAV:acl property of a resource is modified by the ACL
          method.  A new DAV:acl value must be written in an its entirety,
          including any inherited ACE, ACEs.  Unless the resource from
               which DAV:acl property of
          the ACE was inherited (and therefore, on which resource can be updated to be exactly the
               explicit ACE is defined and editable) is identified value specified
          in the
               DAV:inheritancesource property.  If the inheritance source
               cannot be determined or if ACL request, the system is unable to generate ACL request MUST fail.  If a
               valid URI server
          restricts the set of ACEs visible to the resource from which current user via the ACE was inherited,
               DAV:inheritancesource contains
          DAV:acl property, then the special tag DAV:unknown.

          6.3 Propagate ACE but do not use for Access Check on this resource

               In some cases, an ACE (whether explicit or inherited) may be
               present on a container ACL purely for request would only replace the sake
          set of propagating
               the ACE ACEs visible to child objects the current user, and NOT would not affect
          any ACE that was not visible.

          In order to be used for access control avoid overwriting DAV:acl changes by another
          client, a client SHOULD acquire a WebDAV lock on the container itself.  In this case, the  optional
               DAV:inheritonly flag is present on resource
          before retrieving the ACE to indicate DAV:acl property of a resource that it should
               not be used for access check
          intends on this container.

          6.4 Propagate to immediate children only

               To indicate that an ACE should be inherited by children, but not
               by grandchildren updating.

     8.1.1 ACL Preconditions

          An implementation MAY enforce one or any further down the tree, more of the optional
               DAV:nopropagateinheritance flag is present following
          constraints on the ACE.  This
               flag indicates that when this ACE is inherited by child objects,
               the DAV:objectinherit and/or DAV:containerinherit elements must
               be removed from the inherited ACE.

          6.5 Protect ACL from inheritance

               To prevent an ACL from inheriting any ACEs, the optional
               DAV:protectaclfrominheritance property is set on the resource. request.  If this property the constraint is present on violated,
          a resource, 403 (Forbidden) response MUST be returned and the DAV:inherited indicated
          XML element must not MUST be present on any ACEs returned in that resource's ACL.
               Other inheritance flags may be present on the ACEs response body.

          <DAV:protected/>: An implementation MAY protect an ACE from
          modification or deletion.  For example, some implementations
          implicitly grant the DAV:owner of a resource DAV:read-acl and
          DAV:write-acl privileges, and this
               resource, since this ACL may cannot be changed by a
          client.

          <DAV:too-many-aces/>: An implementation MAY limit the source number
          of inheritable ACEs
               for the subtree under this resource.

          7  XML SCHEMA FOR DEFINED ELEMENTS

                 <?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"

                 targetNamespace="http://www.ietf.org/standards/webdav"
                         xmlns:dav="http://www.ietf.org/standards/webdav"
                         blockDefault="#all" elementFormDefault="qualified">

                 <element name="right" abstract="true">
                   <complexType content="empty">
                 </element>

                 <!--For those folks not familiar with XML Schema, minOccurs
                      defaults in an ACL.  However, ACL-compliant servers MUST
          support at least one ACE granting privileges to 0, a single
          principal, and maxOccurs defaults one ACE granting privileges 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"
                 equivClass="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>

                 <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"/>
                     <complexType>
                       <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"/>
                       </choice>
                     </complexType>
                   </element>
                   <element name="DAV:principal" minOccurs="0" maxOccurs="1">
                     <complexType>
                       <element name="DAV:principal-name" type="string"
                 minOccurs="1"/>
                       <element name="DAV:principal-type" type="string"
                 minOccurs="1"/>
                     </complexType>
                   </element>
                 </complexType>

                 <element name="DAV:acl">
                   <complexType>
                     <element name="DAV:ace" type="DAV:ace"
                            minOccurs="0" maxOccurs="unbounded"/>
                   </complexType>
                 </element>

                 <element name="DAV:rights">
                   <complexType>
                     <choice minOccurs="1" maxOccurs="unbounded">
                       <element ref="DAV:right"/>
                     </choice>
                   </complexType>
                 </element>
                 </schema>

          8  INTERNATIONALIZATION CONSIDERATIONS

               To be supplied.

          9  SECURITY CONSIDERATIONS

               To be supplied.

          10 SCALABILITY

               To a collection
          principal.

          <DAV:non-inherited-must-precede-inherited/>: All non-inherited
          ACEs MUST precede all inherited ACEs.

          <DAV:deny-must-precede-grant/>: All non-inherited deny ACEs
          MUST precede all non-inherited grant ACEs.

          <DAV:acl-requires-lock-token/>: If a resource is locked, the
          lock token MUST be supplied.

          11 AUTHENTICATION

               Authentication mechanisms defined specified in WebDAV will also apply to
               WebDAV ACL.

          12 IANA CONSIDERATIONS

               This document uses the namespace defined ACL request.

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 16] 
     8.1.2 Example: the ACL method

          In the following example, user "fielding", authenticated by [RFC2518] for XML
               elements.  All other IANA considerations mentioned
          information in [RFC2518]
               also applicable to WebDAV ACL.

          13 INTELLECTUAL PROPERTY

               The following notice is copied from RFC 2026, section 10.4, the Authorization header, grants the principal
          identified by the URL http://www.foo.org/users/esedlar  (i.e.,
          the user "esedlar") read and
               describes write privileges, grants the position
          owner of the IETF concerning intellectual
               property claims made against this document.

               The IETF takes no position regarding resource read-acl and write-acl privileges, and
          grants everyone read privileges inherited from the validity or scope of any
               intellectual property or other rights that might be claimed to
               pertain to parent
          collection http://www.foo.bar/top/.

          >> Request <<

          ACL /top/container HTTP/1.1
          Host: www.foo.org
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxxx
          Authorization: Digest username="fielding",
             realm="users@foo.org", nonce="...",
             uri="/top/container/", response="...", opaque="..."

          <?xml version="1.0" encoding="utf-8" ?>
          <D:acl xmlns:D="DAV:">
            <D:ace>
              <D:principal>
                <D:href>http://www.foo.org/users/esedlar</D:href>
              </D:principal>
              <D:grant>
                <D:privilege> <D:read/> </D:privilege>
                <D:privilege> <D:write/> </D:privilege> </D:grant>
            </D:ace>
            <D:ace>
              <D:principal>
                <D:property> <D:owner/> </D:property> </D:principal>
              <D:grant>
                <D:privilege> <D:read-acl/> </D:privilege>
                <D:privilege> <D:write-acl/> </D:privilege> </D:grant>
            <D:ace/>
            <D:ace>
              <D:principal> <D:all/> </D:principal>
              <D:grant>
                <D:privilege> <D:read/> </D:privilege></D:grant>
              <D:inherited>
                <D:href>http://www.foo.org/top/</D:href> </D:inherited>
            </D:ace> </D:acl>

          >> Response <<

          HTTP/1.1 200 OK

     8.1.3Example: ACL method failure

          In the implementation or use other technology described following request, user "fielding", authenticated by
          information in this document or the extent Authorization header, attempts to which any license under such
               rights might or might not be available; neither does it represent
               that it grant
          principal identified by the URL
          http://www.foo.org/users/esedlar  (i.e., the user "esedlar")
          read privileges, but fails because an implicit ACE has made any effort to identify any such rights.
               Information on been

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 17] 
          omitted (e.g. the IETF's procedures with respect to rights in
               standards-track ACE granting the DAV:owner DAV:read-acl and standards-related documentation
          DAV:write-acl privileges).

          >> Request <<

          ACL /top/container HTTP/1.1
          Host: www.foo.bar
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxxx
          Authorization: Digest username="fielding",
             realm="users@foo.org", nonce="...",
             uri="/top/container/", response="...", opaque="..."

          <?xml version="1.0" encoding="utf-8" ?>
          <D:acl xmlns:D="DAV:">
            <D:ace>
              <D:principal>
                <D:href>http://www.foo.bar/users/esedlar</D:href>
              </D:principal>
              <D:grant>
                <D:privilege> <D:read/> </D:privilege> </D:grant>
            </D:ace>
          </D:acl>

          >> Response <<

          HTTP/1.1 403 Forbidden
          Content-Type: text/xml; charset="utf-8"
          Content-Length: xxx

          <?xml version="1.0" encoding="utf-8" ?>
          <DAV:cannot-change-implicit-ace/>

     9  INTERNATIONALIZATION CONSIDERATIONS

          In this specification, the only human-readable content 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 DAV:authentication-id property, found on
          principal resources.  This property contains the name used to obtain
          authenticate a general license or
               permission for the use of such proprietary rights principal, typically by implementers
               or users of a user entering this specification can be obtained from
          name into a password entry screen.  As a result, the IETF
               Secretariat.

               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
          authentication-id must be required capable of representing names in
          multiple character sets.  Since DAV:authentication-id is a
          WebDAV property, it is represented on-the-wire as XML [REC-
          XML], and hence can leverage XML's language tagging and
          character set encoding capabilities. Specifically, XML
          processors must, at minimum, be able to practice read XML elements
          encoded using the UTF-8 [UTF-8] encoding of the ISO 10646
          multilingual plane. XML examples in this standard.  Please address specification
          demonstrate use of the information to charset parameter of the Content-Type
          header, as defined in [RFC2376], as well as the
               IETF Executive Director.

          14 ACKNOWLEDGEMENTS

               This protocol XML "encoding"
          attribute, which together provide charset identification
          information for MIME and XML processors.

          For properties other than DAV:authentication-id, it is
          expected that implementations will treat the collaborative product of property names
          and values as tokens, and convert these tokens into human-

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 18] 
          readable text in the user's language and character set when
          displayed to a person.  Only a generic WebDAV ACL
               design team: xxx, yyy, zzz.  We property display
          utility would like to acknowledge the
               foundation laid for us by display these values in their raw form.

          For error reporting, we follow the authors convention of HTTP/1.1
          status codes, including with each status code a short, English
          description of the WebDAV and HTTP
               protocols upon which code (e.g., 200 (OK)).  While the
          possibility exists that a poorly crafted user agent would
          display this protocol is layered, message to a user, internationalized applications
          will ignore this message, and display an appropriate message
          in the invaluable
               feedback from the WebDAV working group.

          15 INDEX

               To be supplied.

          16 REFERENCES

               [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, user's language 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 character set.

          Further internationalization considerations for use this protocol
          are described 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 the WebDAV Distributed Authoring - WEBDAV", Microsoft,
               U.C.Irvine, Netscape, Novell, 1999
               <http://www.ietf.org/rfc/rfc2518.txt>.

          17 AUTHORS' ADDRESSES

               Geoffrey Clemm
               Rational Software
               20 Maguire Road
               Lexington, MA
               Email: geoffrey.clemm@rational.com

               Anne Hopkins
               Microsoft Corporation
               One Microsoft Way
               Redmond, WA
               Email: annehop@microsoft.com

               Eric Sedlar
               Oracle Corporation
               500 Oracle Parkway
               Redwood Shores, CA  94065
               Email: esedlar@us.oracle.com

          18 STILL TO DO :

               . Describe protocol
          specification [RFC2518].

     10 SECURITY CONSIDERATIONS

          Applications and users of this access control protocol should
          be aware of several security considerations, detailed below.
          In addition to the interactions with resource locking.  I'm not
                 clear what discussion in this document, the resolution was as far as locking security
          considerations detailed in the ACL
                 separately from locking HTTP/1.1 specification
          [RFC2616], the resource.

               . Add a section defining new error codes/messages?  Or WebDAV Distributed Authoring Protocol
          specification [RFC2518], and the XML specification (discussed
          in [RFC2376]) should we
                 make be considered in a pass through security analysis of
          this protocol.

     10.1 Increased Risk of Compromised Users

          In the doc and ensure all possible error
                 conditions absence of a mechanism for remotely manipulating access
          control specifications, if a single user's authentication
          credentials are mapped to existing errors?

               . Articulate that compromised, only those resources for which
          the required DAV:principal property should be
                 able to user has access permission can be used for equality checks.  Equality checks were
                 mentioned as one reason why read, modified, moved,
          or deleted. With the introduction of this property should be mandatory,
                 even access control
          protocol, if a single compromised user has the URI is fake.

               . Update "Setting Access Control Information" and ability to address
                 whether read-only (ie, inherited) ACEs should
          change ACLs for a broad range of other users (e.g., a super-
          user), the number of resources that could be stripped out altered by a
          single compromised user increases. This risk can be mitigated
          by limiting the client prior to PROPPATCH.  Fix, if necessary, comments number of people who have write-acl privileges
          across a broad range of resources.

     10.2 Authentication-id Property and Dictionary Attacks

          Every principal has a DAV:authentication-id property defined
          on editing inherited ACEs it, which provides the name used to authenticate this
          principal, typically the username portion of a
          username/password authentication scheme. An attacker can use
          the information in ACL Inheritance section.

               . Renaming DAV:rights this property when attempting either a
          brute-force, or a dictionary attack to DAV:effectiverights? and update sample

               . Revisit description guess the principal's
          identifying password. By providing the username in
          DAV:authentication-id, the scope of Property ACEs an attack can be reduced
          to reflect group
                 agreement.  Add sample code.  Anne will need a single, valid username. Furthermore, it is possible that
          principals can potentially belong to update
                 Semantics descriptions a collection. In this

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 19] 
          case, it is possible to address property ACEs.

               . Update use the self, ownergroup stuff according PROPFIND method to eventual
                 agreements.

               . Make document consistent:

                      o Ensure all property descriptions indicate whether retrieve
          the DAV:authentication-id property is:

                           . "live" or "dead"
                           . read-only or writable
                           . REQUIRED or OPTIONAL
                      o Ensure sample XML exists for from all new properties, tags,
                         etc.
                      o Complete empty sections, like Scalability
          19 OPEN ISSUES:

               Issue          Description                   Status
               1. Aggregate of the principals
          in a right, if granted, collection, thus providing multiple usernames that     Now addressed can be
          the focus of attack.

          To reduce this risk, the DAV:authentication-id property should
          not be world-readable. Which principals are granted default
          read permission for DAV:authentication-id should be carefully
          considered in any deployment of this protocol.

     10.3 Risks of the read-acl Privilege

          The ability to read the access permissions (stored in the
          DAV:acl property), or the privileges permitted the currently
          authenticated user (stored in
                rights        grants access to a the DAV:current-user-privilege-
          set of     spec.
                              subsidiary rights
               2. Rights      How do we find out what       Now addressed in
                discovery     rights are applicable to property) on a    spec.
                              given resource?  Can this be
                              done by resource type, to
                              avoid may seem innocuous, since reading
          an ACL cannot possibly affect the need resource's state. However,
          if all resources have world-readable ACLs, it is possible to ask each
                              resource this question?
               3. Defined     Should we define a 'group'    Collection
                list of       principal type which          principals will
                "principal-   specifically requires
          perform an exhaustive search for those resources that have semantic
                types"        principal membership be       meaning (recursive
                              recursive?  This might make   membership applies)
                              administrative client
                              implementation easier.
                              Should
          inadvertently left themselves in a vulnerable state, such as
          being world-writeable. Once found, this vulnerability can be
          exploited by a
                              recommendation rather than a
                              requirement?
               4. Reserved    Is the list denial of 'reserved'     Discussed service attack in 4/28
                principals    principals complete (         conference call.
                              'owner', 'all', or            Still Open.
                              'unauthenticated', 'all-
                              authenticated', etc.)
               5. Standard    Is which the list of standard       Discussed on
                rights        rights complete?              conference call and
                                                            updated once open
          resource is repeatedly overwritten. Alternately, writeable
          resources can be modified in
                                                            draft.
               6. XML         Do we need undesirable ways.

          To reduce this risk, read-acl privileges should not be granted
          to scope the       Use DAV namespace,
                namespace     namespace of our XML          like other working unauthenticated principals, and restrictions on read-acl
          privileges for ACL       elements via <?namespace      groups.  Closed.
                              href =
                              "http://www.ietf.org/standar
                              ds/acl/ AS = "A"?>, or can
                              we use authenticated principals should be carefully
          analysed when deploying this protocol.

     11 AUTHENTICATION

          Authentication mechanisms defined in WebDAV will also apply to
          WebDAV ACL.

     12 IANA CONSIDERATIONS

          This document uses the regular DAV namespace (shared defined by both
                              versioning and RFC 2518)?
               7. Rights      What is the method [RFC2518] for        Not a method.
                discovery     figuring out the list of      DAV:Access-Rights
                              rights?                       property available.
                                                            Closed.
               8. Multiple    Are we sure we don't want to  Requires an
                principals/A  allow multiple                explicit vote
                CE [CKNIGHT]  principals/ACE?
               9. Grant &     Are we sure we don't want to  Added to spec.
                Deny          allow grant & deny XML
          elements.  All other IANA considerations mentioned in the     Decision reversed
                [CKNIGHT]     same ACE?  Note that this     per 6/23 call and
                              simplifies the ACE rule to    added
          [RFC2518] also applicable to spec 01.3.
                              disallow two ACEs for WebDAV ACL.

     13 INTELLECTUAL PROPERTY

          The following notice is copied from RFC 2026, section 10.4,
          and describes the     Closed.
                              same principal.
               10.  Semantic  Do we need to specify stuff   Yes.  Added to
                meaning position of    like whether or not           spec.
                principal     collection principal
                colls.        membership is recursive?
                [GCLEMM]
               11.  principa the IETF concerning intellectual
          property claims made against this document.

          The semantic meaning IETF takes no position regarding the validity or scope of       Added to spec=97
                l-name vs.    principal-name should be      principal-name
                display-name  defined,
          any intellectual property or display-name      holds
                [GCLEMM]      should other rights that might be used                "authentication"
                                                            string and
                                                            displayname holds
                                                            readable string
               12.  ChangeOw  Can servers disallow          PROPPATCH support
                ner [GCLEMM/  changing
          claimed to pertain to the owner?           for owner is
                CKNIGHT]                                    optional implementation or use other
          technology described in this document or the
                                                            spec.
               13.  Local     What text is needed           Open
                principal     regarding principal URLs
                URLs          without hostname:port
               14.  ACL as    To what extent should ACLs    ACLs are
                properties to which
          any license under such rights might or might not be treated as properties?     properties. Closed.
               15.  Semantic  Would available;

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 20] 
          neither does it be more appropriate  Open
                s Model represent that it has made any effort to
          identify these semantic
                names         models by their
                [ANNEHOP]     implementation names, ie,
                              UNIX, NT Canonical?  Could any such rights.  Information on the IETF's
          procedures with respect to rights in standards-track and
          standards-related documentation can be easier found in BCP-11.
          Copies of claims of rights made available for developers publication and
                              users.  Neither
          any assurances of these
                              models is likely licenses to be re-
                              used made available, or the result
          of an attempt made to obtain a general license or permission
          for the use of such proprietary rights by another
                              implementation.
               16.  Addition  Do we need implementers or
          users of this specification can be obtained from the IETF
          Secretariat.

          The IETF invites any interested party to include         Open
                al Semantics  additional ACL semantics
                models        models?  What bring to its
          attention any copyrights, patents or patent applications, or
          other systems
                [ANNEHOP]     (.htaccess?) do we need proprietary rights that may cover technology that may be
          required to practice this standard.  Please address the
          information to the IETF Executive Director.

     14 ACKNOWLEDGEMENTS

          This protocol is the collaborative product of the WebDAV ACL
          design team: Bernard Chester, Geoff Clemm (Rational), Anne
          Hopkins (Microsoft), Barry Lind (Xythos), Sean Lyndersay
          (Microsoft), Eric Sedlar (Oracle), Greg Stein (Apache.org),
          and Jim Whitehead (UC Santa Cruz). Prior work on WebDAV access
          control protocols has been performed by Yaron Goland, Paul
          Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff. We would
          like to
                              support?
               17.  Detectin  How are WebDAV Access         Open
                g a WebDAV    Control compliant servers
                Access        detected?  Define acl
                Control       extension acknowledge the foundation laid for us by the DAV:
                server        header?
                [SEANLYND]
               18.  DAV:user  If we're going to be          Open
                /group or     treating users as resources,
                DAV:resource  then we should go all authors
          of the
                /collection   way.
                [SEANLYND]
               19.  Per-      ability WebDAV and HTTP protocols upon which this protocol is
          layered, and the invaluable feedback from the WebDAV working
          group.

     15 REFERENCES

     15.1 Normative References

          [RFC2119] S.Bradner, "Key words for use in RFCs to specify rights on Indicate
          Requirement Levels." RFC 2119, BCP 14, Harvard, March, 1997.

          [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen,
          "Extensible Markup Language (XML)." World Wide Web Consortium
          Recommendation REC-xml-19980210. http://www.w3.org/TR/REC-xml-
          19980210.[RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H.
          Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext
          Transfer Protocol -- HTTP/1.1." RFC 2616. U.C.Irvine, Compaq,
          Xerox, Microsoft, MIT/LCS, June, 1999.

          [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S.
          Lawrence, P. Leach, A. Luotonen, L. Stewart, "HTTP
          Authentication: Basic and Digest Access Authentication. " RFC
          2617. Northwestern University, Verisign, AbiSource, Agranat,
          Microsoft, Netscape, Open
                property Market, June, 1999.

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 21] 
          [RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D.
          Jensen, "HTTP Extensions for Distributed Authoring _ WEBDAV."
          RFC 2518. Microsoft, U.C.Irvine, Netscape, Novell, February,
          1999.

          [UTF-8] F. Yergeau, "UTF-8, a per-property basis could
                ACEs transformation format of Unicode
          and ISO 10646." RFC 2279. Alis Technologies. January, 1998.

     15.2 Informational References

          [RFC2026] S.Bradner, "The Internet Standards Process _
          Revision 3." RFC 2026, BCP 9. Harvard, October, 1996.

          [RFC2396] E. Whitehead, M. Murata, "XML Media Types." RFC
          2376. U.C. Irvine, Fuji Xerox Info. Systems. July, 1998. (This
          RFC will soon be very useful for webdav.
                [ANNEHOP]     consider adding an optional
                              propertytype-id to superseded by <draft-murata-xml-09.txt>,
          which has been approved by the ace?
               20.  Register  Need to describe process for  Open
                ing           registering IESG as a new ACL
                Semantics     semantics model option.
                Models
                [ANNEHOP]
               21.  Strip     Should the client strip all   Agreed to strip
                Inherited     Inherited (read-only) ACEs    inherited ACEs in
                ACEs?         prior to setting Proposed Standard,
          but not yet issued as an ACL?  Do  6/23 call. RFC.)

     16 AUTHORS' ADDRESSES

          Geoffrey Clemm
          Rational Software
          20 Maguire Road
          Lexington, MA 02421
          Email: geoffrey.clemm@rational.com

          Anne
                [ANNEHOP] Hopkins
          Microsoft Corporation
          One Microsoft Way
          Redmond, WA 98052
          Email: annehop@microsoft.com

          Eric Sedlar
          Oracle Corporation
          500 Oracle Parkway
          Redwood Shores, CA 94065
          Email: esedlar@us.oracle.com

          Jim Whitehead
          U.C. Santa Cruz
          Dept. of Computer Science
          Baskin Engineering
          1156 High Street
          Santa Cruz, CA 95064
          Email: ejw@cse.ucsc.edu

     17 STILL TO DO

          * If we need a flag that           re-opening issue.
                              indicates whether can add more elements to DAV:resourcetype, we can
            eliminate DAV:is-principal.

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 22] 
          * Add back the server
                              accepts a client update of
                              inherited ACEs (to support
                              client-side propagation of
                              inheritance)?  And/or XML schema if provides info not in the DTD's.

          * Consider adding a flag
                              to indicate DAV:matching-principals, which identifies
            all ACL principals that match the client
                              WANTs to set inherited ACEs? current user.

          * Add DAV:ordering-constraints, DAV:required-principals, and
            DAV:ace-combination-semantics as sub-elements of DAV:acl-
            semantics.

     Clemm, Hopkins, Sedlar, Whitehead                        [Page 23]