Try out our new RRULE tool for creating RRULE compatible strings.
CalDAV Scheduling (RFC 6638)
Abstract
This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV.
Author
C. Daboo, Apple, Inc.; B. Desruisseaux, Oracle; June 2012
11. Security Considerations
The process of scheduling involves the sending and receiving of scheduling messages. As a result, the security problems related to messaging in general are relevant here. In particular, the authenticity of the scheduling messages needs to be verified. Servers and clients MUST use an HTTP connection protected with Transport Layer Security (TLS) as defined in [RFC2818] for all scheduling operations. Clients MUST use the procedures detailed in Section 6 of [RFC6125] to verify the authenticity of the server. Servers MUST make use of HTTP authentication [RFC2617] to verify the authenticity of the calendar user for whom the client is sending requests.
11.2. Verifying Scheduling Operations
When handling a scheduling operation:
1. Servers MUST verify that the principal associated with the DAV: owner of the calendar collection in which a scheduling object resource is being manipulated contains a CALDAV:schedule-outbox- URL property value.
2. Servers MUST verify that the currently authenticated user has the CALDAV:schedule-send privilege, or a sub-privilege aggregated under this privilege, on the scheduling Outbox collection of the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated.
3. Servers MUST only deliver scheduling messages to recipients when the CALDAV:schedule-deliver privilege, or a sub-privilege aggregated under this privilege, is granted on the recipient's scheduling Inbox collection for the principal associated with the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated.
4. To prevent impersonation of calendar users, the server MUST verify that the "ORGANIZER" property in an organizer scheduling object resource matches one of the calendar user addresses of the DAV:owner of the calendar collection in which the resource is stored.
5. To prevent spoofing of an existing scheduling object resource, servers MUST verify that the "UID" iCalendar property value in a new scheduling object resource does not match that of an existing scheduling object resource with a different "ORGANIZER" property value.
11.3. Verifying Busy Time Information Requests
When handling a POST request on a scheduling Outbox collection:
1. Servers MUST verify that the principal associated with the calendar user address specified in the "ORGANIZER" property of the scheduling message data in the request contains a CALDAV: schedule-outbox-URL property value that matches the scheduling Outbox collection targeted by the request.
2. Servers MUST verify that the currently authenticated user has the CALDAV:schedule-send privilege, or a sub-privilege aggregated under this privilege, on the scheduling Outbox collection targeted by the request. 3. Servers MUST only return valid freebusy information for recipients when the CALDAV:schedule-deliver privilege, or a sub-privilege aggregated under this privilege, is granted on the recipient's scheduling Inbox collection for the principal associated with the DAV:owner of the scheduling Outbox collection targeted by the request.
11.4. Privacy Issues
This specification only defines how calendar users on the same server are able to schedule with each other -- unauthenticated users have no way to carry out scheduling operations. Access control privileges (as per Section 6) can control which of those users can schedule with others. Calendar users not wishing to expose their calendar information to other users can do so by denying privileges to specific users, or all users, for all scheduling operations, or perhaps only freebusy.
"Attendees" can also use the Schedule-Reply request header (Section 8.1) with the value set to "F" to prevent notification to an "Organizer" that a scheduling object resource was deleted. This allows "Attendees" to remove unwanted scheduling messages without any response to the "Organizer".
Servers MUST NOT expose any private iCalendar data, or WebDAV resource state information (URLs, WebDAV properties, etc.) for one calendar user to another via scheduling messages or error responses to scheduling operations. In particular, as per Section 8.1 of [RFC4918], authorization errors MUST take preference over other errors.
This document was automatically converted to XHTML using an RFC to HTML converter with the original text document at the Internet Engineering Task Force web site at ietf.org . The original text document should be referred to if there are any errors or discrepancies found in this document.
Need to test your iCalendar feeds?
The iCalendar Validator provides developers and testers a method to validate their iCalendar feeds, which can take data from either a URL, file or text snippet and compare it against the RFC 5545 specification. We believe we have one of the best iCalendar validation tools available on the internet. More information about the validator can be found here.