Network Working Group | W. Sanchez |
Request for Comments: 5397 | C. Daboo |
Category: Standards Track | Apple Inc. |
December 2008 |
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright © 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user.
WebDAV [RFC4918] is an extension to HTTP [RFC2616] to support improved document authoring capabilities. The WebDAV Access Control Protocol ("WebDAV ACL") [RFC3744] extension adds access control capabilities to WebDAV. It introduces the concept of a "principal" resource, which is used to represent information about authenticated entities on the system.¶
Some clients have a need to determine which [RFC3744] principal a server is associating with the currently authenticated HTTP user. While [RFC3744] defines a DAV:current-user-privilege-set property for retrieving the privileges granted to that principal, there is no recommended way to identify the principal in question, which is necessary to perform other useful operations. For example, a client may wish to determine which groups the current user is a member of, or modify a property of the principal resource associated with the current user.¶
The DAV:principal-match REPORT provides some useful functionality, but there are common situations where the results from that query can be ambiguous. For example, not only is an individual user principal returned, but also every group principal that the user is a member of, and there is no clear way to distinguish which is which.¶
This specification proposes an extension to WebDAV ACL that adds a DAV:current-user-principal property to resources under access control on the server. This property provides a URL to a principal resource corresponding to the currently authenticated user. This allows a client to "bootstrap" itself by performing additional queries on the principal resource to obtain additional information from that resource, which is the purpose of this extension. Note that while it is possible for multiple URLs to refer to the same principal resource, or for multiple principal resources to correspond to a single principal, this specification only allows for a single http(s) URL in the DAV:current-user-principal property. If a client wishes to obtain alternate URLs for the principal, it can query the principal resource for this information; it is not the purpose of this extension to provide a complete list of such URLs, but simply to provide a means to locate a resource which contains that (and other) information.¶
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.¶
Processing of XML by clients and servers MUST follow the rules defined in Section 17 of WebDAV [RFC4918].¶
<!ELEMENT current-user-principal (unauthenticated | href)> <!-- href value: a URL to a principal resource -->
<D:current-user-principal xmlns:D="DAV:"> <D:href>/principals/users/cdaboo</D:href> </D:current-user-principal>
This specification is based on discussions that took place within the Calendaring and Scheduling Consortium's CalDAV Technical Committee. The authors thank the participants of that group for their input.¶
The authors thank Julian Reschke for his valuable input via the WebDAV working group mailing list.¶