SIMPLE J. Rosenberg Internet-Draft Cisco Systems Expires: January 19, 2006 July 18, 2005 Presence Authorization Rules draft-ietf-simple-presence-rules-03 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 January 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. Rosenberg Expires January 19, 2006 [Page 1] Internet-Draft Presence Authorization July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Structure of Presence Authorization Documents . . . . . . . 4 3.1 Conditions . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1 Identity . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2 Sphere . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Actions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1 Subscription Handling . . . . . . . . . . . . . . . . 7 3.3 Transformations . . . . . . . . . . . . . . . . . . . . . 9 3.3.1 Providing Access to Data Component Elements . . . . . 9 3.3.1.1 Device Information . . . . . . . . . . . . . . . . 9 3.3.1.2 Person Information . . . . . . . . . . . . . . . . 10 3.3.1.3 Service Information . . . . . . . . . . . . . . . 11 3.3.2 Providing Access to Presence Attributes . . . . . . . 12 3.3.2.1 Provide Activities . . . . . . . . . . . . . . . . 12 3.3.2.2 Provide Class . . . . . . . . . . . . . . . . . . 12 3.3.2.3 Provide Device ID . . . . . . . . . . . . . . . . 13 3.3.2.4 Provide Mood . . . . . . . . . . . . . . . . . . . 13 3.3.2.5 Provide Place-is . . . . . . . . . . . . . . . . . 13 3.3.2.6 Provide Place-type . . . . . . . . . . . . . . . . 13 3.3.2.7 Provide Privacy . . . . . . . . . . . . . . . . . 13 3.3.2.8 Provide Relationship . . . . . . . . . . . . . . . 13 3.3.2.9 Provide Sphere . . . . . . . . . . . . . . . . . . 14 3.3.2.10 Provide Status-Icon . . . . . . . . . . . . . . 14 3.3.2.11 Provide Time-Offset . . . . . . . . . . . . . . 14 3.3.2.12 Provide User-Input . . . . . . . . . . . . . . . 14 3.3.2.13 Provide Note . . . . . . . . . . . . . . . . . . 15 3.3.2.14 Provide Unknown Attribute . . . . . . . . . . . 15 3.3.2.15 Provide All Attributes . . . . . . . . . . . . . 16 4. When to Apply the Authorization Policies . . . . . . . . . . 16 5. Example Document . . . . . . . . . . . . . . . . . . . . . . 16 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Schema Extensibility . . . . . . . . . . . . . . . . . . . . 20 8. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1 Application Unique ID . . . . . . . . . . . . . . . . . . 20 8.2 Structure of Permission Statements . . . . . . . . . . . . 20 8.3 Additional Constraints . . . . . . . . . . . . . . . . . . 20 8.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 20 8.5 Authorization Policies . . . . . . . . . . . . . . . . . . 20 8.6 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 10.1 XCAP Application Usage ID . . . . . . . . . . . . . . . 21 10.2 URN Sub-Namespace Registration . . . . . . . . . . . . . 21 10.3 XML Schema Registrations . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Rosenberg Expires January 19, 2006 [Page 2] Internet-Draft Presence Authorization July 2005 11.1 Normative References . . . . . . . . . . . . . . . . . . 22 11.2 Informative References . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . 25 Rosenberg Expires January 19, 2006 [Page 3] Internet-Draft Presence Authorization July 2005 1. Introduction The Session Initiation Protocol (SIP) for Instant Messaging and Presence (SIMPLE) specifications allow a user, called a watcher, to subscribe to another user, called a presentity [19], in order to learn their presence information [22]. This subscription is handled by a presence agent. However, presence information is sensitive, and a presence agent needs authorization from the presentity prior to handing out presence information. As such, a presence authorization document format is needed. This specification defines a format for such a document, called a presence authorization document. [12] specifies a framework for representing authorization policies, and is applicable to systems such as geo-location and presence. This framework is used as the basis for presence authorization documents. In the framework, an authorization policy is a set of rules. Each rule contains conditions, actions, and transformations. The conditions specify under what conditions the rule is to be applied to presence server processing. The actions element tells the server what actions to take. The transformations element indicates how the presence data is to be manipulated before being presented to that watcher, and as such, defines a privacy filtering operation. [12] identifies a small number of specific conditions, actions and permissions common to presence and location services, and leaves it to other specifications, such as this one, to fill in usage specific details. A presence authorization document can be manipulated by clients using several means. One such mechanism is the XML Configuration Access Protocol (XCAP) [2]. This specification defines the details necessary for using XCAP to manage presence authorization documents. 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 [1] and indicate requirement levels for compliant implementations. 3. Structure of Presence Authorization Documents A presence authorization document is an XML document, formatted according to the schema defined in [12]. Presence authorization documents inherit the MIME type of common policy documents, application/auth-policy+xml. As described in [12], this document is composed of three parts - conditions, actions, and transformations. Each action or transformation, which is also called a permission, has the property of being a positive grant of information to the watcher. Rosenberg Expires January 19, 2006 [Page 4] Internet-Draft Presence Authorization July 2005 As a result, there is a well-defined mechanism for combining actions and transformations obtained from several sources. This mechanism is privacy safe, since the lack of any action or transformation can only result in less information being presented to a watcher. This section defines the new conditions, actions and transformations defined by this specification. 3.1 Conditions 3.1.1 Identity Although the element is defined in [12], that specification indicates that the specific usages of the framework document need to define details that are protocol and usage specific. In particular, it is neccesary for a usage of the common policy framework to: o Define how authentication mechanisms for the protocol produce identities of the form user@domain. o Define whether those identities are authenticated, unauthenticated, or asserted. This sub-section defines those details for systems based on [22]. For requests that are authenticated using SIP [9] digest authentication [8], the identity of the watcher is set equal to the user and domain part of the SIP Address of Record (AOR) for the user that has authenticated themselves. For example, consider the following "user record": SIP AOR: sip:alice@example.com digest username: ali digest password: f779ajvvh8a6s6 digest realm: example.com If the presence server receives a SUBSCRIBE request, challenges it with the realm set to "example.com", and the subsequent SUBSCRIBE contains an Authorization header field with a username of "ali" and a digest response generated with the password "f779ajvvh8a6s6", the identity used in matching operations is "sip:alice@example.com". Identities obtained through digest authentication are considered "authenticated identities" according to the common policy framework. For requests that are authenticated using RFC 3325 [23], the identity is equal to the username and domain parts of the SIP URI in the Rosenberg Expires January 19, 2006 [Page 5] Internet-Draft Presence Authorization July 2005 P-Asserted-ID header field. These identities are considered "asserted identities" according to the common policy framework. If the P-Asserted-ID header field only contains a tel URI [18], it is not possible to obtain an identity of the form user@domain. As such, the identity for such requests is considered undefined, and thus equivalent to an unauthenticated identity. For requests that are authenticated using the SIP Identity mechanism [14], the common policy identity is equal to the username and domain part of the URI in the From header field of the request, assuming that the signature in the Identity header field has been validated. These identities are considered "asserted identities" according to the common policy framework. In SIP systems, it is possible for a user to have aliases - that is, there are multiple SIP AOR "assigned" to a single user. In terms of this specification, there is no relationship between those aliases. Each would look like a different user. This will be the consequence for systems were the watcher is in a different domain than the presentity. However, even if the watcher and presentity are in the same domain, and the presence server knows that there are aliases for the watcher, these aliases are not mapped to each other or used in any way. SIP also allows for anonymous requests. The request is considered anonymous if it was authenticated by the presence server using the username defined in RFC 3261, if the asserted identity [23] has a URI in the "anonymous.invalid" domain [17], or if the From field has a username of anonymous within some domain, and the Identity header field is present with a valid signature provided by that domain [14]. The common policy framework does not have any support for anonymous identities. As such, if a SIP request is anonymous, it is equivalent to unauthenticated as far as the common policy framework. 3.1.2 Sphere The element is defined in [12]. However, each application making use of the common policy specification needs to determine how the presence server computes the value of the sphere to be used in the evaluation of the condition. To compute the value of , the presence agent examines all published presence documents for the presentity. If at least one of them include the element [13] as part of the person data component [15], and all of those containing the element have the same value for it, that is the value used for the sphere in common policy processing. If, however, the element was not present in any Rosenberg Expires January 19, 2006 [Page 6] Internet-Draft Presence Authorization July 2005 of the published documents, or it was present but had inconsistent values, its value is considered undefined in terms of common policy processing. Care must be taken in using as a condition for determining the subscription handling. Since the value of changes dynamically, a state change can cause a subscription to be suddenly terminated. The watcher has no way to know, aside from polling, when their subscription would be re-instated as the value of changes. For this reason, is primarily useful for matching on rules that define transformations. 3.2 Actions 3.2.1 Subscription Handling The element specifies the subscription authorization decision that the server should make. It also specifies whether or not the presence document for the watcher should be constructed using "polite blocking" or not. Usage of polite blocking and the subscription authorization decision are specified jointly since proper privacy handling requires a correlation between them. As discussed in [12], since the combination algorithm runs independently for each permission, if correlations exist between permissions, they must be merged into a single variable. That is what is done here. The element is an enumerated Integer type. The defined values are: block: This action tells the server to place the subscription in the rejected state. It has the value of zero, and it represents the default value. No value of the sub-handling element can ever be lower than this. Strictly speaking, it is not necessary to every include an explicit block action, since the default in the absence of any action will be block. However, it is included for completeness. confirm: This action tells the server to place the subscription in the "pending" state, and await input from the presentity to determine how to proceed. It has a value of one. polite-block: This action tells the server to place the subscription into the "accepted" state, and to produce a presence document that indicates that the presentity is unavailable. A reasonable document would exclude device and person information elements, and include only a single service whose basic status is set to closed [3]. This action has a value of two. Rosenberg Expires January 19, 2006 [Page 7] Internet-Draft Presence Authorization July 2005 allow: This action tells the server to place the subscription into the "accepted" state. This action has a value of three. NOTE WELL: Placing a value of block for this element does not guarantee that a subscription is denied! If any matching rule has any other value for this element, the subscription will receive treatment based on the maximum of those other values. This is based on the combining rules defined in [12]. Future specifications can define additional values for this permission, allowing for the selection of other composition policies. The exact behavior of a presence server upon a change in the sub- handling value can be described by utilizing the subscription processing state machine in Figure 1 of RFC 3857 [10]. Each subscription is associated with a set of permissions that represents the combination of all permissions that apply to that subscription, using the combining rules in [12]. If the sub-handling permission changes value to "block", this causes a "rejected" event to be generated into the subscription state machine for all affected subscriptions. This will cause the state machine to move into the terminated state, resulting in the transmission of a NOTIFY to the watcher with a Subscription-State header field with value "terminated" and a reason of "rejected" [11], which terminates their subscription. If a new subscription arrives later on, and the value of sub-handling that applies to that subscription is "block", the subscription processing follows the "subscribe, policy=reject" branch from the init state, and a 403 response to the SUBSCRIBE is generated. If the sub-handling permission changes value to confirm, the processing depends on the states of the affected subscriptions. Unfortunately, the state machine in RFC 3857 does not define an event corresponding to an authorization decision of "pending". If the subscription is in the active state, it moves back into the pending state. This causes a NOTIFY to be sent, updating the Subscription- State [11] to "pending". No reason is included in the Subscription- State header field (none are defined to handle this case). No further documents are sent to this watcher. There is no change in state if the subscription is in the pending, waiting or terminated states. If a new subscription arrives later on, and the value of sub-handling that apples to that subscription is "pending", the subscription processing follows the "subscribe, no policy" branch from the init state, and a 202 response to the SUBSCRIBE is generated, followed by a NOTIFY with Subscription-State of pending. No presence document is included in that NOTIFY. Rosenberg Expires January 19, 2006 [Page 8] Internet-Draft Presence Authorization July 2005 If the sub-handling permission changes value to "polite-block" or "allow", this causes an "approved" event to be generated into the state machine for all affected subscriptions. This will cause the machine to move into the active state if it is currently in pending, resulting in the transmission of a NOTIFY with a Subscription-State header field of "active", and the inclusion of a presence document in that NOTIFY. If a new subscription arrives later on, and the value of sub-handling that applies to that subscription is is "polite- block" or "allow", the subscription processing follows the "subscribe, policy=accept" branch from the init state, and a 200 OK response to the SUBSCRIBE is generated, followed by a NOTIFY with Subscription-State of "active" with a presence document in the body of the NOTIFY. 3.3 Transformations The transformations defined here are used to drive the behavior of the privacy filtering operation. Each transformation defines the visibility a watcher is granted to a particular component of the presence document. One group of transformations grant visibility to person, device and service data elements based on identifying information for those elements. Another group of transformations provide access to particular data elements in the presence document. 3.3.1 Providing Access to Data Component Elements The transformations in this section provide access to person, device and service data component elements. Once access has been granted to such an element, access to specific presence attributes for that element is controlled by the permissions defined in Section 3.3.2. 3.3.1.1 Device Information The permission allows a watcher to see information present in the presence document. It is a set variable. Each member of the set provides a way to identify a device or group of devices. This specification defines three types of elements in the set - , which identifies a device occurrence by class, , which identifies a device occurrence by device ID, and , which identifies a device occurrence by occurrence ID. Each member of the set is identified by its type (class, device-id or occurrence-id) and value (value of the class, value of the device-id, or value of the occurrence-id). For example, consider the following element: Rosenberg Expires January 19, 2006 [Page 9] Internet-Draft Presence Authorization July 2005 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 biz This set has two members. This is combined with a element from a different rule: home biz The result of the set combination (using the union operation) is a set with four elements: home biz urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 The element can also take on the special value which is a short-hand notation for all device occurrences present in the presence document. Permission is granted to see a particular device occurrence if one of the device identifiers in the set identifies that device occurrence. If a permission is granted to the watcher, and the of the device occurrence matches the value of the permission based on case sensitive equality, the device occurrence is included in the presence document. If a permission is granted to the watcher, and the of the device occurrence matches the value of the permission based on URI equivalence, the device occurrence is included in the presence document. If a permission is granted to the watcher, and the of the device occurrence matches the value of the permission based on case sensitive equality, the device occurrence is included in the presence document. In addition, a device occurrence is included in the presence document if the permission was granted to the watcher. 3.3.1.2 Person Information The permission allows a watcher to see the information present in the presence document. It is a set variable. Rosenberg Expires January 19, 2006 [Page 10] Internet-Draft Presence Authorization July 2005 Each member of the set provides a way to identify a person occurrence. This specification defines two types of elements in the set - , which identifies a person occurrence by class, and , which identifies an occurrence by its occurrence ID. Each member of the set is identified by its type (class or occurrence-id) and value (value of the class or value of the occurrence-id). The element can also take on the special value which is a short-hand notation for all person occurrences present in the presence document. The set combination is done identically to the element. Permission is granted to see a particular person occurrence if one of the person identifiers in the set identifies that person occurrence. If a permission is granted to the watcher, and the of the person occurrence matches the value of the permission based on case sensitive equality, the person occurrence is included in the presence document. If a permission is granted to the watcher, and the of the person occurrence matches the value of the permission based on case sensitive equality, the person occurrence is included in the presence document. In addition, a person occurrence is included in the presence document if the permission was granted to the watcher. 3.3.1.3 Service Information The permission allows a watcher to see service information present in elements in the presence document. Like , it is a set variable. Each member of the set provides a way to identify a service occurrence. This specification defines four types of elements in the set - , which identifies a service occurrence by class, , which identifies a service by its occurrence ID, , which identifies a service by its service URI, and , which identifies a service by its service URI scheme. Each member of the set is identified by its type (class, occurrence-id, service-uri or service-uri-scheme) and value (value of the class, value of the occurrence-id, value of the service-uri or value of the service-uri- scheme ). The element can also take on the special value which is a short-hand notation for all service occurrences present in the presence document. The set combination is done identically to the element. Permission is granted to see a particular service occurrence if one of the service identifiers in the set identifies that service occurrence. If a permission is granted to the watcher, and the of the service occurrence matches the value of the permission based on case sensitive equality, the service Rosenberg Expires January 19, 2006 [Page 11] Internet-Draft Presence Authorization July 2005 occurrence is included in the presence document. If a permission is granted to the watcher, and the of the service occurrence matches the value of the permission based on URI equivalence, the service occurrence is included in the presence document. If a permission is granted to the watcher, and the of the service occurrence matches the value of the permission based on case sensitive equality, the service occurrence is included in the presence document. If a permission is granted to the watcher, and the scheme of the service URI for the service occurrence matches the value of based on case sensitive equality, the service occurrence is included in the presence document. In addition, a service occurrence is included in the presence document if the permission was granted to the watcher. 3.3.2 Providing Access to Presence Attributes The permissions of Section 3.3.1 provide coarse grained access to presence data by allowing or blocking specific services or devices, and allowing or blocking person information. Once person, device or service information is included in the document, the permissions in this section define which presence attributes are reported there. Certain information is always reported. In particular, the , [13], status and elements in all elements, if present, are provided to watchers . The element in all elements, if present, is provided to watchers. The and elements in all elements, if present, is provided to all watchers. 3.3.2.1 Provide Activities This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.2 Provide Class This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the element in the person, service or device data element is reported to the watcher. If FALSE, this presence attribute is Rosenberg Expires January 19, 2006 [Page 12] Internet-Draft Presence Authorization July 2005 removed if present. 3.3.2.3 Provide Device ID This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the element in the service data element is reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.4 Provide Mood This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.5 Provide Place-is This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.6 Provide Place-type This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.7 Provide Privacy This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the element in the service data element is reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.8 Provide Relationship This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is Rosenberg Expires January 19, 2006 [Page 13] Internet-Draft Presence Authorization July 2005 TRUE, then the element in the service data element is reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.9 Provide Sphere This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.10 Provide Status-Icon This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then any element in the person or service data element is reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.11 Provide Time-Offset This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the element in the person data element is reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.12 Provide User-Input This permission controls access to the element defined in [13]. The name of the element providing this permission is , and it is an enumerated integer type. Its value defines what information is provided to watchers: false: This value indicates that the element is removed from the document. It is assigned the numeric value of 0. bare: This value indicates that the element is to be retained. However, any "idle-threshold" and "since" attributes are to be removed. This value is assigned the numeric value of 1. thresholds: This value indicates that the element is to be retained. However, only the "idle-threshold" attribute is to be retained. This value is assigned to the numeric value of 2. Rosenberg Expires January 19, 2006 [Page 14] Internet-Draft Presence Authorization July 2005 full: This value indicates that the element is to be retained, including any attributes. This value is assigned to the numeric value of 3. 3.3.2.13 Provide Note This permission controls access to the element defined in [3] for and [15] for and . The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the elements in the person, service or device data elements are reported to the watcher. If FALSE, this presence attribute is removed if present. 3.3.2.14 Provide Unknown Attribute It is important that systems be allowed to include proprietary or new presence information, and that users be able to set permissions for that information, without requiring an upgrade of the presence server and authorization system. For this reason, the permission is defined. This permission indicates that the unknown presence attribute with the given name (supplied as mandatory attribute of the element) should be included in the document. Its type is boolean. The value of the name attribute MUST be a qualified element name (meaning that the namespace prefix MUST be included), which will be matched to all unknown child elements of the PIDF , or is present. In this context, "unknown" means that the presence server is not aware of any schemas that define authorization policies for that element. By definition, this will exclude the rule from being applied to any of the presence status extensions defined by RPID. Another consequence of this definition is that the interpretation of the element can change should the presence server be upgraded with a new schema that defines authorization rules for elements included in a . The permissions for those elements will then be ignored, resulting in a removal of those elements from presence documents sent to watchers. The system remains privacy safe, but behavior might not be as expected. Developers of systems which allow clients to set policies are advised to check the capabilities of the server, as defined in [21], before uploading a new authorization document, to make sure that the behavior will be as expected. Rosenberg Expires January 19, 2006 [Page 15] Internet-Draft Presence Authorization July 2005 3.3.2.15 Provide All Attributes This permission grants access to all presence attributes in all of the person, device and tuple elements that are present in the document (the ones present in the document are determedined by the , and permissions). It is effectively a macro that expands into a set of provide-activities, provide-class, provide-device-id, provide-mood, provide-place-is, provide-place-type, provide-privacy, provide- relationship, provide-sphere, provide-status-icon, provide-time- offset, provide-user-input, provide-note and provide-unknown- attribute permissions such that each presence attribute in the document has a permission for it. This implies that, so long as an entire person, service or device occurrence is provided, every single presence attribute, including ones not known to the server and/or defined in future presence document extensions, is granted to the watcher. 4. When to Apply the Authorization Policies This specification does not mandate at what point in the processing of presence data the privacy filtering aspects of the authorization policy are applied. However, they must be applied such that the final presence document sent to the watcher is compliant to the privacy policy described in the document. More concretely, if the document sent to a watcher is D, and the privacy filtering operation applied do a presence document x is F(x), then D MUST have the property that D = F(D). A corollary of this is that F(F(D)) = D for all D. The subscription processing aspects of the document get applied by the server when it decides to accept or reject the subscription. 5. Example Document The following presence authorization document specifies permissions for the user "user@example.com". Rosenberg Expires January 19, 2006 [Page 16] Internet-Draft Presence Authorization July 2005 allow sip mailto true bare true 6. XML Schema Rosenberg Expires January 19, 2006 [Page 17] Internet-Draft Presence Authorization July 2005 Rosenberg Expires January 19, 2006 [Page 18] Internet-Draft Presence Authorization July 2005 Rosenberg Expires January 19, 2006 [Page 19] Internet-Draft Presence Authorization July 2005 7. Schema Extensibility It is anticipated that future changes to this specification are accomplished through extensions that define new types of permissions. These extensions MUST exist within a different namespace. Furthermore, the schema defined above and the namespace for elements defined within it MUST NOT be altered by future specifications. Changes in the basic schema, or in the interpretation of elements within that schema, may result in violations of user privacy due to mis-interpretation of documents. This specification also defines two substitution groups. One is for service identifiers, and one is for device identifiers. It is expected that future extensions will specify new ways of identifying services and devices for inclusion in a document. These new permissions MUST be assigned to this substitution group. 8. XCAP Usage The following section defines the details necessary for clients to manipulate presence authorization documents from a server using XCAP. 8.1 Application Unique ID XCAP requires application usages to define a unique application usage ID (AUID) in either the IETF tree or a vendor tree. This specification defines the "pres-rules" AUID within the IETF tree, via the IANA registration in Section 10. 8.2 Structure of Permission Statements The structure of permission statements is defined in Section 3. 8.3 Additional Constraints There are no additional constraints defined by this specification. 8.4 Naming Conventions When a presence agent receives a subscription for some user foo within a domain, it will look for all documents within http://[xcap root]/ pres-rules/users/foo, and use all documents found beneath that point to guide authorization policy. 8.5 Authorization Policies This application usage does not modify the default XCAP authorization policy, which is that only a user can read, write or modify their own Rosenberg Expires January 19, 2006 [Page 20] Internet-Draft Presence Authorization July 2005 documents. A server can allow priveleged users to modify documents that they don't own, but the establishment and indication of such policies is outside the scope of this document. 8.6 XML Schema The XML schema is defined in Section 6. 9. Security Considerations Presence authorization policies contain very sensitive information. They indicate which other users are "liked" or "disliked" by a user. As such, when these documents are transported over a network, they SHOULD be encrypted. Modification of these documents by an attacker can disrupt the service seen by a user, often in subtle ways. As a result, when these documents are transported, the transport SHOULD provide authenticity and message integrity. In the case where XCAP is used to transfer the document, clients SHOULD use HTTP over TLS, and servers SHOULD define the root services URI as an https URI. The server SHOULD authenticate the client over the resulting TLS connection using HTTP digest. 10. IANA Considerations There are several IANA considerations associated with this specification. 10.1 XCAP Application Usage ID This section registers an XCAP Application Usage ID (AUID) according to the IANA procedures defined in [2]. Name of the AUID: pres-rules Description: Presence rules are documents that describe the permissions that a presentity [19] has granted to users that seek to watch their presence. 10.2 URN Sub-Namespace Registration This section registers a new XML namespace, per the guidelines in [16] Rosenberg Expires January 19, 2006 [Page 21] Internet-Draft Presence Authorization July 2005 URI: The URI for this namespace is urn:ietf:params:xml:ns:pres-rules. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). XML: BEGIN Presence Rules Namespace

Namespace for Permission Statements

urn:ietf:params:xml:ns:pres-rules

See RFCXXXX.

END 10.3 XML Schema Registrations This section registers an XML schema per the procedures in [16]. URI: urn:ietf:params:xml:schema:pres-rules. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). The XML for this schema can be found as the sole content of Section 6. 11. References 11.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Rosenberg Expires January 19, 2006 [Page 22] Internet-Draft Presence Authorization July 2005 [2] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-07 (work in progress), June 2005. [3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [4] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000. [5] Moats, R., "URN Syntax", RFC 2141, May 1997. [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [10] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [12] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-04 (work in progress), February 2005. [13] Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", draft-ietf-simple-rpid-07 (work in progress), June 2005. [14] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-05 (work in progress), May 2005. [15] Rosenberg, J., "A Data Model for Presence", Rosenberg Expires January 19, 2006 [Page 23] Internet-Draft Presence Authorization July 2005 draft-ietf-simple-presence-data-model-02 (work in progress), February 2005. [16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [17] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [18] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 11.2 Informative References [19] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [20] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [21] Rosenberg, J., "An Extensible Markup Language (XML) Representation for Expressing Presence Policy Capabilities", draft-rosenberg-simple-pres-policy-caps-02 (work in progress), February 2005. [22] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [23] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. Author's Address Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 Email: jdrosen@cisco.com URI: http://www.jdrosen.net Rosenberg Expires January 19, 2006 [Page 24] Internet-Draft Presence Authorization July 2005 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 (2005). 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. Rosenberg Expires January 19, 2006 [Page 25]