4 Calendar Server Extension C. Daboo
9 Calendar User Proxy Functionality in CalDAV
14 This specification defines an extension to CalDAV that makes it easy
15 for clients to setup and manage calendar user proxies, using the
16 WebDAV Access Control List extension as a basis.
21 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
22 2. Conventions Used in This Document . . . . . . . . . . . . . . 2
23 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
24 3.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 3
25 3.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 3
26 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
27 5. New features in CalDAV . . . . . . . . . . . . . . . . . . . . 4
28 5.1. Proxy Principal Resource . . . . . . . . . . . . . . . . . 4
29 5.2. Privilege Provisioning . . . . . . . . . . . . . . . . . . 8
30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
32 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
33 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9
34 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 10
35 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
62 CalDAV [RFC4791] provides a way for calendar users to store calendar
63 data and exchange this data via scheduling operations. Based on the
64 WebDAV protocol [RFC2518], it also includes the ability to manage
65 access to calendar data via the WebDAV ACL extension [RFC3744].
67 It is often common for a calendar user to delegate some form of
68 responsibility for their calendar and schedules to another calendar
69 user (e.g., a boss allows an assistant to check a calendar or to send
70 and accept scheduling invites on his behalf). The user handling the
71 calendar data on behalf of someone else is often referred to as a
72 "calendar user proxy".
74 Whilst CalDAV does have fine-grained access control features that can
75 be used to setup complex sharing and management of calendars, often
76 the proxy behavior required is an "all-or-nothing" approach - i.e.
77 the proxy has access to all the calendars or to no calendars (in
78 which case they are of course not a proxy). So a simple way to
79 manage access to an entire set of calendars and scheduling ability
82 In addition, calendar user agents will often want to display to a
83 user who has proxy access to their calendars, or to whom they are
84 acting as a proxy. Again, CalDAV's access control discovery and
85 report features can be used to do that, but with fine-grained control
86 that exists, it can be hard to tell who is a "real" proxy as opposed
87 to someone just granted rights to some subset of calendars. Again, a
88 simple way to discover proxy information would be handy.
91 2. Conventions Used in This Document
93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
95 document are to be interpreted as described in [RFC2119].
97 When XML element types in the namespace "DAV:" are referenced in this
98 document outside of the context of an XML fragment, the string "DAV:"
99 will be prefixed to the element type names.
101 When XML element types in the namespaces "DAV:" and
102 "urn:ietf:params:xml:ns:caldav" are referenced in this document
103 outside of the context of an XML fragment, the string "DAV:" and
104 "CALDAV:" will be prefixed to the element type names respectively.
106 The namespace "http://calendarserver.org/ns/" is used for XML
107 elements defined in this specification. When XML element types in
113 CalDAV Proxy May 2007
116 this namespace are referenced in this document outside of the context
117 of an XML fragment, the string "CS:" will be prefixed to the element
118 type names respectively.
125 For each calendar user principal on the server, the server will
126 generate two group principals - "proxy groups". One is used to hold
127 the list of principals who have read-only proxy access to the main
128 principal's calendars, the other holds the list of principals who
129 have read-write and scheduling proxy access. NB these new group
130 principals would have no equivalent in Open Directory.
132 Privileges on each "proxy group" principal will be set so that the
133 "owner" has the ability to change property values.
135 The "proxy group" principals will be child resources of the user
136 principal resource with specific resource types and thus are easy to
137 discover. As a result the user principal resources will also be
138 collection resources.
140 When provisioning the calendar user home collection, the server will:
142 a. Add an ACE to the calendar home collection giving the read-only
143 "proxy group" inheritable read access.
145 b. Add an ACE to the calendar home collection giving the read-write
146 "proxy group" inheritable read-write access.
148 c. Add an ACE to each of the calendar Inbox and Outbox collections
149 giving the CALDAV:schedule privilege
150 [I-D.desruisseaux-caldav-sched] to the read-write "proxy group".
154 A client can see who the proxies are for the current principal by
155 examining the principal resource for the two "proxy group" properties
156 and then looking at the DAV:group-member-set property of each.
158 The client can edit the list of proxies for the current principal by
159 editing the DAV:group-member-set property on the relevant "proxy
160 group" principal resource.
162 The client can find out who the current principal is a proxy for by
163 running a DAV:principal-match REPORT on the principal collection.
169 CalDAV Proxy May 2007
172 Alternatively, the client can find out who the current principal is a
173 proxy for by examining the DAV:group-membership property on the
174 current principal resource looking for membership in other users'
180 1. Do we want to separate read-write access to calendars vs the
181 ability to schedule as a proxy?
183 2. We may want to restrict changing properties on the proxy group
184 collections to just the DAV:group-member-set property?
186 3. There is no way for a proxy to be able to manage the list of
187 proxies. We could allow the main calendar user DAV:write-acl on
188 their "proxy group" principals, in which case they could grant
189 others the right to modify the group membership.
191 4. Should the "proxy group" principals also be collections given
192 that the regular principal resources will be?
195 5. New features in CalDAV
197 5.1. Proxy Principal Resource
199 Each "regular" principal resource that needs to allow calendar user
200 proxy support MUST be a collection resource. i.e. in addition to
201 including the DAV:principal XML element in the DAV:resourcetype
202 property on the resource, it MUST also include the DAV:collection XML
205 Each "regular" principal resource MUST contain two child resources
206 with names "calendar-proxy-read" and "calendar-proxy-write" (note
207 that these are only suggested names - the server could choose any
208 unique name for these). These resources are themselves principal
209 resources that are groups contain the list of principals for calendar
210 users who can act as a read-only or read-write proxy respectively.
212 The server MUST include the CS:calendar-proxy-read or CS:calendar-
213 proxy-write XML elements in the DAV:resourcetype property of the
214 child resources, respectively. This allows clients to discover the
215 "proxy group" principals by using a PROPFIND, Depth:1 request on the
216 current user's principal resource and requesting the DAV:resourcetype
217 property be returned. The element type declarations are:
225 CalDAV Proxy May 2007
228 <!ELEMENT calendar-proxy-read EMPTY>
230 <!ELEMENT calendar-proxy-write EMPTY>
232 The server MUST allow the "parent" principal to change the DAV:group-
233 member-set property on each of the "child" "proxy group" principal
234 resources. When a principal is listed as a member of the "child"
235 resource, the server MUST include the "child" resource URI in the
236 DAV:group-membership property on the included principal resource.
237 Note that this is just "normal" behavior for a group principal.
239 An example principal resource layout might be:
254 If the principal "cyrus" wishes to have the principal "red" act as a
255 calendar user proxy on his behalf and have the ability to change
256 items on his calendar or schedule meetings on his behalf, then he
257 would add the principal resource URI for "red" to the DAV:group-
258 member-set property of the principal resource /principals/users/
259 cyrus/calendar-proxy-write, giving:
261 <DAV:group-member-set>
262 <DAV:href>/principals/users/red/</DAV:href>
263 </DAV:group-member-set>
265 The DAV:group-membership property on the resource /principals/users/
268 <DAV:group-membership>
269 <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
270 </DAV:group-membership>
272 If the principal "red" was also a read-only proxy for the principal
273 "wilfredo", then the DA:group-membership property on the resource
274 /principals/users/red/ would be:
281 CalDAV Proxy May 2007
284 <DAV:group-membership>
285 <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
286 <DAV:href>/principals/users/wilfredo/calendar-proxy-read</DAV:href>
287 </DAV:group-membership>
289 Thus a client can discover to which principals a particular principal
290 is acting as a calendar user proxy for by examining the DAV:group-
293 An alternative to discovering which principals a user can proxy as is
294 to use the WebDAV ACL principal-match report, targeted at the
295 principal collections available on the server.
301 REPORT /principals/ HTTP/1.1
302 Host: cal.example.com
304 Content-Type: application/xml; charset="utf-8"
306 Authorization: Digest username="red",
307 realm="cal.example.com", nonce="...",
308 uri="/principals/", response="...", opaque="..."
310 <?xml version="1.0" encoding="utf-8" ?>
311 <D:principal-match xmlns:D="DAV:">
337 CalDAV Proxy May 2007
342 HTTP/1.1 207 Multi-Status
343 Date: Fri, 10 Nov 2006 09:32:12 GMT
344 Content-Type: application/xml; charset="utf-8"
347 <?xml version="1.0" encoding="utf-8" ?>
348 <D:multistatus xmlns:D="DAV:"
349 xmlns:A="http://calendarserver.org/ns/">
351 <D:href>/principals/users/red/</D:href>
359 <D:status>HTTP/1.1 200 OK</D:status>
363 <D:href>/principals/users/cyrus/calendar-proxy-write</D:href>
368 <A:calendar-proxy-write/>
371 <D:status>HTTP/1.1 200 OK</D:status>
375 <D:href>/principals/users/wilfredo/calendar-proxy-read</D:href>
380 <A:calendar-proxy-read/>
383 <D:status>HTTP/1.1 200 OK</D:status>
393 CalDAV Proxy May 2007
396 5.2. Privilege Provisioning
398 In order for a calendar user proxy to be able to access the calendars
399 of the user they are proxying for the server MUST ensure that the
400 privileges on the relevant calendars are setup accordingly:
402 The DAV:read privilege MUST be granted for read-only and read-
403 write calendar user proxy principals
405 The DAV:write privilege MUST be granted for read-write calendar
406 user proxy principals.
408 Additionally, the CalDAV scheduling Inbox and Outbox calendar
409 collections for the user allowing proxy access, MUST have the CALDAV:
410 schedule privilege [I-D.desruisseaux-caldav-sched] granted for read-
411 write calendar user proxy principals.
413 Note that with a suitable repository layout, a server may be able to
414 grant the appropriate privileges on a parent collection and ensure
415 that all the contained collections and resources inherit that. For
416 example, given the following repository layout:
438 In order for the principal "red" to act as a read-write proxy for the
439 principal "cyrus", the following WebDAV ACE will need to be granted
440 on the resource /calendars/users/cyrus/ and all children of that
449 CalDAV Proxy May 2007
454 <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
457 <DAV:grant><DAV:read/><DAV:write/></DAV:grant>
462 6. Security Considerations
467 7. IANA Considerations
469 This document does not require any actions on the part of IANA.
472 8. Normative References
474 [I-D.desruisseaux-caldav-sched]
475 Desruisseaux, B., "Scheduling Extensions to CalDAV",
476 draft-desruisseaux-caldav-sched-03 (work in progress),
479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
480 Requirement Levels", BCP 14, RFC 2119, March 1997.
482 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
483 Jensen, "HTTP Extensions for Distributed Authoring --
484 WEBDAV", RFC 2518, February 1999.
486 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
487 Distributed Authoring and Versioning (WebDAV) Access
488 Control Protocol", RFC 3744, May 2004.
490 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
491 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
495 Appendix A. Acknowledgments
497 This specification is the result of discussions between the Apple
498 calendar server and client teams.
505 CalDAV Proxy May 2007
508 Appendix B. Change History
512 1. Updated to RFC 4791 reference.
516 1. Added more details on actual CalDAV protocol changes.
518 2. Changed namespace from http://apple.com/ns/calendarserver/ to
519 http://calendarserver.org/ns/.
521 3. Made "proxy group" principals child resources of their "owner"
524 4. The "proxy group" principals now have their own resourcetype.
535 Email: cyrus@daboo.name
536 URI: http://www.apple.com/