idnits 2.17.1 draft-ietf-simple-presence-rules-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1186. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1199. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 9, 2006) is 6524 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-11 ** Obsolete normative reference: RFC 2617 (ref. '4') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 3265 (ref. '7') (Obsoleted by RFC 6665) == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-common-policy-10 == Outdated reference: A later version (-01) exists of draft-ietf-simple-pres-policy-caps-00 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: December 11, 2006 June 9, 2006 6 Presence Authorization Rules 7 draft-ietf-simple-presence-rules-07 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 11, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Authorization is a key function in presence systems. Authorization 41 policies, also known as authorization rules, specify what presence 42 information can be given to which watchers, and when. This 43 specification defines an Extensible Markup Language (XML) document 44 format for expressing presence authorization rules. Such a document 45 can be manipulated by clients using the XML Configuration Access 46 Protocol (XCAP), although other techniques are permitted. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Structure of Presence Authorization Documents . . . . . . . . 4 53 3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1.1. Identity . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1.1.1. Acceptable Forms of Authentication . . . . . . . . 5 56 3.1.1.2. Computing a URI for the Watcher . . . . . . . . . 6 57 3.1.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.2.1. Subscription Handling . . . . . . . . . . . . . . . . 8 60 3.3. Transformations . . . . . . . . . . . . . . . . . . . . . 9 61 3.3.1. Providing Access to Data Component Elements . . . . . 10 62 3.3.1.1. Device Information . . . . . . . . . . . . . . . . 10 63 3.3.1.2. Person Information . . . . . . . . . . . . . . . . 11 64 3.3.1.3. Service Information . . . . . . . . . . . . . . . 12 65 3.3.2. Providing Access to Presence Attributes . . . . . . . 13 66 3.3.2.1. Provide Activities . . . . . . . . . . . . . . . . 13 67 3.3.2.2. Provide Class . . . . . . . . . . . . . . . . . . 13 68 3.3.2.3. Provide DeviceID . . . . . . . . . . . . . . . . . 13 69 3.3.2.4. Provide Mood . . . . . . . . . . . . . . . . . . . 13 70 3.3.2.5. Provide Place-is . . . . . . . . . . . . . . . . . 14 71 3.3.2.6. Provide Place-type . . . . . . . . . . . . . . . . 14 72 3.3.2.7. Provide Privacy . . . . . . . . . . . . . . . . . 14 73 3.3.2.8. Provide Relationship . . . . . . . . . . . . . . . 14 74 3.3.2.9. Provide Sphere . . . . . . . . . . . . . . . . . . 14 75 3.3.2.10. Provide Status-Icon . . . . . . . . . . . . . . . 15 76 3.3.2.11. Provide Time-Offset . . . . . . . . . . . . . . . 15 77 3.3.2.12. Provide User-Input . . . . . . . . . . . . . . . . 15 78 3.3.2.13. Provide Note . . . . . . . . . . . . . . . . . . . 15 79 3.3.2.14. Provide Unknown Attribute . . . . . . . . . . . . 16 80 3.3.2.15. Provide All Attributes . . . . . . . . . . . . . . 17 81 4. When to Apply the Authorization Policies . . . . . . . . . . . 17 82 5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 17 83 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 7. Schema Extensibility . . . . . . . . . . . . . . . . . . . . . 21 85 8. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 22 87 8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 22 88 8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 22 89 8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 22 90 8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 22 91 8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 22 92 8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 22 93 8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 22 94 8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 23 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 97 10.1. XCAP Application Usage ID . . . . . . . . . . . . . . . . 23 98 10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 23 99 10.3. XML Schema Registrations . . . . . . . . . . . . . . . . . 24 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 103 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 105 Intellectual Property and Copyright Statements . . . . . . . . . . 28 107 1. Introduction 109 The Session Initiation Protocol (SIP) for Instant Messaging and 110 Presence (SIMPLE) specifications allow a user, called a watcher, to 111 subscribe to another user, called a presentity [16], in order to 112 learn their presence information [18]. This subscription is handled 113 by a presence agent. However, presence information is sensitive, and 114 a presence agent needs authorization from the presentity prior to 115 handing out presence information. As such, a presence authorization 116 document format is needed. This specification defines a format for 117 such a document, called a presence authorization document. 119 [8] specifies a framework for representing authorization policies, 120 and is applicable to systems such as geo-location and presence. This 121 framework is used as the basis for presence authorization documents. 122 In the framework, an authorization policy is a set of rules. Each 123 rule contains conditions, actions, and transformations. The 124 conditions specify under what conditions the rule is to be applied to 125 presence server processing. The actions element tells the server 126 what actions to take. The transformations element indicates how the 127 presence data is to be manipulated before being presented to that 128 watcher, and as such, defines a privacy filtering operation. [8] 129 identifies a small number of specific conditions common to presence 130 and location services, and leaves it to other specifications, such as 131 this one, to fill in usage specific details. 133 A presence authorization document can be manipulated by clients using 134 several means. One such mechanism is the XML Configuration Access 135 Protocol (XCAP) [2]. This specification defines the details 136 necessary for using XCAP to manage presence authorization documents. 138 2. Terminology 140 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 141 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 142 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 143 indicate requirement levels for compliant implementations. 145 3. Structure of Presence Authorization Documents 147 A presence authorization document is an XML document, formatted 148 according to the schema defined in [8]. Presence authorization 149 documents inherit the MIME type of common policy documents, 150 application/auth-policy+xml. As described in [8], this document is 151 composed of rules which contain three parts - conditions, actions, 152 and transformations. Each action or transformation, which is also 153 called a permission, has the property of being a positive grant of 154 information to the watcher. As a result, there is a well-defined 155 mechanism for combining actions and transformations obtained from 156 several sources. This mechanism is privacy safe, since the lack of 157 any action or transformation can only result in less information 158 being presented to a watcher. 160 This section defines the new conditions, actions and transformations 161 defined by this specification. 163 3.1. Conditions 165 3.1.1. Identity 167 Although the element is defined in [8], that specification 168 indicates that the specific usages of the framework document need to 169 define details that are protocol and usage specific. In particular, 170 it is neccesary for a usage of the common policy framework to: 172 o Define acceptable means of authentication. 174 o Define the procedure for representing the identity of the WR 175 (Watcher/Requestor) as a URI or IRI [14]. 177 This sub-section defines those details for systems based on [18]. 179 3.1.1.1. Acceptable Forms of Authentication 181 When used with SIP, a request is considered authenticated if one of 182 the following techniques is used: 184 SIP Digest: The presence agent has authenticated the watcher using 185 SIP [5] digest authentication [4]. However, if the anonymous 186 authentication described on page 194 of RFC 3261 [5] was used, the 187 watcher is not considered authenticated. 189 Asserted Identity: If a request contains a P-Asserted-ID header field 190 [19] and the request is coming from a trusted element, the watcher 191 is considered authenticated. 193 Cryptographically Verified Identity: If a request contains an 194 Identity header field as defined in [10], and it validates the 195 From header field of the request, the request is considered to be 196 authenticated. Note that this is true even if the request 197 contained a From header field of the form 198 sip:anonymous@example.com. As long as the signature verifies that 199 the request legitimately came from this identity, it is considered 200 authenticated. 202 3.1.1.2. Computing a URI for the Watcher 204 For requests that are authenticated using SIP Digest, the identity of 205 the watcher is set equal to the address of record (AoR) for the user 206 that has authenticated themselves. The AoR is always a URI, and can 207 be either a SIP URI or tel URI [13]. For example, consider the 208 following "user record" in a database: 210 SIP AOR: sip:alice@example.com 211 digest username: ali 212 digest password: f779ajvvh8a6s6 213 digest realm: example.com 215 If the presence server receives a SUBSCRIBE request, challenges it 216 with the realm set to "example.com", and the subsequent SUBSCRIBE 217 contains an Authorization header field with a username of "ali" and a 218 digest response generated with the password "f779ajvvh8a6s6", the 219 identity used in matching operations is "sip:alice@example.com". 221 For requests that are authenticated using RFC 3325 [19], the identity 222 of the watcher is equal to the URI in the P-Asserted-ID header field. 223 If there are multiple values for the P-Asserted-ID header field 224 (there can be one sip URI and one tel URI [13]), then each of them is 225 used for the comparisons outlined in [8], and if either of them match 226 a or element, it is considered a match. 228 For requests that are authenticated using the SIP Identity mechanism 229 [10], identity of the WR is equal to the SIP URI in the From header 230 field of the request, assuming that the signature in the Identity 231 header field has been validated. 233 In SIP systems, it is possible for a user to have aliases - that is, 234 there are multiple SIP AoRs "assigned" to a single user. In terms of 235 this specification, there is no relationship between those aliases. 236 Each would look like a different user. This will be the consequence 237 for systems where the watcher is in a different domain than the 238 presentity. However, even if the watcher and presentity are in the 239 same domain, and the presence server knows that there are aliases for 240 the watcher, these aliases are not mapped to each other or used in 241 any way. 243 SIP also allows for anonymous requests. If a request is anonymous 244 because the digest challenge/response used the "anonymous" username, 245 the request is considered unauthenticated and will match only an 246 empty element. If a request is anonymous because it 247 contains a Privacy header field [15], but still contains a 248 P-Asserted-ID header field, the identity in the P-Asserted-ID header 249 field is still used in the authorization computations; the fact that 250 the request was anonymous has no impact on the identity processing. 251 However, if the request had traversed a trust boundary and the 252 P-Asserted-ID header field and the Privacy header field had been 253 removed, the request will be considered unauthenticated when it 254 arrives at the presence server. Finally, if a request contained an 255 Identity header field that was validated, and the From header field 256 contained a URI of the form sip:anonymous@example.com, then the 257 watcher is considered authenticated, and it will have an identity 258 equal to sip:anonymous@example.com. Had such an identity been placed 259 into a or element, there will be a match. 261 It is important to note that SIP frequently uses both SIP URI and tel 262 URI [13] as identifiers, and to make matters more confusing, a SIP 263 URI can contain a phone number in its user part, in the same format 264 used in a tel URI. A WR identity that is a SIP URI with a phone 265 number will NOT match the and conditions whose 'id' is 266 a tel URI with the same number. The same is true in the reverse. If 267 the WR identity is a tel URI, this will not match a SIP URI in the 268 or conditions whose user part is a phone number. URIs 269 of different schemes are never equivalent. 271 3.1.2. Sphere 273 The element is defined in [8]. However, each application 274 making use of the common policy specification needs to determine how 275 the presence server computes the value of the sphere to be used in 276 the evaluation of the condition. 278 To compute the value of , the presence agent examines all 279 published presence documents for the presentity. If at least one of 280 them include the element [9] as part of the person data 281 component [11], and all of those containing the element have the same 282 value for it, that is the value used for the sphere in presence 283 policy processing. If, however, the element was not present 284 in any of the published documents, or it was present but had 285 inconsistent values, its value is considered undefined in terms of 286 presence policy processing. 288 Care must be taken in using as a condition for determining 289 the subscription handling. Since the value of changes 290 dynamically, a state change can cause a subscription to be suddenly 291 terminated. The watcher has no way to know, aside from polling, when 292 their subscription would be re-instated as the value of 293 changes. For this reason, is primarily useful for matching 294 on rules that define transformations. 296 3.2. Actions 298 3.2.1. Subscription Handling 300 The element specifies the subscription authorization 301 decision that the server should make. It also specifies whether or 302 not the presence document for the watcher should be constructed using 303 "polite blocking" or not. Usage of polite blocking and the 304 subscription authorization decision are specified jointly since 305 proper privacy handling requires a correlation between them. As 306 discussed in [8], since the combination algorithm runs independently 307 for each permission, if correlations exist between permissions, they 308 must be merged into a single variable. That is what is done here. 309 The element is an enumerated Integer type. The 310 defined values are: 312 block: This action tells the server to place the subscription in the 313 rejected state. It has the value of zero, and it represents the 314 default value. No value of the sub-handling element can ever be 315 lower than this. Strictly speaking, it is not necessary to every 316 include an explicit block action, since the default in the absence 317 of any action will be block. However, it is included for 318 completeness. 320 confirm: This action tells the server to place the subscription in 321 the "pending" state, and await input from the presentity to 322 determine how to proceed. It has a value of ten. 324 polite-block: This action tells the server to place the subscription 325 into the "accepted" state, and to produce a presence document that 326 indicates that the presentity is unavailable. A reasonable 327 document would exclude device and person information elements, and 328 include only a single service whose basic status is set to closed 329 [3]. This action has a value of twenty. 331 allow: This action tells the server to place the subscription into 332 the "accepted" state. This action has a value of thirty. 334 NOTE WELL: Placing a value of block for this element does not 335 guarantee that a subscription is denied! If any matching rule has 336 any other value for this element, the subscription will receive 337 treatment based on the maximum of those other values. This is 338 based on the combining rules defined in [8]. 340 Future specifications can define additional values for this 341 permission, allowing for the selection of other composition policies. 343 The exact behavior of a presence server upon a change in the sub- 344 handling value can be described by utilizing the subscription 345 processing state machine in Figure 1 of RFC 3857 [6]. 347 If the sub-handling permission changes value to "block", this causes 348 a "rejected" event to be generated into the subscription state 349 machine for all affected subscriptions. This will cause the state 350 machine to move into the terminated state, resulting in the 351 transmission of a NOTIFY to the watcher with a Subscription-State 352 header field with value "terminated" and a reason of "rejected" [7], 353 which terminates their subscription. If a new subscription arrives 354 later on, and the value of sub-handling that applies to that 355 subscription is "block", the subscription processing follows the 356 "subscribe, policy=reject" branch from the init state, and a 403 357 response to the SUBSCRIBE is generated. 359 If the sub-handling permission changes value to confirm, the 360 processing depends on the states of the affected subscriptions. 361 Unfortunately, the state machine in RFC 3857 does not define an event 362 corresponding to an authorization decision of "pending". If the 363 subscription is in the active state, it moves back into the pending 364 state. This causes a NOTIFY to be sent, updating the Subscription- 365 State [7] to "pending". No reason is included in the Subscription- 366 State header field (none are defined to handle this case). No 367 further documents are sent to this watcher. There is no change in 368 state if the subscription is in the pending, waiting or terminated 369 states. If a new subscription arrives later on, and the value of 370 sub-handling that apples to that subscription is "pending", the 371 subscription processing follows the "subscribe, no policy" branch 372 from the init state, and a 202 response to the SUBSCRIBE is 373 generated, followed by a NOTIFY with Subscription-State of pending. 374 No presence document is included in that NOTIFY. 376 If the sub-handling permission changes value to "polite-block" or 377 "allow", this causes an "approved" event to be generated into the 378 state machine for all affected subscriptions. This will cause the 379 machine to move into the active state if it is currently in pending, 380 resulting in the transmission of a NOTIFY with a Subscription-State 381 header field of "active", and the inclusion of a presence document in 382 that NOTIFY. If a new subscription arrives later on, and the value 383 of sub-handling that applies to that subscription is "polite-block" 384 or "allow", the subscription processing follows the "subscribe, 385 policy=accept" branch from the init state, and a 200 OK response to 386 the SUBSCRIBE is generated, followed by a NOTIFY with Subscription- 387 State of "active" with a presence document in the body of the NOTIFY. 389 3.3. Transformations 391 The transformations defined here are used to drive the behavior of 392 the privacy filtering operation. Each transformation defines the 393 visibility a watcher is granted to a particular component of the 394 presence document. One group of transformations grant visibility to 395 person, device and service data elements based on identifying 396 information for those elements. Another group of transformations 397 provide access to particular data elements in the presence document. 399 3.3.1. Providing Access to Data Component Elements 401 The transformations in this section provide access to person, device 402 and service data component elements. Once access has been granted to 403 such an element, access to specific presence attributes for that 404 element is controlled by the permissions defined in Section 3.3.2. 406 3.3.1.1. Device Information 408 The permission allows a watcher to see 409 information present in the presence document. It is a set variable. 410 Each member of the set provides a way to identify a device or group 411 of devices. This specification defines three types of elements in 412 the set - , which identifies a device occurrence by class, 413 , which identifies a device occurrence by device ID, and 414 , which identifies a device occurrence by occurrence 415 ID. The device ID and occurrence ID are defined in [11]. Each 416 member of the set is identified by its type (class, deviceID or 417 occurrence-id) and value (value of the class, value of the deviceID, 418 or value of the occurrence-id). 420 For example, consider the following element: 422 423 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 424 biz 425 427 This set has two members. This is combined with a 428 element from a different rule: 430 431 home 432 biz 433 435 The result of the set combination (using the union operation) is a 436 set with three elements: 438 439 home 440 biz 441 urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 442 444 The element can also take on the special value 445 which is a short-hand notation for all device 446 occurrences present in the presence document. 448 Permission is granted to see a particular device occurrence if one of 449 the device identifiers in the set identifies that device occurrence. 450 If a permission is granted to the watcher, and the of 451 the device occurrence matches the value of the permission 452 based on case sensitive equality, the device occurrence is included 453 in the presence document. If a permission is granted to 454 the watcher, and the of the device occurrence matches the 455 value of the permission based on URI equivalence, the 456 device occurrence is included in the presence document. If a 457 permission is granted to the watcher, and the 458 of the device occurrence matches the value of the 459 permission based on case sensitive equality, the 460 device occurrence is included in the presence document. In addition, 461 a device occurrence is included in the presence document if the permission was granted to the watcher. 464 3.3.1.2. Person Information 466 The permission allows a watcher to see the 467 information present in the presence document. It is a set variable. 468 Each member of the set provides a way to identify a person 469 occurrence. This specification defines two types of elements in the 470 set - , which identifies a person occurrence by class, and 471 , which identifies an occurrence by its occurrence ID. 472 Each member of the set is identified by its type (class or 473 occurrence-id) and value (value of the class or value of the 474 occurrence-id). The element can also take on the 475 special value which is a short-hand notation for all 476 person occurrences present in the presence document. The set 477 combination is done identically to the element. 479 Permission is granted to see a particular person occurrence if one of 480 the person identifiers in the set identifies that person occurrence. 481 If a permission is granted to the watcher, and the of 482 the person occurrence matches the value of the permission 483 based on case sensitive equality, the person occurrence is included 484 in the presence document. If a permission is granted 485 to the watcher, and the of the person occurrence 486 matches the value of the permission based on case 487 sensitive equality, the person occurrence is included in the presence 488 document. In addition, a person occurrence is included in the 489 presence document if the permission was granted to the 490 watcher. 492 3.3.1.3. Service Information 494 The permission allows a watcher to see service 495 information present in elements in the presence document. 496 Like , it is a set variable. Each member of the set 497 provides a way to identify a service occurrence. This specification 498 defines four types of elements in the set - , which identifies 499 a service occurrence by class, , which identifies a 500 service by its occurrence ID, , which identifies a 501 service by its service URI, and , which 502 identifies a service by its service URI scheme. Each member of the 503 set is identified by its type (class, occurrence-id, service-uri or 504 service-uri-scheme) and value (value of the class, value of the 505 occurrence-id, value of the service-uri or value of the service-uri- 506 scheme ). The element can also take on the 507 special value which is a short-hand notation for all 508 service occurrences present in the presence document. The set 509 combination is done identically to the element. 511 Permission is granted to see a particular service occurrence if one 512 of the service identifiers in the set identifies that service 513 occurrence. If a permission is granted to the watcher, and 514 the of the service occurrence matches the value of the 515 permission based on case sensitive equality, the service 516 occurrence is included in the presence document. If a 517 permission is granted to the watcher, and the of the 518 service occurrence matches the value of the permission 519 based on URI equivalence, the service occurrence is included in the 520 presence document. If a permission is granted to the 521 watcher, and the of the service occurrence matches 522 the value of the permission based on case sensitive 523 equality, the service occurrence is included in the presence 524 document. If a permission is granted to the 525 watcher, and the scheme of the service URI for the service occurrence 526 matches the value of based on case sensitive 527 equality, the service occurrence is included in the presence 528 document. In addition, a service occurrence is included in the 529 presence document if the permission was granted to the 530 watcher. 532 3.3.2. Providing Access to Presence Attributes 534 The permissions of Section 3.3.1 provide coarse grained access to 535 presence data by allowing or blocking specific services or devices, 536 and allowing or blocking person information. 538 Once person, device or service information is included in the 539 document, the permissions in this section define which presence 540 attributes are reported there. Certain information is always 541 reported. In particular, the , [9], 542 status and elements in all elements, if present, 543 are provided to watchers . The element in all 544 elements, if present, is provided to watchers. The and 545 elements in all elements, if present, is provided 546 to all watchers. 548 3.3.2.1. Provide Activities 550 This permission controls access to the element defined 551 in [9]. The name of the element providing this permission is 552 , and it is a boolean type. If its value is 553 TRUE, then the element in the person data element is 554 reported to the watcher. If FALSE, this presence attribute is 555 removed if present. 557 3.3.2.2. Provide Class 559 This permission controls access to the element defined in 560 [9]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then any 562 element in a person, service or device data element is 563 reported to the watcher. If FALSE, this presence attribute is 564 removed if present. 566 3.3.2.3. Provide DeviceID 568 This permission controls access to the element in a 569 element, as defined in [9]. The name of the element 570 providing this permission is , and it is a boolean 571 type. If its value is TRUE, then the element in the 572 service data element is reported to the watcher. If FALSE, this 573 presence attribute is removed if present. Note that the 574 in a device data element is always included, and not controlled by 575 this permission. 577 3.3.2.4. Provide Mood 579 This permission controls access to the element defined in [9]. 581 The name of the element providing this permission is , 582 and it is a boolean type. If its value is TRUE, then the 583 element in the person data element is reported to the watcher. If 584 FALSE, this presence attribute is removed if present. 586 3.3.2.5. Provide Place-is 588 This permission controls access to the element defined in 589 [9]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the 591 element in the person data element is reported to the 592 watcher. If FALSE, this presence attribute is removed if present. 594 3.3.2.6. Provide Place-type 596 This permission controls access to the element defined 597 in [9]. The name of the element providing this permission is 598 , and it is a boolean type. If its value is 599 TRUE, then the element in the person data element is 600 reported to the watcher. If FALSE, this presence attribute is 601 removed if present. 603 3.3.2.7. Provide Privacy 605 This permission controls access to the element defined in 606 [9]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the 608 element in the person or service data element is reported 609 to the watcher. If FALSE, this presence attribute is removed if 610 present. 612 3.3.2.8. Provide Relationship 614 This permission controls access to the element defined 615 in [9]. The name of the element providing this permission is 616 , and it is a boolean type. If its value is 617 TRUE, then the element in the service data element is 618 reported to the watcher. If FALSE, this presence attribute is 619 removed if present. 621 3.3.2.9. Provide Sphere 623 This permission controls access to the element defined in 624 [9]. The name of the element providing this permission is , and it is a boolean type. If its value is TRUE, then the 626 element in the person data element is reported to the 627 watcher. If FALSE, this presence attribute is removed if present. 629 3.3.2.10. Provide Status-Icon 631 This permission controls access to the element defined 632 in [9]. The name of the element providing this permission is 633 , and it is a boolean type. If its value is 634 TRUE, then any element in the person or service data 635 element is reported to the watcher. If FALSE, this presence 636 attribute is removed if present. 638 3.3.2.11. Provide Time-Offset 640 This permission controls access to the element defined 641 in [9]. The name of the element providing this permission is 642 , and it is a boolean type. If its value is 643 TRUE, then the element in the person data element is 644 reported to the watcher. If FALSE, this presence attribute is 645 removed if present. 647 3.3.2.12. Provide User-Input 649 This permission controls access to the element defined 650 in [9]. The name of the element providing this permission is 651 , and it is an enumerated integer type. Its 652 value defines what information is provided to watchers in person, 653 device or service data elements: 655 false: This value indicates that the element is removed 656 from the document. It is assigned the numeric value of 0. 658 bare: This value indicates that the element is to be 659 retained. However, any "idle-threshold" and "since" attributes 660 are to be removed. This value is assigned the numeric value of 661 10. 663 thresholds: This value indicates that the element is to 664 be retained. However, only the "idle-threshold" attribute is to 665 be retained. This value is assigned to the numeric value of 20. 667 full: This value indicates that the element is to be 668 retained, including any attributes. This value is assigned to the 669 numeric value of 30. 671 3.3.2.13. Provide Note 673 This permission controls access to the element defined in [3] 674 for and [11] for and . The name of the 675 element providing this permission is , and it is a 676 boolean type. If its value is TRUE, then any elements in the 677 person, service or device data elements are reported to the watcher. 678 If FALSE, this presence attribute is removed if present. 680 This permission has no bearing on any values present within 681 , , , , , 682 or elements. Notes there are 683 essentially values for their respective elements, and are present if 684 the respective element is permitted in the presence document. For 685 example, if an element is present in a presence 686 document, and there is a value for it, that note is present in 687 the document sent to the watcher if the 688 permission is given, regardless of whether the 689 permission is given. 691 3.3.2.14. Provide Unknown Attribute 693 It is important that systems be allowed to include proprietary or new 694 presence information, and that users be able to set permissions for 695 that information, without requiring an upgrade of the presence server 696 and authorization system. For this reason, the permission is defined. This permission indicates that the 698 unknown presence attribute with the given name and namespace 699 (supplied as mandatory attributes of the 700 element) should be included in the document. Its type is boolean. 702 The value of the name attribute MUST be an unqualified element name 703 (meaning that a namespace prefix MUST NOT be included), and the the 704 value of the ns attribute MUST be a namespace URI. The two are 705 combined to form a qualified element name, which will be matched to 706 all unknown child elements of the PIDF , or 707 elements with the same qualified name. In this context, "unknown" 708 means that the presence server is not aware of any schemas that 709 define authorization policies for that element. By definition, this 710 will exclude the rule from being applied 711 to any of the presence status extensions defined by RPID, since 712 authorization policies for those are defined here. 714 Another consequence of this definition is that the interpretation of 715 the element can change should the 716 presence server be upgraded. For example, consider a server which, 717 prior to the upgrade, had an authorization document that used 718 for some attribute, say foo. This 719 attribute was from a namespace and schema unknown to the server, and 720 so the attribute was provided to watchers. However, after upgrade, 721 the server is now aware of a new namespace and schema for a 722 permission that grants access to the foo attribute. Now, the 723 permission for the foo attribute will be 724 ignored, resulting in a removal of those elements from presence 725 documents sent to watchers. The system remains privacy safe, but 726 behavior might not be as expected. Developers of systems which allow 727 clients to set policies are advised to check the capabilities of the 728 server, (using mechanisms like those defined in [17], for example) 729 before uploading a new authorization document, to make sure that the 730 behavior will be as expected. 732 3.3.2.15. Provide All Attributes 734 This permission grants access to all presence attributes in all of 735 the person, device and tuple elements that are present in the 736 document (the ones present in the document are determined by the 737 , and 738 permissions). It is effectively a macro that expands into a set of 739 provide-activities, provide-class, provide-deviceID, provide-mood, 740 provide-place-is, provide-place-type, provide-privacy, provide- 741 relationship, provide-sphere, provide-status-icon, provide-time- 742 offset, provide-user-input, provide-note and provide-unknown- 743 attribute permissions such that each presence attribute in the 744 document has a permission for it. This implies that, so long as an 745 entire person, service or device occurrence is provided, every single 746 presence attribute, including ones not known to the server and/or 747 defined in future presence document extensions, is granted to the 748 watcher. 750 4. When to Apply the Authorization Policies 752 This specification does not mandate at what point in the processing 753 of presence data the privacy filtering aspects of the authorization 754 policy are applied. However, they must be applied such that the 755 final presence document sent to the watcher is compliant to the 756 privacy policy described in the document. More concretely, if the 757 document sent to a watcher is D, and the privacy filtering operation 758 applied do a presence document x is F(x), then D MUST have the 759 property that D = F(D). In other words, further applications of the 760 privacy filtering operation would not result in any further changes 761 of the document, making further application of the filtering 762 operation a no-op. A corollary of this is that F(F(D)) = D for all 763 D. 765 The subscription processing aspects of the document get applied by 766 the server when it decides to accept or reject the subscription. 768 5. Example Document 770 The following presence authorization document specifies permissions 771 for the user "user@example.com". The watcher is allowed to access 772 presence information (the 'allow' value for ). They 773 will be granted access to all services whose contact URI schemes are 774 sip and mailto. Person information is also provided. However, since 775 there is no , no device information will be given to 776 the watcher. Within the service and person information provided to 777 the watcher, the element will be shown, as will the 778 element. However, any "idle-threshold" and "since" 779 attributes in the element will be removed. Finally, the 780 presence attribute will be shown to the watcher. Any other 781 presence attributes will be removed. 783 784 787 788 789 790 791 792 793 794 allow 795 796 797 798 sip 799 mailto 800 801 802 803 804 true 805 bare 806 true 809 810 811 813 6. XML Schema 814 815 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 880 882 884 886 888 890 892 894 896 898 900 902 903 904 905 906 907 908 909 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 934 935 936 937 939 7. Schema Extensibility 941 It is anticipated that future changes to this specification are 942 accomplished through extensions that define new types of permissions. 943 These extensions MUST exist within a different namespace. 944 Furthermore, the schema defined above and the namespace for elements 945 defined within it MUST NOT be altered by future specifications. 946 Changes in the basic schema, or in the interpretation of elements 947 within that schema, may result in violations of user privacy due to 948 mis-interpretation of documents. 950 8. XCAP Usage 952 The following section defines the details necessary for clients to 953 manipulate presence authorization documents from a server using XCAP. 955 8.1. Application Unique ID 957 XCAP requires application usages to define a unique application usage 958 ID (AUID) in either the IETF tree or a vendor tree. This 959 specification defines the "pres-rules" AUID within the IETF tree, via 960 the IANA registration in Section 10. 962 8.2. XML Schema 964 XCAP requires application usages to define a schema for their 965 documents. The schema for presence authorization documents is in 966 Section 6. 968 8.3. Default Namespace 970 XCAP requires application usages to define the default namespace for 971 their documents. The default namespace is 972 urn:ietf:params:xml:ns:pres-rules. 974 8.4. MIME Type 976 XCAP requires application usages to defined the MIME type for 977 documents they carry. Presence authorization documents inherit the 978 MIME type of common policy documents, application/auth-policy+xml. 980 8.5. Validation Constraints 982 There are no additional constraints defined by this specification. 984 8.6. Data Semantics 986 Semantics of a presence authorization document are discussed in 987 Section 3. 989 8.7. Naming Conventions 991 When a presence agent receives a subscription for some user foo 992 within a domain, it will look for all documents within http://[xcap 993 root]/pres-rules/users/foo, and use all documents found beneath that 994 point to guide authorization policy. If only a single document is 995 used, it SHOULD be called "index". 997 8.8. Resource Interdependencies 999 There are no additional resource interdependencies defined by this 1000 application usage. 1002 8.9. Authorization Policies 1004 This application usage does not modify the default XCAP authorization 1005 policy, which is that only a user can read, write or modify their own 1006 documents. A server can allow priveleged users to modify documents 1007 that they don't own, but the establishment and indication of such 1008 policies is outside the scope of this document. 1010 9. Security Considerations 1012 Presence authorization policies contain very sensitive information. 1013 They indicate which other users are "liked" or "disliked" by a user. 1014 As such, when these documents are transported over a network, they 1015 SHOULD be encrypted. 1017 Modification of these documents by an attacker can disrupt the 1018 service seen by a user, often in subtle ways. As a result, when 1019 these documents are transported, the transport SHOULD provide 1020 authenticity and message integrity. 1022 In the case where XCAP is used to transfer the document, clients 1023 SHOULD use HTTP over TLS, and servers SHOULD define the root services 1024 URI as an https URI. The server SHOULD authenticate the client over 1025 the resulting TLS connection using HTTP digest. 1027 10. IANA Considerations 1029 There are several IANA considerations associated with this 1030 specification. 1032 10.1. XCAP Application Usage ID 1034 This section registers an XCAP Application Usage ID (AUID) according 1035 to the IANA procedures defined in [2]. 1037 Name of the AUID: pres-rules 1039 Description: Presence rules are documents that describe the 1040 permissions that a presentity [16] has granted to users that seek 1041 to watch their presence. 1043 10.2. URN Sub-Namespace Registration 1045 This section registers a new XML namespace, per the guidelines in 1046 [12] 1047 URI: The URI for this namespace is 1048 urn:ietf:params:xml:ns:pres-rules. 1050 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1051 Jonathan Rosenberg (jdrosen@jdrosen.net). 1053 XML: 1055 BEGIN 1056 1057 1059 1060 1061 1063 Presence Rules Namespace 1064 1065 1066

Namespace for Permission Statements

1067

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

1068

See RFCXXXX.

1069 1070 1071 END 1073 10.3. XML Schema Registrations 1075 This section registers an XML schema per the procedures in [12]. 1077 URI: urn:ietf:params:xml:schema:pres-rules. 1079 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1080 Jonathan Rosenberg (jdrosen@jdrosen.net). 1082 The XML for this schema can be found as the sole content of 1083 Section 6. 1085 11. Acknowledgements 1087 The authors would like to thank Richard Barnes, Jari Urpalainen, and 1088 Martin Hynar for their comments. 1090 12. References 1091 12.1. Normative References 1093 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1094 Levels", BCP 14, RFC 2119, March 1997. 1096 [2] Rosenberg, J., "The Extensible Markup Language (XML) 1097 Configuration Access Protocol (XCAP)", 1098 draft-ietf-simple-xcap-11 (work in progress), May 2006. 1100 [3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 1101 J. Peterson, "Presence Information Data Format (PIDF)", 1102 RFC 3863, August 2004. 1104 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1105 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 1106 Basic and Digest Access Authentication", RFC 2617, June 1999. 1108 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1109 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1110 Session Initiation Protocol", RFC 3261, June 2002. 1112 [6] Rosenberg, J., "A Watcher Information Event Template-Package 1113 for the Session Initiation Protocol (SIP)", RFC 3857, 1114 August 2004. 1116 [7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1117 Notification", RFC 3265, June 2002. 1119 [8] Schulzrinne, H., "Common Policy: An XML Document Format for 1120 Expressing Privacy Preferences", 1121 draft-ietf-geopriv-common-policy-10 (work in progress), 1122 May 2006. 1124 [9] Schulzrinne, H., "RPID: Rich Presence Extensions to the 1125 Presence Information Data Format (PIDF)", 1126 draft-ietf-simple-rpid-10 (work in progress), December 2005. 1128 [10] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1129 Identity Management in the Session Initiation Protocol (SIP)", 1130 draft-ietf-sip-identity-06 (work in progress), October 2005. 1132 [11] Rosenberg, J., "A Data Model for Presence", 1133 draft-ietf-simple-presence-data-model-07 (work in progress), 1134 January 2006. 1136 [12] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1137 January 2004. 1139 [13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 1140 December 2004. 1142 [14] Duerst, M. and M. Suignard, "Internationalized Resource 1143 Identifiers (IRIs)", RFC 3987, January 2005. 1145 [15] Peterson, J., "A Privacy Mechanism for the Session Initiation 1146 Protocol (SIP)", RFC 3323, November 2002. 1148 12.2. Informative References 1150 [16] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 1151 and Instant Messaging", RFC 2778, February 2000. 1153 [17] Rosenberg, J., "An Extensible Markup Language (XML) 1154 Representation for Expressing Presence Policy Capabilities", 1155 draft-ietf-simple-pres-policy-caps-00 (work in progress), 1156 July 2005. 1158 [18] Rosenberg, J., "A Presence Event Package for the Session 1159 Initiation Protocol (SIP)", RFC 3856, August 2004. 1161 [19] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 1162 to the Session Initiation Protocol (SIP) for Asserted Identity 1163 within Trusted Networks", RFC 3325, November 2002. 1165 Author's Address 1167 Jonathan Rosenberg 1168 Cisco Systems 1169 600 Lanidex Plaza 1170 Parsippany, NJ 07054 1171 US 1173 Phone: +1 973 952-5000 1174 Email: jdrosen@cisco.com 1175 URI: http://www.jdrosen.net 1177 Intellectual Property Statement 1179 The IETF takes no position regarding the validity or scope of any 1180 Intellectual Property Rights or other rights that might be claimed to 1181 pertain to the implementation or use of the technology described in 1182 this document or the extent to which any license under such rights 1183 might or might not be available; nor does it represent that it has 1184 made any independent effort to identify any such rights. Information 1185 on the procedures with respect to rights in RFC documents can be 1186 found in BCP 78 and BCP 79. 1188 Copies of IPR disclosures made to the IETF Secretariat and any 1189 assurances of licenses to be made available, or the result of an 1190 attempt made to obtain a general license or permission for the use of 1191 such proprietary rights by implementers or users of this 1192 specification can be obtained from the IETF on-line IPR repository at 1193 http://www.ietf.org/ipr. 1195 The IETF invites any interested party to bring to its attention any 1196 copyrights, patents or patent applications, or other proprietary 1197 rights that may cover technology that may be required to implement 1198 this standard. Please address the information to the IETF at 1199 ietf-ipr@ietf.org. 1201 Disclaimer of Validity 1203 This document and the information contained herein are provided on an 1204 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1205 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1206 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1207 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1208 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1209 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1211 Copyright Statement 1213 Copyright (C) The Internet Society (2006). This document is subject 1214 to the rights, licenses and restrictions contained in BCP 78, and 1215 except as set forth therein, the authors retain all their rights. 1217 Acknowledgment 1219 Funding for the RFC Editor function is currently provided by the 1220 Internet Society.