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