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