OwlCyberSecurity - MANAGER

Edit File: caldav-proxy.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="../rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2119 PUBLIC '' 'bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2518 PUBLIC '' 'bibxml/reference.RFC.2518.xml'>
<!ENTITY rfc3744 PUBLIC '' 'bibxml/reference.RFC.3744.xml'>
<!ENTITY rfc4791 PUBLIC '' 'bibxml/reference.RFC.4791.xml'>
<!ENTITY rfc4918 PUBLIC '' 'bibxml/reference.RFC.4918.xml'>
<!ENTITY rfc6638 PUBLIC '' 'bibxml/reference.RFC.6638.xml'>
]> 
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private="Calendar Server Extension"?>
<rfc ipr="none" docName='caldav-cu-proxy-03'>
    <front>
        <title abbrev="CalDAV Proxy">Calendar User Proxy Functionality in CalDAV</title> 
        <author initials="C." surname="Daboo" fullname="Cyrus Daboo">
            <organization abbrev="Apple Inc.">
                Apple, Inc.
            </organization>
            <address>
                <postal>
                    <street>1 Infinite Loop</street>
                    <city>Cupertino</city>
                    <region>CA</region>
                    <code>95014</code> 
                    <country>USA</country>
                </postal>
                <email>cyrus@daboo.name</email>
                <uri>http://www.apple.com/</uri>
            </address>
        </author>
        <date/>
        <abstract>
            <t>
                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.
            </t>
        </abstract>
    </front>
    <middle>
        <section title='Introduction'>
            <t>
                <xref target="RFC4791">CalDAV</xref> provides a way for calendar users to store calendar data and exchange this data via scheduling operations. Based on the WebDAV protocol <xref target='RFC2518' />, it also includes the ability to manage access to calendar data via the WebDAV ACL extension <xref target='RFC3744' />.
            </t>
            <t>
                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".
            </t>
            <t>
                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.
            </t>
            <t>
                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.
            </t>
        </section>
        <section title='Conventions Used in This Document'>
            <t>
                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 <xref target='RFC2119' />. 
            </t>
            <t>
                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. 
            </t>
            <t>
                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. 
            </t>
            <t>
                The namespace "http://calendarserver.org/ns/" is used for XML elements defined in this specification.  When XML element types in 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. 
            </t>
        </section>
         
        <section title='Overview' anchor='overview'>
            <section title='Server'>
                <t>
                    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.
                </t>
                <t>
                    Privileges on each "proxy group" principal will be set so that the "owner" has the ability to change property values.
                </t>
                <t>
                    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.
                </t>
                <t>
                    When provisioning the calendar user home collection, the server will:
                    <list style='letters'>
                        <t>
                            Add an ACE to the calendar home collection giving the read-only "proxy group" inheritable read access.
                        </t>
                        <t>
                            Add an ACE to the calendar home collection giving the read-write "proxy group" inheritable read-write access.
                        </t>
                        <t>
                            Add an ACE to each of the calendar Inbox and Outbox collections giving the <xref target='RFC6638'>CALDAV:schedule privilege</xref> to the read-write "proxy group".
                        </t>
                    </list>
                </t>
                <t>
                	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.
                </t>
            </section>
            <section title='Client'>
                <t>
                    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.
                </t>
                <t>
                    The client can edit the list of proxies for the current principal by editing the DAV:group-member-set property on the relevant "proxy group" principal resource.
                </t>
                <t>
                    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.
                </t>
            </section>
        </section>

<section title="Open Issues">
            <t>
                <list style="numbers">
                    <t>
                        Do we want to separate read-write access to calendars vs the ability to schedule as a proxy?
                    </t>
                    <t>
                        We may want to restrict changing properties on the proxy group collections to just the DAV:group-member-set property?
                    </t>
                    <t>
                        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.
                    </t>
                    <t>
                        Should the "proxy group" principals also be collections given that the regular principal resources will be?
                    </t>
                </list>
            </t>
        </section>
            
        <section title='New features in CalDAV' anchor='changes'>
            <section title="Feature Discovery">
                <t>
                    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.
                </t>
            </section>
            <section title='Proxy Principal Resource'>
                <t>
                    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.
                </t>
                <t>
                    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.
                </t>
                <t>
                    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:
                        <figure>
                            <artwork><![CDATA[
<!ELEMENT calendar-proxy-read EMPTY>

<!ELEMENT calendar-proxy-write EMPTY>
                            ]]></artwork>
                        </figure>
                </t>
                <t>
                    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.
                </t>
                <t>
                    An example principal resource layout might be:
                    <figure>
                        <artwork><![CDATA[
        + /
          + principals/
            + users/
              + cyrus/
                  calendar-proxy-read
                  calendar-proxy-write
              + red/
                  calendar-proxy-read
                  calendar-proxy-write
              + wilfredo/
                  calendar-proxy-read
                  calendar-proxy-write
                        ]]></artwork>
                    </figure>
                    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:
                    <figure>
                        <artwork><![CDATA[
<DAV:group-member-set>
  <DAV:href>/principals/users/red/</DAV:href>
</DAV:group-member-set>
                        ]]></artwork>
                    </figure>
                    The DAV:group-membership property on the resource /principals/users/red/ would be:
                    <figure>
                        <artwork><![CDATA[
<DAV:group-membership>
  <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
</DAV:group-membership>
                        ]]></artwork>
                    </figure>
                </t>
                <t>
                    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:
                    <figure>
                        <artwork><![CDATA[
<DAV:group-membership>
  <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
  <DAV:href>/principals/users/wilfredo/calendar-proxy-read</DAV:href>
</DAV:group-membership>
                        ]]></artwork>
                    </figure>
                    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.
                </t>
                <t>
                    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.
                </t>
                <t>Example:
                  <figure>
                    <preamble>&gt;&gt; Request &lt;&lt;</preamble>
                    <artwork><![CDATA[
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="..."

<?xml version="1.0" encoding="utf-8" ?>
<D:principal-match xmlns:D="DAV:">
  <D:self/>
  <D:prop>
    <D:resourcetype/>
  </D:prop>
</D:principal-match>
                    ]]></artwork>
                  </figure>
                  <figure>
                    <preamble>&gt;&gt; Response &lt;&lt;</preamble>
                    <artwork><![CDATA[
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

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
               xmlns:A="http://calendarserver.org/ns/">
  <D:response>
    <D:href>/principals/users/red/</D:href>
    <D:propstat>
      <D:prop>
        <D:resourcetype>
          <D:principal/>
          <D:collection/>
        </D:resourcetype>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>/principals/users/cyrus/calendar-proxy-write</D:href>
    <D:propstat>
      <D:prop>
        <D:resourcetype>
          <D:principal/>
          <A:calendar-proxy-write/>
        </D:resourcetype>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>/principals/users/wilfredo/calendar-proxy-read</D:href>
    <D:propstat>
      <D:prop>
        <D:resourcetype>
          <D:principal/>
          <A:calendar-proxy-read/>
        </D:resourcetype>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>
                    ]]></artwork>
                  </figure>
                </t>
            </section>
            <section title="New Principal Properties">
            	<t>
            		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.
            	</t>
        <section title="CS:calendar-proxy-read-for Property">
          <t>
            <list style="hanging">
              <t hangText="Name:">calendar-proxy-read-for</t>
              <t hangText="Namespace:">http://calendarserver.org/ns/</t>
              <t hangText="Purpose:">Lists principals for whom the current principal is a read-only proxy for.</t>
              <t hangText="Protected:">This property MUST be protected.</t>
              <t hangText="PROPFIND behavior:">This property SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of <xref target="RFC4918"/>).</t>

<t hangText="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.</t>
              <t hangText="Definition:">
                <figure><artwork><![CDATA[
  <!ELEMENT calendar-proxy-read-for (DAV:href*)>
]]></artwork></figure>
              </t>
            </list>
          </t>
        </section>
        <section title="CS:calendar-proxy-write-for Property">
          <t>
            <list style="hanging">
              <t hangText="Name:">calendar-proxy-write-for</t>
              <t hangText="Namespace:">http://calendarserver.org/ns/</t>
              <t hangText="Purpose:">Lists principals for whom the current principal is a read-write proxy for.</t>
              <t hangText="Protected:">This property MUST be protected.</t>
              <t hangText="PROPFIND behavior:">This property SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of <xref target="RFC4918"/>).</t>

<t hangText="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.</t>
              <t hangText="Definition:">
                <figure><artwork><![CDATA[
  <!ELEMENT calendar-proxy-write-for (DAV:href*)>
]]></artwork></figure>
              </t>
            </list>
          </t>
        </section>
            </section>
            <section title='Privilege Provisioning'>
                <t>
                    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:
                    <list>
                        <t>The DAV:read privilege MUST be granted for read-only and read-write calendar user proxy principals</t>
                        <t>The DAV:write privilege MUST be granted for read-write calendar user proxy principals.</t>
                    </list>
                    Additionally, the  CalDAV scheduling Inbox and Outbox calendar collections for the user allowing proxy access, MUST have the <xref target='RFC6638'>CALDAV:schedule privilege</xref> granted for read-write calendar user proxy principals.
                </t>
                <t>
                    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:
                    <figure>
                        <artwork><![CDATA[
        + /
          + calendars/
            + users/
              + cyrus/
                  inbox
                  outbox
                  home
                  work
              + red/
                  inbox
                  outbox
                  work
                  soccer
              + wilfredo/
                  inbox
                  outbox
                  home
                  work
                  flying
                        ]]></artwork>
                    </figure>
                    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:
                    <figure>
                        <artwork><![CDATA[
<DAV:ace>
  <DAV:principal>
    <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
  </DAV:principal>
  <DAV:privileges>
    <DAV:grant><DAV:read/><DAV:write/></DAV:grant>
  </DAV:privileges>
</DAV:ace>
                        ]]></artwork>
                    </figure>
                </t>

</section>
        </section>

<section title='Security Considerations'>
            <t>
                TBD
            </t>
        </section>
        <section title='IANA Considerations'>
            <t>
                This document does not require any actions on the part of IANA.
            </t>
        </section>
    </middle>
    <back>
        <references title='Normative References'>
            &rfc2119;
            &rfc2518;
            &rfc3744;
            &rfc4791;
            &rfc4918;
            &rfc6638; 
        </references>

        <section title='Acknowledgments'>
            <t>
                This specification is the result of discussions between the Apple calendar server and client teams.
            </t>
        </section>
        <section title='Change History'>
            <t>Changes in -03:
                <list style='numbers'>
                    <t>
                        Added OPTIONS DAV header token.
                    </t>
                    <t>
                    	Added CS:calendar-proxy-read-for and CS:calendar-proxy-write-for properties for faster discovery of proxy relationships.
                    </t>
                </list>
            </t>
            <t>Changes in -02:
                <list style='numbers'>
                    <t>
                        Updated to RFC 4791 reference.
                    </t>
                </list>
            </t>
            <t>Changes in -01:
                <list style='numbers'>
                    <t>
                        Added more details on actual CalDAV protocol changes.
                    </t>
                    <t>
                        Changed namespace from http://apple.com/ns/calendarserver/ to http://calendarserver.org/ns/.
                    </t>
                    <t>
                        Made "proxy group" principals child resources of their "owner" principals.
                    </t>
                    <t>
                        The "proxy group" principals now have their own resourcetype.
                    </t>
                </list>
            </t>
        </section>
    </back>
</rfc>