view Side-By-Side changes
INTERNET-DRAFT P. J. Leach
Expires: April 1998 Y. Y. Goland
Standards Track Microsoft Eric Sedlar, Oracle Corporation
WebDAV Working Group
draft-ietf-webdav-acl-01.txt Geoffrey Clemm, Rational Software
Expires November 10, 1997 1, 2000 May 1, 2000
Access Control Extensions to WebDAV ACL Protocol
draft-ietf-webdav-acl-00.txt
Status of this Memo
This document is an Internet-Draft. 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 Internet- Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status
The list of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo document specifies the format a set of methods, headers, and manipulation mechanisms for
access control lists (ACLs) for resource-types
that define the WebDAV objects.
Contents
Status Access Control extensions to the HTTP/1.1
protocol.
Sedlar, Clemm [Page 1]
INTERNET-DRAFT WebDAV ACL May 1, 2000
Table of this Memo................................................1
Abstract...........................................................1
Contents...........................................................1
1. Introduction....................................................2
2. Principals Identifiers..........................................2
3. Granting and Denying Rights.....................................3
4. ACL Inheritance.................................................4
5. Properties and ACLs.............................................4
6. Contents
1 INTRODUCTION............................................3
1.1 Notational Conventions................................3
2 PRINCIPALS..............................................3
3 RIGHTS..................................................4
3.1 RIGHTS-DISCOVERY method...............................5
3.2 Rights Definitions..............................................5
7. Default Principal Types.........................................7
8. ACL Method......................................................7
9. Examples.......................................................11
10.Authors' Addresses.............................................13
11.Bibliography...................................................14
Leach and Goland defined by WebDAV..............................6
3.2.1 read Right........................................6
3.2.2 write Right.......................................6
3.2.3 readacl Right.....................................6
3.2.4 writeacl Right....................................6
3.2.5 all Right.........................................6
4 ACCESS CONTROL PROPERTIES...............................7
4.1 Example 1 - Retrieving Access Control information.....8
5 USING ACLS..............................................9
6 ACL METHOD.............................................10
6.1 Example 1 - Setting ACLs.............................10
7 ACL INHERITANCE / DEFAULT ACLS.........................11
8 XML SCHEMA FOR DEFINED ELEMENTS........................12
9 INTERNATIONALIZATION CONSIDERATIONS....................13
10 SECURITY CONSIDERATIONS..............................13
11 SCALABILITY..........................................13
12 AUTHENTICATION.......................................13
13 IANA CONSIDERATIONS..................................13
14 INTELLECTUAL PROPERTY................................13
15 ACKNOWLEDGEMENTS.....................................14
16 INDEX................................................14
17 REFERENCES...........................................14
18 AUTHORS' ADDRESSES...................................15
19 STILL TO DO :........................................15
Sedlar, Clemm [Page 1] 2]
INTERNET-DRAFT WEBDav WebDAV ACL Protocol November 10, 1997
1. Introduction May 1, 2000
1 INTRODUCTION
The basic model for underlying principle of access control, informally expressed, control is that who you are
determines how you can access a resource. The "who you are" is
defined by a principal "principal" identifier; users, client software,
servers
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 Access Control Elements (ACE). An ACE specifies a set of principals, "access
control entries" (ACEs), where each ACE specifies a set of granted rights, principal and
a set of denied
rights.
Rights may be generic, such as "read", "write", or "delete", rights that are either granted or they
might be specific denied to the kind of resource protected by that ACL,
such as (perhaps) "send-to", "unsubscribe", and "administer" for
mailing lists.
When a resource
principal.
1.1 Notational Conventions
The augmented BNF used by this document to describe protocol
elements is created it inherits a set described in Section 2.1 of default ACL
properties from a designated resource, referred [RFC2068]. Because this
augmented BNF uses the basic production rules provided in Section
2.2 of [RFC2068], those rules apply to this document as an ACL source. well.
The inheritance can key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be "static", so interpreted as described in
[RFC2119].
2 PRINCIPALS
A principal identifies an entity that subsequent changes can be given access rights
to the
ACL source do not effect the new resources ACL properties; HTTP resources. On many implementations, a user or it can a group
will be "dynamic", so that subsequent changes examples of principals, but other types of principals are reflected in
possible. For the new
resource's ACL properties.
Properties 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 default, dynamically inherit from the
ACL on the resource. In other words, the a URL. The set of properties exposed by that
resource is the ACL source
for the properties. However individual are implementation dependent, although certain
properties can be given their
own ACL.
2. Principals Identifiers are required by this specification. Those properties
include:
@ <dav:principalname>: A "live" property containing the
name used to authenticate this principal identifier can identify
(typically typed into a single principal or login prompt/dialog).
[OPTIONAL]
@ <dav:displayname>: A property containing a compound human-readable
description of this principal. This property
may be "live" and not settable via PROPPATCH.
[REQUIRED]
@ <dav:principal-type>: A single principal identifier refers to "live" property containing a single
principal, such
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
Sedlar, Clemm [Page 3]
INTERNET-DRAFT WebDAV ACL May 1, 2000
this property can be used to distinguish it
as a person or principal from other resources on a program. A compound
WebDAV server. (Note that <dav:resourcetype>
may not be used, as all collections must use
the value "collection" for <resourcetype>,
which wouldn't distinguish normal collections
from principal
identifier specifies one or more principals. collections.) [REQUIRED]
Server implementations may include any other descriptive
information for a principal via properties.
A compound principal resource may or may not necessarily just be a list 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. It The WebDAV methods for examining
maintaining collections (e.g. BIND, DELETE, PROPFIND) may in
fact be used
to maintain collection principals. Membership in a program that accepts collection
principal is recusive, so a principal identifier as input and
output true or false to indicate membership.
This specification relies upon 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 underlying authentication
mechanism(s)
client attempts to bind collection principals into other
collection principals. Using WebDAV methods to provide alter the syntax content
of a principal identifiers. Thus,
for (e.g. using PROPPATCH or PUT) is outside the purposes scope
of this specification, principal identifiers are
opaque.
Leach and Goland [Page 2]
INTERNET-DRAFT WEBDav ACL Protocol November 10, 1997
3. Granting and Denying Rights
An ACL can both grant and deny rights. The reason both types of
grants are required is because of compound principals.
The consequence of the existence of compound principals is that
there are times when not required, recommended, or
forbidden by this spec.
3 RIGHTS
A right controls access to a compound principal may be granted particular set of HTTP operations on
a right but resource. The set of rights that apply to a particular member
resource may vary with the <dav:resourcetype> of the compound principal may need to resource, as
well as between different server implementations. To promote
interoperability, however, WebDAV defines a set of well-known
rights (e.g. <dav:read> and <dav:write>), which can at least be denied
access. In order
used to make this possible an ACL must be able set some context to list
principals both allowed and denied a right.
By default all the other rights for defined on a principal MUST be denied.
particular resource.
Rights MAY
only may be granted to a principal by an explicit listing of that
principal in a "grant" section aggregates of an ACL.
Additionally it is possible for access rights to collide in scope. other rights. For example, a container one
implementation may have an access split out a right which specifies controlling the ability of principals to delete the
BIND children of that container.
This would affect into a principal's ability to use collection from the DELETE method.
However right allowing a particular internal child may have granted access rights
resource to DELETE. As such, the two rights could collide.
The following rules, processed in order, MUST be used to resolve
scope conflicts between rights.
1) In a conflict between a right granted by a parent and a right
granted by removed from a child, collection. Since these rights
control the right specified ability to write to a collection, these rights would
be aggregated by the child MUST override.
2) In a conflict <dav:write> right. The relationships
between a right granted or denied to a compound
principal atomic rights and aggregate rights can be discovered via
the RIGHTS-DISCOVERY HTTP method on a right granted or denied to a member of particular resource.
Servers may specify some rights as abstract, which means that it
may not appear in an ACL, but is described in the compound
principal, RIGHTS-
DISCOVERY method to aid in setting context. Server
implementations must return the reference same response to the member RIGHTS-
DISCOVERY method on all of the compound principal
MUST override.
Note that rule 2 is conceptually identical to rule 1. The concept
represented by rules 1 and 2, stated generally, resources with the same
<dav:resourcetype> value.
Sedlar, Clemm [Page 4]
INTERNET-DRAFT WebDAV ACL May 1, 2000
3.1 RIGHTS-DISCOVERY method
Rights discovery is that a specific
references always overrides a more general reference.
3.1. Examples
The following examples demonstrate a situation where the specified
conflict resolution rule would be applied.
3.1.1. Rule 1
A resource specifies method with no arguments, that principal A is granted returns the
rights aggregation tree. Each right to delete
the resource. A property on the resource specifies that principal A
is denied 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 cannot be used in
an ACL/ACE. Defaults to delete "false"
@ description (string): a human readable description of what
this right controls access to. Required.
For example, the property. The conflict is resolved following response might be generated to a
RIGHTS-DISCOVERY request on a WebDAV server implemented by rule 1, a
relational database (where the resource is in this case corresponds
to a table):
Request
RIGHTS-DISCOVERY /schemas/scott/emp HTTP/1.1
Host: www.foo.bar
Content-type: text/xml; charset="utf-8"
Content-Length: 0
Response
HTTP/1.1 200 Success
Content-Type: text/xml
Content-Length: xxxxx
<?xml version="1.0" encoding="utf-8" ?>
<?namespace href = "http://www.oracle.com/webdav/ AS = ORA"?>
<D:response>
<D:all abstract=true description="All access">
<D:write abstract=true description="Write any database row">
<ORA:insert abstract=false description="Insert a row"/>
<ORA:update abstract=false description="Update a row"/>
<ORA:delete abstract=false description="Delete a row"/>
</D:write>
<D:read abstract=false description="SELECT data from a row"/>
<D:readacl abstract=false description="Read the parent and ACL"/>
<D:acadmin abstract=false description="Update the property ACL and
owner"/>
</D:all>
</D:response>
It is envisioned that a WebDAV ACL-aware administrative client
would list the child.
As such the child's declaration overrides available in a dialog box, and principal A is denied allow the right user to delete the resource.
Leach and Goland
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 3] 5]
INTERNET-DRAFT WEBDav WebDAV ACL Protocol November 10, 1997
Note, however, that if other properties do not deny principal A the
right to delete them then principal A could delete all properties
but May 1, 2000
3.2 Rights defined by WebDAV
The rights defined by WebDAV access control MUST be present in
the one mentioned above and could PUT an empty body response to the
resource. However it could RIGHTS-DISCOVERY method, although they may be
abstract (and not successfully execute a DELETE usable within an ACE on a particular
implementation).
3.2.1read Right
Name: <dav:read>
Purpose: The read right provides and restricts access to
information regarding the
resource, as this would have the effect state of deleting the property
along with resource, including the resource.
3.1.2. Rule 2
A resource specifies that principal A is denied the read right.
resource's properties. Affected methods include GET and PROPFIND.
The
same resource also specifies that principal B is granted the read
right. Principal A, however, is a compound principal of which
Principal B is a member. Rule 1 right does not apply because affect the rights in
question are defined on OPTIONS method since it
reflects capabilities rather than state.
3.2.2write Right
Name: <dav:write>
Purpose: The <write> right affects the same resource. The conflict is resolved
by rule 2 methods as
the conflict Write Lock. Please refer to [WEBDAV] section 5.3 for the list
of affected methods. Note however, that a write lock is between a compound principal
different mechanism than a write access change, although they
affect the same methods, they have independent methods to set
them and one independent error codes.
3.2.3readacl Right
Name: <dav:readacl>
Purpose: The <readacl> right provides and restricts
access to the <dav:acl> property of
its members. In that case principal B this resource, rather than
the <dav:read> right. If a user has the <readacl> right to read and not
the
resource.
4. ACL Inheritance
When a new resource <read> right, the <dav:acl> property ONLY is created it may inherit its ACL from its
containing resource. If no inheritance accessible via
PROPFIND, and the GET method is specified then the
resource not authorized. If a user has no ACL. Note, however, that
the owner value is
automatically set when a resource is created, so even without
inheritance, there will always be an owner.
An inherited ACL MUST be applied to <read> right and not the resource before it is
available for manipulation. Thus, if inheritance is used, <readacl> right, the
resource <dav:acl>
property will never be in a state where it does not have access
control protection.
Inheritance can either be static or dynamic.
Static inheritance means that the ACL specified by included in any PROPFIND requests on the parent will
be used
associated resource.
3.2.4writeacl Right
Name: <dav:writeacl>
Purpose: The <writeacl> (Access Control ADMINistration)
right provides and restricts access to define the ACL for method, which is the child. Any subsequent changes made
to the parent will not cause the child's ACL to be altered.
Dynamic inheritance means that
only means of altering the <dav:acl> (and indirectly,
<dav:rights>) property of a resource.
3.2.5all Right
Name: <dav:all>
Sedlar, Clemm [Page 6]
INTERNET-DRAFT WebDAV ACL specified by May 1, 2000
Purpose: The <dav:all> right controls all other rights on
this resource. If the parent <dav:all> right appears in an ACE, it is
used
an error to define the ACL have any other right in that ACE. This right is
merely shorthand for all of the child but any changes on rights enumerated in the parent's
ACL MUST automatically be made to any inheriting children. The child
is still allowed RIGHTS-
DISCOVERY method, and should not control access to define its own ACL values rights not
exposed via that MUST override any
conflicting inherited ACL.
5. Properties and ACLs
Properties MAY have their own ACL independent route.
4 ACCESS CONTROL PROPERTIES
This specification defines a number of new properties for WebDAV
resources. Access control properties may be retrieved just like
other WebDAV properties, using the associated
resource. By default PROPFIND method. An HTTP
resource on a property's ACL WebDAV ACL-compliant server MUST be dynamically inherited
from contain the
following properties:
@ <dav:owner>: A property containing the principal
information identifying a particular user as
the owner of the associated resource. Note that properties can only inherit
from their associated This property is
readable by anyone with read access to the
resource.
It There is legal no provision for a client
updating this property to carry a setting for what sort of
inheritance its children will have. Currently in this value has no
Leach and Goland [Page 4]
INTERNET-DRAFT WEBDav ACL Protocol November 10, 1997
meaning as properties can not have children, but spec, however
it is expected in
the future recommended that hierarchical properties will any authenticated user
with appropriate administrative privileges be adopted, so
allowed to issue a PROPPATCH to update its
value. Normally, an attempt to PROPPATCH this
setting
property will then have meaning. For now compliant resources MUST
record this value but do not have to do anything with it.
For purposes result in a 401 (Not
Authorized) error. [REQUIRED]
@ <dav:owner-name>: A "live" property containing a human-
readable description of applying scoping conflict resolution rules the
resource is <dav:owner>
[OPTIONAL]
@ <dav:rights>: A "live" property containing the parent and list of
rights of the currently authenticated HTTP
user. Read access to this property is
controlled by the child.
Compliant resources are not required to support setting ACLs
directly on properties.
6. Rights Definitions
The following define a variety of rights. <read> right. This
property can NEVER be set directly.
[REQUIRED]
@ <dav:acl>: A compliant "live" property containing one or more
<dav:ace> tags, which specify which
principals are to get access to what rights,
for the resource MUST
support all with this ACL property.
[REQUIRED]
The <dav:acl> element (property) contains 0 or more of the
following XML elements:
@ <dav:ace>: An access control entry, which specifies the
set of rights contained herein.
6.1. all Right
Name: all
Namespace: http://www.ietf.org/standards/acl/
Purpose: The all right provides all rights.
Values: None
Description: In to be granted to a conflict between single
principal.
The <dav:ace> element contains the "all" right and other
rights, following XML elements:
Sedlar, Clemm [Page 7]
INTERNET-DRAFT WebDAV ACL May 1, 2000
@ <dav:grant>: Contains the set of XML elements
corresponding to the "all" rights being granted via
this ACE. Must contain at least one right is considered a parent and
@ <dav:deny>: Contains the set of XML elements
corresponding to the other rights
a "child." Thus being denied via
this ACE. Must contain at least one ACE could provide right,
if present.
@ <dav:principal-id>: A URL of the ALL right for a particular principal but another resource this ACE in the same ACL could deny
applies to, or one of the same
principal a particular right. tags <dav:owner> or
<dav:all-principals>. Always present. The conflict would
value of this element must be resolved by
denying unique within
an ACL.
@ <dav:principal>: Contains properties of the specified principal the more specific right.
6.2. read Right
Name: read
Namespace: http://www.ietf.org/standards/acl/
Purpose: The read right provides and restricts access
resource (made available here to
information regarding the state of the resource, including the
resource's properties. Effected methods are GET, INDEX, and
PROPFIND. OPTIONS is not covered by a Read ACL as it reflects
capabilities rather than state.
Values: None
6.3. write Right
Name: write
Namespace: http://www.ietf.org/standards/acl/
Purpose: The Write right affects the same methods as avoid the
Write Lock. Please refer to [WEBDAV] section 5.3
need for the list of
affected methods. Note however, that a write lock is separate PROPFIND request).
Optional.
A PROPFIND on a different
mechanism than resource on a write access change, although they affect WebDAV ACL server might produce the same
methods, they have independent methods to set them and independent
error codes.
Values: None
Leach and Goland
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 5] 8]
INTERNET-DRAFT WEBDav WebDAV ACL Protocol November 10, 1997
6.4. delete Right
Name: delete
Namespace: http://www.ietf.org/standards/acl/
Purpose: The delete right controls 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, a principal has no access rights to the DELETE
method. This method does not affect the ability to remove
properties.
Values: None
6.5. createchild Right
Name: createchild
Namespace: http://www.ietf.org/standards/acl/
Purpose: This right controls the ability to PUT internal
members of an object
protected by an ACL. A particular ACE may either grant or deny a collection and ADDREF external members
set of rights to a collection.
This single principal. It is illegal for an ACL has no affect if set on non-collections.
Values: None
6.6. deletechild Right
Name: deletechild
Namespace: http://www.ietf.org/standards/acl/
Purpose: The deletechild right controls the ability to
have two ACEs applying to the
DELETE internal members of a collection and DELREF external members
of same principal. However, since a collection. This ACL has no affect if set on non-collections.
Values: None
6.7. writeowner Right
Name: writeowner
Namespace: http://www.ietf.org/standards/acl/
Purpose: The writeowner right controls
server may match the ability currently authenticated HTTP user with
multiple principals, it is possible for multiple ACEs to apply to change
the value of current user. In this case, if a particular right is denied
to the owner current user by any ACE, this supercedes any ACE that
might grant that right.
Values: None
6.8. readacl Right
Name: readacl
Namespace: http://www.ietf.org/standards/acl/
Purpose: The readacl right controls This is the ability case regardless if a ("more
specific") ACE granting access applied to read a principal identifying
the
ACL property.
Values: None
6.9. writeacl Right
Name: writeacl
Namespace: http://www.ietf.org/standards/acl/
Purpose: The writeacl right controls user directly, while the ability ACE denying access applied to alter a
collection principal containing that user. The particular order
of the ACEs within an ACL property.
Values: None
Leach and Goland [Page 6]
INTERNET-DRAFT WEBDav ACL Protocol November 10, 1997
7. Default Principal Types is irrelevant. The <principal-id> tag
can also contain the following two XML elements are defined principal types.
7.1. allprincipals XML Element
Name: allprincipals
Namespace: http://www.ietf.org/standards/acl/
Purpose: special tags: <owner>, <all>,
<unauthenticated>. These tags have the following meaning:
Sedlar, Clemm [Page 9]
INTERNET-DRAFT WebDAV ACL May 1, 2000
@ owner: The allprincipals XML element represents all
principals. It principal identified by the owner property on
this resource is used to specify granted or denied the rights belonging to all
principals, regardless of authentication.
Values: None
7.2. allauthprincipals XML Element
Name: allauthprincipals
Namespace: http://www.ietf.org/standards/acl/
Purpose: specified in
this ACE.
@ all: The allauthprincipals XML element represents all
authenticated principals. It current user always matches this ACE, whether or
not s/he is used authenticated.
@ unauthenticated: The current user matches this ACE if not
authenticated
Server implementations may limit the number of ACEs in an ACL.
However, ACL-compliant servers are required to specify support at least
one ACE granting rights belonging to
all authenticated principals.
Values: None
8. 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 METHOD
The ACL Method serves two distinct purposes. provides a mechanism to set ACL information. Its
request body is used to define alterations to the ACL of the
resource and its
properties. The identified by the request-URI. Its response body
contains the current ACL for that resource. The ACL method
replaces the associated
resource <acl> and its properties.
The Request-URI of <owner> properties on the specified
resource with the properties in the request. All readable ACEs
previously stored in the ACL method identifies on the indicated resource whose are
removed, so an ACL
information is method on a resource with an unreadable <acl>
property will be ignored. (If the server implements rights
outside of those defined in this specification, they might allow
only some ACEs to be retrieved and possibly altered. visibleùin this case, only part of the ACL
will be replaced).
Change requests through the ACL method MUST be atomic, additionally
changes are all or nothing. atomic. If any
part of the change request fails then all changes MUST fail.
8.1. Request
The request may contain up to four XML elements, owner,
aclinheritance, and ACL. The presence of an element, except as
otherwise specified, in the request body causes the associated value
to change.
The presence of an empty ACL causes all ACEs in the ACL, including
ACEs for associated properties, to be deleted.
If an ACE is specified in a request it completely replaces the ACE
currently use for the same principal, if it exists. If an ACE is
submitted with empty grant and deny lists then the ACE is deleted.
It is a syntax error for two ACEs to reference the same principal.
Additionally, although an ACE can be submitted which references
multiple principals, this is primarily a convenience feature.
Leach and Goland [Page 7]
INTERNET-DRAFT WEBDav ACL Protocol November 10, 1997
Strictly speaking, what the user has done is specify an ACE for
every principal specified. The same logic applies to results that
aggregate principals into a single ACE.
It is illegal to delete any value, ACE, owner, aclinheritance, etc.
with a redundant value. For example, if one ACE grants all
principals read rights and another ACE grants a single principal
read rights, both ACEs MUST be maintained. The reason being that in
the future all principals may have their read rights removed but the
single principal will retain the read right because the more
specific ACE will override the more general ACE. Additionally if the
currently inherited value of owner is "someuser" and the principal
explicitly requests that the owner by set to "someuser", the
information MUST be recorded on the resource. That way if owner on
the source ACL is changed, the proper value as requested by the
client will remain on the inheriting ACL.
An empty request body will cause no change to the ACL or associated
values.
8.2. Response
If the request body was empty or if the changes were successful a
200 Success response MUST be returned with a response body
containing the owner, aclinheritance, and the acl XML elements with
values for all properties.
[Ed Note - I am not dealing with error conditions yet as the error
reporting format is going to have to be pretty complex and I want to
get buy off on the ACL model and the request format before I write
up a couple of pages on how to do errors for that format.]
8.3. acl XML element
Name: acl
Namespace: http://www.ietf.org/standards/acl/
Purpose: Defines an ACL.
Parent: Any
Values= (inheritance [owner] [aclinheritance] *ACE
*property)
Description: An empty ACL element will delete all ACEs contained
in an ACL, including the ACEs of any properties. Note, however, that
there MUST always be an ACL value defined on a resource, even if it
is empty.
Leach and Goland [Page 8]
INTERNET-DRAFT WEBDav ACL Protocol November 10, 1997
8.4. owner XML Element
Name: owner
Namespace: http://www.ietf.org/standards/acl/
Purpose: Specifies the owner of the resource.
Parent= acl
Values= Principal
Description: The owner XML element specifies the principal who
owns the resource. The default value for owner MUST be the principal
who created the resource. The owner always retains the right to
alter the ACL. So, for example, an owner who was not granted the
right to read the resource could not read the resource. However the
owner could alter the ACL so as to grant the read right to
themselves. A principal MUST have the writeowner right to change the
owner property's value. An empty Owner element submitted in a
request will not cause a change in the Onwer value. Owner MUST
always have a value. All compliant resources MUST support the owner
value.
8.5. aclinheritance XML Element
Name: aclinheritance
Namespace: http://www.ietf.org/standards/acl/
Parent= acl
Purpose: The aclinheritance XML element identifies the type
of inheritance to be used with children of the associated resource.
The AclInheritance value MUST default to Dynamic. An empty
AclInheritance submitted in a request will not cause a change in the
AclInheritance value. This element has no meaning on non-
collections. However, collections MUST provide this property.
Values= ("Dynamic" | "Static" | "None" | Extension)
;Extension is defined, somewhere in DAV. URL is defined, someplace,
somewhere.
Description: Although this element has no meaning when defined
on a property, resources MUST record its value.
8.6. inheritance XML Element
Name: inheritance
Namespace: http://www.ietf.org/standards/acl/
Purpose: Defines the inheritance used for a particular ACL.
Parent: acl
Values= ("Dynamic" | "None" | Extension)
Description: Specifies if the ACL is inheriting its value
dynamically or not at all. Static is not an option since static
inheritance can only occur when the ACL was created and so was
controlled by the ACL source.
Leach and Goland [Page 9]
INTERNET-DRAFT WEBDav ACL Protocol November 10, 1997
8.7. principal XML Element
Name: principal
Namespace: http://www.ietf.org/standards/acl/
Purpose: To identify a principal.
Parent: any
Values= *cdata
8.8. ace XML Element
Name: ace
Namespace: http://www.ietf.org/standards/acl/
Purpose: Contains access right information associated with
one or more principals.
Parent: acl
Values= Principal Allow Deny
Description: A principal MUST NOT be directly referred to in
more than one ACE on a resource. That is, each principal has a
particular ACE which specifies all of its directly granted rights.
Thus specifying two ACEs which directly reference the same principal
in a request is a syntax error.
8.9. grant XML Element
Name: grant
Namespace: http://www.ietf.org/standards/acl/
Purpose: Identifies the rights the associated principals are
granted.
Parent: ACE
Values: Right Identifiers
8.10. deny XML Element
Name: deny
Namespace: http://www.ietf.org/standards/acl/
Purpose: Identifies the rights the associated principals are
denied.
Parent: ACE
Values: Right Identifiers
8.11. property XML Element
Name: property
Namespace: http://www.ietf.org/standards/acl/
Purpose: Provides ACL for properties.
Parent: ACL
Values= Prop ACL
Description: MUST fail. The properties
presence of an empty ACL causes all ACEs in the Prop XML element MUST ACL, including
ACEs for associated properties, to be
empty.
Leach and Goland [Page 10]
INTERNET-DRAFT WEBDav deleted. An empty request
body will cause no change to the ACL Protocol November 10, 1997
9. Examples
9.1. or associated values. If
the <principal> element (specifying properties of the resource
identified by the ACE's <principal-id>) is specified, it (and its
children) is ignored.
6.1 Example 1 - Retrieving Setting ACLs
An ACL information request body is an acl-info XML element. The <dav:acl-
info> element contains properties that can be set by the ACL
method (currently just <acl>).
Request
ACL /top/container/ /top/container HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml
HTTP/1.1 200 Success www.foo.com
Content-Type: text/xml
Content-Length: xxxxx
<?namespace href = "http://www.ietf.org/standards/acl/" AS = "a"?> xxxx
<?namespace href = "http://www.ietf.org/standards/dav/" "http://www.ietf.org/standards/webdav/ AS = "d"?>
<a:acl>
<a:inheritance>dynamic</a:inheritance>
<a:owner>someonesomewhere</a:owner>
<a:ace>
<a:principal>domain/joebob</a:principal>
<a:grant/>
<a:deny><a:all/></a:deny>
</a:ace>
<a:property>
<d:prop><d:creationdate></d:prop>
<a:acl>
<a:inheritance>dynamic</a:inheritance>
<a:owner>blah</a:owner>
<a:ace>
<a:principal>domain/joebob</a:principal>
<a:grant/><a:all/></a:grant>
<a:deny/>
</a:ace>
</a:acl>
</a:property>
<a:property>
<d:prop>
<d:displayname><d:get-content-language><d:get-content-
length><d:get-content-type><d:get-etag><d:get-
lastmodified><d:index-content-language><d:index-content-
length><d:index-etag><d:index-last-modified><d:resourcetype>
</d:prop>
<a:acl>
<a:inheritance>dynamic</a:inheritance>
</a:acl>
</a:property>
</a:acl>
The
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: 0
This request was empty so no changes will be made, rather the
response will just contain all group ACE to disallow read access to the relevant values. The resource
gets its own
ACL dynamically for the marketing group. The other information had to be
recopied from its parent, top. However this
Leach and Goland the ACL retrieved in the previous example.
7 ACL INHERITANCE / DEFAULT ACLS
To be added
Sedlar, Clemm [Page 11]
INTERNET-DRAFT WEBDav WebDAV ACL Protocol November 10, 1997
resource does override May 1, 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 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"/>
Sedlar, Clemm [Page 12]
INTERNET-DRAFT WebDAV ACL May 1, 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>
9 INTERNATIONALIZATION CONSIDERATIONS
To be supplied.
10 SECURITY CONSIDERATIONS
To be supplied.
11 SCALABILITY
To be supplied.
12 AUTHENTICATION
Authentication mechanisms defined in WebDAV will also apply to
WebDAV ACL.
13 IANA CONSIDERATIONS
This document uses the inherited namespace defined by [RFC2518] for XML
elements. All other IANA considerations mentioned in [RFC2518]
also applicable to WebDAV ACL. Specifically, it defines
its owner, someonesomewhere, rather than inheriting it. However,
14 INTELLECTUAL PROPERTY
The following notice is copied from RFC 2026, section 10.4, and
describes the
absence position of an aclinheritance element indicates the IETF concerning intellectual
property claims made against this document.
Sedlar, Clemm [Page 13]
INTERNET-DRAFT WebDAV ACL May 1, 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 resource
inherits 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 value. Additional the principal domain/joebob is
denied all it has made any effort to identify any such rights. So regardless of what
Information on the IETF's procedures with respect to rights domain/joebob may
have been granted in top's ACL, all those rights are denied
standards-track and standards-related documentation can be found
in
relation to top/container. While the ACL BCP-11. Copies of claims of rights made available for creationdate is also
inherited it has its own owner, blah,
publication and has any assurances of licenses to be made available,
or the result of an additional ACE attempt made to obtain a general license or
permission for
joebob. All the rest use of the properties have their ACLs inherited such proprietary rights by implementers
or users of this specification can be obtained from the resource. Therefore the denial of all 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
domain/joebob would also apply practice this standard. Please address the information to the resource's properties but
creationdate..
9.2. Example 2 - Setting ACLs
ACL /top/container.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml
Content-Length: xxxx
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
<?namespace href = "http://www.ietf.org/standards/acl/ AS = "A"?>
<a:acl>
<a:property>
<a:aclinheritance>none</a:aclinheritance>
<d:prop>
<d:creationdate/>
</d:prop>
<a:acl>
<a:ace>
<a:principal>domain/joebob</a:principal>
<a:grant/><a:deny/>
</a:ace>
</a:acl>
</a:property>
</a:acl>
Leach and Goland [Page 12]
INTERNET-DRAFT WEBDav ACL Protocol November 10, 1997
HTTP/1.1 200 Success
Content-Type: text/xml
Content-Length: xxxxx
<?namespace href = "http://www.ietf.org/standards/acl/" AS = "a"?>
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "d"?>
<a:acl>
<a:inheritance>dynamic</a:inheritance>
<a:owner>someonesomewhere</a:owner>
<a:aclinheritance>none</a:aclinheritance>
<a:ace>
<a:principal>domain/joebob</a:principal>
<a:grant/>
<a:deny><a:all/></a:deny>
</a:ace>
<a:property>
<d:prop><d:creationdate></d:prop>
<a:acl>
<a:inheritance>dynamic</a:inheritance>
<a:owner>blah</a:owner>
</a:acl>
</a:property>
<a:property>
<d:prop>
<d:displayname><d:get-content-language><d:get-content-
length><d:get-content-type><d:get-etag><d:get-
lastmodified><d:index-content-language><d:index-content-
length><d:index-etag><d:index-last-modified><d:resourcetype>
</d:prop>
<a:acl>
<a:inheritance>dynamic</a:inheritance>
</a:acl>
</a:property>
</a:acl>
IETF Executive Director.
15 ACKNOWLEDGEMENTS
This example assumes the state left from example 1. In the request protocol is the user asks that collaborative product of the aclinheritance value be set WebDAV ACL
design team: xxx, yyy, zzz. We would like to none and that
the ACE on acknowledge the property creationdate
foundation laid for us by the principal domain/joebob
be removed. Even if authors of the inherited aclinheritance value WebDAV and HTTP
protocols upon which this protocol is none, the
resource MUST still record the redundant value as layered, and the value on invaluable
feedback from the
source ACL may change.
10. Authors' Addresses
Paul J. Leach
Yaron Y. Goland
Microsoft
1 Microsoft Way
Redmond, WA 98052
Phone: (425)936-4765
Email: {paulle, yarong}@microsoft.com
Leach and Goland [Page 13]
INTERNET-DRAFT WEBDav ACL Protocol November 10, 1997
11. Bibliography WebDAV working group.
16 INDEX
To 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. Mogul, H. Frystyk, T. Berners-
Lee, 'Hypertext R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and
T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1', HTTP/1.1", RFC
2068, January 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, <URL:ftp://ds.internic.net/rfc/rfc2068.txt>
[WebDAV]
<http://www.ietf.org/rfc/rfc2119.txt >.
[RFC2518] Y. Goland, E. J. Whitehead, Jr., Asad Faizi, Stephen R.
Carter, Del Jensen 'Extensions E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
"HTTP Extensions for Distributed Authoring and
Versioning on the World Wide Web -- WEBDAV', October 1997, WORK
IN PROGRESS, <URL:ftp://ftp.ietf.org/internet-drafts/draft-ietf-
webdav-protocol-04.txt>
[XML] W3C, 'Extensible Markup Language - Part1. Syntax', March 1997
<URL:http://www.w3.org/pub/WWW/TR/WD-xml-lang.html>
Leach and Goland WEBDAV", Microsoft,
U.C.Irvine, Netscape, Novell, 1999
<http://www.ietf.org/rfc/rfc2518.txt>.
Sedlar, Clemm [Page 14]
INTERNET-DRAFT WebDAV ACL May 1, 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 the interactions with resource locking. I'm not
clear what the resolution was as far as locking the ACL
separately from locking the resource.
----