INTERNET-DRAFT                                             P. J. Leach
Expires: April 1998                                       Y. Y. Goland
Standards Track                                  Microsoft                   Eric Sedlar, Oracle Corporation
WebDAV Working Group
    draft-ietf-webdav-acl-01.txt   Geoffrey Clemm, Rational Software

    Expires November 10, 1997 1, 2000         May 1, 2000

                     Access Control Extensions to WebDAV ACL Protocol
                      draft-ietf-webdav-acl-00.txt

    Status of this Memo

    This document is an Internet-Draft. Internet-Draft and is in full conformance with all
    provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering Task
    Force (IETF), its areas, and its working groups. Note that other
    groups may also distribute working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time. It is inappropriate to use Internet-Drafts Internet- Drafts as reference
    material or to cite them other than as "work in progress."

   To learn the current status

    The list of any Internet-Draft, please check the
   "1id-abstracts.txt" listing  contained in the current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim). can be accessed at
    http://www.ietf.org/shadow.html.

    Abstract

    This memo document specifies the format a set of methods, headers, and manipulation mechanisms for
   access control lists (ACLs) for resource-types
    that define the WebDAV objects.

Contents

   Status Access Control extensions to the HTTP/1.1
    protocol.

    Sedlar, Clemm                                       [Page 1] 
    Table of this Memo................................................1
   Abstract...........................................................1
   Contents...........................................................1
   1. Introduction....................................................2
   2. Principals Identifiers..........................................2
   3. Granting and Denying Rights.....................................3
   4. ACL Inheritance.................................................4
   5. Properties and ACLs.............................................4
   6. Contents

    1 INTRODUCTION............................................3
    1.1 Notational Conventions................................3

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

    3 RIGHTS..................................................4
    3.1 RIGHTS-DISCOVERY method...............................5
    3.2 Rights Definitions..............................................5
   7. Default Principal Types.........................................7
   8. ACL Method......................................................7
   9. Examples.......................................................11
   10.Authors' Addresses.............................................13
   11.Bibliography...................................................14

1.   Introduction defined by WebDAV..............................6
     3.2.1 read Right........................................6
     3.2.2 write Right.......................................6
     3.2.3 readacl Right.....................................6
     3.2.4 writeacl Right....................................6
     3.2.5 all Right.........................................6

    4 ACCESS CONTROL PROPERTIES...............................7
    4.1 Example 1 - Retrieving Access Control information.....8

    5 USING ACLS..............................................9

    6 ACL METHOD.............................................10
    6.1 Example 1 - Setting ACLs.............................10

    7 ACL INHERITANCE / DEFAULT ACLS.........................11

    8 XML SCHEMA FOR DEFINED ELEMENTS........................12

    9 INTERNATIONALIZATION CONSIDERATIONS....................13

    10  SECURITY CONSIDERATIONS..............................13

    11  SCALABILITY..........................................13

    12  AUTHENTICATION.......................................13

    13  IANA CONSIDERATIONS..................................13

    14  INTELLECTUAL PROPERTY................................13

    15  ACKNOWLEDGEMENTS.....................................14

    16  INDEX................................................14

    17  REFERENCES...........................................14

    18  AUTHORS' ADDRESSES...................................15

    19  STILL TO DO :........................................15

    Sedlar, Clemm                                       [Page 2] 
    1  INTRODUCTION

         The basic model for underlying principle of access control, informally expressed, control is that who you are
         determines how you can access a resource. The "who you are" is
         defined by a principal "principal" identifier; users, client software,
   servers
         servers, and groups of the previous have principal identifiers.
         The "how" is determined by an "access control list" (ACL)
         associated with a resource.  An ACL contains Access Control Elements (ACE). An ACE specifies a set of principals, "access
         control entries" (ACEs), where each ACE specifies a set of granted rights, principal and
         a set of denied
   rights.

   Rights may be generic, such as "read", "write", or "delete", rights that are either granted or they
   might be specific denied to the kind of resource protected by that ACL,
   such as (perhaps) "send-to", "unsubscribe", and "administer" for
   mailing lists.

   When a resource
         principal.

    1.1 Notational Conventions

         The augmented BNF used by this document to describe protocol
         elements is created it inherits a set described in Section 2.1 of default ACL
   properties from a designated resource, referred [RFC2068]. Because this
         augmented BNF uses the basic production rules provided in Section
         2.2 of [RFC2068], those rules apply to this document as an ACL source. well.

         The inheritance can key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
         NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
         "OPTIONAL" in this document are to be "static", so interpreted as described in
         [RFC2119].

    2  PRINCIPALS

         A principal identifies an entity that subsequent changes can be given access rights
         to the
   ACL source do not effect the new resources ACL properties; HTTP resources.  On many implementations, a user or it can a group
         will be "dynamic", so that subsequent changes examples of principals, but other types of principals are reflected in the new
   resource's ACL properties.

   Properties on a resource, by default, dynamically inherit from the
   ACL on
         possible.  For the resource. In most part, any classification or other words,
         information about the resource entity identified by a principal is opaque
         with respect to this specification, and is dependent on the ACL source
   for the properties. However individual properties can be given their
   own ACL.

2.
         implementation.

         Principals Identifiers are manifested to clients as a HTTP resource,
         identified by a URL.  The set of properties exposed by that
         resource are implementation dependent, although certain
         properties are required by this specification.  Those properties
         include:

           @ <dav:principalname>:     A "live" property containing the
                             name used to authenticate this principal identifier can identify
                             (typically typed into a single principal or login prompt/dialog).
                             [OPTIONAL]

           @ <dav:displayname>:  A property containing a compound human-readable
                             description of this principal.  This property
                             may be "live" and not settable via PROPPATCH.
                             [REQUIRED]

           @ <dav:principal-type>:    A single principal identifier refers to "live" property containing a single
   principal, such
                             classification word for this principal.  The
                             values <dav:user/> and <dav:group/> are
                             choices for value of this property
                             recommended by this spec. The presence of

    Sedlar, Clemm                                       [Page 3] 
                             this property can be used to distinguish it
                             as a person or principal from other resources on a program. A compound
                             WebDAV server.  (Note that <dav:resourcetype>
                             may not be used, as all collections must use
                             the value "collection" for <resourcetype>,
                             which wouldn't distinguish normal collections
                             from principal
   identifier specifies one or more principals. collections.) [REQUIRED]

         Server implementations may include any other descriptive
         information for a principal via properties.

         A compound principal resource may or may not necessarily just be a list 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. It  The WebDAV methods for examining
         maintaining collections (e.g. BIND, DELETE, PROPFIND) may in
   fact be used
         to maintain collection principals.  Membership in a program that accepts collection
         principal is recusive, so a principal identifier as input and
   output true or false to indicate membership.

   This specification relies upon in a collection principal A
         contained by collection principal B is a member of both
         collection principals.  Implementations not supporting recursive
         membership in principal collections can return an error if the underlying authentication
   mechanism(s)
         client attempts to provide bind collection principals into other
         collection principals.  Using WebDAV methods to alter the syntax content
         of a principal identifiers. Thus,
   for (e.g. using PROPPATCH or PUT) is outside the purposes scope
         of this specification, principal identifiers are
   opaque.

3.   Granting and Denying Rights

   An ACL can both grant and deny rights. The reason both types of
   grants are required is because not required, recommended, or
         forbidden by this spec.

    3  RIGHTS

         A right controls access to a particular set of compound principals. HTTP operations on
         a resource.  The consequence of the existence set of compound principals is rights that
   there are times when apply to a compound principal particular
         resource may be granted a right but
   a particular member vary with the <dav:resourcetype> of the compound principal may need to resource, as
         well as between different server implementations.  To promote
         interoperability, however, WebDAV defines a set of well-known
         rights (e.g. <dav:read> and <dav:write>), which can at least be denied
   access. In order
         used to make this possible an ACL must be able set some context to list
   principals both allowed and denied a right.

   By default all the other rights for defined on a principal MUST be denied.
         particular resource.

         Rights MAY
   only may be granted to a principal by an explicit listing of that
   principal in a "grant" section aggregates of an ACL.

   Additionally it is possible for access rights to collide in scope. other rights.  For example, a container one
         implementation may have an access split out a right which specifies controlling the ability of principals to delete the
         BIND children of that container.
   This would affect into a collection from the right allowing a
         resource to be removed from a principal's collection.  Since these rights
         control the ability to use write to a collection, these rights would
         be aggregated by the DELETE method.
   However <dav:write> right.  The relationships
         between atomic rights and aggregate rights can be discovered via
         the RIGHTS-DISCOVERY HTTP method on a particular internal child resource.
         Servers may have granted access specify some rights as abstract, which means that it
         may not appear in an ACL, but is described in the RIGHTS-
         DISCOVERY method to aid in setting context.  Server
         implementations must return the same response to DELETE. As such, the two RIGHTS-
         DISCOVERY method on all of the resources with the same
         <dav:resourcetype> value.

    Sedlar, Clemm                                       [Page 4] 
    3.1 RIGHTS-DISCOVERY method

         Rights discovery is a method with no arguments, that returns the
         rights could collide.

   The aggregation tree.  Each right appears as an XML element,
         where aggregate rights list all of their children as sub-
         elements.  Each right element can contain the following rules, processed in order, MUST
         attributes:

           @ abstract (Boolean):  "true" if this right cannot be used in
              an ACL/ACE.  Defaults to resolve
   scope conflicts between rights.

   1) In a conflict between a "false"

           @ description (string):  a human readable description of what
              this right granted by controls access to.  Required.

         For example, the following response might be generated to a parent and
         RIGHTS-DISCOVERY request on a right
   granted WebDAV server implemented by a child,
         relational database (where the right specified by the child MUST override.

   2) In a conflict between resource in this case corresponds
         to a right granted or denied to table):

         Request
         RIGHTS-DISCOVERY /schemas/scott/emp HTTP/1.1
         Host: www.foo.bar
         Content-type: text/xml; charset="utf-8"
         Content-Length: 0

         Response
         HTTP/1.1 200 Success
         Content-Type: text/xml
         Content-Length: xxxxx

         <?xml version="1.0" encoding="utf-8" ?>
         <?namespace href = "http://www.oracle.com/webdav/ AS = ORA"?>
         <D:response>
           <D:all abstract=true description="All access">
             <D:write abstract=true description="Write any database row">
               <ORA:insert abstract=false description="Insert a row"/>
               <ORA:update abstract=false description="Update a row"/>
               <ORA:delete abstract=false description="Delete a row"/>
             </D:write>
             <D:read abstract=false description="SELECT data from a compound
   principal row"/>
             <D:readacl abstract=false description="Read the ACL"/>
             <D:acadmin abstract=false description="Update the ACL and
         owner"/>
           </D:all>
         </D:response>

            It is envisioned that a right granted or denied to a member of WebDAV ACL-aware administrative client
         would list the compound
   principal, available in a dialog box, and allow the reference user to the member of the compound principal
   MUST override.

   Note that rule 2 is conceptually identical
         choose non-abstract rights to rule 1. apply in an ACE.  The concept
   represented by rules 1 and 2, stated generally, rights tree
         is useful programmatically to map well-known rights (defined by
         WebDAV or other standards groups) into rights that a specific
   references always overrides a more general reference.

3.1. Examples are supported
         by any particular server implementation.

    Sedlar, Clemm                                       [Page 5] 
    3.2 Rights defined by WebDAV

         The following examples demonstrate a situation where the specified
   conflict resolution rule would rights defined by WebDAV access control MUST be applied.

3.1.1.    Rule 1

   A resource specifies that principal A is granted present in
         the right response to delete the resource. A property RIGHTS-DISCOVERY method, although they may be
         abstract (and not usable within an ACE on the resource specifies that principal A
   is denied the a particular
         implementation).

    3.2.1read Right

         Name:            <dav:read>

         Purpose:         The read right provides and restricts access to delete
         information regarding the property. The conflict is resolved
   by rule 1, state of the resource is resource, including the parent
         resource's properties. Affected methods include GET and PROPFIND.
         The read right does not affect the property is the child.
   As such OPTIONS method since it
         reflects capabilities rather than state.

    3.2.2write Right

         Name:            <dav:write>

         Purpose:         The <write> right affects the child's declaration overrides and principal A is denied same methods as
         the right Write Lock. Please refer to delete [WEBDAV] section 5.3 for the resource.

   Note, list
         of affected methods. Note however, that if other properties do not deny principal A a write lock is a
         different mechanism than a write access change, although they
         affect the
   right same methods, they have independent methods to delete set
         them then principal A could delete all properties
   but the one mentioned above and could PUT an empty body to the
   resource. However it could not successfully execute a DELETE on independent error codes.

    3.2.3readacl Right

         Name:            <dav:readacl>

         Purpose:         The <readacl> right provides and restricts
         access to the
   resource, as <dav:acl> property of this would have resource, rather than
         the effect of deleting <dav:read> right.  If a user has the property
   along with <readacl> right and not
         the resource.

3.1.2.    Rule 2

   A resource specifies that principal A is denied <read> right, the read right. The
   same resource also specifies that principal B <dav:acl> property ONLY is granted accessible via
         PROPFIND, and the read
   right. Principal A, however, is a compound principal of which
   Principal B GET method is not authorized.  If a member. Rule 1 does user has
         the <read> right and not apply because the rights <readacl> right, the <dav:acl>
         property will not be included in
   question are defined any PROPFIND requests on the same
         associated resource.

    3.2.4writeacl Right

         Name:            <dav:writeacl>

         Purpose:         The conflict <writeacl> (Access Control ADMINistration)
         right provides and restricts access to ACL method, which is resolved
   by rule 2 as the conflict is between a compound principal and one
         only means of
   its members. In that case principal B has the right to read altering the
   resource.

4.   ACL Inheritance

   When <dav:acl> (and indirectly,
         <dav:rights>) property of a new resource is created it may inherit its ACL from its
   containing resource.

    3.2.5all Right

         Name:            <dav:all>

    Sedlar, Clemm                                       [Page 6] 
         Purpose:         The <dav:all> right controls all other rights on
         this resource.  If no inheritance method is specified then the
   resource has no ACL. Note, however, that the owner value is
   automatically set when a resource <dav:all> right appears in an ACE, it is created, so even without
   inheritance, there will always be
         an owner.

   An inherited ACL MUST be applied error to the resource before it have any other right in that ACE.  This right is
   available
         merely shorthand for manipulation. Thus, if inheritance is used, all of the
   resource will never be rights enumerated in a state where it does the RIGHTS-
         DISCOVERY method, and should not have 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 protection.

   Inheritance can either properties may be static or dynamic.

   Static inheritance means that retrieved just like
         other WebDAV properties, using the ACL specified by PROPFIND method.  An HTTP
         resource on a WebDAV ACL-compliant server MUST contain the parent will
   be used to define the ACL for the child. Any subsequent changes made
   to the parent will not cause the child's ACL to be altered.

   Dynamic inheritance means that the ACL specified by the parent is
   used to define the ACL for
         following properties:

           @ <dav:owner>:   A property containing the child but any changes on principal
                             information identifying a particular user as
                             the parent's
   ACL MUST automatically be made to any inheriting children. The child
   is still allowed to define its own ACL values that MUST override any
   conflicting inherited ACL.

5.   Properties and ACLs

   Properties MAY have their own ACL independent owner of the associated resource. By default a property's ACL MUST be dynamically inherited
   from  This property is
                             readable by anyone with read access to the associated resource. Note that properties can only inherit
   from their associated
                             resource.

   It  There is legal no provision for a client
                             updating this property to carry a setting for what sort of
   inheritance its children will have. Currently in this value has no
   meaning as properties can not have children, but spec, however
                             it is expected in
   the future recommended that hierarchical properties will any authenticated user
                             with appropriate administrative privileges be adopted, so
                             allowed to issue a PROPPATCH to update its
                             value. Normally, an attempt to PROPPATCH this
   setting
                             property will then have meaning. For now compliant resources MUST
   record this value but do not have to do anything with it.

   For purposes result in a 401 (Not
                             Authorized) error.  [REQUIRED]

           @ <dav:owner-name>:   A "live" property containing a human-
                             readable description of applying scoping conflict resolution rules the
   resource is <dav:owner>
                             [OPTIONAL]

           @ <dav:rights>:  A "live" property containing the parent and list of
                             rights of the currently authenticated HTTP
                             user.  Read access to this property is
                             controlled by the child.

   Compliant resources <read> right.  This
                             property can NEVER be set directly.
                             [REQUIRED]

           @ <dav:acl>:     A "live" property containing one or more
                             <dav:ace> tags, which specify which
                             principals are not required to support setting ACLs
   directly on properties.

6.   Rights Definitions

   The following define a variety of rights. A compliant get access to what rights,
                             for the resource MUST
   support all with this ACL property.
                             [REQUIRED]

         The <dav:acl> element (property) contains 0 or more of the
         following XML elements:

           @ <dav:ace>:     An access control entry, which specifies the
                             set of rights contained herein.

6.1. all Right

   Name:            all
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         The all right provides all rights.
   Values:          None
   Description:     In to be granted to a conflict between the "all" right and other
   rights, the "all" right is considered a parent and the other rights
   a "child." Thus one ACE could provide the ALL right for a particular
   principal but another ACE in the same ACL could deny the same
   principal a particular right. The conflict would be resolved by
   denying the specified principal the more specific right.

6.2. read Right

   Name:            read
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         The read right provides and restricts access to
   information regarding the state of the resource, including the
   resource's properties. Effected methods are GET, INDEX, and
   PROPFIND. OPTIONS is not covered by a Read ACL as it reflects
   capabilities rather than state.
   Values:          None

6.3. write Right

   Name:            write
   Namespace:       http://www.ietf.org/standards/acl/
   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.
   Values:          None

6.4. delete Right

   Name:            delete
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         The delete right controls access to the DELETE
   method. This method does not affect the ability to remove
   properties.
   Values:          None

6.5. createchild Right

   Name:            createchild
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         This right controls the ability to PUT internal
   members of a collection and ADDREF external members of a collection.
   This ACL has no affect if set on non-collections.
   Values:          None

6.6. deletechild Right

   Name:            deletechild
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         The deletechild right controls the ability to the
   DELETE internal members of a collection and DELREF external members
   of a collection. This ACL has no affect if set on non-collections.
   Values:          None

6.7. writeowner Right

   Name:            writeowner
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         The writeowner right controls the ability to change
   the value of the owner right.
   Values:          None

6.8. readacl Right

   Name:            readacl
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         The readacl right controls the ability to read the
   ACL property.
   Values:          None

6.9. writeacl Right

   Name:            writeacl
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         The writeacl right controls the ability to alter
   the ACL property.
   Values:          None

7.   Default Principal Types

   The following two XML elements are defined principal types.

7.1. allprincipals XML Element

   Name:            allprincipals
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         The allprincipals XML element represents all
   principals. It is used to specify rights belonging to all
   principals, regardless of authentication.
   Values:          None

7.2. allauthprincipals XML Element

   Name:            allauthprincipals
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         The allauthprincipals XML element represents all
   authenticated principals. It is used to specify rights belonging to
   all authenticated principals.
   Values:          None

8.   ACL Method

   The ACL Method serves two distinct purposes. Its request body is
   used to define alterations to the ACL of the resource and its
   properties. The response contains the ACL for the associated
   resource and its properties.

   The Request-URI of the ACL method identifies the resource whose ACL
   information is to be retrieved and possibly altered.

   Change requests through the ACL method MUST be atomic, additionally
   changes are all or nothing. If any part of the change request fails
   then all changes MUST fail.

8.1. Request

   The request may contain up to four XML elements, owner,
   aclinheritance, and ACL. The presence of an element, except as
   otherwise specified, in the request body causes the associated value
   to change.

   The presence of an empty ACL causes all ACEs in the ACL, including
   ACEs for associated properties, to be deleted.

   If an ACE is specified in a request it completely replaces the ACE
   currently use for the same principal, if it exists. If an ACE is
   submitted with empty grant and deny lists then single
                             principal.

         The <dav:ace> element contains the ACE is deleted.
   It is a syntax error for two ACEs following XML elements:

    Sedlar, Clemm                                       [Page 7] 
           @ <dav:grant>:   Contains the set of XML elements
                             corresponding to reference the same principal.
   Additionally, although an ACE can be submitted which references
   multiple principals, rights being granted via
                             this is primarily a convenience feature.

   Strictly speaking, what the user has done is specify an ACE for
   every principal specified. The same logic applies to results that
   aggregate principals into a single ACE.

   It is illegal to delete any value, ACE, owner, aclinheritance, etc.
   with a redundant value. For example, if  Must contain at least one ACE grants all
   principals read rights and another ACE grants a single principal
   read rights, both ACEs MUST be maintained. The reason being that in
   the future all principals may have their read rights removed but the
   single principal will retain the read right because

           @ <dav:deny>:    Contains the more
   specific ACE will override set of XML elements
                             corresponding to the more general rights being denied via
                             this ACE. Additionally  Must contain at least one right,
                             if present.

           @ <dav:principal-id>: A URL of the
   currently inherited principal resource this ACE
                             applies to, or one of the tags <dav:owner> or
                             <dav:all-principals>.  Always present.  The
                             value of owner is "someuser" and this element must be unique within
                             an ACL.

           @ <dav:principal>:    Contains properties of the principal
   explicitly requests that the owner by set
                             resource (made available here to "someuser", avoid the
   information MUST be recorded
                             need for a separate PROPFIND request).
                             Optional.

         A PROPFIND on the resource. That way if owner a resource on
   the source a WebDAV ACL is changed, the proper value as requested by the
   client will remain on server might produce the inheriting ACL.

   An empty request body will cause
         following XML output:

    4.1 Example 1 - Retrieving Access Control information

         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 200 Success
         Content-Type: text/xml
         Content-Length: xxxxx

         <?xml version="1.0" encoding="utf-8" ?>
         <?namespace href = "http://www.ietf.org/standards/webdav/ AS =
         D"?>
         <D:response>
           <D:propstat>
             <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>http://www.rational.com/principals/users/gclemm</d:owner
         >
             <D:owner-name>Geoffrey Clemm</d:owner-name>

    Sedlar, Clemm                                       [Page 8] 
             <D:rights>
               <D:read/><D:readacl/>
             </D:rights>
             <D:acl>
                <D:ace>
                  <D:grant><D:read/><D:write/><D:readacl/></D:grant>
                  <D:principal-id>
                  <D:href>http://www.foo.com/users/esedlar</D:href>
                </D:principal-id>
                  <D:principal>
                    <D:principal-type>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:deny><D:writeacl/></D:deny>
                  <D:principal-id>
                    <D:href>http://www.foo.com/groups/marketing</d:href>
                </D:principal-id>
                  <D:principal>
                    <D:principal-type>Group</D:principal-type>
                    <D:displayname>Foo.Com marketing
    department</D:displayname>
                    <D:principalname>mktdept</D:principalname>
                  </D:principal>
                </D:ace>
                <D:ace>
                <D:grant><D:read/></D:grant>
                  <D:principal-id><d:all/></D:principal-id>
                </D:ace>
             </D:acl>
           <D:propstat>
         <D:response>

    5  USING ACLS

         By default, a principal has no change access rights to the ACL or associated
   values.

8.2. Response

   If the request body was empty an object
         protected by an ACL. A particular ACE may either grant or if the changes were successful deny a
   200 Success response MUST be returned with
         set of rights to a response body
   containing single principal.  It is illegal for an ACL to
         have two ACEs applying to the owner, aclinheritance, and same principal.  However, since a
         server may match the acl XML elements with
   values for all properties.

   [Ed Note - I am not dealing currently authenticated HTTP user with error conditions yet as the error
   reporting format
         multiple principals, it is going possible for multiple ACEs to have apply to be pretty complex and I want
         the current user.  In this case, if a particular right is denied
         to
   get buy off on the ACL model and current user by any ACE, this supercedes any ACE that
         might grant that right.  This is the request format before I write
   up case regardless if a couple of pages on how ("more
         specific") ACE granting access applied to do errors for a principal identifying
         the user directly, while the ACE denying access applied to a
         collection principal containing that format.]

8.3. acl XML element

   Name:            acl
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         Defines an ACL.
   Parent:          Any
   Values=          (inheritance [owner] [aclinheritance] *ACE
   *property)
   Description:     An empty ACL element will delete all ACEs contained
   in an ACL, including user.  The particular order
         of the ACEs of any properties. Note, however, that
   there MUST always be within an ACL value defined on a resource, even if it is empty.

8.4. owner XML Element

   Name:            owner
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         Specifies irrelevant.  The <principal-id> tag
         can also contain the owner of following special tags: <owner>, <all>,
         <unauthenticated>.  These tags have the resource.
   Parent=          acl

   Values=          Principal
   Description: following meaning:

    Sedlar, Clemm                                       [Page 9] 
           @ owner:  The owner XML element specifies the principal who
   owns identified by the resource. The default value for owner MUST be the principal
   who created property on
              this resource is granted or denied the resource. rights specified in
              this ACE.

           @ all:  The owner current user always retains matches this ACE, whether or
              not s/he is authenticated.

           @ unauthenticated:  The current user matches this ACE if not
              authenticated

         Server implementations may limit the right number of ACEs in an ACL.
         However, ACL-compliant servers are required to support at least
         one ACE granting rights to a single principal, and one ACE
         granting rights to a collection principal.  The server should
         return an error "Too many ACEs" in this case.

    6  ACL METHOD

         The ACL Method provides a mechanism to
   alter the ACL. So, for example, an owner who was not granted the
   right set ACL information. Its
         request body is used to define alterations to read the resource could not read ACL of the resource. However
         resource identified by the
   owner could alter request-URI. Its response body
         contains the current ACL so as to grant for that resource.  The ACL method
         replaces the read right to
   themselves. A principal MUST have <acl> and <owner> properties on the writeowner right to change specified
         resource with the
   owner property's value. An empty Owner element submitted in a
   request will not cause a change properties in the Onwer value. Owner MUST
   always have a value. request.  All compliant resources MUST support the owner
   value.

8.5. aclinheritance XML Element

   Name:            aclinheritance
   Namespace:       http://www.ietf.org/standards/acl/
   Parent=          acl
   Purpose:         The aclinheritance XML element identifies readable ACEs
         previously stored in the type
   of inheritance to be used with children of ACL on the associated resource.
   The AclInheritance value MUST default to Dynamic. An empty
   AclInheritance submitted in indicated resource are
         removed, so an ACL method on a request resource with an unreadable <acl>
         property will not cause a change in be ignored.  (If the
   AclInheritance value. This element has no meaning on non-
   collections. However, collections MUST provide this property.
   Values=          ("Dynamic" | "Static" | "None" | Extension)
   ;Extension is defined, somewhere server implements rights
         outside of those defined in DAV. URL is defined, someplace,
   somewhere.
   Description:     Although this element has no meaning when defined
   on a property, resources MUST record its value.

8.6. inheritance XML Element

   Name:            inheritance
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         Defines the inheritance used for a particular ACL.
   Parent:          acl
   Values=          ("Dynamic" | "None" | Extension)
   Description:     Specifies if the ACL is inheriting its value
   dynamically or not at all. Static is not an option since static
   inheritance can specification, they might allow
         only some ACEs to be visible¨in this case, only occur when part of the ACL was created and so was
   controlled by
         will be replaced).

         Change requests through the ACL source.

8.7. principal XML Element

   Name:            principal
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         To identify a principal.
   Parent:          any
   Values=          *cdata

8.8. ace XML Element

   Name:            ace
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         Contains access right information associated with
   one or more principals.
   Parent:          acl
   Values=          Principal Allow Deny
   Description:     A principal method MUST NOT be directly referred to in
   more than one ACE on a resource. That is, each principal has a
   particular ACE which specifies atomic. If any
         part of the change request fails then all changes MUST fail.  The
         presence of its directly granted rights.
   Thus specifying two an empty ACL causes all ACEs which directly reference the same principal in a request is a syntax error.

8.9. grant XML Element

   Name:            grant
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         Identifies the rights the ACL, including
         ACEs for associated principals are
   granted.
   Parent:          ACE
   Values:          Right Identifiers

8.10.     deny XML Element

   Name:            deny
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         Identifies the rights properties, to be deleted.  An empty request
         body will cause no change to the associated principals are
   denied.
   Parent:          ACE
   Values:          Right Identifiers

8.11.     property XML Element

   Name:            property
   Namespace:       http://www.ietf.org/standards/acl/
   Purpose:         Provides ACL for properties.
   Parent:          ACL
   Values=          Prop ACL
   Description:     The properties in or associated values.  If
         the Prop XML <principal> element MUST be
   empty.

9.   Examples

9.1. (specifying properties of the resource
         identified by the ACE's <principal-id>) is specified, it (and its
         children) is ignored.

    6.1 Example 1 - Retrieving Setting ACLs

         An ACL information request body is an acl-info XML element.  The <dav:acl-
         info> element contains properties that can be set by the ACL
         method (currently just <acl>).

         Request
         ACL /top/container/ /top/container HTTP/1.1
         Host: www.foo.bar
   Content-Length: xxxx
   Content-Type: text/xml

   HTTP/1.1 200 Success www.foo.com
         Content-Type: text/xml
         Content-Length: xxxxx

   <?namespace href = "http://www.ietf.org/standards/acl/" AS = "a"?> xxxx
         <?namespace href = "http://www.ietf.org/standards/dav/" "http://www.ietf.org/standards/webdav/ AS = "d"?>
   <a:acl>
     <a:inheritance>dynamic</a:inheritance>
     <a:owner>someonesomewhere</a:owner>
     <a:ace>
          <a:principal>domain/joebob</a:principal>
          <a:grant/>
          <a:deny><a:all/></a:deny>
     </a:ace>
     <a:property>
          <d:prop><d:creationdate></d:prop>
          <a:acl>
               <a:inheritance>dynamic</a:inheritance>
               <a:owner>blah</a:owner>
               <a:ace>
                    <a:principal>domain/joebob</a:principal>
                    <a:grant/><a:all/></a:grant>
                    <a:deny/>
               </a:ace>
          </a:acl>
     </a:property>
     <a:property>
          <d:prop>
               <d:displayname><d:get-content-language><d:get-content-
          length><d:get-content-type><d:get-etag><d:get-
          lastmodified><d:index-content-language><d:index-content-
          length><d:index-etag><d:index-last-modified><d:resourcetype>
          </d:prop>
          <a:acl>
               <a:inheritance>dynamic</a:inheritance>
          </a:acl>
     </a:property>
   </a:acl>

   The
         D"?>
         <D:acl-info>

    Sedlar, Clemm                                      [Page 10] 
           <D:acl>
                <D:ace>
                  <D:grant><D:read/><D:write/><D:readacl/></D:grant>
                  <D:principal-id>
                    <D:href>http://www.foo.com/users/esedlar</D:href>
                </D:principal-id>
                </D:ace>
                <D:ace>
                  <D:grant><D:read/> </D:grant>
                  <D:principal-id>
                  <D:href>http://www.foo.com/groups/marketing</D:href>
                </D:principal-id>
                </D:ace>
           </D:acl>
         </D:acl-info>

         Response
         HTTP/1.1 200 Success
         Content-Length: 0

         This request was empty so no changes will the group ACE to disallow read access to the
         ACL for the marketing group. The other information had to be made, rather
         recopied from the
   response ACL retrieved in the previous example.

    7  ACL INHERITANCE / DEFAULT ACLS

         To be added

    Sedlar, Clemm                                      [Page 11] 
    8  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 to 0, and maxOccurs defaults to 1 -->

           <element name="dav:read" base="right" equivClass="right"/>
           <element name="dav:write" base="right" equivClass="right"/>
           <element name="dav:readacl" base="right" equivClass="right"/>
           <element name="dav:writeacl" base="right"
           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"/>

    Sedlar, Clemm                                      [Page 12] 
                 <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>

    9  INTERNATIONALIZATION CONSIDERATIONS

         To be supplied.

    10 SECURITY CONSIDERATIONS

         To be supplied.

    11 SCALABILITY

         To be supplied.

    12 AUTHENTICATION

         Authentication mechanisms defined in WebDAV will just contain all also apply to
         WebDAV ACL.

    13 IANA CONSIDERATIONS

         This document uses the relevant values. namespace defined by [RFC2518] for XML
         elements.  All other IANA considerations mentioned in [RFC2518]
         also applicable to WebDAV ACL.

    14 INTELLECTUAL PROPERTY

         The resource
   gets its own ACL dynamically following notice is copied from its parent, top. However this
   resource does override RFC 2026, section 10.4, and
         describes the inherited ACL. Specifically, it defines
   its owner, someonesomewhere, rather than inheriting it. However, position of the IETF concerning intellectual
         property claims made against this document.

    Sedlar, Clemm                                      [Page 13] 
         The IETF takes no position regarding the
   absence validity or scope of an aclinheritance element indicates any
         intellectual property or other rights that might be claimed to
         pertain to the resource
   inherits that value. Additional implementation or use other technology described
         in this document or the principal domain/joebob is
   denied all extent to which any license under such
         rights might or might not be available; neither does it represent
         that it has made any effort to identify any such rights. So regardless of what
         Information on the IETF's procedures with respect to rights domain/joebob may
   have been granted in top's ACL, all those rights are denied
         standards-track and standards-related documentation can be found
         in
   relation to top/container. While the ACL BCP-11.  Copies of claims of rights made available for creationdate is also
   inherited it has its own owner, blah,
         publication and has any assurances of licenses to be made available,
         or the result of an additional ACE attempt made to obtain a general license or
         permission for
   joebob. All the rest use of the properties have their ACLs inherited such proprietary rights by implementers
         or users of this specification can be obtained from the resource. Therefore the denial of all 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 be required
         to
   domain/joebob would also apply practice this standard.  Please address the information to the resource's properties but
   creationdate..

9.2. Example 2 - Setting ACLs

   ACL /top/container.html HTTP/1.1
   Host: www.foo.com
   Content-Type: text/xml
   Content-Length: xxxx

   <?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
   <?namespace href = "http://www.ietf.org/standards/acl/ AS = "A"?>
   <a:acl>
     <a:property>
     <a:aclinheritance>none</a:aclinheritance>
          <d:prop>
               <d:creationdate/>
          </d:prop>
          <a:acl>
               <a:ace>
                    <a:principal>domain/joebob</a:principal>
                    <a:grant/><a:deny/>
               </a:ace>
          </a:acl>
     </a:property>
   </a:acl>
   HTTP/1.1 200 Success
   Content-Type: text/xml
   Content-Length: xxxxx

   <?namespace href = "http://www.ietf.org/standards/acl/" AS = "a"?>
   <?namespace href = "http://www.ietf.org/standards/dav/" AS = "d"?>
   <a:acl>
     <a:inheritance>dynamic</a:inheritance>
     <a:owner>someonesomewhere</a:owner>
     <a:aclinheritance>none</a:aclinheritance>
     <a:ace>
          <a:principal>domain/joebob</a:principal>
          <a:grant/>
          <a:deny><a:all/></a:deny>
     </a:ace>
     <a:property>
          <d:prop><d:creationdate></d:prop>
          <a:acl>
               <a:inheritance>dynamic</a:inheritance>
               <a:owner>blah</a:owner>
          </a:acl>
     </a:property>
     <a:property>
          <d:prop>
               <d:displayname><d:get-content-language><d:get-content-
          length><d:get-content-type><d:get-etag><d:get-
          lastmodified><d:index-content-language><d:index-content-
          length><d:index-etag><d:index-last-modified><d:resourcetype>
          </d:prop>
          <a:acl>
               <a:inheritance>dynamic</a:inheritance>
          </a:acl>
     </a:property>
   </a:acl>
         IETF Executive Director.

    15 ACKNOWLEDGEMENTS

         This example assumes the state left from example 1. In the request protocol is the user asks that collaborative product of the aclinheritance value be set WebDAV ACL
         design team: xxx, yyy, zzz.  We would like to none and that
   the ACE on acknowledge the property creationdate
         foundation laid for us by the principal domain/joebob
   be removed. Even if authors of the inherited aclinheritance value WebDAV and HTTP
         protocols upon which this protocol is none, the
   resource MUST still record the redundant value as layered, and the value on invaluable
         feedback from the
   source ACL may change.

10.  Authors' Addresses

   Paul J. Leach
   Yaron Y. Goland
   Microsoft
   1 Microsoft Way
   Redmond, WA 98052
   Phone: (425)936-4765

   Email: {paulle, yarong}@microsoft.com

11.  Bibliography WebDAV working group.

    16 INDEX

         To be supplied.

    17 REFERENCES

         [RFC2026] S.Bradner, "The Internet Standards Process", Harvard,
         1996, <http://www.ietf.org/rfc/rfc2026.txt>.

         [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-
      Lee, 'Hypertext R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and
         T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1', HTTP/1.1", RFC
         2068, January U.C. Irvine, DEC, MIT/LCS, 1997,
         <http://www.ietf.org/rfc/rfc2068.txt >.

         [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
         Requirement Levels", Harvard, 1997, <URL:ftp://ds.internic.net/rfc/rfc2068.txt>

   [WebDAV]
         <http://www.ietf.org/rfc/rfc2119.txt >.

          [RFC2518] Y. Goland, E. J. Whitehead, Jr., Asad Faizi, Stephen R.
      Carter, Del Jensen 'Extensions E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
         "HTTP Extensions for Distributed Authoring and
      Versioning on the World Wide Web -- WEBDAV', October 1997, WORK
      IN PROGRESS, <URL:ftp://ftp.ietf.org/internet-drafts/draft-ietf-
      webdav-protocol-04.txt>

   [XML] W3C, 'Extensible Markup Language - Part1. Syntax', March 1997
      <URL:http://www.w3.org/pub/WWW/TR/WD-xml-lang.html> WEBDAV", Microsoft,
         U.C.Irvine, Netscape, Novell, 1999
         <http://www.ietf.org/rfc/rfc2518.txt>.

    Sedlar, Clemm                                      [Page 14] 
    18 AUTHORS' ADDRESSES

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

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

    19 STILL TO DO :

           @ Describe the interactions with resource locking.  I'm not
              clear what the resolution was as far as locking the ACL
              separately from locking the resource.