view Side-By-Side changes
INTERNET-DRAFT Eric Sedlar, Oracle Corporation
draft-ietf-webdav-acl-01.txt Geoffrey Clemm, Rational Software
draft-ietf-webdav-acl-02 Anne Hopkins, Microsoft Corporation
Eric Sedlar, Oracle Corporation
Expires November 1, 2000 May 1, January 14, 2001 July 14, 2000
Access Control Extensions to WebDAV
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 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
that define the WebDAV Access Control extensions to the HTTP/1.1
protocol.
Sedlar, Clemm Clemm, Hopkins [Page 1]
INTERNET-DRAFT WebDAV ACL May 1, July 14, 2000
Table of Contents
1 INTRODUCTION............................................3
1.1 Notational Conventions................................3
2 PRINCIPALS..............................................3
3 RIGHTS..................................................4
3.1 RIGHTS-DISCOVERY method...............................5 DAV:access-rights property............................5
3.2 Rights defined by WebDAV..............................6
3.2.1 read Right........................................6
3.2.2 write Right.......................................6 Right.......................................7
3.2.3 readacl Right.....................................6 Right.....................................7
3.2.4 writeacl Right....................................6 Right....................................7
3.2.5 all Right.........................................6 Right.........................................7
4 ACCESS CONTROL PROPERTIES...............................7
4.1 Example 1 - Retrieving Access Control information.....8 Information................11
4.1.1 Example: Retrieving Access Control information...11
4.2 Setting Access Control Information...................12
4.2.1 Example: Setting Access Control information......13
5 USING ACLS..............................................9 ACLS.............................................14
5.1 System Controlled Rights.............................14
5.2 Special Principal Identifiers........................15
5.3 ACL Semantics Options................................15
5.3.1 FirstSpecific....................................16
5.3.2 ExplicitDenyPrecedence...........................16
6 ACL METHOD.............................................10 INHERITANCE........................................18
6.1 Example 1 - Setting ACLs.............................10
7 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 INHERITANCE / DEFAULT ACLS.........................11
8 from inheritance.........................19
7 XML SCHEMA FOR DEFINED ELEMENTS........................12
9 ELEMENTS........................20
8 INTERNATIONALIZATION CONSIDERATIONS....................13
10 CONSIDERATIONS....................21
9 SECURITY CONSIDERATIONS..............................13 CONSIDERATIONS................................21
10 SCALABILITY..........................................21
11 SCALABILITY..........................................13 AUTHENTICATION.......................................21
12 AUTHENTICATION.......................................13
13 IANA CONSIDERATIONS..................................13
14 CONSIDERATIONS..................................21
13 INTELLECTUAL PROPERTY................................13 PROPERTY................................21
14 ACKNOWLEDGEMENTS.....................................22
15 ACKNOWLEDGEMENTS.....................................14
16 INDEX................................................14
17 REFERENCES...........................................14
18 AUTHORS' ADDRESSES...................................15
19 STILL TO DO :........................................15
Sedlar, Clemm INDEX................................................22
Clemm,Hopkins,Sedlar [Page 2]
INTERNET-DRAFT WebDAV ACL May 1, July 14, 2000
16 REFERENCES...........................................22
17 AUTHORS' ADDRESSES...................................23
18 STILL TO DO :........................................23
19 OPEN ISSUES:.........................................25
1 INTRODUCTION
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 "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 to describe protocol
elements is described in Section 2.1 of [RFC2068]. Because this
augmented BNF uses the basic production rules provided in Section
2.2 of [RFC2068], 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 an entity that can be given access rights
to HTTP resources. On many implementations, a user or a group
will be examples of principals, but other types of principals are
possible. For the most part, any classification or other
information about the entity identified by a principal is opaque
with respect to this specification, and 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 required by this specification. Those properties
include:
@ <dav:principalname>:
. DAV:principalname: A "live" 'live' property containing the name
used to authenticate this principal (typically typed into a
login prompt/dialog). [OPTIONAL]
@ <dav:displayname>:
Clemm,Hopkins,Sedlar [Page 3]
INTERNET-DRAFT WebDAV ACL July 14, 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>:
. DAV:principal-type: A "live" 'live' property containing a
classification word for this principal. The values <dav:user/> DAV:user
and <dav:group/> DAV:group are choices for value of this property
recommended by this spec. The presence of
Sedlar, Clemm [Page 3]
INTERNET-DRAFT WebDAV ACL May 1, 2000 this property can be
used to distinguish it as a principal from other resources on
a WebDAV server. (Note that <dav:resourcetype> DAV:resourcetype may not be used,
as all collections must use the value "collection" for <resourcetype>,
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
maintaining collections (e.g. BIND, DELETE, PROPFIND) may be used to
maintain collection principals. Membership in a collection
principal is recusive, recursive, so a principal in a collection principal
A contained by collection principal B is a member of both
collection principals. Implementations not supporting recursive
membership in principal collections can return an error if the
client attempts to bind collection principals into other
collection principals. Using WebDAV methods to alter the content
of a principal (e.g. using PROPPATCH or PUT) is outside the scope
of this specification, and is not required, recommended, or
forbidden by this spec.
3 RIGHTS
A right controls access to a particular set of HTTP operations on
a resource. The set of rights that apply to a particular
resource may vary with the <dav:resourcetype> DAV:resourcetype of the resource, as
well as between different server implementations. To promote
interoperability, however, WebDAV defines a set of well-known
rights (e.g. <dav:read> DAV:read and <dav:write>), DAV:write), which can at least be used
to set some context to the other rights defined on a particular
resource.
Rights may be aggregates of other rights. For example, one
implementation may split out a right controlling the ability to
BIND
add children into to a collection from the right allowing a resource
to be removed from a collection. Since these rights control the
ability to write to a collection, these rights would be
aggregated by the <dav:write> DAV:write right. The relationships between
atomic rights and aggregate rights can be discovered via the RIGHTS-DISCOVERY HTTP method
DAV:access-rights property on a particular resource. Servers may
specify some rights as abstract, which means that it
may MUST not
Clemm,Hopkins,Sedlar [Page 4]
INTERNET-DRAFT WebDAV ACL July 14, 2000
appear in an ACL, but is described in the RIGHTS-
DISCOVERY method DAV:access-rights
property to aid in setting context. Server implementations must
return the same response to the RIGHTS-
DISCOVERY method DAV:access-rights property on all
of the resources with the same
<dav:resourcetype> DAV:resourcetype value.
Sedlar, Clemm [Page 4]
INTERNET-DRAFT WebDAV ACL May 1, 2000
3.1 RIGHTS-DISCOVERY method
Rights discovery DAV:access-rights property
The DAV:access-rights property is a method with no arguments, live property that returns 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" 'true' if this right cannot MUST NOT be used in
an ACL/ACE. Defaults to "false"
@ description 'false.' Note: an abstract right need
not be an aggregate right.
. Description (string): a human readable human-readable description of what
this right controls access to. Required. [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
RIGHTS-DISCOVERY
request on a WebDAV server implemented by a
relational database (where the resource in this case corresponds
to a table): server.
Request
RIGHTS-DISCOVERY /schemas/scott/emp
PROPFIND /file HTTP/1.1
Host: www.foo.bar
Content-type: text/xml; charset="utf-8"
Content-Length:
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 200 Success 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxxx xxx
<?xml version="1.0" encoding="utf-8" ?>
<?namespace href = "http://www.oracle.com/webdav/ AS = ORA"?> version="1.0"?>
<D:multistatus xmlns:D="DAV:"
xlmns:A="http://www.foo.bar/schema/">
<D:response>
<D:all abstract=true description="All access">
<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 abstract="true" description="Write any database row">
<ORA:insert abstract=false description="Insert a row"/>
<ORA:update abstract=false
object">
<A:create abstract="false" description="Create an
object"/>
<A:update abstract="false" description="Update a row"/>
<ORA:delete abstract=false an
object"/>
<A:delete abstract="false" description="Delete a row"/>
</D:write> an
object"/>
<D:write/>
<D:read abstract=false description="SELECT data from a row"/> abstract="false" description="Read any
object"/>
<D:readacl abstract=false abstract="false" description="Read the
ACL"/>
<D:acadmin abstract=false description="Update
<D:writeacl abstract="false" description="Write the ACL and
owner"/>
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.
Sedlar, Clemm [Page 5]
INTERNET-DRAFT WebDAV ACL May 1, 2000
3.2 Rights defined by WebDAV
The rights defined by WebDAV access control MUST be present in
the response to the RIGHTS-DISCOVERY method, DAV:access-rights property, although they may be abstract
(and not usable within an ACE on a particular implementation).
3.2.1read Right
Name: <dav:read>
Purpose: The read right provides and restricts access
Ability to
information regarding the state perform a given method on a resource MUST be
controlled by some right. Authors of the resource, including the
resource's 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> DAV:write
Purpose: The <write> 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> DAV:readacl
Purpose: The <readacl> readacl right provides and restricts access
to the <dav:acl> DAV:acl property of this resource, rather than the <dav:read>
DAV:read right. If a user has the <readacl> readacl right and not the <read> read
right, the <dav:acl> property ONLY is 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> read right and not the <readacl> readacl right, the <dav:acl>
property
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> DAV:writeacl
Purpose: The <writeacl> (Access Control ADMINistration) writeacl right provides and restricts access
to ACL method, which is the
only means of altering the <dav:acl> (and indirectly,
<dav:rights>) property of a resource. DAV:acl and DAV:owner properties.
3.2.5all Right
Name: <dav:all>
Sedlar, Clemm [Page 6]
INTERNET-DRAFT WebDAV ACL May 1, 2000 DAV:all
Purpose: The <dav:all> DAV:all right controls all other rights on
this resource. If the <dav:all> 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 RIGHTS-
DISCOVERY method, 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 method. and
PROPPATCH method (subject to permissions and 'liveness.' An HTTP
resource on a WebDAV ACL-compliant Access Control-compliant server MUST contain
the following properties:
@ <dav:owner>:
. 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. There is no provision for a client
updating this property in this spec, however
it is recommended that any authenticated user
with appropriate administrative privileges be
allowed to issue a PROPPATCH to update its
value. Normally, an attempt to PROPPATCH this
property will result in a 401 (Not
Authorized) error. [REQUIRED]
@ <dav:owner-name>: A "live" property containing a human-
readable description of the <dav:owner>
[OPTIONAL]
@ <dav:rights>:
. DAV:rights: A "live" 'live' readonly property containing the list of
rights of the currently authenticated HTTP user. Read The read
right controls read access to this property is
controlled by the <read> right. This
property can NEVER be set directly. property. [REQUIRED]
@ <dav:acl>:
. DAV:acl: A "live" 'live' property containing one or more
<dav:ace> DAV:ace
tags, which specify which principals are to get access to what
rights, for the resource with this ACL property. [REQUIRED]
The <dav:acl> element (property) contains 0 or more of
. DAV:aclsemantics: A readonly property indicating the
following XML elements:
@ <dav:ace>: An access control entry, which specifies ACL
semantics model supported by the
set of rights to be granted to a single
principal.
The <dav:ace> element contains system. [REQUIRED]
. DAV:protectaclfrominheritance: A "live" property indicating
that the following XML elements:
Sedlar, Clemm [Page 7]
INTERNET-DRAFT WebDAV ACL May 1, 2000
@ <dav:grant>: Contains does not inherit any ACEs. If this property is
present, the set of XML elements
corresponding to 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 MUST contain at least
Clemm,Hopkins,Sedlar [Page 8]
INTERNET-DRAFT WebDAV ACL July 14, 2000
one right
@ <dav:deny>: 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 MUST contain at least
one right, if present.
@ <dav:principal-id>: A URL of MUST NOT be present if the DAV:grant
element is present.
. DAV:principal: Contains information about the principal
resource this ACE applies to, or to. [REQUIRED].
. DAV:acepropertytypes: A "live" property containing one of the tags <dav:owner> or
<dav:all-principals>. Always present. The
value more
elements, each of this element must be unique within which is an ACL.
@ <dav:principal>: Contains properties of the principal XML tag identifying either a
property on this resource (made available here to avoid the
need for or a separate PROPFIND request).
Optional.
A PROPFIND property on a child resource on
that may inherit this ACE. Presence of DAV:acepropertytypes
distinguishes this ACE as a WebDAV ACL server might produce the
following XML output:
4.1 Example 1 - Retrieving Access Control information
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 200 Success
Content-Type: text/xml
Content-Length: xxxxx
<?xml version="1.0" encoding="utf-8" ?>
<?namespace href = "http://www.ietf.org/standards/webdav/ AS =
D"?>
<D:response>
<D:propstat>
<D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
<D:displayname>Example collection</D:displayname>
<D:resourcetype><D:collection/></D:resourcetype>
<D:supportedlock> XXXXX</D:supportedlock>
<D:owner>http://www.rational.com/principals/users/gclemm</d:owner
>
<D:owner-name>Geoffrey Clemm</d:owner-name>
Sedlar, Clemm [Page 8]
INTERNET-DRAFT WebDAV ACL May 1, 2000
<D:rights>
<D:read/><D:readacl/>
</D:rights>
<D:acl>
<D:ace>
<D:grant><D:read/><D:write/><D:readacl/></D:grant>
<D:principal-id>
<D:href>http://www.foo.com/users/esedlar</D:href>
</D:principal-id>
<D:principal>
<D:principal-type>User</D:principal-type>
<D:principalname>esedlar</D:principalname>
<D:displayname>Eric Sedlar</D:displayname>
</D:principal>
</D:ace>
<D:ace>
<D:grant><D:read/><D:readacl/></D:grant>
<D:deny><D:writeacl/></D:deny>
<D:principal-id>
<D:href>http://www.foo.com/groups/marketing</d:href>
</D:principal-id>
<D:principal>
<D:principal-type>Group</D:principal-type>
<D:displayname>Foo.Com marketing
department</D:displayname>
<D:principalname>mktdept</D:principalname>
</D:principal>
</D:ace>
<D:ace>
<D:grant><D:read/></D:grant>
<D:principal-id><d:all/></D:principal-id>
</D:ace>
</D:acl>
<D:propstat>
<D:response>
5 USING ACLS
By default, "Property ACE." The rights
associated with a principal has no "Property ACE" control access rights to an object
protected by an ACL. A particular ACE may either grant or deny only the
property(ies) contained in DAV:acepropertytypes, and do not
control access to the resource as a whole. The set of access
rights to a single principal. It is illegal for an ACL to
have two supported on Property ACEs applying to the same principal. However, since a
server may match the currently authenticated HTTP user with
multiple principals, it is possible for multiple ACEs to apply to
the current user. In this case, if be all or a particular right is denied
to subset of
the current user by any ACE, DAV:access-rights present on this supercedes any ACE that
might grant that right. resource. This is the case regardless if spec
does not provide a ("more
specific") ACE granting access applied mechanism to specify a principal identifying
the user directly, while the ACE denying access applied to different set of
access-rights for a
collection principal containing property, than for the resource. An
implementation that user. The particular order supports a different set of access-rights
for a property than for the ACEs within resource, must return an ACL is irrelevant. The <principal-id> tag
can also contain the following special tags: <owner>, <all>,
<unauthenticated>. These tags have the following meaning:
Sedlar, Clemm [Page 9]
INTERNET-DRAFT WebDAV ACL May 1, 2000
@ owner: The principal identified error
"Unsupported Right" on an attempt to write a Property ACE with
rights not supported by the owner server. [OPTIONAL]
. DAV:inherittochildtype: A "live" property on
this resource is granted containing one or denied
more elements, each of which is an XML tag identifying the rights specified in
type of child object that will inherit this ACE.
@ all: The current user always matches this ACE, whether or
not s/he This
property is authenticated.
@ unauthenticated: The only present if DAV:inheritanceflags contains at
least one of the following: DAV:inheritonly,
DAV:containerinherit, or DAV:objectinherit. A child of the
current user matches resource will only inherit this ACE if not
authenticated
Server implementations may limit the number type of ACEs the
child object is present in DAV:inherittochildtype.
. DAV:inheritanceflags: A "live" property containing flags
indicating the inheritance features of this ACE. For an ACL.
However, ACL-compliant servers are required to support at least
one ACE granting rights to a single principal, and one ACE
granting rights to a collection principal. The server should
return an error "Too many ACEs" in this case.
6 ACL METHOD
The ACL Method provides a mechanism to set ACL information. Its
request body
that is used to define alterations to neither inherited, nor inheritable, this element may
be either not present, or present but empty. [OPTIONAL]
. DAV:inheritancesource: A readonly property containing the ACL URL
of the resource identified by the request-URI. Its response body
contains from which this ACE was inherited (contained
within an DAV:href element). In other words, the current ACL for that resource. The ACL method
replaces the <acl> and <owner> properties on the specified
resource with referred to by this URI contains the properties inheritable
explicit ACE which, when propagated to the current resource,
resulted in the request. All readable ACEs
previously stored in the ACL on current ACE. This element may contain the indicated resource are
removed, so an ACL method on a resource with an unreadable <acl>
property will be ignored. (If
special value of DAV:system-ace to indicate that the server implements ACE is
read-only and represents rights
outside granted implicitly by the
system. This element may contain the special value of those defined in this specification, they might allow
only some ACEs
DAV:unknown if the server is unable to generate a valid URI to be visibleùin this case, only part of
the ACL
will resource from which this element was inherited. This
element MUST be replaced).
Change requests through present if DAV:inheritanceflags contains the
Clemm,Hopkins,Sedlar [Page 9]
INTERNET-DRAFT WebDAV ACL method July 14, 2000
DAV:inherited flag for inherited ACEs and MUST NOT be atomic. If any
part of the change request fails then all changes MUST fail. present
for explicit ACEs.
The
presence of an empty ACL causes all ACEs in DAV:principal element contains the ACL, including
ACEs for associated properties, to be deleted. An empty request
body will cause no change following elements:
. DAV:href: This is a URI representing the resource to which
the ACL ACE applies, or associated values. If one of the <principal> element (specifying properties 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 resource
identified by same as the ACE's <principal-id>) is specified, it (and its
children) is ignored.
6.1 Example 1 - Setting ACLs
An ACL request body is an acl-info XML element. The <dav:acl-
info> element contains properties that can be set by exist on the ACL
method (currently just <acl>).
Request
ACL /top/container HTTP/1.1
Host: www.foo.com
Content-Type: text/xml
Content-Length: xxxx
<?namespace href = "http://www.ietf.org/standards/webdav/ AS =
D"?>
<D:acl-info>
Sedlar, Clemm [Page 10]
INTERNET-DRAFT WebDAV ACL May 1, 2000
<D:acl>
<D:ace>
<D:grant><D:read/><D:write/><D:readacl/></D:grant>
<D:principal-id>
<D:href>http://www.foo.com/users/esedlar</D:href>
</D:principal-id>
</D:ace>
<D:ace>
<D:grant><D:read/> </D:grant>
<D:principal-id>
<D:href>http://www.foo.com/groups/marketing</D:href>
</D:principal-id>
</D:ace>
</D:acl>
</D:acl-info>
Response
HTTP/1.1 200 Success
Content-Length: 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 request changes flag indicates the group ACE to disallow read access to is inherited from
the ACL for the marketing group. 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 other information had to 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
recopied
removed from the ACL retrieved in inherited effective ACE on the previous example.
7 ACL INHERITANCE / DEFAULT ACLS
To 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 added
Sedlar, Clemm
removed from the inherited effective ACE on the non-container
resource. If the DAV:nopropagateinheritance> flag is not
present, then container resources will also inherit this ACE
with the addition of the DAV:inheritonly> flag. [REQUIRED]
. DAV:nopropagateinheritance: This flag indicates the ACE should
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 11] 10]
INTERNET-DRAFT WebDAV ACL May 1, July 14, 2000
8 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
The DAV:aclsemantics element MUST contain exactly one of the
following XML Schema, minOccurs
defaults to 0, and maxOccurs defaults elements:
. DAV:firstspecific: This element is present if the ACL
conforms 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"/>
Sedlar, Clemm 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 the
server implements rights outside of those defined in this
specification, they might allow only some ACEs to be visible=97
Clemm,Hopkins,Sedlar [Page 12]
INTERNET-DRAFT WebDAV ACL May 1, July 14, 2000
<element name="dav:principal-type" type="string"
minOccurs="1"/>
</complexType>
</element>
</complexType>
<element name="dav:acl">
behaviour on a PROPPATCH is undefined with respect to this
specification).
Setting an empty ACL property causes all ACEs in the ACL,
including ACEs for associated properties, to be deleted.
Since permission to set an ACL is typically controlled by a
different right from permission to set other properties, it is
recommended that ACL-setting PROPPATCHes be executed
independently from PROPPATCHes of other properties. PROPATCH as
defined in [WEBDAV] is an atomic operation, so failure to set the
ACL will result in a failure to set all other properties.
[WEBDAV] also defines that operations must be performed from top
to bottom, so multiple instances of the DAV:acl element in a
single PROPPATCH result in only the last being set.
Changing ownership of a resource requires setting the DAV:href
element of the DAV:owner property.
4.2.1Example: Setting Access Control information
The following example follows from the previous example and
changes the group ACE to disallow read access to the ACL for the
marketing group. The other information had to be copied from the
ACL retrieved in 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
An ACL contains zero or more ACEs that express the rights granted
or denied to the principal specified in the ACE. An ACL with
zero ACEs implies that no principal is granted any rights. A
particular ACE may either grant or deny a set of rights to a
single principal. However, since a server may match the
currently authenticated HTTP user with multiple principals (for
instance, in the case where one principal refers to the user and
another principal refers to a group to which the user belongs),
it is possible for multiple ACEs to "match" the current user. A
user has no access rights to an object protected by an ACL unless
that user matches one or more of the principals specified in the
ACEs.
Server implementations may limit the number of ACEs in an ACL.
However, ACL-compliant servers are required to support at least
one ACE granting rights to a single principal, and one ACE
granting rights to a collection principal. If a client tries to
write an ACL containing more ACEs than the server supports, the
server should return an error "Too many ACEs."
5.1 System Controlled Rights
Some implementations may grant certain rights implicitly. For
example, some systems grant the resource owner DAV:readacl and
DAV:writeacl implicitly to prevent an ACL from becoming
irrevocably locked by an update that grants no one the
DAV:writeacl right. Any rights granted implicitly by the system
should be reflected as standard ACEs in the ACL returned to the
client. Since these implicit permissions are read-only, they
should be reflected as "system controlled" ACEs where
DAV:inheritanceflags contains DAV:inherited and the
DAV:inheritancesource element contains DAV:system-ace.
Clemm,Hopkins,Sedlar [Page 14]
INTERNET-DRAFT WebDAV ACL July 14, 2000
5.2 Special Principal Identifiers
The DAV:principal element in an ACE may contain, instead of a
specific security principal identifier, one of the following
special tags:
. DAV:owner: The principal identified by the owner property on
this resource is granted or denied the rights specified in
this ACE.
. DAV:all: The current user always matches this ACE, whether or
not s/he is authenticated.
. DAV:authenticated: The current user matches this ACE if
authenticated.
. DAV:unauthenticated: The current user matches this ACE if not
authenticated
. DAV:selfprincipal: The current user matches this ACE 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 is used
to indicate what semantics to apply to the ACL. A client may use
this tag to display information that helps an ACL author
understand the implications of his updates. The client must also
use this tag to determine the legal semantics for ordering ACEs
prior to updating the ACL property.
The following ACL Semantics options have been defined to
indicate:
. restrictions, if any, on the ordering of ACEs within a stored
ACL,
. how to determine during access check which ACE(s) apply to a
user that matches multiple principals,
. how to combine 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 the user identity and the ACEs, but also on the "requested
rights," which is the set of rights required by the operation for
which the access check is being performed.
Clemm,Hopkins,Sedlar [Page 15]
INTERNET-DRAFT WebDAV ACL July 14, 2000
Effective Rights: The "effective rights" of a user is the set of
all rights that would be granted to a user by a given ACL. This
set, which is exposed via the DAV:rights property, is independent
of any operation "requested rights" and may be generated by a
different algorithm than the access check algorithm that
determines whether a user has specific requested rights. Each
right in the Effective Rights set applies to the user whether the
right is requested individually, or in combination with other
rights, in the requested rights for an operation.
5.3.1FirstSpecific
The FirstSpecific semantic model has the following
characteristics:
Order of ACEs: ACEs are ordered from "most specific" to "least
specific." Typically, the "most specific" ACEs identify
principals that refer to a single user. ACEs with "intermediate"
specificity have principals that refer to a collection or group
of users or other entities. The "least specific" ACEs contain
principals, like "World" or "Everyone," that indicate an
unbounded set of users. If multiple ACEs with the same level of
specificity are present, their order relative to each other is
not defined here. Implementations of the FirstSpecific model are
unlikely to have multiple ACEs in the intermediate and least
specific categories (where multiple ACE matches are possible),
making it unimportant to define a rule for relative ordering of
ACEs within these two specificity levels.
ACE Matching Algorithm: ACEs are evaluated in the order in which
they appear in the ACL, from first to last. When a match is
found, the algorithm is complete. This first matching ACE alone
is used to determine the effective rights of the user. If it is
a Grant ACE, then the user is granted all rights in the ACE. If
it is a Deny ACE, then the user is denied all rights in the ACE.
Requested rights may be compared with the effective rights to
determine if access should be granted.
ACE Combining Algorithm: The FirstSpecific model never matches
more than one ACE to a user, thus there's no need to combine the
rights of multiple ACEs.
Example Implementation: UNIX rights (rwx for user:group:world) is
an example of the FirstSpecific model.
5.3.2ExplicitDenyPrecedence
The ExplicitDenyPrecedence model has the following
characteristics:
Order of ACEs: All Explicit ACEs must precede all Inherited ACEs.
Within the group of Explicit ACEs, all Deny ACEs must precede all
Grant ACEs. Inherited ACEs are placed in the order in which they
are inherited. ACEs inherited from the resource's parent come
first, then ACEs from the grandparent, and so on.
Clemm,Hopkins,Sedlar [Page 16]
INTERNET-DRAFT WebDAV ACL July 14, 2000
ACE Matching and Combining Algorithm: 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 of
"Denied rights", both initialized with zero rights, are
maintained in the algorithms to check for Requested Rights and to
calculate Effective Rights. In both cases, ACEs are evaluated in
the order in which they appear in the ACL, from first to last.
Checking for Requested Rights: For each ACE evaluated, if the ACE
matches the current user, then:
. if it is a Grant ACE, any rights in the ACE that are not
already in the "Granted rights" or "Denied rights" sets are
added to the "Granted rights" set
. if it is a Deny ACE, any rights in the ACE that are not
already in the "Granted rights" or "Denied rights" sets are
added to the "Denied rights" set
If the "Granted rights" set now contains all rights in the set of
"requested rights," then no more ACEs are evaluated and the
algorithm completes with "Requested Access Granted."
If the "Denied rights" set now contains any right that is in the
set of "requested rights," then no more ACEs are evaluated and
the algorithm completes with "Requested Access Denied."
If neither of these cases is true, then the next ACE is
evaluated. If there are no more ACEs present in the ACL, then
the algorithm completes with "Requested Access Denied" since the
accumulated Granted rights did not contain all of the requested
rights.
Calculating the effective rights of a user: As in the check for
requested rights, for each ACE evaluated, if the ACE matches the
current user, then:
. if it is a Grant ACE, any rights in the ACE that are not
already in the "Granted rights" or "Denied rights" sets are
added to the "Granted rights" set
. if it is a Deny ACE, any rights in the ACE that are not
already in the "Granted rights" or "Denied rights" sets are
added to the "Denied rights" set
If the union of the "Granted rights" and "Denied rights" now
contains all possible rights, then no more ACEs are evaluated and
the algorithm returns the Granted rights as the set of Effective
Rights.
Otherwise, the next ACE is evaluated. If there are no more ACEs
present in the ACL, then all rights present in the "Granted
rights" set are returned as Effective Rights.
Example Implementation: Microsoft Windows NT canonical ACLs are
an example of this model.
Clemm,Hopkins,Sedlar [Page 17]
INTERNET-DRAFT WebDAV ACL July 14, 2000
6 ACL INHERITANCE
To support a more scalable administration model for configuration
of access control information, the spec defines an ACL
inheritance model that enables an ACL, or elements of an ACL, to
be inherited and reused by other resources. An ACL-compliant
implementation is not required to support inheritance.
Typically, an ACL defined on a container resource may be
inherited by children of that container, grandchildren if they
exist, and so on down the tree. Although this hierarchical tree
model of inheritance is popular, this spec does not require an
implementation's ACL inheritance model to follow a tree structure
where child resource inherits from parent resource. Nonetheless,
for convenience, this description of inheritance assumes that a
child resource would inherit access control information from its
parent.
6.1 Inheritable ACEs
Access control information is inherited at the granularity of an
ACE. An inherited ace is identified by the presence of the
DAV:inherited element in the DAV:inheritanceflags property. An
"Explicit" ACE is an ACE defined directly on a resource, rather
than inherited from a different resource. An ACE without the
DAV:inherited element is by definition an Explicit ACE. Only
Explicit ACEs may updated by the client.
To indicate that an ACE should be inherited by child resources,
the DAV:inheritanceflags should contain:
. DAV:objectinherit to indicate that non-container children
should inherit the ACE,
. DAV:containerinherit to indicate that container children
should inherit the ACE, or
. both to indicate that all child resources should inherit the
ACE.
6.2 Updating an inherited ACE
When a child resource ACL inherits an ACE, the DAV:inherited
flag is present on the ACE to indicate that this ACE is read-
only (it may only be edited on the resource where the ACE was
explicitly defined). To assist users who want to make changes
to the rights that appear in an inherited ACE, the resource from
which the ACE was inherited (and therefore, on which the
explicit ACE is defined and editable) is identified in the
DAV:inheritancesource property. If the inheritance source
cannot be determined or if the system is unable to generate a
valid URI to the resource from which the ACE was inherited,
DAV:inheritancesource contains the special tag DAV:unknown.
Clemm,Hopkins,Sedlar [Page 18]
INTERNET-DRAFT WebDAV ACL July 14, 2000
6.3 Propagate ACE but do not use for Access Check on this resource
In some cases, an ACE (whether explicit or inherited) may be
present on a container ACL purely for the sake of propagating
the ACE to child objects and NOT to be used for access control
on the container itself. In this case, the optional
DAV:inheritonly flag is present on the ACE to indicate it should
not be used for access check on this container.
6.4 Propagate to immediate children only
To indicate that an ACE should be inherited by children, but not
by grandchildren or any further down the tree, the optional
DAV:nopropagateinheritance flag is present on the ACE. This
flag indicates that when this ACE is inherited by child objects,
the DAV:objectinherit and/or DAV:containerinherit elements must
be removed from the inherited ACE.
6.5 Protect ACL from inheritance
To prevent an ACL from inheriting any ACEs, the optional
DAV:protectaclfrominheritance property is set on the resource.
If this property is present on a resource, the DAV:inherited
element must not be present on any ACEs in that resource's ACL.
Other inheritance flags may be present on the ACEs of this
resource, since this ACL may be the source of inheritable ACEs
for the subtree under this resource.
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 [Page 20]
INTERNET-DRAFT WebDAV ACL July 14, 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" name="DAV:ace" type="DAV:ace"
minOccurs="0" maxOccurs="unbounded"/>
</complexType>
</element>
<element name="dav:rights"> name="DAV:rights">
<complexType>
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="dav:right"/> ref="DAV:right"/>
</choice>
</complexType>
</element>
</schema>
9
8 INTERNATIONALIZATION CONSIDERATIONS
To be supplied.
10 SECURITY CONSIDERATIONS
To 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 the namespace defined by [RFC2518] for XML
elements. All other 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 position of the IETF concerning intellectual
property claims made against this document.
Clemm,Hopkins,Sedlar [Page 21]
INTERNET-DRAFT WebDAV ACL July 14, 2000
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described
in this document or the extent to which any license under such
rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can be found
in BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers
or users of this specification can be obtained from the IETF
Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to practice this standard. Please address the information to the
IETF Executive Director.
14 ACKNOWLEDGEMENTS
This protocol is the collaborative product of the WebDAV ACL
design team: xxx, yyy, zzz. We would like to acknowledge the
foundation laid for us by the authors of the WebDAV and HTTP
protocols upon which this protocol is layered, and the invaluable
feedback from the WebDAV working group.
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, and
T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, U.C. Irvine, DEC, MIT/LCS, 1997,
<http://www.ietf.org/rfc/rfc2068.txt >.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Harvard, 1997,
<http://www.ietf.org/rfc/rfc2119.txt >.
[RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
"HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft,
U.C.Irvine, Netscape, Novell, 1999
<http://www.ietf.org/rfc/rfc2518.txt>.
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 the interactions with resource locking. I'm not
clear what the resolution was as far as locking the ACL
separately from locking the resource.
. Add a section defining new error codes/messages? Or should we
make a pass through the doc and ensure all possible error
conditions are mapped to existing errors?
. Articulate that the required DAV:principal property should be
able to be supplied.
11 SCALABILITY
To used for equality checks. Equality checks were
mentioned as one reason why this property should be supplied.
12 AUTHENTICATION
Authentication mechanisms defined in WebDAV will also apply to
WebDAV ACL.
13 IANA CONSIDERATIONS
This document uses mandatory,
even if the namespace defined URI is fake.
. Update "Setting Access Control Information" and to address
whether read-only (ie, inherited) ACEs should be stripped out
by [RFC2518] for XML
elements. All other IANA considerations mentioned the client prior to PROPPATCH. Fix, if necessary, comments
on editing inherited ACEs in [RFC2518]
also applicable ACL Inheritance section.
. Renaming DAV:rights to WebDAV ACL.
14 INTELLECTUAL PROPERTY
The following notice is copied from RFC 2026, section 10.4, DAV:effectiverights? and
describes the position update sample
. Revisit description of Property ACEs to reflect group
agreement. Add sample code. Anne will need to update
Semantics descriptions to address property ACEs.
. Update the self, ownergroup stuff according to eventual
agreements.
. Make document consistent:
o Ensure all property descriptions indicate whether the IETF concerning intellectual
property claims made against this document.
Sedlar, Clemm is:
Clemm,Hopkins,Sedlar [Page 13] 23]
INTERNET-DRAFT WebDAV ACL May 1, July 14, 2000
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation
. "live" or use other technology described
in this document "dead"
. read-only or the extent to which any license under such
rights might writable
. REQUIRED or might not be available; neither does it represent OPTIONAL
o Ensure sample XML exists for all new properties, tags,
etc.
o Complete empty sections, like Scalability
Clemm,Hopkins,Sedlar [Page 24]
INTERNET-DRAFT WebDAV ACL July 14, 2000
19 OPEN ISSUES:
Issue Description Status
1. Aggregate a right, if granted, that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect Now addressed in
rights grants access to a set of spec.
subsidiary rights
2. Rights How do we find out what Now addressed in
standards-track and standards-related documentation can be found
in BCP-11. Copies of claims of
discovery rights made available for
publication and any assurances of licenses are applicable to a spec.
given resource? Can this be made available,
or
done by resource type, to
avoid the result of an attempt made need to obtain ask each
resource this question?
3. Defined Should we define a general license or
permission for the use of such proprietary rights by implementers
or users 'group' Collection
list of principal type which principals will
"principal- specifically requires that have semantic
types" principal membership be meaning (recursive
recursive? This might make membership applies)
administrative client
implementation easier.
Should this specification can be obtained from a
recommendation rather than a
requirement?
4. Reserved Is the IETF
Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, list of 'reserved' Discussed in 4/28
principals principals complete ( conference call.
'owner', 'all', or other
proprietary Still Open.
'unauthenticated', 'all-
authenticated', etc.)
5. Standard Is the list of standard Discussed on
rights that may cover technology that may be required rights complete? conference call and
updated once in
draft.
6. XML Do we need to practice this standard. Please address scope the information to Use DAV namespace,
namespace namespace of our XML like other working
for ACL elements via <?namespace groups. Closed.
href =
"http://www.ietf.org/standar
ds/acl/ AS = "A"?>, or can
we use the
IETF Executive Director.
15 ACKNOWLEDGEMENTS
This protocol regular DAV
namespace (shared by both
versioning and RFC 2518)?
7. Rights What is the collaborative product method for Not a method.
discovery figuring out the list of DAV:Access-Rights
rights? property available.
Closed.
8. Multiple Are we sure we don't want to Requires an
principals/A allow multiple explicit vote
CE [CKNIGHT] principals/ACE?
9. Grant & Are we sure we don't want to Added to spec.
Deny allow grant & deny in the Decision reversed
Clemm,Hopkins,Sedlar [Page 25]
INTERNET-DRAFT WebDAV ACL
design team: xxx, yyy, zzz. We would like to acknowledge July 14, 2000
[CKNIGHT] same ACE? Note that this per 6/23 call and
simplifies the
foundation laid ACE rule to added to spec 01.3.
disallow two ACEs for us by the authors Closed.
same principal.
10. Semantic Do we need to specify stuff Yes. Added to
meaning of the WebDAV and HTTP
protocols upon which this protocol like whether or not spec.
principal collection principal
colls. membership is layered, recursive?
[GCLEMM]
11. principa The semantic meaning of Added to spec=97
l-name vs. principal-name should be principal-name
display-name defined, or display-name holds
[GCLEMM] should be used "authentication"
string and
displayname holds
readable string
12. ChangeOw Can servers disallow PROPPATCH support
ner [GCLEMM/ changing the invaluable
feedback from owner? for owner is
CKNIGHT] optional in the WebDAV working group.
16 INDEX
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 supplied.
17 REFERENCES
[RFC2026] S.Bradner, "The Internet Standards Process", Harvard,
1996, <http://www.ietf.org/rfc/rfc2026.txt>.
[RFC2068] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and
T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, U.C. Irvine, DEC, MIT/LCS, 1997,
<http://www.ietf.org/rfc/rfc2068.txt >.
[RFC2119] S.Bradner, "Key words treated as properties? properties. Closed.
15. Semantic Would it be more appropriate Open
s Model to identify these semantic
names models by their
[ANNEHOP] implementation names, ie,
UNIX, NT Canonical? Could
be easier for use in RFCs developers and
users. Neither of these
models is likely 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 be re-
used by another
implementation.
16. Addition Do we need to include Open
al Semantics additional ACL semantics
models models? What other systems
[ANNEHOP] (.htaccess?) do we need to
support?
17. Detectin How are WebDAV Access Open
g a WebDAV Control compliant servers
Access detected? Define acl
Control extension for Distributed Authoring - WEBDAV", Microsoft,
U.C.Irvine, Netscape, Novell, 1999
<http://www.ietf.org/rfc/rfc2518.txt>.
Sedlar, Clemm the DAV:
server header?
[SEANLYND]
18. DAV:user If we're going to be Open
/group or treating users as resources,
DAV:resource then we should go all the
Clemm,Hopkins,Sedlar [Page 14] 26]
INTERNET-DRAFT WebDAV ACL May 1, July 14, 2000
18 AUTHORS' ADDRESSES
Eric Sedlar
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
Email: esedlar@us.oracle.com
Geoffrey Clemm
Rational Software
20 Maguire Road
Lexington, MA
Email: geoffrey.clemm@rational.com
19 STILL TO DO :
@ Describe
/collection way.
[SEANLYND]
19. Per- ability to specify rights on Open
property a per-property basis could
ACEs be very useful for webdav.
[ANNEHOP] consider adding an optional
propertytype-id to the interactions with resource locking. I'm not
clear what ace?
20. Register Need to describe process for Open
ing registering a new ACL
Semantics semantics model option.
Models
[ANNEHOP]
21. Strip Should the resolution was as far as locking client strip all Agreed to strip
Inherited Inherited (read-only) ACEs inherited ACEs in
ACEs? prior to setting an ACL? Do 6/23 call. Anne
[ANNEHOP] we need a flag that re-opening issue.
indicates whether the ACL
separately from locking server
accepts a client update of
inherited ACEs (to support
client-side propagation of
inheritance)? And/or a flag
to indicate that the resource. client
WANTs to set inherited ACEs?
Clemm,Hopkins,Sedlar [Page 27]
----