--- 1/draft-ietf-webdav-acl-11.txt 2006-02-05 02:10:22.000000000 +0100
+++ 2/draft-ietf-webdav-acl-12.txt 2006-02-05 02:10:22.000000000 +0100
@@ -1,17 +1,17 @@
INTERNET-DRAFT Geoffrey Clemm, IBM
- draft-ietf-webdav-acl-11 Anne Hopkins, Microsoft Corporatio
+ draft-ietf-webdav-acl-12 Anne Hopkins, Microsoft Corporation
Eric Sedlar, Oracle Corporation
Jim Whitehead, U.C. Santa Cruz
- Expires March 10, 2004 September 10, 2003
+ Expires April 10, 2004 October 10, 2003
WebDAV Access Control Protocol
Status of this Memo
This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
@@ -423,21 +423,21 @@
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
+ 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.
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.
@@ -453,34 +453,34 @@
3.3 DAV:write-properties
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-
+ 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 PROPPATCH.
Clemm, Hopkins, Sedlar, Whitehead [Page 9]
3.4 DAV:write-content
The DAV:write-content privilege controls methods that modify the
content or (in the case of a collection) membership of the
resource, such as PUT and DELETE. Any implementation-defined
privilege that also controls access to content or alteration of
- collection membership must be aggregated under DAV:write-content—
+ collection membership 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 or DELETE.
3.5 DAV:unlock
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
@@ -1011,29 +1011,29 @@
This is a protected property that specifies the list of access
control entries (ACEs), which define what principals are to get
what privileges for this resource.
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.
-
5.4.1 ACE Principal
The DAV:principal element identifies the principal to which this
ACE applies.
-
The current user matches DAV:href only if that user is
authenticated as being (or being a member of) the principal
identified by the URL contained by that DAV:href.
The current user always matches DAV:all.
The current user matches DAV:authenticated only if authenticated.
@@ -1054,32 +1054,32 @@
Clemm, Hopkins, Sedlar, Whitehead [Page 20]
element, the URI value of DAV:href 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
, 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.
- Alternately, some servers may support ACEs applying to those users
- NOT matching the current principal, e.g. all users not in a
- particular group. This can be done by wrapping the DAV:principal
- element with DAV:invert.
-
-
The current user matches DAV:self in a DAV:acl property of the
resource only if that resource is a principal and that principal
matches the current user or, if the principal is a group, a member
of that group matches the current user.
+ Some servers may support ACEs applying to those users
+ NOT matching the current principal, e.g. all users not in a
+ particular group. This can be done by wrapping the DAV:principal
+ element with DAV:invert.
+
+
5.4.2 ACE Grant and Deny
Each DAV:grant or DAV:deny element specifies the set of privileges
to be either granted or denied to the specified principal. A
DAV:grant or DAV:deny element of the DAV:acl of a resource MUST
only contain non-abstract elements specified in the DAV:supported-
privilege-set of that resource.
@@ -1269,21 +1269,21 @@
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
http://www.example.com/papers/
-
+
HTTP/1.1 200 OK
@@ -1575,21 +1575,21 @@
in access being denied.
Note that the semantics of many other existing ACL systems may be
represented via this mechanism, by mixing deny and grant ACEs.
For example, consider the standard "rwx" privilege scheme used by
UNIX. In this scheme, if the current user is the owner of the
file, access is granted if the corresponding privilege bit is set
and denied if not set, regardless of the permissions set on the
Clemm, Hopkins, Sedlar, Whitehead [Page 30]
- file’s group and for the world. An ACL for UNIX permissions of
+ fileĆs group and for the world. An ACL for UNIX permissions of
"r--rw-r--"might be constructed like:
@@ -1605,21 +1605,21 @@
and the would be defined as:
-
+
Note that the client can still get errors from a UNIX server in
spite of obeying the , including (adding an ACE specifying a principal other than the
ones in the ACL above) or (by trying to reorder
the ACEs in the example above), as these particular implementation
@@ -1643,21 +1643,21 @@
insufficient privileges, the response body to the "403 Forbidden"
error MUST contain the element, which in turn contains
the element, which contains one or more
elements indicating which resource had insufficient
privileges, and what the lacking privileges were:
Since some methods require multiple permissions on multiple
resources, this information is needed to resolve any ambiguity.
- There is no requirement that all privilege violations be reported—
+ There is no requirement that all privilege violations be reportedů
for implementation reasons, some servers may only report the first
privilege violation. For example:
>> Request <<
MOVE /a/b/ HTTP/1.1
Host: www.example.com
Destination: http://www.example.com/c/d
>> Response <<
@@ -2854,129 +2854,126 @@
Email: ejw@cse.ucsc.edu
Clemm, Hopkins, Sedlar, Whitehead [Page 55]
19 APPENDICES
19.1 WebDAV XML Document Type Definition Addendum
All XML elements defined in this Document Type Definition (DTD)
belong to the DAV namespace. This DTD should be viewed as an
addendum to the DTD provided in [RFC2518], section 23.1.
-
+
-
-
+
-
Clemm, Hopkins, Sedlar, Whitehead [Page 56]
-
-
-
-
+
+
-
+
-
+
-
+
+
+
-
+
-
+ Clemm, Hopkins, Sedlar, Whitehead [Page 57]
+
-
+
-
-
-
-
+
-
-
+
- Clemm, Hopkins, Sedlar, Whitehead [Page 57]
-
-
-
+
-
+
+
+
+
+
ANY value: a sequence of one or more elements, with at most one
@@ -2989,20 +2986,21 @@
an href element that contains the URI of a principal
+
19.2 WebDAV Method Privilege Table (Normative)
The following table of WebDAV methods (as defined in RFC 2518, 2616,
and 3253) clarifies which privileges are required for access for each
method. Note that the privileges listed, if denied, MUST cause access
to be denied. However, given that a specific implementation MAY define
an additional custom privilege to control access to existing methods,
having all of the indicated privileges does not mean that access will