Calendar Server Extension C. Daboo
Apple Inc.
November 13, 2012
Calendar User Proxy Functionality in CalDAV
Abstract
This specification defines an extension to CalDAV that makes it easy
for clients to setup and manage calendar user proxies, using the
WebDAV Access Control List extension as a basis.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. New features in CalDAV . . . . . . . . . . . . . . . . . . . . 4
5.1. Feature Discovery . . . . . . . . . . . . . . . . . . . . 4
5.2. Proxy Principal Resource . . . . . . . . . . . . . . . . . 4
5.3. New Principal Properties . . . . . . . . . . . . . . . . . 8
5.3.1. CS:calendar-proxy-read-for Property . . . . . . . . . 8
5.3.2. CS:calendar-proxy-write-for Property . . . . . . . . . 8
5.4. Privilege Provisioning . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Daboo [Page 1]
CalDAV Proxy November 2012
1. Introduction
CalDAV [RFC4791] provides a way for calendar users to store calendar
data and exchange this data via scheduling operations. Based on the
WebDAV protocol [RFC2518], it also includes the ability to manage
access to calendar data via the WebDAV ACL extension [RFC3744].
It is often common for a calendar user to delegate some form of
responsibility for their calendar and schedules to another calendar
user (e.g., a boss allows an assistant to check a calendar or to send
and accept scheduling invites on his behalf). The user handling the
calendar data on behalf of someone else is often referred to as a
"calendar user proxy".
Whilst CalDAV does have fine-grained access control features that can
be used to setup complex sharing and management of calendars, often
the proxy behavior required is an "all-or-nothing" approach - i.e.
the proxy has access to all the calendars or to no calendars (in
which case they are of course not a proxy). So a simple way to
manage access to an entire set of calendars and scheduling ability
would be handy.
In addition, calendar user agents will often want to display to a
user who has proxy access to their calendars, or to whom they are
acting as a proxy. Again, CalDAV's access control discovery and
report features can be used to do that, but with fine-grained control
that exists, it can be hard to tell who is a "real" proxy as opposed
to someone just granted rights to some subset of calendars. Again, a
simple way to discover proxy information would be handy.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
When XML element types in the namespace "DAV:" are referenced in this
document outside of the context of an XML fragment, the string "DAV:"
will be prefixed to the element type names.
When XML element types in the namespaces "DAV:" and
"urn:ietf:params:xml:ns:caldav" are referenced in this document
outside of the context of an XML fragment, the string "DAV:" and
"CALDAV:" will be prefixed to the element type names respectively.
The namespace "http://calendarserver.org/ns/" is used for XML
elements defined in this specification. When XML element types in
Daboo [Page 2]
CalDAV Proxy November 2012
this namespace are referenced in this document outside of the context
of an XML fragment, the string "CS:" will be prefixed to the element
type names respectively.
3. Overview
3.1. Server
For each calendar user principal on the server, the server will
generate two group principals - "proxy groups". One is used to hold
the list of principals who have read-only proxy access to the main
principal's calendars, the other holds the list of principals who
have read-write and scheduling proxy access. NB these new group
principals would have no equivalent in Open Directory.
Privileges on each "proxy group" principal will be set so that the
"owner" has the ability to change property values.
The "proxy group" principals will be child resources of the user
principal resource with specific resource types and thus are easy to
discover. As a result the user principal resources will also be
collection resources.
When provisioning the calendar user home collection, the server will:
a. Add an ACE to the calendar home collection giving the read-only
"proxy group" inheritable read access.
b. Add an ACE to the calendar home collection giving the read-write
"proxy group" inheritable read-write access.
c. Add an ACE to each of the calendar Inbox and Outbox collections
giving the CALDAV:schedule privilege [RFC6638] to the read-write
"proxy group".
On each user principal resource, the server maintains two WebDAV
properties containing lists of other user principals for which the
target principal is a read-only or read-write proxy.
3.2. Client
A client can see who the proxies are for the current principal by
examining the principal resource for the two "proxy group" properties
and then looking at the DAV:group-member-set property of each.
The client can edit the list of proxies for the current principal by
editing the DAV:group-member-set property on the relevant "proxy
Daboo [Page 3]
CalDAV Proxy November 2012
group" principal resource.
The client can find out who the current principal is a proxy for by
examining the CS:calendar-proxy-read-for and CS:calendar-proxy-write-
for properties, possibly using the DAV:expand-property REPORT to get
other useful properties about the principals being proxied for.
4. Open Issues
1. Do we want to separate read-write access to calendars vs the
ability to schedule as a proxy?
2. We may want to restrict changing properties on the proxy group
collections to just the DAV:group-member-set property?
3. There is no way for a proxy to be able to manage the list of
proxies. We could allow the main calendar user DAV:write-acl on
their "proxy group" principals, in which case they could grant
others the right to modify the group membership.
4. Should the "proxy group" principals also be collections given
that the regular principal resources will be?
5. New features in CalDAV
5.1. Feature Discovery
A server that supports the features described in this document MUST
include "calendar-proxy" as a field in the DAV response header from
an OPTIONS request on any resource that supports these features.
5.2. Proxy Principal Resource
Each "regular" principal resource that needs to allow calendar user
proxy support MUST be a collection resource. i.e. in addition to
including the DAV:principal XML element in the DAV:resourcetype
property on the resource, it MUST also include the DAV:collection XML
element.
Each "regular" principal resource MUST contain two child resources
with names "calendar-proxy-read" and "calendar-proxy-write" (note
that these are only suggested names - the server could choose any
unique name for these). These resources are themselves principal
resources that are groups contain the list of principals for calendar
users who can act as a read-only or read-write proxy respectively.
Daboo [Page 4]
CalDAV Proxy November 2012
The server MUST include the CS:calendar-proxy-read or CS:calendar-
proxy-write XML elements in the DAV:resourcetype property of the
child resources, respectively. This allows clients to discover the
"proxy group" principals by using a PROPFIND, Depth:1 request on the
current user's principal resource and requesting the DAV:resourcetype
property be returned. The element type declarations are:
The server MUST allow the "parent" principal to change the DAV:group-
member-set property on each of the "child" "proxy group" principal
resources. When a principal is listed as a member of the "child"
resource, the server MUST include the "child" resource URI in the
DAV:group-membership property on the included principal resource.
Note that this is just "normal" behavior for a group principal.
An example principal resource layout might be:
+ /
+ principals/
+ users/
+ cyrus/
calendar-proxy-read
calendar-proxy-write
+ red/
calendar-proxy-read
calendar-proxy-write
+ wilfredo/
calendar-proxy-read
calendar-proxy-write
If the principal "cyrus" wishes to have the principal "red" act as a
calendar user proxy on his behalf and have the ability to change
items on his calendar or schedule meetings on his behalf, then he
would add the principal resource URI for "red" to the DAV:group-
member-set property of the principal resource /principals/users/
cyrus/calendar-proxy-write, giving:
/principals/users/red/
The DAV:group-membership property on the resource /principals/users/
red/ would be:
Daboo [Page 5]
CalDAV Proxy November 2012
/principals/users/cyrus/calendar-proxy-write
If the principal "red" was also a read-only proxy for the principal
"wilfredo", then the DA:group-membership property on the resource
/principals/users/red/ would be:
/principals/users/cyrus/calendar-proxy-write
/principals/users/wilfredo/calendar-proxy-read
Thus a client can discover to which principals a particular principal
is acting as a calendar user proxy for by examining the DAV:group-
membership property.
An alternative to discovering which principals a user can proxy as is
to use the WebDAV ACL principal-match report, targeted at the
principal collections available on the server.
Example:
>> Request <<
REPORT /principals/ HTTP/1.1
Host: cal.example.com
Depth: 0
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="red",
realm="cal.example.com", nonce="...",
uri="/principals/", response="...", opaque="..."
Daboo [Page 6]
CalDAV Proxy November 2012
>> Response <<
HTTP/1.1 207 Multi-Status
Date: Fri, 10 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
/principals/users/red/
HTTP/1.1 200 OK
/principals/users/cyrus/calendar-proxy-write
HTTP/1.1 200 OK
/principals/users/wilfredo/calendar-proxy-read
HTTP/1.1 200 OK
Daboo [Page 7]
CalDAV Proxy November 2012
5.3. New Principal Properties
Each "regular" principal that is a proxy for other principals MUST
have the CS:calendar-proxy-read-for and CS:calendar-proxy-write-for
WebDAV properties available on its principal resource, to allow
clients to quickly find the "proxy for" information.
5.3.1. CS:calendar-proxy-read-for Property
Name: calendar-proxy-read-for
Namespace: http://calendarserver.org/ns/
Purpose: Lists principals for whom the current principal is a read-
only proxy for.
Protected: This property MUST be protected.
PROPFIND behavior: This property SHOULD NOT be returned by a
PROPFIND allprop request (as defined in Section 14.2 of
[RFC4918]).
Description: This property allows a client to quickly determine the
principal for whom the current principal is a read-only proxy for.
The server MUST account for any group memberships of the current
principal that are either direct or indirect members of a proxy
group. e.g., if principal "A" assigns a group "G" as a read-only
proxy, and principal "B" is a member of group "G", then principal
"B" will see principal "A" listed in the CS:calendar-proxy-read-
for property on their principal resource.
Definition:
5.3.2. CS:calendar-proxy-write-for Property
Name: calendar-proxy-write-for
Namespace: http://calendarserver.org/ns/
Purpose: Lists principals for whom the current principal is a read-
write proxy for.
Protected: This property MUST be protected.
Daboo [Page 8]
CalDAV Proxy November 2012
PROPFIND behavior: This property SHOULD NOT be returned by a
PROPFIND allprop request (as defined in Section 14.2 of
[RFC4918]).
Description: This property allows a client to quickly determine the
principal for whom the current principal is a read-write proxy
for. The server MUST account for any group memberships of the
current principal that are either direct or indirect members of a
proxy group. e.g., if principal "A" assigns a group "G" as a read-
write proxy, and principal "B" is a member of group "G", then
principal "B" will see principal "A" listed in the CS:calendar-
proxy-write-for property on their principal resource.
Definition:
5.4. Privilege Provisioning
In order for a calendar user proxy to be able to access the calendars
of the user they are proxying for the server MUST ensure that the
privileges on the relevant calendars are setup accordingly:
The DAV:read privilege MUST be granted for read-only and read-
write calendar user proxy principals
The DAV:write privilege MUST be granted for read-write calendar
user proxy principals.
Additionally, the CalDAV scheduling Inbox and Outbox calendar
collections for the user allowing proxy access, MUST have the CALDAV:
schedule privilege [RFC6638] granted for read-write calendar user
proxy principals.
Note that with a suitable repository layout, a server may be able to
grant the appropriate privileges on a parent collection and ensure
that all the contained collections and resources inherit that. For
example, given the following repository layout:
Daboo [Page 9]
CalDAV Proxy November 2012
+ /
+ calendars/
+ users/
+ cyrus/
inbox
outbox
home
work
+ red/
inbox
outbox
work
soccer
+ wilfredo/
inbox
outbox
home
work
flying
In order for the principal "red" to act as a read-write proxy for the
principal "cyrus", the following WebDAV ACE will need to be granted
on the resource /calendars/users/cyrus/ and all children of that
resource:
/principals/users/cyrus/calendar-proxy-write
6. Security Considerations
TBD
7. IANA Considerations
This document does not require any actions on the part of IANA.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Daboo [Page 10]
CalDAV Proxy November 2012
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
Jensen, "HTTP Extensions for Distributed Authoring --
WEBDAV", RFC 2518, February 1999.
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV)
Access Control Protocol", RFC 3744, May 2004.
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
March 2007.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
CalDAV", RFC 6638, June 2012.
Appendix A. Acknowledgments
This specification is the result of discussions between the Apple
calendar server and client teams.
Appendix B. Change History
Changes in -03:
1. Added OPTIONS DAV header token.
2. Added CS:calendar-proxy-read-for and CS:calendar-proxy-write-for
properties for faster discovery of proxy relationships.
Changes in -02:
1. Updated to RFC 4791 reference.
Changes in -01:
1. Added more details on actual CalDAV protocol changes.
2. Changed namespace from http://apple.com/ns/calendarserver/ to
http://calendarserver.org/ns/.
Daboo [Page 11]
CalDAV Proxy November 2012
3. Made "proxy group" principals child resources of their "owner"
principals.
4. The "proxy group" principals now have their own resourcetype.
Author's Address
Cyrus Daboo
Apple, Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Email: cyrus@daboo.name
URI: http://www.apple.com/
Daboo [Page 12]