draft-ietf-webdav-acl-00.txt   draft-ietf-webdav-acl-01.txt 
INTERNET-DRAFT P. J. Leach INTERNET-DRAFT Eric Sedlar, Oracle Corporation
Expires: April 1998 Y. Y. Goland draft-ietf-webdav-acl-01.txt Geoffrey Clemm, Rational Software
Standards Track Microsoft Corporation
WebDAV Working Group November 10, 1997
WebDAV ACL Protocol Expires November 1, 2000 May 1, 2000
draft-ietf-webdav-acl-00.txt
Access Control Extensions to WebDAV
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with all
documents of the Internet Engineering Task Force (IETF), its areas, provisions of Section 10 of RFC2026.
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 Internet-Drafts are working documents of the Internet Engineering Task
months and may be updated, replaced, or obsoleted by other documents Force (IETF), its areas, and its working groups. Note that other
at any time. It is inappropriate to use Internet-Drafts as groups may also distribute working documents as Internet-Drafts.
reference material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the Internet-Drafts are draft documents valid for a maximum of six months
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow and may be updated, replaced, or obsoleted by other documents at any
Directories on ds.internic.net (US East Coast), nic.nordu.net time. It is inappropriate to use Internet- Drafts as reference
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific material or to cite them other than as "work in progress."
Rim).
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 Abstract
This memo specifies the format and manipulation mechanisms for This document specifies a set of methods, headers, and resource-types
access control lists (ACLs) for WebDAV objects. that define the WebDAV Access Control extensions to the HTTP/1.1
protocol.
Contents Sedlar, Clemm [Page 1]
Table of Contents
Status of this Memo................................................1 1 INTRODUCTION............................................3
Abstract...........................................................1 1.1 Notational Conventions................................3
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. Rights Definitions..............................................5
7. Default Principal Types.........................................7
8. ACL Method......................................................7
9. Examples.......................................................11
10.Authors' Addresses.............................................13
11.Bibliography...................................................14
1. Introduction 2 PRINCIPALS..............................................3
The basic model for access control, informally expressed, is that 3 RIGHTS..................................................4
who you are determines how you can access a resource. The "who you 3.1 RIGHTS-DISCOVERY method...............................5
are" is defined by a principal identifier; users, client software, 3.2 Rights defined by WebDAV..............................6
servers and groups of the previous have principal identifiers. The 3.2.1 read Right........................................6
"how" is determined by an "access control list" (ACL) associated 3.2.2 write Right.......................................6
with a resource. 3.2.3 readacl Right.....................................6
3.2.4 writeacl Right....................................6
3.2.5 all Right.........................................6
An ACL contains Access Control Elements (ACE). An ACE specifies a 4 ACCESS CONTROL PROPERTIES...............................7
set of principals, a set of granted rights, and a set of denied 4.1 Example 1 - Retrieving Access Control information.....8
rights.
Rights may be generic, such as "read", "write", or "delete", or they 5 USING ACLS..............................................9
might be specific to the kind of resource protected by that ACL,
such as (perhaps) "send-to", "unsubscribe", and "administer" for
mailing lists.
When a resource is created it inherits a set of default ACL 6 ACL METHOD.............................................10
properties from a designated resource, referred to as an ACL source. 6.1 Example 1 - Setting ACLs.............................10
The inheritance can be "static", so that subsequent changes to the
ACL source do not effect the new resources ACL properties; or it can
be "dynamic", so that subsequent changes are reflected in the new
resource's ACL properties.
Properties on a resource, by default, dynamically inherit from the 7 ACL INHERITANCE / DEFAULT ACLS.........................11
ACL on the resource. In other words, the resource is the ACL source
for the properties. However individual properties can be given their
own ACL.
2. Principals Identifiers 8 XML SCHEMA FOR DEFINED ELEMENTS........................12
A principal identifier can identify a single principal or a compound 9 INTERNATIONALIZATION CONSIDERATIONS....................13
principal. A single principal identifier refers to a single
principal, such as a person or a program. A compound principal
identifier specifies one or more principals. A compound principal
may not necessarily just be a list of other principals. It may in
fact be a program that accepts a principal identifier as input and
output true or false to indicate membership.
This specification relies upon the underlying authentication 10 SECURITY CONSIDERATIONS..............................13
mechanism(s) to provide the syntax of principal identifiers. Thus,
for the purposes of this specification, principal identifiers are
opaque.
3. Granting and Denying Rights 11 SCALABILITY..........................................13
An ACL can both grant and deny rights. The reason both types of 12 AUTHENTICATION.......................................13
grants are required is because of compound principals.
The consequence of the existence of compound principals is that 13 IANA CONSIDERATIONS..................................13
there are times when a compound principal may be granted a right but
a particular member of the compound principal may need to be denied
access. In order to make this possible an ACL must be able to list
principals both allowed and denied a right.
By default all rights for a principal MUST be denied. Rights MAY 14 INTELLECTUAL PROPERTY................................13
only be granted to a principal by an explicit listing of that
principal in a "grant" section of an ACL.
Additionally it is possible for access rights to collide in scope. 15 ACKNOWLEDGEMENTS.....................................14
For example, a container may have an access right which specifies
the ability of principals to delete the children of that container.
This would affect a principal's ability to use the DELETE method.
However a particular internal child may have granted access rights
to DELETE. As such, the two rights could collide.
The following rules, processed in order, MUST be used to resolve 16 INDEX................................................14
scope conflicts between rights.
1) In a conflict between a right granted by a parent and a right 17 REFERENCES...........................................14
granted by a child, the right specified by the child MUST override.
2) In a conflict between a right granted or denied to a compound 18 AUTHORS' ADDRESSES...................................15
principal and a right granted or denied to a member of the compound
principal, the reference to the member of the compound principal
MUST override.
Note that rule 2 is conceptually identical to rule 1. The concept 19 STILL TO DO :........................................15
represented by rules 1 and 2, stated generally, is that a specific
references always overrides a more general reference.
3.1. Examples Sedlar, Clemm [Page 2]
1 INTRODUCTION
The following examples demonstrate a situation where the specified The underlying principle of access control is that who you are
conflict resolution rule would be applied. determines how you can access a resource. The "who you are" is
defined by a "principal" identifier; users, client software,
servers, and groups of the previous have principal identifiers.
The "how" is determined by an "access control list" (ACL)
associated with a resource. An ACL contains a set of "access
control entries" (ACEs), where each ACE specifies a principal and
a set of rights that are either granted or denied to that
principal.
3.1.1. Rule 1 1.1 Notational Conventions
A resource specifies that principal A is granted the right to delete The augmented BNF used by this document to describe protocol
the resource. A property on the resource specifies that principal A elements is described in Section 2.1 of [RFC2068]. Because this
is denied the right to delete the property. The conflict is resolved augmented BNF uses the basic production rules provided in Section
by rule 1, the resource is the parent and the property is the child. 2.2 of [RFC2068], those rules apply to this document as well.
As such the child's declaration overrides and principal A is denied
the right to delete the resource.
Note, however, that if other properties do not deny principal A the The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
right to delete them then principal A could delete all properties NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
but the one mentioned above and could PUT an empty body to the "OPTIONAL" in this document are to be interpreted as described in
resource. However it could not successfully execute a DELETE on the [RFC2119].
resource, as this would have the effect of deleting the property
along with the resource.
3.1.2. Rule 2 2 PRINCIPALS
A resource specifies that principal A is denied the read right. The A principal identifies an entity that can be given access rights
same resource also specifies that principal B is granted the read to HTTP resources. On many implementations, a user or a group
right. Principal A, however, is a compound principal of which will be examples of principals, but other types of principals are
Principal B is a member. Rule 1 does not apply because the rights in possible. For the most part, any classification or other
question are defined on the same resource. The conflict is resolved information about the entity identified by a principal is opaque
by rule 2 as the conflict is between a compound principal and one of with respect to this specification, and is dependent on the
its members. In that case principal B has the right to read the implementation.
resource.
4. ACL Inheritance Principals are manifested to clients as a HTTP resource,
identified by a URL. The set of properties exposed by that
resource are implementation dependent, although certain
properties are required by this specification. Those properties
include:
When a new resource is created it may inherit its ACL from its @ <dav:principalname>: A "live" property containing the
containing resource. If no inheritance method is specified then the name used to authenticate this principal
resource has no ACL. Note, however, that the owner value is (typically typed into a login prompt/dialog).
automatically set when a resource is created, so even without [OPTIONAL]
inheritance, there will always be an owner.
An inherited ACL MUST be applied to the resource before it is @ <dav:displayname>: A property containing a human-readable
available for manipulation. Thus, if inheritance is used, the description of this principal. This property
resource will never be in a state where it does not have access may be "live" and not settable via PROPPATCH.
control protection. [REQUIRED]
Inheritance can either be static or dynamic. @ <dav:principal-type>: A "live" property containing a
classification word for this principal. The
values <dav:user/> and <dav:group/> are
choices for value of this property
recommended by this spec. The presence of
Static inheritance means that the ACL specified by the parent will Sedlar, Clemm [Page 3]
be used to define the ACL for the child. Any subsequent changes made this property can be used to distinguish it
to the parent will not cause the child's ACL to be altered. as a principal from other resources on a
WebDAV server. (Note that <dav:resourcetype>
may not be used, as all collections must use
the value "collection" for <resourcetype>,
which wouldn't distinguish normal collections
from principal collections.) [REQUIRED]
Dynamic inheritance means that the ACL specified by the parent is Server implementations may include any other descriptive
used to define the ACL for the child but any changes on the parent's information for a principal via properties.
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 A principal resource may or may not be a collection. A
collection principal may only contain other principals (not other
types of resources). Servers that support aggregation of
principals (e.g. groups of users or other groups) MUST manifest
them as collection principals. The WebDAV methods for examining
maintaining collections (e.g. BIND, DELETE, PROPFIND) may be used
to maintain collection principals. Membership in a collection
principal is recusive, so a principal in a collection principal A
contained by collection principal B is a member of both
collection principals. Implementations not supporting recursive
membership in principal collections can return an error if the
client attempts to bind collection principals into other
collection principals. Using WebDAV methods to alter the content
of a principal (e.g. using PROPPATCH or PUT) is outside the scope
of this specification, and is not required, recommended, or
forbidden by this spec.
Properties MAY have their own ACL independent of the associated 3 RIGHTS
resource. By default a property's ACL MUST be dynamically inherited
from the associated resource. Note that properties can only inherit
from their associated resource.
It is legal for a property to carry a setting for what sort of A right controls access to a particular set of HTTP operations on
inheritance its children will have. Currently this value has no a resource. The set of rights that apply to a particular
meaning as properties can not have children, but it is expected in resource may vary with the <dav:resourcetype> of the resource, as
the future that hierarchical properties will be adopted, so this well as between different server implementations. To promote
setting will then have meaning. For now compliant resources MUST interoperability, however, WebDAV defines a set of well-known
record this value but do not have to do anything with it. rights (e.g. <dav:read> and <dav:write>), which can at least be
used to set some context to the other rights defined on a
particular resource.
For purposes of applying scoping conflict resolution rules the Rights may be aggregates of other rights. For example, one
resource is the parent and the property is the child. implementation may split out a right controlling the ability to
BIND children into a collection from the right allowing a
resource to be removed from a collection. Since these rights
control the ability to write to a collection, these rights would
be aggregated by the <dav:write> right. The relationships
between atomic rights and aggregate rights can be discovered via
the RIGHTS-DISCOVERY HTTP method on a particular resource.
Servers may specify some rights as abstract, which means that it
may not appear in an ACL, but is described in the RIGHTS-
DISCOVERY method to aid in setting context. Server
implementations must return the same response to the RIGHTS-
DISCOVERY method on all of the resources with the same
<dav:resourcetype> value.
Compliant resources are not required to support setting ACLs Sedlar, Clemm [Page 4]
directly on properties. 3.1 RIGHTS-DISCOVERY method
6. Rights Definitions Rights discovery is a method with no arguments, that returns the
rights aggregation tree. Each right appears as an XML element,
where aggregate rights list all of their children as sub-
elements. Each right element can contain the following
attributes:
The following define a variety of rights. A compliant resource MUST @ abstract (Boolean): "true" if this right cannot be used in
support all of the rights contained herein. an ACL/ACE. Defaults to "false"
6.1. all Right @ description (string): a human readable description of what
this right controls access to. Required.
Name: all For example, the following response might be generated to a
Namespace: http://www.ietf.org/standards/acl/ RIGHTS-DISCOVERY request on a WebDAV server implemented by a
Purpose: The all right provides all rights. relational database (where the resource in this case corresponds
Values: None to a table):
Description: In 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 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 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 WebDAV ACL-aware administrative client
would list the available in a dialog box, and allow the user to
choose non-abstract rights to apply in an ACE. The rights tree
is useful programmatically to map well-known rights (defined by
WebDAV or other standards groups) into rights that are supported
by any particular server implementation.
Sedlar, Clemm [Page 5]
3.2 Rights defined by WebDAV
The rights defined by WebDAV access control MUST be present in
the response to the RIGHTS-DISCOVERY method, although they may be
abstract (and not usable within an ACE on a particular
implementation).
3.2.1read Right
Name: <dav:read>
Name: read
Namespace: http://www.ietf.org/standards/acl/
Purpose: The read right provides and restricts access to Purpose: The read right provides and restricts access to
information regarding the state of the resource, including the information regarding the state of the resource, including the
resource's properties. Effected methods are GET, INDEX, and resource's properties. Affected methods include GET and PROPFIND.
PROPFIND. OPTIONS is not covered by a Read ACL as it reflects The read right does not affect the OPTIONS method since it
capabilities rather than state. reflects capabilities rather than state.
Values: None
6.3. write Right 3.2.2write Right
Name: write Name: <dav: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 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.
Name: delete 3.2.3readacl Right
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: <dav:readacl>
Name: createchild Purpose: The <readacl> right provides and restricts
Namespace: http://www.ietf.org/standards/acl/ access to the <dav:acl> property of this resource, rather than
Purpose: This right controls the ability to PUT internal the <dav:read> right. If a user has the <readacl> right and not
members of a collection and ADDREF external members of a collection. the <read> right, the <dav:acl> property ONLY is accessible via
This ACL has no affect if set on non-collections. PROPFIND, and the GET method is not authorized. If a user has
Values: None the <read> right and not the <readacl> right, the <dav:acl>
property will not be included in any PROPFIND requests on the
associated resource.
6.6. deletechild Right 3.2.4writeacl Right
Name: deletechild Name: <dav:writeacl>
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 Purpose: The <writeacl> (Access Control ADMINistration)
right provides and restricts access to ACL method, which is the
only means of altering the <dav:acl> (and indirectly,
<dav:rights>) property of a resource.
Name: writeowner 3.2.5all Right
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: <dav:all>
Name: readacl Sedlar, Clemm [Page 6]
Namespace: http://www.ietf.org/standards/acl/ Purpose: The <dav:all> right controls all other rights on
Purpose: The readacl right controls the ability to read the this resource. If the <dav:all> right appears in an ACE, it is
ACL property. an error to have any other right in that ACE. This right is
Values: None merely shorthand for all of the rights enumerated in the RIGHTS-
DISCOVERY method, and should not control access to rights not
exposed via that route.
6.9. writeacl Right 4 ACCESS CONTROL PROPERTIES
Name: writeacl This specification defines a number of new properties for WebDAV
Namespace: http://www.ietf.org/standards/acl/ resources. Access control properties may be retrieved just like
Purpose: The writeacl right controls the ability to alter other WebDAV properties, using the PROPFIND method. An HTTP
the ACL property. resource on a WebDAV ACL-compliant server MUST contain the
Values: None following properties:
7. Default Principal Types @ <dav:owner>: A property containing the principal
information identifying a particular user as
the owner of the resource. This property is
readable by anyone with read access to the
resource. There is no provision for a client
updating this property in this spec, however
it is recommended that any authenticated user
with appropriate administrative privileges be
allowed to issue a PROPPATCH to update its
value. Normally, an attempt to PROPPATCH this
property will result in a 401 (Not
Authorized) error. [REQUIRED]
The following two XML elements are defined principal types. @ <dav:owner-name>: A "live" property containing a human-
readable description of the <dav:owner>
[OPTIONAL]
7.1. allprincipals XML Element @ <dav:rights>: A "live" property containing the list of
rights of the currently authenticated HTTP
user. Read access to this property is
controlled by the <read> right. This
property can NEVER be set directly.
[REQUIRED]
Name: allprincipals @ <dav:acl>: A "live" property containing one or more
Namespace: http://www.ietf.org/standards/acl/ <dav:ace> tags, which specify which
Purpose: The allprincipals XML element represents all principals are to get access to what rights,
principals. It is used to specify rights belonging to all for the resource with this ACL property.
principals, regardless of authentication. [REQUIRED]
Values: None
7.2. allauthprincipals XML Element The <dav:acl> element (property) contains 0 or more of the
following XML elements:
Name: allauthprincipals @ <dav:ace>: An access control entry, which specifies the
Namespace: http://www.ietf.org/standards/acl/ set of rights to be granted to a single
Purpose: The allauthprincipals XML element represents all principal.
authenticated principals. It is used to specify rights belonging to
all authenticated principals.
Values: None
8. ACL Method The <dav:ace> element contains the following XML elements:
The ACL Method serves two distinct purposes. Its request body is Sedlar, Clemm [Page 7]
used to define alterations to the ACL of the resource and its @ <dav:grant>: Contains the set of XML elements
properties. The response contains the ACL for the associated corresponding to the rights being granted via
resource and its properties. this ACE. Must contain at least one right
The Request-URI of the ACL method identifies the resource whose ACL @ <dav:deny>: Contains the set of XML elements
information is to be retrieved and possibly altered. corresponding to the rights being denied via
this ACE. Must contain at least one right,
if present.
Change requests through the ACL method MUST be atomic, additionally @ <dav:principal-id>: A URL of the principal resource this ACE
changes are all or nothing. If any part of the change request fails applies to, or one of the tags <dav:owner> or
then all changes MUST fail. <dav:all-principals>. Always present. The
value of this element must be unique within
an ACL.
8.1. Request @ <dav:principal>: Contains properties of the principal
resource (made available here to avoid the
need for a separate PROPFIND request).
Optional.
The request may contain up to four XML elements, owner, A PROPFIND on a resource on a WebDAV ACL server might produce the
aclinheritance, and ACL. The presence of an element, except as following XML output:
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 4.1 Example 1 - Retrieving Access Control information
ACEs for associated properties, to be deleted.
If an ACE is specified in a request it completely replaces the ACE Request
currently use for the same principal, if it exists. If an ACE is PROPFIND /top/container HTTP/1.1
submitted with empty grant and deny lists then the ACE is deleted. Host: www.foo.bar
It is a syntax error for two ACEs to reference the same principal. Content-type: text/xml; charset="utf-8"
Additionally, although an ACE can be submitted which references Content-Length: 0
multiple principals, this is primarily a convenience feature. Depth: 0
Strictly speaking, what the user has done is specify an ACE for <?xml version="1.0">
every principal specified. The same logic applies to results that <D:propfind xmlns:D="DAV:">
aggregate principals into a single ACE. <D:allprop/>
</D:propfind>
It is illegal to delete any value, ACE, owner, aclinheritance, etc. Response
with a redundant value. For example, if one ACE grants all HTTP/1.1 200 Success
principals read rights and another ACE grants a single principal Content-Type: text/xml
read rights, both ACEs MUST be maintained. The reason being that in Content-Length: xxxxx
the future all principals may have their read rights removed but the
single principal will retain the read right because the more
specific ACE will override the more general ACE. Additionally if the
currently inherited value of owner is "someuser" and the principal
explicitly requests that the owner by set to "someuser", the
information MUST be recorded on the resource. That way if owner on
the source ACL is changed, the proper value as requested by the
client will remain on the inheriting ACL.
An empty request body will cause no change to the ACL or associated <?xml version="1.0" encoding="utf-8" ?>
values. <?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>
8.2. Response <D:owner>http://www.rational.com/principals/users/gclemm</d:owner
>
<D:owner-name>Geoffrey Clemm</d:owner-name>
If the request body was empty or if the changes were successful a Sedlar, Clemm [Page 8]
200 Success response MUST be returned with a response body <D:rights>
containing the owner, aclinheritance, and the acl XML elements with <D:read/><D:readacl/>
values for all properties. </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>
[Ed Note - I am not dealing with error conditions yet as the error 5 USING ACLS
reporting format is going to have to be pretty complex and I want to
get buy off on the ACL model and the request format before I write
up a couple of pages on how to do errors for that format.]
8.3. acl XML element By default, a principal has no access rights to an object
protected by an ACL. A particular ACE may either grant or deny a
set of rights to a single principal. It is illegal for an ACL to
have two ACEs applying to the same principal. However, since a
server may match the currently authenticated HTTP user with
multiple principals, it is possible for multiple ACEs to apply to
the current user. In this case, if a particular right is denied
to the current user by any ACE, this supercedes any ACE that
might grant that right. This is the case regardless if a ("more
specific") ACE granting access applied to a principal identifying
the user directly, while the ACE denying access applied to a
collection principal containing that user. The particular order
of the ACEs within an ACL is irrelevant. The <principal-id> tag
can also contain the following special tags: <owner>, <all>,
<unauthenticated>. These tags have the following meaning:
Name: acl Sedlar, Clemm [Page 9]
Namespace: http://www.ietf.org/standards/acl/ @ owner: The principal identified by the owner property on
Purpose: Defines an ACL. this resource is granted or denied the rights specified in
Parent: Any this ACE.
Values= (inheritance [owner] [aclinheritance] *ACE
*property)
Description: An empty ACL element will delete all ACEs contained
in an ACL, including the ACEs of any properties. Note, however, that
there MUST always be an ACL value defined on a resource, even if it
is empty.
8.4. owner XML Element @ all: The current user always matches this ACE, whether or
not s/he is authenticated.
Name: owner @ unauthenticated: The current user matches this ACE if not
Namespace: http://www.ietf.org/standards/acl/ authenticated
Purpose: Specifies the owner of the resource.
Parent= acl
Values= Principal Server implementations may limit the number of ACEs in an ACL.
Description: The owner XML element specifies the principal who However, ACL-compliant servers are required to support at least
owns the resource. The default value for owner MUST be the principal one ACE granting rights to a single principal, and one ACE
who created the resource. The owner always retains the right to granting rights to a collection principal. The server should
alter the ACL. So, for example, an owner who was not granted the return an error "Too many ACEs" in this case.
right to read the resource could not read the resource. However the
owner could alter the ACL so as to grant the read right to
themselves. A principal MUST have the writeowner right to change the
owner property's value. An empty Owner element submitted in a
request will not cause a change in the Onwer value. Owner MUST
always have a value. All compliant resources MUST support the owner
value.
8.5. aclinheritance XML Element 6 ACL METHOD
Name: aclinheritance The ACL Method provides a mechanism to set ACL information. Its
Namespace: http://www.ietf.org/standards/acl/ request body is used to define alterations to the ACL of the
Parent= acl resource identified by the request-URI. Its response body
Purpose: The aclinheritance XML element identifies the type contains the current ACL for that resource. The ACL method
of inheritance to be used with children of the associated resource. replaces the <acl> and <owner> properties on the specified
The AclInheritance value MUST default to Dynamic. An empty resource with the properties in the request. All readable ACEs
AclInheritance submitted in a request will not cause a change in the previously stored in the ACL on the indicated resource are
AclInheritance value. This element has no meaning on non- removed, so an ACL method on a resource with an unreadable <acl>
collections. However, collections MUST provide this property. property will be ignored. (If the server implements rights
Values= ("Dynamic" | "Static" | "None" | Extension) outside of those defined in this specification, they might allow
;Extension is defined, somewhere in DAV. URL is defined, someplace, only some ACEs to be visible¨in this case, only part of the ACL
somewhere. will be replaced).
Description: Although this element has no meaning when defined
on a property, resources MUST record its value.
8.6. inheritance XML Element Change requests through the ACL method MUST be atomic. If any
part of the change request fails then all changes MUST fail. The
presence of an empty ACL causes all ACEs in the ACL, including
ACEs for associated properties, to be deleted. An empty request
body will cause no change to the ACL or associated values. If
the <principal> element (specifying properties of the resource
identified by the ACE's <principal-id>) is specified, it (and its
children) is ignored.
Name: inheritance 6.1 Example 1 - Setting ACLs
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 only occur when the ACL was created and so was
controlled by the ACL source.
8.7. principal XML Element An ACL request body is an acl-info XML element. The <dav:acl-
info> element contains properties that can be set by the ACL
method (currently just <acl>).
Name: principal Request
Namespace: http://www.ietf.org/standards/acl/ ACL /top/container HTTP/1.1
Purpose: To identify a principal. Host: www.foo.com
Parent: any Content-Type: text/xml
Values= *cdata Content-Length: xxxx
<?namespace href = "http://www.ietf.org/standards/webdav/ AS =
D"?>
<D:acl-info>
8.8. ace XML Element 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>
Name: ace Response
Namespace: http://www.ietf.org/standards/acl/ HTTP/1.1 200 Success
Purpose: Contains access right information associated with Content-Length: 0
one or more principals.
Parent: acl
Values= Principal Allow Deny
Description: A principal MUST NOT be directly referred to in
more than one ACE on a resource. That is, each principal has a
particular ACE which specifies all of its directly granted rights.
Thus specifying two ACEs which directly reference the same principal
in a request is a syntax error.
8.9. grant XML Element This request changes the group ACE to disallow read access to the
ACL for the marketing group. The other information had to be
recopied from the ACL retrieved in the previous example.
Name: grant 7 ACL INHERITANCE / DEFAULT ACLS
Namespace: http://www.ietf.org/standards/acl/
Purpose: Identifies the rights the associated principals are
granted.
Parent: ACE
Values: Right Identifiers
8.10. deny XML Element To be added
Name: deny Sedlar, Clemm [Page 11]
Namespace: http://www.ietf.org/standards/acl/ 8 XML SCHEMA FOR DEFINED ELEMENTS
Purpose: Identifies the rights the associated principals are
denied.
Parent: ACE
Values: Right Identifiers
8.11. property XML Element <?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"
Name: property targetNamespace="http://www.ietf.org/standards/webdav"
Namespace: http://www.ietf.org/standards/acl/ xmlns:dav="http://www.ietf.org/standards/webdav"
Purpose: Provides ACL for properties. blockDefault="#all" elementFormDefault="qualified">
Parent: ACL
Values= Prop ACL
Description: The properties in the Prop XML element MUST be
empty.
9. Examples <element name="right" abstract="true">
<complexType content="empty">
</element>
9.1. Example 1 - Retrieving ACL information <!--For those folks not familiar with XML Schema, minOccurs
defaults to 0, and maxOccurs defaults to 1 -->
ACL /top/container/ HTTP/1.1 <element name="dav:read" base="right" equivClass="right"/>
Host: www.foo.bar <element name="dav:write" base="right" equivClass="right"/>
Content-Length: xxxx <element name="dav:readacl" base="right" equivClass="right"/>
Content-Type: text/xml <element name="dav:writeacl" base="right"
equivClass="right"/>
<element name="dav:all" base="right" equivClass="right"/>
HTTP/1.1 200 Success <complexType name="dav:rights-list">
Content-Type: text/xml <choice minOccurs="1" maxOccurs="unbounded">
Content-Length: xxxxx <element ref="dav:right">
<element name="dav:unauthenticated" content="empty"/>
<element name="dav:all" content="empty"/>
<element name="dav:owner" content="empty"/>
</complexType>
<?namespace href = "http://www.ietf.org/standards/acl/" AS = "a"?> <complexType name="dav:ace">
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "d"?> <element name="dav:grant" type="dav:rights-list"
<a:acl> minOccurs="0" maxOccurs="1">
<a:inheritance>dynamic</a:inheritance> <element name="dav:deny" type="dav:rights-list"
<a:owner>someonesomewhere</a:owner> minOccurs="0" maxOccurs="1">
<a:ace> <element name="dav:principal-id" minOccurs="1"/>
<a:principal>domain/joebob</a:principal> <complexType>
<a:grant/> <choice minOccurs="1">
<a:deny><a:all/></a:deny> <element name="dav:owner" content="empty"/>
</a:ace> <element name="dav:all" content="empty"/>
<a:property> <element name="dav:unauthenticated" content="empty"/>
<d:prop><d:creationdate></d:prop> <element name="dav:href" type="uri"/>
<a:acl> </choice>
<a:inheritance>dynamic</a:inheritance> </complexType>
<a:owner>blah</a:owner> </element>
<a:ace> <element name="dav:principal" minOccurs="0" maxOccurs="1">
<a:principal>domain/joebob</a:principal> <complexType>
<a:grant/><a:all/></a:grant> <element name="dav:principal-name" type="string"
<a:deny/> minOccurs="1"/>
</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 request was empty so no changes will be made, rather the Sedlar, Clemm [Page 12]
response will just contain all the relevant values. The resource <element name="dav:principal-type" type="string"
gets its own ACL dynamically from its parent, top. However this minOccurs="1"/>
resource does override the inherited ACL. Specifically, it defines </complexType>
its owner, someonesomewhere, rather than inheriting it. However, the </element>
absence of an aclinheritance element indicates that the resource </complexType>
inherits that value. Additional the principal domain/joebob is
denied all rights. So regardless of what rights domain/joebob may
have been granted in top's ACL, all those rights are denied in
relation to top/container. While the ACL for creationdate is also
inherited it has its own owner, blah, and has an additional ACE for
joebob. All the rest of the properties have their ACLs inherited
from the resource. Therefore the denial of all rights to
domain/joebob would also apply to the resource's properties but
creationdate..
9.2. Example 2 - Setting ACLs <element name="dav:acl">
<complexType>
<element name="dav:ace" type="dav:ace"
minOccurs="0" maxOccurs="unbounded"/>
</complexType>
</element>
ACL /top/container.html HTTP/1.1 <element name="dav:rights">
Host: www.foo.com <complexType>
Content-Type: text/xml <choice minOccurs="1" maxOccurs="unbounded">
Content-Length: xxxx <element ref="dav:right"/>
</choice>
</complexType>
</element>
</schema>
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?> 9 INTERNATIONALIZATION CONSIDERATIONS
<?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"?> To be supplied.
<?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>
This example assumes the state left from example 1. In the request 10 SECURITY CONSIDERATIONS
the user asks that the aclinheritance value be set to none and that
the ACE on the property creationdate for the principal domain/joebob
be removed. Even if the inherited aclinheritance value is none, the
resource MUST still record the redundant value as the value on the
source ACL may change.
10. Authors' Addresses To be supplied.
Paul J. Leach 11 SCALABILITY
Yaron Y. Goland
Microsoft
1 Microsoft Way
Redmond, WA 98052
Phone: (425)936-4765
Email: {paulle, yarong}@microsoft.com To be supplied.
11. Bibliography 12 AUTHENTICATION
[RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- Authentication mechanisms defined in WebDAV will also apply to
Lee, 'Hypertext Transfer Protocol -- HTTP/1.1', RFC 2068, January WebDAV ACL.
1997, <URL:ftp://ds.internic.net/rfc/rfc2068.txt>
[WebDAV] Y. Goland, E. J. Whitehead, Jr., Asad Faizi, Stephen R. 13 IANA CONSIDERATIONS
Carter, Del Jensen '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 This document uses the namespace defined by [RFC2518] for XML
<URL:http://www.w3.org/pub/WWW/TR/WD-xml-lang.html> elements. All other IANA considerations mentioned in [RFC2518]
also applicable to WebDAV ACL.
14 INTELLECTUAL PROPERTY
The following notice is copied from RFC 2026, section 10.4, and
describes the position of the IETF concerning intellectual
property claims made against this document.
Sedlar, Clemm [Page 13]
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described
in this document or the extent to which any license under such
rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can be found
in BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers
or users of this specification can be obtained from the IETF
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 practice this standard. Please address the information to the
IETF Executive Director.
15 ACKNOWLEDGEMENTS
This protocol is the collaborative product of the WebDAV ACL
design team: xxx, yyy, zzz. We would like to acknowledge the
foundation laid for us by the authors of the WebDAV and HTTP
protocols upon which this protocol is layered, and the invaluable
feedback from the WebDAV working group.
16 INDEX
To be supplied.
17 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, and
T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, U.C. Irvine, DEC, MIT/LCS, 1997,
<http://www.ietf.org/rfc/rfc2068.txt >.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Harvard, 1997,
<http://www.ietf.org/rfc/rfc2119.txt >.
[RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
"HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft,
U.C.Irvine, Netscape, Novell, 1999
<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.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/