SIMPLE WG J. Urpalainen Internet-Draft Nokia Research Center Expires: May 18, 2007 November 14, 2006 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) co-operation with HTTP Extensions for Distributed Authoring (WEBDAV) draft-urpalainen-simple-xcap-webdav-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, 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 months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." 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. This Internet-Draft will expire on May 18, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) allows a client to read, write and modify application configuration data, stored in XML format on an HTTP server. HTTP Extensions for Distributed Authoring (WebDAV) provides many useful HTTP extensions for web content authoring. This document describes conventions for the co-operation of XCAP resources with WebDAV. Urpalainen Expires May 18, 2007 [Page 1]
Internet-Draft XCAP with WebDAV November 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. WebDAV Extensions to XCAP . . . . . . . . . . . . . . . . . . 3 4.1. Collections . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Properties . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Locking . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Conditional requests with the If-header . . . . . . . . . 5 4.5. Other WebDAV methods . . . . . . . . . . . . . . . . . . . 5 4.6. Access Control Lists . . . . . . . . . . . . . . . . . . . 5 4.6.1. Server provisioned ACL after a successful PUT . . . . 6 4.6.2. Server provisioned ACL after a successful MKCOL . . . 11 4.6.3. Privileges . . . . . . . . . . . . . . . . . . . . . . 11 4.6.4. Aggregation of privileges . . . . . . . . . . . . . . 11 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 11 6. XCAP Server Capabilities extension . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Urpalainen Expires May 18, 2007 [Page 2]
Internet-Draft XCAP with WebDAV November 2006 1. Introduction The Extensible Markup Language (XML) [2] Configuration Access Protocol (XCAP) [3] was designed to store XML documents on an HTTP server. Also patching of XML document components, i.e. XML elements and attributes can be achieved with basic HTTP PUT and DELETE methods. Thus XML documents contain usually many XCAP resources and access to them is achieved by using a node selector in the path segment of the request URI. The document tree structure is also described by the core XCAP protocol. HTTP Extensions for Distributed Authoring (WebDAV) [4] provides many useful HTTP [5] extensions for web content authoring including many other MIME types than just XML documents. The extension set includes properties, collections, locks and namespace operations of WebDAV resources. With WebDAV access control protocol [6] access to shared resources can easily be allowed or denied. This document describes conventions for XCAP servers utilizing these WebDAV authoring extensions. The aim is to use existing specifications with compatibility in mind, an existing XCAP client can still use resources of the server which complies with the rules described in this document. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119, BCP 14 [1] and indicate requirement levels for compliant implementations. 3. Definitions This document uses terms defined in WebDAV [4], XCAP [3] and WebDAV access control protocol (ACL) [6]. 4. WebDAV Extensions to XCAP In XCAP, the request URI contains a node selector when an XML document component is being updated. This selector value can be used to locate for example, an XML element to be removed from the XML document. WebDAV in general does not utilize this sort of granularity of an XML document. This document does not thus propose such a model mostly because of simplicity and compatibility reasons and instead, all WebDAV features, for example properties and locks Urpalainen Expires May 18, 2007 [Page 3]
Internet-Draft XCAP with WebDAV November 2006 operate only on an XML document level, that is, it is not allowed to set some property of an XML element or lock an XML element along with its descendants. In other words, if the request URI contains an XCAP node selector with e.g. a PROPPATCH or any other WebDAV method, an error is produced. Especially "locked empty resources" with LOCK method might otherwise be created unless this rule is obeyed. Note: Actual implementations can then easily utilize existing libraries as they can dispatch request handlers to appropriate ones: WebDAV or XCAP according to request URIs and HTTP methods: typically, if the request URI contains a node selector and a node selector separator with GET, PUT or DELETE method, XCAP handlers are used and otherwise requests are passed to WebDAV handlers. These handlers are then free to respond with appropriate formats as there are minimal inter-dependencies. In other words, XCAP features do not overlap with WebDAV ones. 4.1. Collections The core XCAP protocol does not support the creation of collections. WebDAV [4] MKCOL method can then be used to create a collection. A collection can be removed with the DELETE method. This WebDAV property is advertised with the OPTIONS query response by "Class 1" compliance. Note: The current XCAP application usages do not specify collection usages in their user "home directories" and some of them only support only single entities (files). In application usages where it makes sense to support collections it is up to the server to decide whether it is allowed or not. 4.2. Properties This document does not introduce any constraints to WebDAV [4] properties except that it is only allowed to set/get properties on the document level. XCAP doesn't describe any way to request or set a property of a resource although it uses ETags for conditional updates. For instance these ETag values can easily be queried with PROPFIND method and the result may contain all resources from a collection. This can for example, be used to maintain a simple sync of remote XCAP resources. The PROPPATCH method sets properties of resources based on QNames [7] and "values" of them. The value of a property is usually a text node content but it may also be of mixed type [8]. Urpalainen Expires May 18, 2007 [Page 4]
Internet-Draft XCAP with WebDAV November 2006 Note: For example, after a successful PUT of an XML element, an XCAP server has to create a new ETag for the document. This ETag is a WebDAV "live" property which MUST be accessible to a WebDAV handler when the ETag value of a resource is being requested. There is thus an inter-dependency between XCAP and WebDAV handling. 4.3. Locking Write locking is an optional feature of a WebDAV server. It is advertised with the OPTIONS query response by "Class 2" compliance. Like properties these are supported only at the XML document level. If locks are supported on the server, before the server applies an XCAP component update, addition or removal, the server has to look for possible locks on the corresponding XML document or ancestor collections. Note that "lost updates" described in chapter 7.2 [4] are less likely as clients may be updating different parts of XML documents although doing conditional updates always is certainly preferred in general. 4.4. Conditional requests with the If-header The If request header defined by [4] is intended to have similar functionality to the If-Match header defined in Section 14.24 of [5]. However, the If header handles any state token as well as ETags. This If-header can thus also be used with conditional XCAP requests especially when using lock tokens. If resources are referenced within the If header, they MUST not contain an XCAP node selector. 4.5. Other WebDAV methods With any other WebDAV methods when accessing XCAP resources, the request URI may not contain an XCAP node selector. 4.6. Access Control Lists In terms of WebDAV access control lists, the core XCAP specifies that the owner of a resource has <DAV:read> and <DAV:write> access rights. With WebDAV ACLs [6] a more fine-grained privileges can be given to users, especially when sharing resources. The privileges (<DAV: read>, <DAV:write> and so on) are used by access control elements (ACE). Several ACEs are combined into an access control list (ACL). The owners of documents are principals which are manifested to clients as a WebDAV resource, identified by a URI. WebDAV ACL does not mandate a body for principal resources, only properties are meaningful. It is thus RECOMMENDED that principals have a base URI like "http://principals.example.com/" for a domain Urpalainen Expires May 18, 2007 [Page 5]
Internet-Draft XCAP with WebDAV November 2006 "example.com". For a user "joe" the principal URI is then "http://principals.example.com/joe/self". The user "joe" is thus an XCAP user identity (XUI). It is anticipated that users can create private groups onto these collections, for example the user "joe" has then <DAV:bind> privilege to the collection "http://principals.example.com/joe/". The principal can then create group resources, i.e. group principal resources or other collections into this collection. It should be noted that a collection is not regarded as a principal. The "DAV:group-member-set" property contains then the principal URIs belonging to the group. These group resources may then be referenced by ACEs. Also group principal URIs may be referenced by the "DAV:group-member-set" property allowing thus nested groups. For new created groups of a principal the server MUST provision <DAV:all> privileges to the owner (principal) shown later in this document. If the server does not intend to support user defined groups the user will not be provisioned <DAV:bind> privilege to his/her principal collection so clients trying to create a private principal group URI will be responded with 403 "Forbidden" return code. Note: XCAP recommends a root URI like "http://xcap.example.com" for a domain "example.com". In theory, principals could be defined as an XCAP application usage, but XCAP application usages have constraints on the body that are not needed for WebDAV ACL principals. It is RECOMMENDED that while provisioning users for XCAP application usages, users are given <DAV:all> privileges to their application usage "home directories". This allows users full control to them: creation of sub-directories, setting access control rights and so on. 4.6.1. Server provisioned ACL after a successful PUT After a successful PUT (201) request a new XCAP resource has been created to the server. The server may then create an appropriate initial ACL for the document as the WebDAV ACL [6] specification does not mandate any specific server behavior. In order to ease implementations and to guarantee compatibility with XCAP clients that don't support ACLs, the server MUST thus provision an ACL for the newly created resource which allows <DAV:read> and <DAV:write> access for the owner of the resource. Similarly the servers MUST set the authenticated user the owner of the document, which means mapping of the user ID (XUI) to a principal URI. An example ACL document after the creation of a new XCAP resource: Urpalainen Expires May 18, 2007 [Page 6]
Internet-Draft XCAP with WebDAV November 2006 <?xml version="1.0" encoding="UTF-8" ?> <acl xmlns="DAV:"> <ace> <principal> <href>http://principals.example.com/joe/self</href> </principal> <grant> <privilege><all/></privilege> </grant> </ace> </acl> The client can always request the created ACL with PROPFIND method from the server and update it to his/her likings but ACL unaware clients can still continue updating this new resource. An ACL for a WebDAV resource can be set with the ACL method which always publishes the full access control list. The request URI refers to a HTTP resource and as with other use cases, it MUST not contain an XCAP node selector. PROPFIND /resource-lists/users/joe/ Host: xcap.example.com Depth: 1 Content-Type: application/xml Content-Length: xxx <?xml version="1.0" encoding="UTF-8" ?> <propfind xmlns="DAV:"> <prop> <owner/> <acl/> <getetag/> </prop> </propfind> Response: HTTP/1.1 207 Multi-Status Content-Type: application/xml Content-Length: xxxx <?xml version="1.0" encoding="UTF-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://xcap.example.com/resource-lists/users/joe/</href> <propstat> <prop> Urpalainen Expires May 18, 2007 [Page 7]
Internet-Draft XCAP with WebDAV November 2006 <owner> <href>http://principals.example.com/joe/self</href> </owner> <acl> <ace> <principal> <property><owner/></property> </principal> <grant> <privilege><all/></privilege> </grant> </ace> </acl> <getetag>"cf223434-cc347899"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>http://xcap.example.com/resource-lists/users/joe/index</href> <propstat> <prop> <owner> <href>http://principals.example.com/joe/self</href> </owner> <acl> <ace> <principal> <href>http://principals.example.com/joe/self</href> </principal> <grant> <privilege><all/></privilege> </grant> </ace> </acl> <getetag>"de33443434-af343455"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> An example about giving read access to "friends": Urpalainen Expires May 18, 2007 [Page 8]
Internet-Draft XCAP with WebDAV November 2006 ACL /resource-lists/users/joe/index Host: xcap.example.com Depth: 0 Content-Type: application/xml Content-Length: xxx <?xml version="1.0" encoding="UTF-8" ?> <acl xmlns="DAV:"> <ace> <principal> <href>http://principals.example.com/joe/self</href> </principal> <grant> <privilege><all/></privilege> </grant> </ace> <ace> <principal> <href>http://principals.example.com/joe/friends</href> </principal> <grant> <privilege><read/></privilege> </grant> </ace> </acl> Response: HTTP/1.1 200 OK And the referenced "friends" group can be queried: PROPFIND /joe/ Host: principals.example.com Depth: 1 Content-Type: application/xml Content-Length: xxx <?xml version="1.0" encoding="UTF-8" ?> <propfind xmlns="DAV:"> <prop> <group-membership/> <displayname/> </prop> </propfind> Urpalainen Expires May 18, 2007 [Page 9]
Internet-Draft XCAP with WebDAV November 2006 Response: HTTP/1.1 207 Multi-Status Content-Type: application/xml Content-Length: xxxx <?xml version="1.0" encoding="UTF-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://principals.example.com/joe/</href> <propstat> <prop> <group-membership/> <displayname/> </prop> <status>HTTP/1.1 403 Forbidden</status> </propstat> </response> <response> <href>http://principals.example.com/joe/self</href> <propstat> <prop> <displayname>Joe Smith</displayname> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <group-membership/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>http://principals.example.com/joe/friends</href> <propstat> <prop> <displayname>Friends of Joe Smith</displayname> <group-membership> <href>http://principals.example.com/lisa/self</href> <href>http://principals.example.com/jack/self</href> <href>http://principals.example.com/tom/friends</href> </group-membership> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> Urpalainen Expires May 18, 2007 [Page 10]
Internet-Draft XCAP with WebDAV November 2006 4.6.2. Server provisioned ACL after a successful MKCOL After a successful MKCOL (201) request a new collection has been created to the server. Similar to a successful PUT, the server provisions <DAV:all> privilege to the owner of this new collection and sets the authenticated user the owner of a resource. 4.6.3. Privileges The Appendix B of WebDAV ACL [6] specification lists normative privileges for different methods. This specification extends this table for DELETE method so that <DAV:unbind> privilege on a target resource allows also the unbinding of the resource from the parent collection. Note: In practice this means that if a user has a <DAV:all> or a <DAV:write> privilege on a resource, the user is able to perform a successful DELETE operation. 4.6.4. Aggregation of privileges The chapter 3.12 of WebDAV ACL [6] specification defines some allowed and disallowed aggregation rules for <DAV:read> and <DAV:write> and other privileges. Given these constraints and while it is also possible to query the implemented aggregation model of a server with <DAV:supported-privilege-set> it is RECOMMENDED that <DAV:read> contains only <DAV:read-current-user-privilege-set>, i.e. it does not contain <read-acl> privilege and similarly, <DAV:write> does not contain <write-acl> privilege. <DAV:write> will then contain <DAV: bind>, <DAV:unbind>, <DAV:write-properties> and <DAV:write-content> privileges. 5. Error Handling XCAP defines an XML error response format for 409 (Conflict) responses. The usage of WebDAV introduces some new error responses, most notably for example 423 (Locked) response. However, this does not typically impose any problem as requests are typically orthogonal, i.e. error responses either follow XCAP or WebDAV conventions depending on the request type. Some of the XCAP 409 (Conflict) responses can easily be handled automatically without user intervention. If WebDAV methods are used with request URIs which contain an otherwise valid XCAP node selector the server SHOULD respond with 501 (Not Implemented). Urpalainen Expires May 18, 2007 [Page 11]
Internet-Draft XCAP with WebDAV November 2006 6. XCAP Server Capabilities extension XCAP Server Capabilities application usage defines responses to XCAP clients about the XCAP server capabilities. The format includes the possibility to describe extensions of the server. If Class 1, 2 or 3 WebDAV compatibility is supported, the text node content of the <extension> element MUST contain "DAV1", "DAV2" or "DAV3". If the server supports several of them, each property MUST be reported with separate <extension> elements. If WebDAV ACL is supported the <extension> element contains "DAV ACL". 7. IANA Considerations This document does not require any action from IANA. 8. Security Considerations Security considerations described in XCAP [3], WebDAV [4] and WebDAV ACL [6] are naturally applicable to this specification. Especially using "distributed" authorization rules may be problematic, for example how to build trust over different domains. Also with distributed groups loops might be generated. However, implementations may disallow "distributed" authorization rules altogether by responding with appropriate precondition errors. 9. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation REC-xml-20060816 , August 2006. [3] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-12, October 2006. [4] Dusseault, L., "HTTP Extensions for Distributed Authoring - WebDAV", draft-ietf-webdav-rfc2518bis-15 (work in progress), June 2006. [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [6] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Urpalainen Expires May 18, 2007 [Page 12]
Internet-Draft XCAP with WebDAV November 2006 Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004. [7] "Namespaces in XML", W3C Recommendation REC-xml-names-19990114 , January 1999. [8] "XML Schema Part 1: Structures Second Edition", W3C Recommendation REC-xmlschema-1-20041028 , October 2004. Urpalainen Expires May 18, 2007 [Page 13]
Internet-Draft XCAP with WebDAV November 2006 Author's Address Jari Urpalainen Nokia Research Center Itamerenkatu 11-13 Helsinki 00180 Finland Phone: +358 7180 37686 Email: jari.urpalainen@nokia.com Urpalainen Expires May 18, 2007 [Page 14]
Internet-Draft XCAP with WebDAV November 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. 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 implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urpalainen Expires May 18, 2007 [Page 15]