Network Working Group G. Clemm
Request for Comments: 3744 IBM
Category: Standards Track J. Reschke
U.C. Santa Cruz
May 2004 Web Distributed Authoring and Versioning (WebDAV)
Access Control Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document specifies a set of methods, headers, message bodies,
properties, and reports that define Access Control extensions to the
WebDAV Distributed Authoring Protocol. This protocol permits a
client to read and modify access control lists that instruct a server
whether to allow or deny operations upon a resource (such as
HyperText Transfer Protocol (HTTP) method invocations) by a given
principal. A lightweight representation of principals as Web
resources supports integration of a wide range of user management
repositories. Search operations allow discovery and manipulation of
principals using human names.
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6216.1. Normative References . . . . . . . . . . . . . . . . . . 6216.2. Informative References . . . . . . . . . . . . . . . . . 63
A. WebDAV XML Document Type Definition Addendum . . . . . . . . . 64B. WebDAV Method Privilege Table (Normative). . . . . . . . . . . 67
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 721. Introduction
The goal of the WebDAV access control extensions is to provide an
interoperable mechanism for handling discretionary access control for
content and metadata managed by WebDAV servers. WebDAV access
control can be implemented on content repositories with security as
simple as that of a UNIX file system, as well as more sophisticated
models. The underlying principle of access control is that who you
are determines what operations you can perform on 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 "operations you can perform" are determined by a
single "access control list" (ACL) associated with a resource. An
ACL contains a set of "access control entries" (ACEs), where each ACE
specifies a principal and a set of privileges that are either granted
or denied to that principal. When a principal submits an operation
(such as an HTTP or WebDAV method) to a resource for execution, the
server evaluates the ACEs in the ACL to determine if the principal
has permission for that operation.
Since every ACE contains the identifier of a principal, client
software operated by a human must provide a mechanism for selecting
this principal. This specification uses http(s) scheme URLs to
identify principals, which are represented as WebDAV-capable
resources. There is no guarantee that the URLs identifying
principals will be meaningful to a human. For example,
http://www.example.com/people/Greg.Stein are both valid URLs that
could be used to identify the same principal. To remedy this, every
principal resource has the DAV:displayname property containing a
human-readable name for the principal.
Since a principal can be identified by multiple URLs, it raises the
problem of determining exactly which principal is being referenced in
a given ACE. It is impossible for a client to determine that an ACE
granting the read privilege to http://www.example.com/people/
Greg.Stein also affects the principal at http://www.example.com/u/
256432. That is, a client has no mechanism for determining that two
URLs identify the same principal resource. As a result, this
specification requires clients to use just one of the many possible
URLs for a principal when creating ACEs. A client can discover which
URL to use by retrieving the DAV:principal-URL property (Section 4.2)
from a principal resource. No matter which of the principal's URLs
is used with PROPFIND, the property always returns the same URL.
With a system having hundreds to thousands of principals, the problem
arises of how to allow a human operator of client software to select
just one of these principals. One approach is to use broad
collection hierarchies to spread the principals over a large number
of collections, yielding few principals per collection. An example
of this is a two level hierarchy with the first level containing 36
collections (a-z, 0-9), and the second level being another 36,
creating collections /a/a/, /a/b/, ..., /a/z/, such that a principal
with last name "Stein" would appear at /s/t/Stein. In effect, this
pre-computes a common query, search on last name, and encodes it into
a hierarchy. The drawback with this scheme is that it handles only a
small set of predefined queries, and drilling down through the
collection hierarchy adds unnecessary steps (navigate down/up) when
the user already knows the principal's name. While organizing
principal URLs into a hierarchy is a valid namespace organization,
users should not be forced to navigate this hierarchy to select a
This specification provides the capability to perform substring
searches over a small set of properties on the resources representing
principals. This permits searches based on last name, first name,
user name, job title, etc. Two separate searches are supported, both
via the REPORT method, one to search principal resources
(DAV:principal-property-search, Section 9.4), the other to determine
which properties may be searched at all (DAV:principal-search-
property-set, Section 9.5).
Once a principal has been identified in an ACE, a server evaluating
that ACE must know the identity of the principal making a protocol
request, and must validate that that principal is who they claim to
be, a process known as authentication. This specification
intentionally omits discussion of authentication, as the HTTP
protocol already has a number of authentication mechanisms [RFC2617].
Some authentication mechanism (such as HTTP Digest Authentication,
which all WebDAV compliant implementations are required to support)
must be available to validate the identity of a principal.
The following issues are out of scope for this document:
o Access control that applies only to a particular property on a
resource (excepting the access control properties DAV:acl and
DAV:current-user-privilege-set), rather than the entire resource,
o Role-based security (where a role can be seen as a dynamically
defined group of principals),
o Specification of the ways an ACL on a resource is initialized,
o Specification of an ACL that applies globally to all resources,
rather than to a particular resource.
o Creation and maintenance of resources representing people or
computational agents (principals), and groups of these.
This specification is organized as follows. Section 1.1 defines key
concepts used throughout the specification, and is followed by a more
in-depth discussion of principals (Section 2), and privileges
(Section 3). Properties defined on principals are specified in
Section 4, and access control properties for content resources are
specified in Section 5. The ways ACLs are to be evaluated is
described in Section 6. Client discovery of access control
capability using OPTIONS is described in Section 7.2. Interactions
between access control functionality and existing HTTP and WebDAV
methods are described in the remainder of Section 7. The access
control setting method, ACL, is specified in Section 8. Four reports
that provide limited server-side searching capabilities are described
in Section 9. Sections on XML processing (Section 10),
Internationalization considerations (Section 11), security
considerations (Section 12), and authentication (Section 13) round
out the specification. An appendix (Appendix A) provides an XML
Document Type Definition (DTD) for the XML elements defined in the
This document uses the terms defined in HTTP [RFC2616] and WebDAV
[RFC2518]. In addition, the following terms are defined:
A "principal" is a distinct human or computational actor that
initiates access to network resources. In this protocol, a
principal is an HTTP resource that represents such an actor.
A "group" is a principal that represents a set of other
A "privilege" controls access to a particular set of HTTP
operations on a resource.
An "aggregate privilege" is a privilege that contains a set of
The modifier "abstract", when applied to a privilege on a
resource, means the privilege cannot be set in an access control
element (ACE) on that resource.
access control list (ACL)
An "ACL" is a list of access control elements that define access
control to a particular resource.
access control element (ACE)
An "ACE" either grants or denies a particular set of (non-
abstract) privileges for a particular principal.
An "inherited ACE" is an ACE that is dynamically shared from the
ACL of another resource. When a shared ACE changes on the primary
resource, it is also changed on inheriting resources.
A "protected property" is one whose value cannot be updated except
by a method explicitly defined as updating that specific property.
In particular, a protected property cannot be updated with a
1.2. Notational Conventions
The augmented BNF used by this document to describe protocol elements
is described in Section 2.1 of [RFC2616]. Because this augmented BNF
uses the basic production rules provided in Section 2.2 of [RFC2616],
those rules apply to this document as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Definitions of XML elements in this document use XML element type
declarations (as found in XML Document Type Declarations), described
in Section 3.2 of [REC-XML]. When an XML element type in the "DAV:"
namespace is referenced in this document outside of the context of an
XML fragment, the string "DAV:" will be prefixed to the element name.
A principal is a network resource that represents a distinct human or
computational actor that initiates access to network resources.
Users and groups are represented as principals in many
implementations; other types of principals are also possible. A URI
of any scheme MAY be used to identify a principal resource. However,
servers implementing this specification MUST expose principal
resources at an http(s) URL, which is a privileged scheme that points
to resources that have additional properties, as described in Section
4. So, a principal resource can have multiple URIs, one of which has
to be an http(s) scheme URL. Although an implementation SHOULD
support PROPFIND and MAY support PROPPATCH to access and modify
information about a principal, it is not required to do so.
A principal resource may be a group, where a group is a principal
that represents a set of other principals, called the members of the
group. If a person or computational agent matches a principal
resource that is a member of a group, they also match the group.
Membership in a group is recursive, so if a principal is a member of
group GRPA, and GRPA is a member of group GRPB, then the principal is
also a member of GRPB.
Ability to perform a given method on a resource MUST be controlled by
one or more privileges. Authors of protocol extensions that define
new HTTP methods SHOULD specify which privileges (by defining new
privileges, or mapping to ones below) are required to perform the
method. A principal with no privileges to a resource MUST be denied
any HTTP access to that resource, unless the principal matches an ACE
constructed using the DAV:all, DAV:authenticated, or
DAV:unauthenticated pseudo-principals (see Section 5.5.1). Servers
MUST report a 403 "Forbidden" error if access is denied, except in
the case where the privilege restricts the ability to know the
resource exists, in which case 404 "Not Found" may be returned.
Privileges may be containers of other privileges, in which case they
are termed "aggregate privileges". If a principal is granted or
denied an aggregate privilege, it is semantically equivalent to
granting or denying each of the aggregated privileges individually.
For example, an implementation may define add-member and remove-
member privileges that control the ability to add and remove a member
of a group. Since these privileges control the ability to update the
state of a group, these privileges would be aggregated by the
DAV:write privilege on a group, and granting the DAV:write privilege
on a group would also grant the add-member and remove-member
Privileges may be declared to be "abstract" for a given resource, in
which case they cannot be set in an ACE on that resource. Aggregate
and non-aggregate privileges are both capable of being abstract.
Abstract privileges are useful for modeling privileges that otherwise
would not be exposed via the protocol. Abstract privileges also
provide server implementations with flexibility in implementing the
privileges defined in this specification. For example, if a server
is incapable of separating the read resource capability from the read
ACL capability, it can still model the DAV:read and DAV:read-acl
privileges defined in this specification by declaring them abstract,
and containing them within a non-abstract aggregate privilege (say,
read-all) that holds DAV:read, and DAV:read-acl. In this way, it is
possible to set the aggregate privilege, read-all, thus coupling the
setting of DAV:read and DAV:read-acl, but it is not possible to set
DAV:read, or DAV:read-acl individually. Since aggregate privileges
can be abstract, it is also possible to use abstract privileges to
group or organize non-abstract privileges. Privilege containment
loops are not allowed; therefore, a privilege MUST NOT contain
itself. For example, DAV:read cannot contain DAV:read.
The set of privileges that apply to a particular resource may vary
with the DAV:resourcetype of the resource, as well as between
different server implementations. To promote interoperability,
however, this specification defines a set of well-known privileges
(e.g., DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, DAV:read-
current-user-privilege-set, and DAV:all), which can at least be used
to classify the other privileges defined on a particular resource.
The access permissions on null resources (defined in [RFC2518],
Section 3) are solely those they inherit (if any), and they are not
discoverable (i.e., the access control properties specified in
Section 5 are not defined on null resources). On the transition from
null to stateful resource, the initial access control list is set by
the server's default ACL value policy (if any).
Server implementations MAY define new privileges beyond those defined
in this specification. Privileges defined by individual
implementations MUST NOT use the DAV: namespace, and instead should
use a namespace that they control, such as an http scheme URL.
3.1. DAV:read Privilege
The read privilege controls methods that return information about the
state of the resource, including the resource's properties. Affected
methods include GET and PROPFIND. Any implementation-defined
privilege that also controls access to GET and PROPFIND must be
aggregated under DAV:read - if an ACL grants access to DAV:read, the
client may expect that no other privilege needs to be granted to have
access to GET and PROPFIND. Additionally, the read privilege MUST
control the OPTIONS method.
<!ELEMENT read EMPTY>
3.2. DAV:write Privilege
The write privilege controls methods that lock a resource or modify
the content, dead properties, or (in the case of a collection)
membership of the resource, such as PUT and PROPPATCH. Note that
state modification is also controlled via locking (see section 5.3 of
[RFC2518]), so effective write access requires that both write
privileges and write locking requirements are satisfied. Any
implementation-defined privilege that also controls access to methods
modifying content, dead properties or collection membership must be
aggregated under DAV:write, e.g., if an ACL grants access to
DAV:write, the client may expect that no other privilege needs to be
granted to have access to PUT and PROPPATCH.
<!ELEMENT write EMPTY>
3.3. DAV:write-properties Privilege
The DAV:write-properties privilege controls methods that modify the
dead properties of the resource, such as PROPPATCH. Whether this
privilege may be used to control access to any live properties is
determined by the implementation. Any implementation-defined
privilege that also controls access to methods modifying dead
properties must be aggregated under DAV:write-properties - e.g., if
an ACL grants access to DAV:write-properties, the client can safely
expect that no other privilege needs to be granted to have access to
<!ELEMENT write-properties EMPTY>
3.4. DAV:write-content Privilege
The DAV:write-content privilege controls methods that modify the
content of an existing resource, such as PUT. Any implementation-
defined privilege that also controls access to content must be
aggregated under DAV:write-content - e.g., if an ACL grants access to
DAV:write-content, the client can safely expect that no other
privilege needs to be granted to have access to PUT. Note that PUT -
when applied to an unmapped URI - creates a new resource and
therefore is controlled by the DAV:bind privilege on the parent
<!ELEMENT write-content EMPTY>
3.5. DAV:unlock Privilege
The DAV:unlock privilege controls the use of the UNLOCK method by a
principal other than the lock owner (the principal that created a
lock can always perform an UNLOCK). While the set of users who may
lock a resource is most commonly the same set of users who may modify
a resource, servers may allow various kinds of administrators to
unlock resources locked by others. Any privilege controlling access
by non-lock owners to UNLOCK MUST be aggregated under DAV:unlock.
A lock owner can always remove a lock by issuing an UNLOCK with the
correct lock token and authentication credentials. That is, even if
a principal does not have DAV:unlock privilege, they can still remove
locks they own. Principals other than the lock owner can remove a
lock only if they have DAV:unlock privilege and they issue an UNLOCK
with the correct lock token. Lock timeout is not affected by the
<!ELEMENT unlock EMPTY>
3.6. DAV:read-acl Privilege
The DAV:read-acl privilege controls the use of PROPFIND to retrieve
the DAV:acl property of the resource.
<!ELEMENT read-acl EMPTY>
3.7. DAV:read-current-user-privilege-set Privilege
The DAV:read-current-user-privilege-set privilege controls the use of
PROPFIND to retrieve the DAV:current-user-privilege-set property of
Clients are intended to use this property to visually indicate in
their UI items that are dependent on the permissions of a resource,
for example, by graying out resources that are not writable.
This privilege is separate from DAV:read-acl because there is a need
to allow most users access to the privileges permitted the current
user (due to its use in creating the UI), while the full ACL contains
information that may not be appropriate for the current authenticated
user. As a result, the set of users who can view the full ACL is
expected to be much smaller than those who can read the current user
privilege set, and hence distinct privileges are needed for each.
<!ELEMENT read-current-user-privilege-set EMPTY>
3.8. DAV:write-acl Privilege
The DAV:write-acl privilege controls use of the ACL method to modify
the DAV:acl property of the resource.
<!ELEMENT write-acl EMPTY>
3.9. DAV:bind Privilege
The DAV:bind privilege allows a method to add a new member URL to the
specified collection (for example via PUT or MKCOL). It is ignored
for resources that are not collections.
<!ELEMENT bind EMPTY>
3.10. DAV:unbind Privilege
The DAV:unbind privilege allows a method to remove a member URL from
the specified collection (for example via DELETE or MOVE). It is
ignored for resources that are not collections.
<!ELEMENT unbind EMPTY>
3.11. DAV:all Privilege
DAV:all is an aggregate privilege that contains the entire set of
privileges that can be applied to the resource.
<!ELEMENT all EMPTY>
3.12. Aggregation of Predefined Privileges
Server implementations are free to aggregate the predefined
privileges (defined above in Sections 3.1-3.10) subject to the
DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-acl,
DAV:write-properties, DAV:write-content, or DAV:read-current-user-
DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-acl, or
DAV:read-current-user-privilege-set MUST NOT contain DAV:write,
DAV:read, DAV:read-acl, or DAV:write-acl.
DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-
DAV:read MUST NOT contain DAV:write, DAV:write-acl, DAV:write-
properties, or DAV:write-content.
DAV:write MUST contain DAV:bind, DAV:unbind, DAV:write-properties and
4. Principal Properties
Principals are manifested to clients as a WebDAV resource, identified
by a URL. A principal MUST have a non-empty DAV:displayname property
(defined in Section 13.2 of [RFC2518]), and a DAV:resourcetype
property (defined in Section 13.9 of [RFC2518]). Additionally, a
principal MUST report the DAV:principal XML element in the value of
the DAV:resourcetype property. The element type declaration for
<!ELEMENT principal EMPTY>
This protocol defines the following additional properties for a
principal. Since it can be expensive for a server to retrieve access
control information, the name and value of these properties SHOULD
NOT be returned by a PROPFIND allprop request (as defined in Section
12.14.1 of [RFC2518]).
This protected property, if non-empty, contains the URIs of network
resources with additional descriptive information about the
principal. This property identifies additional network resources
(i.e., it contains one or more URIs) that may be consulted by a
client to gain additional knowledge concerning a principal. One
expected use for this property is the storage of an LDAP [RFC2255]
scheme URL. A user-agent encountering an LDAP URL could use LDAP
[RFC2251] to retrieve additional machine-readable directory
information about the principal, and display that information in its
user interface. Support for this property is REQUIRED, and the value
is empty if no alternate URI exists for the principal.
<!ELEMENT alternate-URI-set (href*)>
A principal may have many URLs, but there must be one "principal URL"
that clients can use to uniquely identify a principal. This
protected property contains the URL that MUST be used to identify
this principal in an ACL request. Support for this property is
<!ELEMENT principal-URL (href)>
This property of a group principal identifies the principals that are
direct members of this group. Since a group may be a member of
another group, a group may also have indirect members (i.e., the
members of its direct members). A URL in the DAV:group-member-set
for a principal MUST be the DAV:principal-URL of that principal.
<!ELEMENT group-member-set (href*)>
This protected property identifies the groups in which the principal
is directly a member. Note that a server may allow a group to be a
member of another group, in which case the DAV:group-membership of