draft-ietf-webdav-acl-02.txt   draft-ietf-webdav-acl-03.txt 
INTERNET-DRAFT Geoffrey Clemm, Rational Software INTERNET-DRAFT Geoffrey Clemm, Rational Software
draft-ietf-webdav-acl-02 Anne Hopkins, Microsoft Corporation draft-ietf-webdav-acl-03 Anne Hopkins, Microsoft
Corporation
Eric Sedlar, Oracle Corporation Eric Sedlar, Oracle Corporation
Jim Whitehead, U.C. Santa Cruz
Expires January 14, 2001 July 14, 2000 Expires May 24, 2001 November 24, 2000
Access Control Extensions to WebDAV WebDAV Access Control Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. This document is an Internet-Draft and is in full conformance with
Internet-Drafts are working documents of the Internet Engineering Task all provisions of Section 10 of RFC2026.
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. Internet-Drafts are working documents of the Internet Engineering
Internet-Drafts are draft documents valid for a maximum of six months Task Force (IETF), its areas, and its working groups. Note that
and may be updated, replaced, or obsoleted by other documents at any other groups may also distribute working documents as Internet-
time. It is inappropriate to use Internet- Drafts as reference Drafts.
material or to cite them other than as "work in progress."
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies a set of methods, headers, and resource-types
that define the WebDAV Access Control extensions to the HTTP/1.1
protocol.
This document specifies a set of methods, headers, and message
bodies that define the WebDAV Access Control extensions to the
HTTP/1.1 protocol. This protocol permits a client to remotely read
and modify access control lists that instruct a server whether to
grant or deny operations upon a resource (such as HTTP method
invocations) by a given principal.
This document is a product of the Web Distributed Authoring and
Versioning (WebDAV) working group of the Internet Engineering Task
Force. Comments on this draft are welcomed, and should be addressed
to the acl@webdav.org mailing list. Other related documents can be
found at http://www.webdav.org/acl/, and
http://www.ics.uci.edu/pub/ietf/webdav/.
Clemm, Hopkins, Sedlar, Whitehead [Page 1]
Table of Contents Table of Contents
1 INTRODUCTION............................................3 1 INTRODUCTION............................................3
1.1 Notational Conventions................................3 1.1 Terms .................................................3
1.2 Notational Conventions ................................4
2 PRINCIPALS..............................................3 2 PRINCIPALS ..............................................4
3 RIGHTS..................................................4 3 PRIVILEGES ..............................................5
3.1 DAV:access-rights property............................5 3.1 DAV:read Privilege ....................................5
3.2 Rights defined by WebDAV..............................6 3.2 DAV:write Privilege ...................................6
3.2.1 read Right........................................6 3.3 DAV:read-acl Privilege ................................6
3.2.2 write Right.......................................7 3.4 DAV:write-acl Privilege ...............................6
3.2.3 readacl Right.....................................7 3.5 DAV:all Privilege .....................................6
3.2.4 writeacl Right....................................7
3.2.5 all Right.........................................7
4 ACCESS CONTROL PROPERTIES...............................7 4 PRINCIPAL PROPERTIES ....................................6
4.1 Retrieving Access Control Information................11 4.1 DAV:is-principal ......................................6
4.1.1 Example: Retrieving Access Control information...11 4.2 DAV:authentication-id .................................6
4.2 Setting Access Control Information...................12
4.2.1 Example: Setting Access Control information......13
5 USING ACLS.............................................14 5 ACCESS CONTROL PROPERTIES ...............................7
5.1 System Controlled Rights.............................14 5.1 DAV:owner .............................................7
5.2 Special Principal Identifiers........................15 5.2 DAV:supported-privilege-set ...........................7
5.3 ACL Semantics Options................................15 5.3 DAV:current-user-privilege-set ........................8
5.3.1 FirstSpecific....................................16 5.4 DAV:acl ...............................................8
5.3.2 ExplicitDenyPrecedence...........................16 5.4.1 ACE Principal .....................................8
5.4.2 ACE Grant and Deny ................................9
5.4.3 ACE Protection ...................................10
5.4.4 ACE Inheritance ..................................10
5.5 DAV:acl-semantics ....................................10
5.5.1 first-match Semantics ............................14
5.5.2 all-grant-before-any-deny Semantics ..............14
5.5.3 no-deny Semantics ................................14
5.6 DAV:principal-collection-set .........................10
5.7 Example: PROPFIND to retrieve access control properties11
6 ACL INHERITANCE........................................18 6 ACCESS CONTROL AND EXISTING METHODS ....................14
6.1 Inheritable ACEs.....................................18 6.1 OPTIONS ..............................................15
6.2 Propagate ACE but do not use for Access Check on this resource....19 6.1.1 Example - OPTIONS ................................15
6.3 Propagate to immediate children only.................19
6.4 Protect ACL from inheritance.........................19
7 XML SCHEMA FOR DEFINED ELEMENTS........................20 7 ACCESS CONTROL METHODS .................................16
7.1 ACL ..................................................16
7.1.1 ACL Preconditions ................................16
7.1.2 Example: the ACL method ..........................17
7.1.3 Example: ACL method failure ......................17
8 INTERNATIONALIZATION CONSIDERATIONS....................21 8 INTERNATIONALIZATION CONSIDERATIONS ....................18
9 SECURITY CONSIDERATIONS................................21 9 SECURITY CONSIDERATIONS ................................19
10 SCALABILITY..........................................21 10 AUTHENTICATION .......................................20
11 AUTHENTICATION.......................................21 11 IANA CONSIDERATIONS ..................................20
12 IANA CONSIDERATIONS..................................21 12 INTELLECTUAL PROPERTY ................................20
13 INTELLECTUAL PROPERTY................................21 13 ACKNOWLEDGEMENTS .....................................21
14 ACKNOWLEDGEMENTS.....................................22 Clemm, Hopkins, Sedlar, Whitehead [Page 2]
14 REFERENCES ...........................................21
15 INDEX................................................22 15 AUTHORS' ADDRESSES ...................................22
16 REFERENCES...........................................22
17 AUTHORS' ADDRESSES...................................23 16 STILL TO DO ..........................................22
18 STILL TO DO :........................................23 1 INTRODUCTION
19 OPEN ISSUES:.........................................25 The goal of the WebDAV access control extensions is to provide
an interoperable mechanism for handling discretionary access
control for content in WebDAV servers. WebDAV access control
can be implemented on content repositories with security as
simple as that of a UNIX file system, as well as more
sophisticated models. The underlying principle of access
control is that who you are determines how you can access a
resource. The "who you are" is defined by a "principal"
identifier; users, client software, servers, and groups of the
previous have principal identifiers. The "how" is determined
by a single "access control list" (ACL) associated with a
resource. An ACL contains a set of "access control entries"
(ACEs), where each ACE specifies a principal and a set of
rights that are either granted or denied to that principal.
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.
1 INTRODUCTION This specification has intentionally omits discussion of
authentication, as the HTTP protocol already has a number of
authentication mechanisms[RFC2617] . Some authentication
mechanism (such as HTTP Digest Authentication, which all
WebDAV compliant implementations are required to support) must
be availableto validate the identity of a principal.
The underlying principle of access control is that who you are In the interests of timeliness, the following set of security
determines how you can access a resource. The "who you are" is mechanisms is currently viewed as out of scope of this
defined by a "principal" identifier; users, client software, document:
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.
1.1 Notational Conventions * Access control that applies only to a particular property
on a resource, rather than the entire resource.
* Role-based security (where a role can be seen as a
dynamically defined collection of principals)
* Specification of the ways an ACL on a resource is
initialized
* Specification of an ACL that applies globally to a
method, rather than to a particular resource
1.1 Terms
This draft uses the terms defined in HTTP [RFC2616] and WebDAV
[RFC2518]. In addition, the following terms are defined:
Clemm, Hopkins, Sedlar, Whitehead [Page 3]
principal
A "principal" is a distinct human or computational actor that
initiates access to network resources. In this protocol, a
principal is an HTTP resource that represents such an actor.
privilege
A "privilege" controls access to a particular set of HTTP
operations on a resource.
aggregate privilege
An "aggregate privilege " is a privilege that comprises a set
of other privileges.
access control list (acl)
An "acl " is a list of access control elements that define
access control to a particular resource.
access control element (ace)
An "ace " either grants or denies a particular set of
privileges for a particular principal.
inherited ace
An "inherited ace " is an ace that is shared from the acl of
another resource.
1.2 Notational Conventions
The augmented BNF used by this document to describe protocol The augmented BNF used by this document to describe protocol
elements is described in Section 2.1 of [RFC2068]. Because this elements is described in Section 2.1 of [RFC2616]. Because
augmented BNF uses the basic production rules provided in Section this augmented BNF uses the basic production rules provided in
2.2 of [RFC2068], those rules apply to this document as well. Section 2.2 of [RFC2616], those rules apply to this document
as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described
[RFC2119]. in [RFC2119].
2 PRINCIPALS 2 PRINCIPALS
A principal identifies an entity that can be given access rights A principal is an HTTP resource that represents a distinct
to HTTP resources. On many implementations, a user or a group human or computational actor that initiates access to network
will be examples of principals, but other types of principals are resources. On many implementations, users and groups are
possible. For the most part, any classification or other represented as principals; other types of principals are also
information about the entity identified by a principal is opaque possible. Although an implementation MAY support PROPFIND
with respect to this specification, and is dependent on the and PROPPATCH to access and modify information about a
implementation. principal, it is not required to do so.
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:
. DAV:principalname: A 'live' property containing the name
used to authenticate this principal (typically typed into a
login prompt/dialog). [OPTIONAL]
. DAV:displayname: A property containing a human-readable
description of this principal. This property may be "live"
and not settable via PROPPATCH. [REQUIRED]
. 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 this property can be
used to distinguish it as a principal from other resources on
a WebDAV server. (Note that DAV:resourcetype may not be used,
as all collections must use the value "collection" for
DAV:resourcetype, which wouldn't distinguish normal
collections from principal collections.) [REQUIRED]
Server implementations may include any other descriptive Clemm, Hopkins, Sedlar, Whitehead [Page 4]
information for a principal via properties.
A principal resource may or may not be a collection. A A principal resource may or may not be a collection. A
collection principal may only contain other principals (not other collection principal may only contain other principals (not
types of resources). Servers that support aggregation of other types of resources). Servers that support aggregation
principals (e.g. groups of users or other groups) MUST manifest of principals (e.g. groups of users or other groups) MUST
them as collection principals. The WebDAV methods for examining manifest them as collection principals. The WebDAV methods
maintaining collections (e.g. DELETE, PROPFIND) may be used to for examining and maintaining collections (e.g. DELETE,
maintain collection principals. Membership in a collection PROPFIND) MAY be used to maintain collection principals.
principal is recursive, so a principal in a collection principal Membership in a collection principal is recursive, so a
A contained by collection principal B is a member of both principal in a collection principal GRPA contained by
collection principals. Implementations not supporting recursive collection principal GRPB is a member of both GRPA and GRPB.
membership in principal collections can return an error if the Implementations not supporting recursive membership in
client attempts to bind collection principals into other principal collections can return an error if the client
collection principals. Using WebDAV methods to alter the content attempts to bind collection principals into other collection
of a principal (e.g. using PROPPATCH or PUT) is outside the scope principals.
of this specification, and is not required, recommended, or
forbidden by this spec.
3 RIGHTS 3 PRIVILEGES
A right controls access to a particular set of HTTP operations on Ability to perform a given method on a resource SHOULD be
a resource. The set of rights that apply to a particular controlled by one or more privileges. Authors of protocol
resource may vary with the DAV:resourcetype of the resource, as extensions that define new HTTP methods SHOULD specify which
well as between different server implementations. To promote privileges (by defining new privileges, or mapping to ones
below) are required to perform the method. A principal with
no privileges to a resource SHOULD be denied any HTTP access
to that resource.
Privileges may be aggregates of other 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 an
internal member of a collection. Since these privileges
control the ability to update the state of a collection, these
privileges would be aggregated by the DAV:write privilege on a
collection, and granting the DAV:write privilege on a
collection would also grant the add-member and remove-member
privileges.
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, WebDAV defines a set of well-known interoperability, however, WebDAV defines a set of well-known
rights (e.g. DAV:read and DAV:write), which can at least be used privileges (e.g. DAV:read and DAV:write), which can at least
to set some context to the other rights defined on a particular be used to classify the other privileges defined on a
resource. particular resource.
Rights may be aggregates of other rights. For example, one
implementation may split out a right controlling the ability to
add children to 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
DAV:access-rights property on a particular resource. Servers may
specify some rights as abstract, which means that it MUST not
appear in an ACL, but is described in the DAV:access-rights
property to aid in setting context. Server implementations must
return the same response to the DAV:access-rights property on all
of the resources with the same DAV:resourcetype value.
3.1 DAV:access-rights property 3.1 DAV:read Privilege
The DAV:access-rights property is a live property that contains The read privilege controls methods that return information
the rights aggregation tree. The DAV:access-rights property MUST about the state of the resource, including the resource's
be available on every resource available via a WebDAV Access properties. Affected methods include GET and PROPFIND. The
Control-compliant server. Each right appears as an XML element, read privilege does not control the OPTIONS method since the
where aggregate rights list all of their children as sub- OPTIONS method returns capabilities rather than state.
elements. Each right element can contain the following
attributes:
. abstract (Boolean): 'true' if this right MUST NOT be used in
an ACL/ACE. Defaults to 'false.' Note: an abstract right need
not be an aggregate right.
. Description (string): a human-readable description of what Clemm, Hopkins, Sedlar, Whitehead [Page 5]
this right controls access to. [REQUIRED]. The server MAY 3.2 DAV:write Privilege
localize this description, based on the Accept-Language header
of the request.
For example, the following response might be generated to a The write privilege controls methods that modify the state of
request on a WebDAV server. the resource, such as PUT and PROPPATCH. Note that state
Request modification is also controlled via locking (see section 5.3
PROPFIND /file HTTP/1.1 of [WEBDAV]), so effective write access requires that both
Host: www.foo.bar write privileges and write locking requirements are satisfied.
Content-type: text/xml; charset="utf-8"
Accept-Language: en-us
Depth: 0
Content-Length: xxx
<?xml version="1.0" encoding="utf-8"?> 3.3 DAV:read-acl Privilege
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:access-rights/>
</D:prop>
</D:propfind>
Response The DAV:read-acl privilege controls the use of PROPFIND to
HTTP/1.1 207 Multi-Status retrieve the DAV:acl, and DAV:current-user-privilege-set
Content-Type: text/xml properties of the resource.
Content-Length: xxx
<?xml version="1.0"?> 3.4 DAV:write-acl Privilege
<D:multistatus xmlns:D="DAV:"
xlmns:A="http://www.foo.bar/schema/"> The DAV:write-acl privilege controls use of the ACL method to
<D:response> modify the DAV:acl property of the resource.
<D:href>http://www.foo.bar/file</D:href>
<D:propstat> 3.5 DAV:all Privilege
<D:status>HTTP/1.1 200 OK</D:status>
<D:prop> The DAV:all privilege controls all privileges on the resource.
<D:access-rights>
<D:all> 4 PRINCIPAL PROPERTIES
<D:write abstract="true" description="Write any
object"> Principals are manifested to clients as an HTTP resource,
<A:create abstract="false" description="Create an identified by a URL. A principal MUST have a DAV:displayname
object"/> property. This protocol defines the following additional
<A:update abstract="false" description="Update an properties for a principal.
object"/>
<A:delete abstract="false" description="Delete an 4.1 DAV:is-principal
object"/>
<D:write/> This property indicates whether this resource is a principal.
<D:read abstract="false" description="Read any A resource MUST have a non-empty DAV:is-principal property if
object"/> and only if it is a principal resource. (Note: If we can
<D:readacl abstract="false" description="Read the just add a DAV:principal element to the DAV:resourcetype
ACL"/> property, then we do not need a DAV:is-principal property.)
<D:writeacl abstract="false" description="Write the
ACL"/> <!ELEMENT is-principal (#PCDATA)>
</D:all> PCDATA value: any non-empty value ("T" is suggested)
</D:access-rights>
</D:prop> 4.2 DAV:authentication-id
</D:propstat>
</D:response> A property containing the name used to authenticate this
</D:multistatus> principal (typically typed into a login prompt/dialog).
<!ELEMENT authentication-id (#PCDATA)>
PCDATA value: any string
Clemm, Hopkins, Sedlar, Whitehead [Page 6]
5 ACCESS CONTROL PROPERTIES
This specification defines a number of new properties for
WebDAV resources. Access control properties may be retrieved
just like other WebDAV properties, using the PROPFIND method.
Some access control properties (such as DAV:owner) MAY be
updated with the PROPPATCH method.
HTTP resources that support the WebDAV Access Control Protocol
MUST contain the following properties:
5.1 DAV:owner
This property identifies a particular principal as being the
"owner" of the resource.
<!ELEMENT owner (href prop?)>
<!ELEMENT prop (see [RFC2518], section 12.11)>
An implementation MAY include a list of selected properties of
that principal resource. Which properties (if any) are
included is implementation defined. An implementation MAY
allow the use of PROPPATCH to update the DAV:owner field.
5.2 DAV:supported-privilege-set
This is a read-only property that identifies the privileges
defined for the resource.
<!ELEMENT supported-privilege-set (supported-privilege*)>
Each privilege appears as an XML element, where aggregate
privileges list as sub-elements all of the privileges that
they aggregate.
<!ELEMENT supported-privilege
(privilege, abstract?, description, supported-privilege*)>
<!ELEMENT privilege ANY>
An abstract privilege is used to classify the non-abstract
privilege elements. An abstract privilege of a resource MUST
NOT be used in an ACE for that resource. Servers MUST fail an
attempt to set an abstract privilege.
<!ELEMENT abstract EMPTY>
A description is a human-readable description of what this
privilege controls access to.
<!ELEMENT description #PCDATA>
It is envisioned that a WebDAV ACL-aware administrative client It is envisioned that a WebDAV ACL-aware administrative client
would list the available rights in a dialog box, and allow the would list the supported privileges in a dialog box, and allow
user to choose non-abstract rights to apply in an ACE. The the user to choose non-abstract privileges to apply in an ACE.
rights tree is useful programmatically to map well-known rights The privileges tree is useful programmatically to map well-
(defined by WebDAV or other standards groups) into rights that
are supported by any particular server implementation.
3.2 Rights defined by WebDAV Clemm, Hopkins, Sedlar, Whitehead [Page 7]
known privileges (defined by WebDAV or other standards groups)
into privileges that are supported by any particular server
implementation. The privilege tree also serves to hide
complexity in implementations allowing large number of
privileges to be defined by displaying aggregates to the user.
The rights defined by WebDAV access control MUST be present in 5.3 DAV:current-user-privilege-set
the DAV:access-rights property, although they may be abstract
(and not usable within an ACE on a particular implementation).
Ability to perform a given method on a resource MUST be
controlled by some right. Authors of Internet drafts that define
new methods must specify which right (by defining a new right, or
mapping to one below) is required to perform the method. A
principal with no rights to a resource should be denied any HTTP
access to that resource.
3.2.1read Right This is a read-only property containing a list of privileges
granted to the currently authenticated HTTP user. The current
user has no access privileges to an object protected by an ACL
unless that user matches one or more of the principals
specified in the ACEs.
Name: DAV:read <!ELEMENT current-user-privilege-set (privilege*)>
Purpose: The read right provides and restricts access to <!ELEMENT privilege ANY>
information regarding the state of the resource, including the
resource's properties. Affected methods include GET and PROPFIND.
The read right does not affect the OPTIONS method since it
reflects capabilities rather than state.
3.2.2write Right Each element in the DAV:current-user-privilege-set property
MUST identify a privilege from the DAV:supported-privilege-set
property.
Name: DAV:write 5.4 DAV: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.
3.2.3readacl Right This property specifies the list of access control entries
(ACEs), which define what principals are to get what
privileges for this resource.
Name: DAV:readacl <!ELEMENT acl (ace*)>
Purpose: The readacl right provides and restricts access
to the DAV:acl property of this resource, rather than the
DAV:read right. If a user has the readacl right and not the read
right, the DAV:acl and DAV:access-rights properties MUST be
accessible via PROPFIND, and the GET method is not authorized.
If a user has the read right and not the readacl right, the
DAV:acl and DAV:access-rights properties will not be included in
any PROPFIND requests on the associated resource.
3.2.4writeacl Right Each DAV:ace element specifies the set of privileges to be
either granted or denied to a single principal. If the
DAV:acl property is empty, no principal is granted any
privilege.
Name: DAV:writeacl <!ELEMENT ace (principal, (grant|deny), protected?,
Purpose: The writeacl right provides and restricts access inherited?)>
to the DAV:acl and DAV:owner properties.
3.2.5all Right An attempt to update the DAV:acl property with a PROPPATCH
MUST fail.
Name: DAV:all 5.4.1 ACE Principal
Purpose: The DAV:all right controls all other rights on
this resource. If the DAV:all right appears in an ACE, it is an
error to have any other right in that ACE. This right is merely
shorthand for all of the rights enumerated in the access-rights
property, and should not control access to rights not exposed via
that route.
4 ACCESS CONTROL PROPERTIES The DAV:principal element identifies the principal to which
this ACE applies.
This specification defines a number of new properties for WebDAV <!ELEMENT principal ((href, prop?)
resources. Access control properties may be set and retrieved | all | authenticated | unauthenticated
just like other WebDAV properties, using the PROPFIND and | property | self)>
PROPPATCH method (subject to permissions and 'liveness.' An HTTP
resource on a WebDAV Access Control-compliant server MUST contain
the following properties:
. DAV:owner: A property containing the principal information
identifying a particular user as the owner of the resource.
This property is readable by anyone with read access to the The current user matches DAV:href only if that user is
resource. [REQUIRED] authenticated as being (or being a member of) the principal
identified by the URL contained by that DAV:href. An
implementation MAY include a DAV:prop element after the
DAV:href element, containing a list of selected properties of
that principal resource. Which properties (if any) are
. DAV:rights: A 'live' readonly property containing the list of Clemm, Hopkins, Sedlar, Whitehead [Page 8]
rights of the currently authenticated HTTP user. The read included in the DAV:prop element is implementation defined.
right controls read access to this property. [REQUIRED] The DAV:prop element is primarily intended for implementations
that do not support PROPFIND requests on the principal URL.
. DAV:acl: A 'live' property containing one or more DAV:ace <!ELEMENT prop (see [RFC2518], section 12.11)>
tags, which specify which principals are to get access to what
rights, for the resource with this ACL property. [REQUIRED]
. DAV:aclsemantics: A readonly property indicating the ACL The current user always matches DAV:all.
semantics model supported by the system. [REQUIRED]
. DAV:protectaclfrominheritance: A "live" property indicating <!ELEMENT all EMPTY>
that the ACL does not inherit any ACEs. If this property is
present, the ACL should contain no ACEs with the DAV:inherited
element present. If this property is not present and the
system supports ACL inheritance, then the ACL will contain
inheritable ACEs from its parent resource. If a resource
without this property present is updated with this property,
it is a client choice whether to remove the inherited ACEs or
retain them but remove the DAV:inherited element from the
ACEs. [OPTIONAL]
The DAV:owner element contains one or more of the following XML The current user matches DAV:authenticated only if
elements: authenticated.
. DAV:href: This contains the URI to the principal resource
that is the 'owner' of the resource. Normally, an attempt to
PROPPATCH this property will result in a 401 (Not Authorized)
error. The principal indicated by the owner property is
implicitly granted readacl and writeacl rights. This enables
the owner to restore an appropriate ACL in the case that it
becomes maliciously or accidently corrupted such that no
principal is granted the writeacl right by any ACE.
[REQUIRED]
. DAV:principalname, DAV:displayname, DAV:principal-type: These <!ELEMENT authenticated EMPTY>
are the same as the properties that can exist on the principal
URI. In this context they are considered 'live.' [OPTIONAL]
The DAV:acl element (property) contains 0 or more of the The current user matches DAV:unauthenticated only if not
following XML elements: authenticated.
. DAV:ace: A "live" property representing an access control
entry, which specifies the set of rights to be either granted
or denied to a single principal.
The DAV:ace element contains the following XML elements: <!ELEMENT unauthenticated EMPTY>
. DAV:grant: Contains the set of XML elements corresponding to
the rights being granted via this ACE. MUST contain at least
one right. MUST NOT be present if the DAV:deny element is
present.
. DAV:deny: Contains the set of XML elements corresponding to DAV:all is the union of DAV:authenticated, and
the rights being denied via this ACE. MUST contain at least DAV:unauthenticated. For a given request, the user matches
one right, if present. MUST NOT be present if the DAV:grant either DAV:authenticated, or DAV:unauthenticated, but not
element is present. both.
. DAV:principal: Contains information about the principal The current user matches a DAV:property principal in a DAV:acl
resource this ACE applies to. [REQUIRED]. property of a resource only if the identified property of that
resource contains a DAV:href that identifies a principal, and
the current user is authenticated as being (or being a member
of) that principal. For example, if the DAV:property element
contained <DAV:owner/>, the current user would match the
DAV:property principal only if the current user is
authenticated as matching the principal identified by the
DAV:owner property of the resource.
. DAV:acepropertytypes: A "live" property containing one or more <!ELEMENT property ANY>
elements, each of which is an XML tag identifying either a
property on this resource or a property on a child resource
that may inherit this ACE. Presence of DAV:acepropertytypes
distinguishes this ACE as a "Property ACE." The rights
associated with a "Property ACE" control access to only the
property(ies) contained in DAV:acepropertytypes, and do not
control access to the resource as a whole. The set of access
rights supported on Property ACEs may be all or a subset of
the DAV:access-rights present on this resource. This spec
does not provide a mechanism to specify a different set of
access-rights for a property, than for the resource. An
implementation that supports a different set of access-rights
for a property than for the resource, must return an error
"Unsupported Right" on an attempt to write a Property ACE with
rights not supported by the server. [OPTIONAL]
. DAV:inherittochildtype: A "live" property containing one or The current user matches DAV:self in a DAV:acl property of the
more elements, each of which is an XML tag identifying the resource only if that resource is a principal object and the
type of child object that will inherit this ACE. This current user is authenticated as being that principal.
property is only present if DAV:inheritanceflags contains at
least one of the following: DAV:inheritonly,
DAV:containerinherit, or DAV:objectinherit. A child of the
current resource will only inherit this ACE if the type of the
child object is present in DAV:inherittochildtype.
. DAV:inheritanceflags: A "live" property containing flags <!ELEMENT self EMPTY>
indicating the inheritance features of this ACE. For an ACE
that is neither inherited, nor inheritable, this element may
be either not present, or present but empty. [OPTIONAL]
. DAV:inheritancesource: A readonly property containing the URL 5.4.2 ACE Grant and Deny
of the resource from which this ACE was inherited (contained
within an DAV:href element). In other words, the ACL on the
resource referred to by this URI contains the inheritable
explicit ACE which, when propagated to the current resource,
resulted in the current ACE. This element may contain the
special value of DAV:system-ace to indicate that the ACE is
read-only and represents rights granted implicitly by the
system. This element may contain the special value of
DAV:unknown if the server is unable to generate a valid URI to
the resource from which this element was inherited. This
element MUST be present if DAV:inheritanceflags contains the
DAV:inherited flag for inherited ACEs and MUST NOT be present
for explicit ACEs.
The DAV:principal element contains the following elements: Each DAV:grant or DAV:deny element specifies the set of
. DAV:href: This is a URI representing the resource to which privileges to be either granted or denied to the specified
the ACE applies, or one of the special principal identifier principal. A DAV:grant or DAV:deny element of the DAV:acl of
tags (e.g., DAV:owner) described in the "Special Principal a resource MUST only contain elements specified in the
Identifiers" section of this spec. [REQUIRED] DAV:supported-privilege-set of that resource.
. DAV:principalname, DAV:displayname, DAV:principal-type: These <!ELEMENT grant (privilege+)>
are the same as the properties that can exist on the principal <!ELEMENT deny (privilege+)>
URI. In this context they are considered 'live.' [OPTIONAL] <!ELEMENT privilege ANY>
The DAV:inheritanceflags element contains 0 or more of the Clemm, Hopkins, Sedlar, Whitehead [Page 9]
following XML elements: 5.4.3 ACE Protection
. DAV:inherited: This flag indicates the ACE is inherited from
the ACL on a different resource, identified in
DAV:inheritancesource. This flag MUST be present for an
inherited ACE and MUST NOT be present for an explicit ACE.
This flag must not be present if the
DAV:protectaclfrominheritance element is present on this
resource unless the DAV:inheritancesource element contains the
special value DAV:system-ace, indicating that this ACE wasn't
really inherited, but reflects implicit system-granted rights.
[REQUIRED]
. DAV:inheritonly: This flag indicates the ACE should be ignored If an ACE contains a DAV:protected element, an ACL request
during access check. The ACE is present for the purposes of without that ACE MUST fail.
inheritance only and does not affect the security of the
current resource. [OPTIONAL]
. DAV:containerinherit: This flag indicates that container <!ELEMENT protected EMPTY>
objects inherit this ACE as an effective ACE. The
DAV:inheritonly flag, if also present on this ACE, will be
removed from the inherited effective ACE on the container. If
the DAV:nopropagateinheritance flag is present on the current
ACE, the DAV: containerinherit flag is removed from the
inherited ACE on the container. [REQUIRED]
. DAV:objectinherit: This flag indicates that non-container 5.4.4 ACE Inheritance
resources inherit this ACE as an effective ACE. The
DAV:inheritonly flag, if also present on this ACE, will be
removed from the inherited effective ACE on the non-container
resource. If the DAV:nopropagateinheritance> flag is not
present, then container resources will also inherit this ACE
with the addition of the DAV:inheritonly> flag. [REQUIRED]
. DAV:nopropagateinheritance: This flag indicates the ACE should The presence of a DAV:inherited element indicates that this
be inherited one level only. If an object inherits this ACE, ACE is inherited from another resource that is identified by
the DAV:containerinherit and DAV:objectinherit flags are the URL contained in a DAV:href element. An inherited ACE
removed from the resultant inherited ACE, preventing further cannot be modified directly, but instead the ACL on the
propagation of this ACE. [OPTIONAL] resource from which it is inherited must be modified.
The DAV:aclsemantics element MUST contain exactly one of the
following XML elements:
. DAV:firstspecific: This element is present if the ACL
conforms to the FirstSpecific semantics described in this
spec.
. DAV:explicitdenyprecedence: This element is present if the ACL Note that ACE inheritance is not the same as ACL
conforms to the ExplicitDenyPrecedence semantics described in initialization. ACL initialization defines the ACL that a
this spec. newly created resource will use (if not specified). ACE
inheritance refers to an ACE that is logically shared - where
an update to the resource containing an ACE will affect the
ACE of each resource that inherits that ACE. The method by
which ACLs are initialized or by which ACEs are inherited is
not defined by this document.
4.1 Retrieving Access Control Information <!ELEMENT inherited (href)>
Retrieving Access Control information is done via PROPFIND on the 5.5 DAV:acl-semantics
resource in question. All ACL properties are also returned as
part of the response to PROPFIND allprop request.
4.1.1Example: Retrieving Access Control information This is a read-only property that defines the ACL semantics.
These semantics define how multiple ACEs that match the
current user are combined, what are the constraints on how
ACEs can be ordered, and which principals must have an ACE.
Since it is not practical to require all implementations to
use the same ACL semantics, the DAV:acl-semantics property is
used to identify the ACL semantics for a particular resource.
The DAV:acl-semantics element is defined in section 6.
5.6 DAV:principal-collection-set
Often a versioning implementation constrains where a principal
can be located in the URL space. The DAV:principal-
collection-set enumerates which collections may contain
principals.
<!ELEMENT principal-collection-set (href*)>
Since different servers can control different parts of the URL
namespace, different resources on the same host MAY have
different DAV:principal-collection-set values . The
collections specified in the DAV:principal-collection-set MAY
be located on different hosts from the resource.
Clemm, Hopkins, Sedlar, Whitehead [Page 10]
5.7 Example: PROPFIND to retrieve access control properties
The following example shows how access control information can
be retrieved by using the PROPFIND method to fetch the values
of the DAV:owner, DAV:supported-privilege-set, DAV:current-
user-privilege-set, and DAV:acl properties.
>> Request <<
The following example shows how access control information could
be retrieved using PROPFIND method.
Request
PROPFIND /top/container/ HTTP/1.1 PROPFIND /top/container/ HTTP/1.1
Host: www.foo.bar Host: www.foo.org
Content-type: text/xml; charset="utf-8" Content-type: text/xml; charset="utf-8"
Content-Length: 0 Content-Length: xxx
Depth: 0 Depth: 0
Authorization: Digest username="ejw",
realm="users@foo.org", nonce="...",
uri="/top/container/", response="...", opaque="..."
<?xml version='1.0'> <?xml version="1.0" encoding="utf-8">
<D:propfind xmlns:D='DAV:'> <D:propfind xmlns:D="DAV:">
<D:allprop/> <D:owner/>
<D:supported-privilege-set/>
<D:current-user-privilege-set/>
<D:acl/>
</D:propfind> </D:propfind>
Response >> Response <<
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml Content-Type: text/xml; charset="utf-8"
Content-Length: xxx Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV"> <D:multistatus
<D:response> xmlns:D="DAV"
<D:propstat> xmlns:A="http://www.acl.org/"> <D:response> <D:propstat>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
<D:prop> <D:prop>
<D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
<D:displayname>Example collection</D:displayname>
<D:resourcetype><D:collection/></D:resourcetype>
<D:supportedlock> XXXXX</D:supportedlock>
<D:owner> <D:owner>
<D:href>http://www.foo.bar/users/gclemm <D:href>http://www.foo.org/users/gclemm</D:href></D:owner>
<D:displayname>Geoffrey Clemm</D:displayname> <D:supported-privilege-set>
</D:owner> <D:supported-privilege>
<D:rights> <D:privilege> <D:all/> </D:privilege>
<D:read/><D:readacl/> <D:abstract/>
</D:rights> <D:description>Any operation</D:description>
<D:supported-privilege>
<D:privilege> </D:read> </D:privilege>
<D:description>Read any object</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege> <D:write/> </D:privilege>
<D:abstract/>
<D:description>Write any object</D:description>
<D:supported-privilege>
<D:privilege> <A:create/> </D:privilege>
Clemm, Hopkins, Sedlar, Whitehead [Page 11]
<D:description>Create an object</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege> <A:update> </D:privilege>
<D:description>Update an object</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege> <A:delete> </D:privilege>
<D:description>Delete an object</D:description>
</D:supported-privilege>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege> <D:read-acl/> </D:privilege>
<D:description>Read the ACL</D:privilege>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege> <D:write-acl/> </D:privilege>
<D:description>Write the ACL</D:privilege>
</D:supported-privilege>
</D:supported-privilege>
</D:supported-privilege-set>
<D:current-user-privilege-set>
<D:privilege> <D:read/> </D:privilege>
<D:privilege> <D:read-acl/> </D:privilege>
</D:current-user-privilege-set>
<D:acl> <D:acl>
<D:ace> <D:ace>
<D:grant><D:read/><D:write/><D:readacl/></D:grant>
<D:principal> <D:principal>
<D:href>http://www.foo.bar/users/esedlar</D:href> <D:href>http://www.foo.org/users/esedlar</D:href>
<D:principal-type><DAV:user/></D:principal-type> <D:prop>
<D:principalname>esedlar</D:principalname> <D:authentication-id>esedlar</D:authentication-id>
<D:displayname>Eric Sedlar</D:displayname> <D:displayname>Eric Sedlar</D:displayname>
</D:principal> </D:prop> </D:principal>
<D:grant>
<D:privilege> <D:read/> </D:privilege>
<D:privilege> <D:write/> </D:privilege>
<D:privilege> <D:read-acl/> </D:privilege></D:grant>
</D:ace> </D:ace>
<D:ace> <D:ace>
<D:grant><D:read/><D:readacl/></D:grant>
<D:principal> <D:principal>
<D:href>http://www.foo.bar/groups/marketing</d:href> <D:href>http://www.foo.org/groups/marketing/</d:href>
<D:principal-type><DAV:group/></D:principal-type>
<D:displayname>Foo.Bar marketing
department</D:displayname>
<D:principalname>mktdept</D:principalname>
</D:principal> </D:principal>
</D:ace> <D:deny>
<D:privilege> <D:read/> </D:privilege> </D:deny>
<D:ace/>
<D:ace> <D:ace>
<D:deny><D:writeacl/></D:deny>
<D:principal> <D:principal>
<D:property> <D:owner/> </D:property> </D:principal>
<D:href>http://www.foo.bar/groups/marketing</d:href> <D:grant>
<D:principal-type><DAV:group/></D:principal-type> <D:privilege> <D:read-acl/> </D:privilege>
<D:displayname>Foo.Bar marketing <D:privilege> <D:write-acl/> </D:privilege></D:grant>
department</D:displayname>
<D:principalname>mktdept</D:principalname>
</D:principal>
<D:ace/> <D:ace/>
<D:ace> <D:ace>
<D:grant><D:read/></D:grant>
<D:principal><d:all/></D:principal> Clemm, Hopkins, Sedlar, Whitehead [Page 12]
</D:ace> <D:principal> <D:all/> </D:principal>
</D:acl> <D:grant>
<D:privilege> <D:read/> </D:privilege> </D:grant>
<D:inherited>
<D:href>http://www.foo.org/top/</D:href></D:inheritied>
</D:ace> </D:acl>
</D:prop> </D:prop>
<D:propstat> </D:propstat> </D:response> </D:multistatus>
<D:response>
<D:multistatus>
4.2 Setting Access Control Information The value of the DAV:owner property is a single DAV:href XML
element containing the URL of the principal that owns this
resource.
An ACL is set by executing a PROPPATCH against the resource that The value of the DAV:supported-privilege-set property is a
contains the DAV:acl property. An ACL must be written in its tree of supported privileges:
entirety. All ACEs (readable by the current user) previously
stored in the ACL on the indicated resource are removed. (If the
server implements rights outside of those defined in this
specification, they might allow only some ACEs to be visible=97
behaviour on a PROPPATCH is undefined with respect to this
specification).
Setting an empty ACL property causes all ACEs in the ACL,
including ACEs for associated properties, to be deleted.
Since permission to set an ACL is typically controlled by a
different right from permission to set other properties, it is
recommended that ACL-setting PROPPATCHes be executed
independently from PROPPATCHes of other properties. PROPATCH as
defined in [WEBDAV] is an atomic operation, so failure to set the
ACL will result in a failure to set all other properties.
[WEBDAV] also defines that operations must be performed from top
to bottom, so multiple instances of the DAV:acl element in a
single PROPPATCH result in only the last being set.
Changing ownership of a resource requires setting the DAV:href
element of the DAV:owner property.
4.2.1Example: Setting Access Control information DAV:acl (abstract)
|
+-- DAV:read
+-- DAV:write (abstract)
|
+-- http://www.acl.org/create
+-- http://www.acl.org/update
+-- http://www.acl.org/delete
+-- DAV:read-acl
+-- DAV:write-acl
The following example follows from the previous example and The DAV:current-user-privilege-set property contains two
changes the group ACE to disallow read access to the ACL for the privileges, DAV:read, and DAV:read-acl. This indicates that
marketing group. The other information had to be copied from the the current authenticated user only has the ability to read
ACL retrieved in the previous example. the resource, and read the DAV:acl property on the resource.
Request
PROPPATCH /top/container HTTP/1.1
Host: www.foo.bar
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0"?> The DAV:acl property contains a set of four ACEs:
<D:propertyupdate xmlns:D="DAV:">
<D:set>
<D:prop>
<D:acl>
<D:ace>
<D:grant><D:read/><D:write/><D:readacl/></D:grant>
<D:principal>
<D:href>http://www.foo.bar/users/esedlar</D:href>
</D:principal>
</D:ace>
<D:ace>
<D:grant><D:read/></D:grant>
<D:principal>
<D:href>http://www.foo.bar/groups/marketing</D:href>
</D:principal>
</D:ace>
</D:acl>
</D:prop>
</D:set>
</D:propertyupdate>
Response ACE #1: The principal identified by the URL
HTTP/1.1 207 Multi-Status http://www.foo.org/users/esedlar is granted the DAV:read,
Content-Type: text/xml DAV:write, and DAV:read-acl privileges.
Content-Length: xxx
<?xml version="1.0"?> ACE #2: The principals identified by the URL
<D:multistatus xmlns:a="DAV:"> http://www.foo.org/groups/marketing/ are denied the DAV:read
<D:response> privilege. In this example, the principal URL identifies a
<D:href>http://www.foo.bar/top/container/</D:href> group, which is represented by a collection principal.
<D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
<D:prop>
<D:acl/>
</D:prop>
</D:propstat>
</D:response>
</D:multistatus>
5 USING ACLS ACE #3: In this ACE, the principal is a property principal,
specifically the DAV:owner property. When evaluating this ACE,
the value of the DAV:owner property is retrieved, and is
examined to see if it contains a DAV:href XML element. If so,
the URL within the DAV:href element is read, and identifies a
principal. In this ACE, the owner is granted DAV:read-acl, and
DAV:write-acl privileges.
An ACL contains zero or more ACEs that express the rights granted ACE #4: This ACE grants the DAV:all principal (all users) the
or denied to the principal specified in the ACE. An ACL with DAV:read privilege. This ACE is inherited from the resource
zero ACEs implies that no principal is granted any rights. A
particular ACE may either grant or deny a set of rights to a
single principal. However, since a server may match the
currently authenticated HTTP user with multiple principals (for
instance, in the case where one principal refers to the user and
another principal refers to a group to which the user belongs),
it is possible for multiple ACEs to "match" the current user. A
user has no access rights to an object protected by an ACL unless
that user matches one or more of the principals specified in the
ACEs.
Server implementations may limit the number of ACEs in an ACL.
However, ACL-compliant servers are required to support at least
one ACE granting rights to a single principal, and one ACE
granting rights to a collection principal. If a client tries to
write an ACL containing more ACEs than the server supports, the
server should return an error "Too many ACEs."
5.1 System Controlled Rights Clemm, Hopkins, Sedlar, Whitehead [Page 13]
http://www.foo.org/top/, the parent collection of this
resource.
Some implementations may grant certain rights implicitly. For 6 ACL SEMANTICS
example, some systems grant the resource owner DAV:readacl and
DAV:writeacl implicitly to prevent an ACL from becoming
irrevocably locked by an update that grants no one the
DAV:writeacl right. Any rights granted implicitly by the system
should be reflected as standard ACEs in the ACL returned to the
client. Since these implicit permissions are read-only, they
should be reflected as "system controlled" ACEs where
DAV:inheritanceflags contains DAV:inherited and the
DAV:inheritancesource element contains DAV:system-ace.
5.2 Special Principal Identifiers The ACL semantics define how multiple ACEs that match the
current user are combined, what are the constraints on how
ACEs can be ordered, and which principals must have an ACE.
The DAV:principal element in an ACE may contain, instead of a <!ELEMENT acl-semantics ANY>
specific security principal identifier, one of the following ANY value: zero or more of the ACL semantic elements
special tags:
. DAV:owner: The principal identified by the owner property on
this resource is granted or denied the rights specified in
this ACE.
. DAV:all: The current user always matches this ACE, whether or 6.1 ACE Combination
not s/he is authenticated.
. DAV:authenticated: The current user matches this ACE if The DAV:ace-combination element defines how privileges from
authenticated. multiple ACEs that match the current user will be combined to
determine the access rights for that user. Multiple ACEs may
match the same user because the same principal can appear in
multiple ACEs, because multiple principals can identify the
same user, and because one principal can be a member of
another principal.
. DAV:unauthenticated: The current user matches this ACE if not <!ELEMENT ace-combination
authenticated (first-match | all-grant-before-any-deny | no-deny)>
. DAV:selfprincipal: The current user matches this ACE if the 6.1.1 DAV:first-match ACE Combination
resource (for example, a user information object or security
principal account) associated with this ACL is a
representation of the current user.
5.3 ACL Semantics Options The ACEs are evaluated in the order in which they appear in
the ACL. If the first ACE that matches the current user does
not grant all the privileges needed for the request, the
request MUST fail.
In order to accommodate the different semantics of multiple <!ELEMENT first-match EMPTY>
existing server implementations, we define a number of ACL
Semantics options. The tag associated with each option is used
to indicate what semantics to apply to the ACL. A client may use
this tag to display information that helps an ACL author
understand the implications of his updates. The client must also
use this tag to determine the legal semantics for ordering ACEs
prior to updating the ACL property.
The following ACL Semantics options have been defined to
indicate:
. restrictions, if any, on the ordering of ACEs within a stored
ACL,
. how to determine during access check which ACE(s) apply to a 6.1.2 DAV:all-grant-before-any-deny ACE Combination
user that matches multiple principals,
. how to combine the rights granted or denied by multiple The ACEs are evaluated in the order in which they appear in
matching ACEs during access check. the ACL. If an evaluated ACE denies a privilege needed for
the request, the request MUST fail. If all ACEs have been
evaluated without the user being granted all privileges needed
for the request, the request MUST fail.
Additional ACL models may be accommodated by defining and <!ELEMENT all-grant-before-any-deny EMPTY>
registering additional ACL Semantics tags. [How is this done?
TBD].
Requested Rights: Some access check algorithms are based on not
just the user identity and the ACEs, but also on the "requested
rights," which is the set of rights required by the operation for
which the access check is being performed.
Effective Rights: The "effective rights" of a user is the set of 6.1.3 DAV:no-deny ACE Combination
all rights that would be granted to a user by a given ACL. This
set, which is exposed via the DAV:rights property, is independent
of any operation "requested rights" and may be generated by a
different algorithm than the access check algorithm that
determines whether a user has specific requested rights. Each
right in the Effective Rights set applies to the user whether the
right is requested individually, or in combination with other
rights, in the requested rights for an operation.
5.3.1FirstSpecific All ACEs in the ACL are evaluated. An "individual ACE" is one
whose principal identifies the current user. A "group ACE" is
one whose principal is a collection that contains a principal
that identifies the current user. A privilege is granted if
it is granted by an individual ACE and not denied by an
individual ACE, or if it is granted by a group ACE and not
denied by an individual or group ACE. A request MUST fail if
any of its needed privileges are not granted.
The FirstSpecific semantic model has the following <!ELEMENT no-deny EMPTY>
characteristics:
Order of ACEs: ACEs are ordered from "most specific" to "least
specific." Typically, the "most specific" ACEs identify
principals that refer to a single user. ACEs with "intermediate"
specificity have principals that refer to a collection or group
of users or other entities. The "least specific" ACEs contain
principals, like "World" or "Everyone," that indicate an
unbounded set of users. If multiple ACEs with the same level of
specificity are present, their order relative to each other is
not defined here. Implementations of the FirstSpecific model are
unlikely to have multiple ACEs in the intermediate and least
specific categories (where multiple ACE matches are possible),
making it unimportant to define a rule for relative ordering of
ACEs within these two specificity levels.
ACE Matching Algorithm: ACEs are evaluated in the order in which
they appear in the ACL, from first to last. When a match is
found, the algorithm is complete. This first matching ACE alone
is used to determine the effective rights of the user. If it is
a Grant ACE, then the user is granted all rights in the ACE. If
it is a Deny ACE, then the user is denied all rights in the ACE.
Requested rights may be compared with the effective rights to
determine if access should be granted.
ACE Combining Algorithm: The FirstSpecific model never matches
more than one ACE to a user, thus there's no need to combine the
rights of multiple ACEs.
Example Implementation: UNIX rights (rwx for user:group:world) is
an example of the FirstSpecific model.
5.3.2ExplicitDenyPrecedence Clemm, Hopkins, Sedlar, Whitehead [Page 14]
6.2 ACE Ordering
The ExplicitDenyPrecedence model has the following The DAV:ace-ordering element defines a constraint on how the
characteristics: ACEs can be ordered in the ACL.
Order of ACEs: All Explicit ACEs must precede all Inherited ACEs.
Within the group of Explicit ACEs, all Deny ACEs must precede all
Grant ACEs. Inherited ACEs are placed in the order in which they
are inherited. ACEs inherited from the resource's parent come
first, then ACEs from the grandparent, and so on.
ACE Matching and Combining Algorithm: The ACE matching and 6.2.1 DAV:deny-before-grant ACE Ordering
combining algorithms are not distinct in this model and must be
described together. A set of "Granted rights" and a set of
"Denied rights", both initialized with zero rights, are
maintained in the algorithms to check for Requested Rights and to
calculate Effective Rights. In both cases, ACEs are evaluated in
the order in which they appear in the ACL, from first to last.
Checking for Requested Rights: For each ACE evaluated, if the ACE
matches the current user, then:
. if it is a Grant ACE, any rights in the ACE that are not
already in the "Granted rights" or "Denied rights" sets are
added to the "Granted rights" set
. if it is a Deny ACE, any rights in the ACE that are not This element indicates that all deny ACEs must precede all
already in the "Granted rights" or "Denied rights" sets are grant ACEs.
added to the "Denied rights" set
If the "Granted rights" set now contains all rights in the set of <!ELEMENT deny-before-grant EMPTY>
"requested rights," then no more ACEs are evaluated and the
algorithm completes with "Requested Access Granted."
If the "Denied rights" set now contains any right that is in the
set of "requested rights," then no more ACEs are evaluated and
the algorithm completes with "Requested Access Denied."
If neither of these cases is true, then the next ACE is
evaluated. If there are no more ACEs present in the ACL, then
the algorithm completes with "Requested Access Denied" since the
accumulated Granted rights did not contain all of the requested
rights.
Calculating the effective rights of a user: As in the check for
requested rights, for each ACE evaluated, if the ACE matches the
current user, then:
. if it is a Grant ACE, any rights in the ACE that are not
already in the "Granted rights" or "Denied rights" sets are
added to the "Granted rights" set
. if it is a Deny ACE, any rights in the ACE that are not 6.3 Required Principals
already in the "Granted rights" or "Denied rights" sets are
added to the "Denied rights" set
If the union of the "Granted rights" and "Denied rights" now The required principal elements identify which principals must
contains all possible rights, then no more ACEs are evaluated and have an ACE defined in the ACL.
the algorithm returns the Granted rights as the set of Effective
Rights.
Otherwise, the next ACE is evaluated. If there are no more ACEs
present in the ACL, then all rights present in the "Granted
rights" set are returned as Effective Rights.
Example Implementation: Microsoft Windows NT canonical ACLs are
an example of this model.
6 ACL INHERITANCE <!ELEMENT required-principal
(href | all | authenticated | unauthenticated | property |
self)>
To support a more scalable administration model for configuration For example, the following element requires that the ACE
of access control information, the spec defines an ACL contain a DAV:owner property ACE:
inheritance model that enables an ACL, or elements of an ACL, to
be inherited and reused by other resources. An ACL-compliant
implementation is not required to support inheritance.
Typically, an ACL defined on a container resource may be
inherited by children of that container, grandchildren if they
exist, and so on down the tree. Although this hierarchical tree
model of inheritance is popular, this spec does not require an
implementation's ACL inheritance model to follow a tree structure
where child resource inherits from parent resource. Nonetheless,
for convenience, this description of inheritance assumes that a
child resource would inherit access control information from its
parent.
6.1 Inheritable ACEs <D:required-principal xmlns:D="DAV:">
<D:property> <D:owner/> </D:property>
</D:required-principal>
Access control information is inherited at the granularity of an 7 ACCESS CONTROL AND EXISTING METHODS
ACE. An inherited ace is identified by the presence of the
DAV:inherited element in the DAV:inheritanceflags property. An
"Explicit" ACE is an ACE defined directly on a resource, rather
than inherited from a different resource. An ACE without the
DAV:inherited element is by definition an Explicit ACE. Only
Explicit ACEs may updated by the client.
To indicate that an ACE should be inherited by child resources,
the DAV:inheritanceflags should contain:
. DAV:objectinherit to indicate that non-container children
should inherit the ACE,
. DAV:containerinherit to indicate that container children This section defines the impact of access control
should inherit the ACE, or functionality on existing methods.
. both to indicate that all child resources should inherit the 7.1 OPTIONS
ACE.
6.2 Updating an inherited ACE If the server supports access control, it MUST return "access-
control" as a field in the DAV response header from an OPTIONS
request on any resource implemented by that server.
When a child resource ACL inherits an ACE, the DAV:inherited 7.1.1 Example - OPTIONS
flag is present on the ACE to indicate that this ACE is read-
only (it may only be edited on the resource where the ACE was
explicitly defined). To assist users who want to make changes
to the rights that appear in an inherited ACE, the resource from
which the ACE was inherited (and therefore, on which the
explicit ACE is defined and editable) is identified in the
DAV:inheritancesource property. If the inheritance source
cannot be determined or if the system is unable to generate a
valid URI to the resource from which the ACE was inherited,
DAV:inheritancesource contains the special tag DAV:unknown.
6.3 Propagate ACE but do not use for Access Check on this resource >>REQUEST
In some cases, an ACE (whether explicit or inherited) may be OPTIONS /foo.html HTTP/1.1
present on a container ACL purely for the sake of propagating Host: www.webdav.org
the ACE to child objects and NOT to be used for access control Content-Length: 0
on the container itself. In this case, the optional
DAV:inheritonly flag is present on the ACE to indicate it should
not be used for access check on this container.
6.4 Propagate to immediate children only >>RESPONSE
To indicate that an ACE should be inherited by children, but not HTTP/1.1 200 OK
by grandchildren or any further down the tree, the optional DAV: 1, 2, access-control
DAV:nopropagateinheritance flag is present on the ACE. This
flag indicates that when this ACE is inherited by child objects,
the DAV:objectinherit and/or DAV:containerinherit elements must
be removed from the inherited ACE.
6.5 Protect ACL from inheritance Clemm, Hopkins, Sedlar, Whitehead [Page 15]
Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL
To prevent an ACL from inheriting any ACEs, the optional In this example, the OPTIONS response indicates that the
DAV:protectaclfrominheritance property is set on the resource. server supports access control and that /foo.html can have its
If this property is present on a resource, the DAV:inherited access control list modified by the ACL method.
element must not be present on any ACEs in that resource's ACL.
Other inheritance flags may be present on the ACEs of this
resource, since this ACL may be the source of inheritable ACEs
for the subtree under this resource.
7 XML SCHEMA FOR DEFINED ELEMENTS 8 ACCESS CONTROL METHODS
<?xml version='1.0'?> 8.1 ACL
<!-- 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" A DAV:acl property of a resource is modified by the ACL
xmlns:dav="http://www.ietf.org/standards/webdav" method. A new DAV:acl value must be written in its entirety,
blockDefault="#all" elementFormDefault="qualified"> including any inherited ACEs. Unless the DAV:acl property of
the resource can be updated to be exactly the value specified
in the ACL request, the ACL request MUST fail. If a server
restricts the set of ACEs visible to the current user via the
DAV:acl property, then the ACL request would only replace the
set of ACEs visible to the current user, and would not affect
any ACE that was not visible.
<element name="right" abstract="true"> In order to avoid overwriting DAV:acl changes by another
<complexType content="empty"> client, a client SHOULD acquire a WebDAV lock on the resource
</element> before retrieving the DAV:acl property of a resource that it
intends on updating.
<!--For those folks not familiar with XML Schema, minOccurs 8.1.1 ACL Preconditions
defaults to 0, and maxOccurs defaults to 1 -->
<element name="DAV:read" base="right" equivClass="right"/> An implementation MAY enforce one or more of the following
<element name="DAV:write" base="right" equivClass="right"/> constraints on an ACL request. If the constraint is violated,
<element name="DAV:readacl" base="right" equivClass="right"/> a 403 (Forbidden) response MUST be returned and the indicated
<element name="DAV:writeacl" base="right" XML element MUST be returned in the response body.
equivClass="right"/>
<element name="DAV:all" base="right" equivClass="right"/>
<complexType name="DAV:rights-list"> <DAV:protected/>: An implementation MAY protect an ACE from
<choice minOccurs="1" maxOccurs="unbounded"> modification or deletion. For example, some implementations
<element ref="DAV:right"> implicitly grant the DAV:owner of a resource DAV:read-acl and
<element name="DAV:unauthenticated" content="empty"/> DAV:write-acl privileges, and this cannot be changed by a
<element name="DAV:all" content="empty"/> client.
<element name="DAV:owner" content="empty"/>
</complexType>
<complexType name="DAV:ace"> <DAV:too-many-aces/>: An implementation MAY limit the number
<element name="DAV:grant" type="DAV:rights-list" of ACEs in an ACL. However, ACL-compliant servers MUST
minOccurs="0" maxOccurs="1"> support at least one ACE granting privileges to a single
<element name="DAV:deny" type="DAV:rights-list" principal, and one ACE granting privileges to a collection
minOccurs="0" maxOccurs="1"> principal.
<element name="DAV:principal-id" minOccurs="1"/>
<complexType>
<choice minOccurs="1">
<element name="DAV:owner" content="empty"/>
<element name="DAV:all" content="empty"/>
<element name="DAV:unauthenticated" content="empty"/>
<element name="DAV:href" type="uri"/>
</choice>
</complexType>
</element>
<element name="DAV:principal" minOccurs="0" maxOccurs="1">
<complexType>
<element name="DAV:principal-name" type="string"
minOccurs="1"/>
<element name="DAV:principal-type" type="string"
minOccurs="1"/>
</complexType>
</element>
</complexType>
<element name="DAV:acl"> <DAV:non-inherited-must-precede-inherited/>: All non-inherited
<complexType> ACEs MUST precede all inherited ACEs.
<element name="DAV:ace" type="DAV:ace"
minOccurs="0" maxOccurs="unbounded"/>
</complexType>
</element>
<element name="DAV:rights"> <DAV:deny-must-precede-grant/>: All non-inherited deny ACEs
<complexType> MUST precede all non-inherited grant ACEs.
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="DAV:right"/>
</choice>
</complexType>
</element>
</schema>
8 INTERNATIONALIZATION CONSIDERATIONS <DAV:acl-requires-lock-token/>: If a resource is locked, the
lock token MUST be specified in the ACL request.
To be supplied. Clemm, Hopkins, Sedlar, Whitehead [Page 16]
8.1.2 Example: the ACL method
9 SECURITY CONSIDERATIONS In the following example, user "fielding", authenticated by
information in the Authorization header, grants the principal
identified by the URL http://www.foo.org/users/esedlar (i.e.,
the user "esedlar") read and write privileges, grants the
owner of the resource read-acl and write-acl privileges, and
grants everyone read privileges inherited from the parent
collection http://www.foo.bar/top/.
To be supplied. >> Request <<
10 SCALABILITY ACL /top/container HTTP/1.1
Host: www.foo.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="fielding",
realm="users@foo.org", nonce="...",
uri="/top/container/", response="...", opaque="..."
To be supplied. <?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:">
<D:ace>
<D:principal>
<D:href>http://www.foo.org/users/esedlar</D:href>
</D:principal>
<D:grant>
<D:privilege> <D:read/> </D:privilege>
<D:privilege> <D:write/> </D:privilege> </D:grant>
</D:ace>
<D:ace>
<D:principal>
<D:property> <D:owner/> </D:property> </D:principal>
<D:grant>
<D:privilege> <D:read-acl/> </D:privilege>
<D:privilege> <D:write-acl/> </D:privilege> </D:grant>
<D:ace/>
<D:ace>
<D:principal> <D:all/> </D:principal>
<D:grant>
<D:privilege> <D:read/> </D:privilege></D:grant>
<D:inherited>
<D:href>http://www.foo.org/top/</D:href> </D:inherited>
</D:ace> </D:acl>
>> Response <<
HTTP/1.1 200 OK
8.1.3Example: ACL method failure
In the following request, user "fielding", authenticated by
information in the Authorization header, attempts to grant
principal identified by the URL
http://www.foo.org/users/esedlar (i.e., the user "esedlar")
read privileges, but fails because an implicit ACE has been
Clemm, Hopkins, Sedlar, Whitehead [Page 17]
omitted (e.g. the ACE granting the DAV:owner DAV:read-acl and
DAV:write-acl privileges).
>> Request <<
ACL /top/container HTTP/1.1
Host: www.foo.bar
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="fielding",
realm="users@foo.org", nonce="...",
uri="/top/container/", response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:acl xmlns:D="DAV:">
<D:ace>
<D:principal>
<D:href>http://www.foo.bar/users/esedlar</D:href>
</D:principal>
<D:grant>
<D:privilege> <D:read/> </D:privilege> </D:grant>
</D:ace>
</D:acl>
>> Response <<
HTTP/1.1 403 Forbidden
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<DAV:cannot-change-implicit-ace/>
9 INTERNATIONALIZATION CONSIDERATIONS
In this specification, the only human-readable content can be
found in the DAV:authentication-id property, found on
principal resources. This property contains the name used to
authenticate a principal, typically by a user entering this
name into a password entry screen. As a result, the
authentication-id must be capable of representing names in
multiple character sets. Since DAV:authentication-id is a
WebDAV property, it is represented on-the-wire as XML [REC-
XML], and hence can leverage XML's language tagging and
character set encoding capabilities. Specifically, XML
processors must, at minimum, be able to read XML elements
encoded using the UTF-8 [UTF-8] encoding of the ISO 10646
multilingual plane. XML examples in this specification
demonstrate use of the charset parameter of the Content-Type
header, as defined in [RFC2376], as well as the XML "encoding"
attribute, which together provide charset identification
information for MIME and XML processors.
For properties other than DAV:authentication-id, it is
expected that implementations will treat the property names
and values as tokens, and convert these tokens into human-
Clemm, Hopkins, Sedlar, Whitehead [Page 18]
readable text in the user's language and character set when
displayed to a person. Only a generic WebDAV property display
utility would display these values in their raw form.
For error reporting, we follow the convention of HTTP/1.1
status codes, including with each status code a short, English
description of the code (e.g., 200 (OK)). While the
possibility exists that a poorly crafted user agent would
display this message to a user, internationalized applications
will ignore this message, and display an appropriate message
in the user's language and character set.
Further internationalization considerations for this protocol
are described in the WebDAV Distributed Authoring protocol
specification [RFC2518].
10 SECURITY CONSIDERATIONS
Applications and users of this access control protocol should
be aware of several security considerations, detailed below.
In addition to the discussion in this document, the security
considerations detailed in the HTTP/1.1 specification
[RFC2616], the WebDAV Distributed Authoring Protocol
specification [RFC2518], and the XML specification (discussed
in [RFC2376]) should be considered in a security analysis of
this protocol.
10.1 Increased Risk of Compromised Users
In the absence of a mechanism for remotely manipulating access
control specifications, if a single user's authentication
credentials are compromised, only those resources for which
the user has access permission can be read, modified, moved,
or deleted. With the introduction of this access control
protocol, if a single compromised user has the ability to
change ACLs for a broad range of other users (e.g., a super-
user), the number of resources that could be altered by a
single compromised user increases. This risk can be mitigated
by limiting the number of people who have write-acl privileges
across a broad range of resources.
10.2 Authentication-id Property and Dictionary Attacks
Every principal has a DAV:authentication-id property defined
on it, which provides the name used to authenticate this
principal, typically the username portion of a
username/password authentication scheme. An attacker can use
the information in this property when attempting either a
brute-force, or a dictionary attack to guess the principal's
identifying password. By providing the username in
DAV:authentication-id, the scope of an attack can be reduced
to a single, valid username. Furthermore, it is possible that
principals can potentially belong to a collection. In this
Clemm, Hopkins, Sedlar, Whitehead [Page 19]
case, it is possible to use the PROPFIND method to retrieve
the DAV:authentication-id property from all of the principals
in a collection, thus providing multiple usernames that can be
the focus of attack.
To reduce this risk, the DAV:authentication-id property should
not be world-readable. Which principals are granted default
read permission for DAV:authentication-id should be carefully
considered in any deployment of this protocol.
10.3 Risks of the read-acl Privilege
The ability to read the access permissions (stored in the
DAV:acl property), or the privileges permitted the currently
authenticated user (stored in the DAV:current-user-privilege-
set property) on a resource may seem innocuous, since reading
an ACL cannot possibly affect the resource's state. However,
if all resources have world-readable ACLs, it is possible to
perform an exhaustive search for those resources that have
inadvertently left themselves in a vulnerable state, such as
being world-writeable. Once found, this vulnerability can be
exploited by a denial of service attack in which the open
resource is repeatedly overwritten. Alternately, writeable
resources can be modified in undesirable ways.
To reduce this risk, read-acl privileges should not be granted
to unauthenticated principals, and restrictions on read-acl
privileges for authenticated principals should be carefully
analysed when deploying this protocol.
11 AUTHENTICATION 11 AUTHENTICATION
Authentication mechanisms defined in WebDAV will also apply to Authentication mechanisms defined in WebDAV will also apply to
WebDAV ACL. WebDAV ACL.
12 IANA CONSIDERATIONS 12 IANA CONSIDERATIONS
This document uses the namespace defined by [RFC2518] for XML This document uses the namespace defined by [RFC2518] for XML
elements. All other IANA considerations mentioned in [RFC2518] elements. All other IANA considerations mentioned in
also applicable to WebDAV ACL. [RFC2518] also applicable to WebDAV ACL.
13 INTELLECTUAL PROPERTY 13 INTELLECTUAL PROPERTY
The following notice is copied from RFC 2026, section 10.4, and The following notice is copied from RFC 2026, section 10.4,
describes the position of the IETF concerning intellectual and describes the position of the IETF concerning intellectual
property claims made against this document. property claims made against this document.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed to any intellectual property or other rights that might be
pertain to the implementation or use other technology described claimed to pertain to the implementation or use other
in this document or the extent to which any license under such technology described in this document or the extent to which
rights might or might not be available; neither does it represent any license under such rights might or might not be available;
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in Clemm, Hopkins, Sedlar, Whitehead [Page 20]
standards-track and standards-related documentation can be found neither does it represent that it has made any effort to
in BCP-11. Copies of claims of rights made available for identify any such rights. Information on the IETF's
publication and any assurances of licenses to be made available, procedures with respect to rights in standards-track and
or the result of an attempt made to obtain a general license or standards-related documentation can be found in BCP-11.
permission for the use of such proprietary rights by implementers Copies of claims of rights made available for publication and
or users of this specification can be obtained from the IETF 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. Secretariat.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its
any copyrights, patents or patent applications, or other attention any copyrights, patents or patent applications, or
proprietary rights that may cover technology that may be required other proprietary rights that may cover technology that may be
to practice this standard. Please address the information to the required to practice this standard. Please address the
IETF Executive Director. information to the IETF Executive Director.
14 ACKNOWLEDGEMENTS 14 ACKNOWLEDGEMENTS
This protocol is the collaborative product of the WebDAV ACL This protocol is the collaborative product of the WebDAV ACL
design team: xxx, yyy, zzz. We would like to acknowledge the design team: Bernard Chester, Geoff Clemm (Rational), Anne
foundation laid for us by the authors of the WebDAV and HTTP Hopkins (Microsoft), Barry Lind (Xythos), Sean Lyndersay
protocols upon which this protocol is layered, and the invaluable (Microsoft), Eric Sedlar (Oracle), Greg Stein (Apache.org),
feedback from the WebDAV working group. and Jim Whitehead (UC Santa Cruz). Prior work on WebDAV access
control protocols has been performed by Yaron Goland, Paul
15 INDEX Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff. 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.
To be supplied. 15 REFERENCES
16 REFERENCES 15.1 Normative 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 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Harvard, 1997, Requirement Levels." RFC 2119, BCP 14, Harvard, March, 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>.
17 AUTHORS' ADDRESSES [REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen,
"Extensible Markup Language (XML)." World Wide Web Consortium
Recommendation REC-xml-19980210. http://www.w3.org/TR/REC-xml-
19980210.[RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H.
Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1." RFC 2616. U.C.Irvine, Compaq,
Xerox, Microsoft, MIT/LCS, June, 1999.
[RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S.
Lawrence, P. Leach, A. Luotonen, L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication. " RFC
2617. Northwestern University, Verisign, AbiSource, Agranat,
Microsoft, Netscape, Open Market, June, 1999.
Clemm, Hopkins, Sedlar, Whitehead [Page 21]
[RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D.
Jensen, "HTTP Extensions for Distributed Authoring _ WEBDAV."
RFC 2518. Microsoft, U.C.Irvine, Netscape, Novell, February,
1999.
[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode
and ISO 10646." RFC 2279. Alis Technologies. January, 1998.
15.2 Informational References
[RFC2026] S.Bradner, "The Internet Standards Process _
Revision 3." RFC 2026, BCP 9. Harvard, October, 1996.
[RFC2396] E. Whitehead, M. Murata, "XML Media Types." RFC
2376. U.C. Irvine, Fuji Xerox Info. Systems. July, 1998. (This
RFC will soon be superseded by <draft-murata-xml-09.txt>,
which has been approved by the IESG as a Proposed Standard,
but not yet issued as an RFC.)
16 AUTHORS' ADDRESSES
Geoffrey Clemm Geoffrey Clemm
Rational Software Rational Software
20 Maguire Road 20 Maguire Road
Lexington, MA Lexington, MA 02421
Email: geoffrey.clemm@rational.com Email: geoffrey.clemm@rational.com
Anne Hopkins Anne Hopkins
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA Redmond, WA 98052
Email: annehop@microsoft.com Email: annehop@microsoft.com
Eric Sedlar Eric Sedlar
Oracle Corporation Oracle Corporation
500 Oracle Parkway 500 Oracle Parkway
Redwood Shores, CA 94065 Redwood Shores, CA 94065
Email: esedlar@us.oracle.com Email: esedlar@us.oracle.com
18 STILL TO DO : Jim Whitehead
U.C. Santa Cruz
. Describe the interactions with resource locking. I'm not Dept. of Computer Science
clear what the resolution was as far as locking the ACL Baskin Engineering
separately from locking the resource. 1156 High Street
Santa Cruz, CA 95064
. Add a section defining new error codes/messages? Or should we Email: ejw@cse.ucsc.edu
make a pass through the doc and ensure all possible error
conditions are mapped to existing errors?
. Articulate that the required DAV:principal property should be
able to be used for equality checks. Equality checks were
mentioned as one reason why this property should be mandatory,
even if the URI is fake.
. Update "Setting Access Control Information" and to address
whether read-only (ie, inherited) ACEs should be stripped out
by the client prior to PROPPATCH. Fix, if necessary, comments
on editing inherited ACEs in ACL Inheritance section.
. Renaming DAV:rights to DAV:effectiverights? and update sample
. Revisit description of Property ACEs to reflect group 17 STILL TO DO
agreement. Add sample code. Anne will need to update
Semantics descriptions to address property ACEs.
. Update the self, ownergroup stuff according to eventual * If we can add more elements to DAV:resourcetype, we can
agreements. eliminate DAV:is-principal.
. Make document consistent: Clemm, Hopkins, Sedlar, Whitehead [Page 22]
* Add back the XML schema if provides info not in the DTD's.
o Ensure all property descriptions indicate whether the * Consider adding a DAV:matching-principals, which identifies
property is: all ACL principals that match the current user.
. "live" or "dead" * Add DAV:ordering-constraints, DAV:required-principals, and
. read-only or writable DAV:ace-combination-semantics as sub-elements of DAV:acl-
. REQUIRED or OPTIONAL semantics.
o Ensure sample XML exists for all new properties, tags,
etc.
o Complete empty sections, like Scalability
19 OPEN ISSUES:
Issue Description Status Clemm, Hopkins, Sedlar, Whitehead [Page 23]
1. Aggregate a right, if granted, that Now addressed in
rights grants access to a set of spec.
subsidiary rights
2. Rights How do we find out what Now addressed in
discovery rights are applicable to a spec.
given resource? Can this be
done by resource type, to
avoid the need to ask each
resource this question?
3. Defined Should we define a 'group' Collection
list of principal type which principals will
"principal- specifically requires that have semantic
types" principal membership be meaning (recursive
recursive? This might make membership applies)
administrative client
implementation easier.
Should this be a
recommendation rather than a
requirement?
4. Reserved Is the list of 'reserved' Discussed in 4/28
principals principals complete ( conference call.
'owner', 'all', or Still Open.
'unauthenticated', 'all-
authenticated', etc.)
5. Standard Is the list of standard Discussed on
rights rights complete? conference call and
updated once in
draft.
6. XML Do we need to scope the Use DAV namespace,
namespace namespace of our XML like other working
for ACL elements via <?namespace groups. Closed.
href =
"http://www.ietf.org/standar
ds/acl/ AS = "A"?>, or can
we use the regular DAV
namespace (shared by both
versioning and RFC 2518)?
7. Rights What is the method for Not a method.
discovery figuring out the list of DAV:Access-Rights
rights? property available.
Closed.
8. Multiple Are we sure we don't want to Requires an
principals/A allow multiple explicit vote
CE [CKNIGHT] principals/ACE?
9. Grant & Are we sure we don't want to Added to spec.
Deny allow grant & deny in the Decision reversed
[CKNIGHT] same ACE? Note that this per 6/23 call and
simplifies the ACE rule to added to spec 01.3.
disallow two ACEs for the Closed.
same principal.
10. Semantic Do we need to specify stuff Yes. Added to
meaning of like whether or not spec.
principal collection principal
colls. membership is recursive?
[GCLEMM]
11. principa The semantic meaning of Added to spec=97
l-name vs. principal-name should be principal-name
display-name defined, or display-name holds
[GCLEMM] should be used "authentication"
string and
displayname holds
readable string
12. ChangeOw Can servers disallow PROPPATCH support
ner [GCLEMM/ changing the owner? for owner is
CKNIGHT] optional in the
spec.
13. Local What text is needed Open
principal regarding principal URLs
URLs without hostname:port
14. ACL as To what extent should ACLs ACLs are
properties be treated as properties? properties. Closed.
15. Semantic Would it be more appropriate Open
s Model to identify these semantic
names models by their
[ANNEHOP] implementation names, ie,
UNIX, NT Canonical? Could
be easier for developers and
users. Neither of these
models is likely to be re-
used by another
implementation.
16. Addition Do we need to include Open
al Semantics additional ACL semantics
models models? What other systems
[ANNEHOP] (.htaccess?) do we need to
support?
17. Detectin How are WebDAV Access Open
g a WebDAV Control compliant servers
Access detected? Define acl
Control extension for the DAV:
server header?
[SEANLYND]
18. DAV:user If we're going to be Open
/group or treating users as resources,
DAV:resource then we should go all the
/collection way.
[SEANLYND]
19. Per- ability to specify rights on Open
property a per-property basis could
ACEs be very useful for webdav.
[ANNEHOP] consider adding an optional
propertytype-id to the ace?
20. Register Need to describe process for Open
ing registering a new ACL
Semantics semantics model option.
Models
[ANNEHOP]
21. Strip Should the client strip all Agreed to strip
Inherited Inherited (read-only) ACEs inherited ACEs in
ACEs? prior to setting an ACL? Do 6/23 call. Anne
[ANNEHOP] we need a flag that re-opening issue.
indicates whether the server
accepts a client update of
inherited ACEs (to support
client-side propagation of
inheritance)? And/or a flag
to indicate that the client
WANTs to set inherited ACEs?
 End of changes. 

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