idnits 2.17.1 draft-ietf-geopriv-common-policy-11.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 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1429. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 384: '...e information delivered to the WR MUST...' RFC 2119 keyword, line 409: '...que token chosen by the RM. A RM MUST...' RFC 2119 keyword, line 423: '... MUST define its own namespace....' RFC 2119 keyword, line 519: '... Common policy MUST either use UTF-8...' RFC 2119 keyword, line 520: '...r non-IDNs, lower-case ASCII SHOULD be...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 906 has weird spacing: '... sphere from ...' == Line 909 has weird spacing: '... alice wor...' == Line 1070 has weird spacing: '...:choice minOc...' -- 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 (August 10, 2006) is 6469 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 3490 (ref. '3') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4288 (ref. '5') (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-rules-07 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-08 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV H. Schulzrinne 3 Internet-Draft Columbia U. 4 Intended status: Standards Track H. Tschofenig 5 Expires: February 11, 2007 Siemens 6 J. Morris 7 CDT 8 J. Cuellar 9 Siemens 10 J. Polk 11 Cisco 12 J. Rosenberg 13 Cisco Systems 14 August 10, 2006 16 Common Policy: A Document Format for Expressing Privacy Preferences 17 draft-ietf-geopriv-common-policy-11.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on February 11, 2007. 44 Copyright Notice 46 Copyright (C) The Internet Society (2006). 48 Abstract 50 This document defines a framework for authorization policies 51 controlling access to application specific data. This framework 52 combines common location- and presence-specific authorization 53 aspects. An XML schema specifies the language in which common policy 54 rules are represented. The common policy framework can be extended 55 to other application domains. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Modes of Operation . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1. Passive Request-Response - PS as Server (Responder) . . . 7 63 3.2. Active Request-Response - PS as Client (Initiator) . . . . 7 64 3.3. Event Notification . . . . . . . . . . . . . . . . . . . . 7 65 4. Goals and Assumptions . . . . . . . . . . . . . . . . . . . . 9 66 5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 6. Basic Data Model and Processing . . . . . . . . . . . . . . . 12 68 6.1. Identification of Rules . . . . . . . . . . . . . . . . . 13 69 6.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7.1. Identity Condition . . . . . . . . . . . . . . . . . . . . 14 72 7.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 14 73 7.1.2. Matching One Entity . . . . . . . . . . . . . . . . . 14 74 7.1.3. Matching Multiple Entities . . . . . . . . . . . . . . 15 75 7.2. Single Entity . . . . . . . . . . . . . . . . . . . . . . 19 76 7.3. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 7.4. Validity . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 8. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 9. Transformations . . . . . . . . . . . . . . . . . . . . . . . 24 80 10. Procedure for Combining Permissions . . . . . . . . . . . . . 25 81 10.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 25 82 10.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 25 83 10.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 11. Meta Policies . . . . . . . . . . . . . . . . . . . . . . . . 29 85 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 86 13. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 31 87 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 88 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 89 15.1. Common Policy Namespace Registration . . . . . . . . . . . 35 90 15.2. Content-type registration for 91 'application/auth-policy+xml' . . . . . . . . . . . . . . 35 92 15.3. Common Policy Schema Registration . . . . . . . . . . . . 37 93 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 94 16.1. Normative References . . . . . . . . . . . . . . . . . . . 38 95 16.2. Informative References . . . . . . . . . . . . . . . . . . 38 96 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 39 97 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 99 Intellectual Property and Copyright Statements . . . . . . . . . . 43 101 1. Introduction 103 This document defines a framework for creating authorization policies 104 for access to application specific data. This framework is the 105 result of combining the common aspects of single authorization 106 systems that more specifically control access to presence and 107 location information and that previously had been developed 108 separately. The benefit of combining these two authorization systems 109 is two-fold. First, it allows to build a system which enhances the 110 value of presence with location information in a natural way and 111 reuses the same underlying authorization mechanism. Second, it 112 encourages a more generic authorization framework with mechanisms for 113 extensibility. The applicability of the framework specified in this 114 document is not limited to policies controling access to presence and 115 location information data, but can be extended to other application 116 domains. 118 The general framework defined in this document is intended to be 119 accompanied and enhanced by application-specific policies specified 120 elsewhere. The common policy framework described here is enhanced by 121 domain-speific policy documents, including presence [7] and location 122 [8]. This relationship is shown in Figure 1. 124 +-----------------+ 125 | | 126 | Common | 127 | Policy | 128 | | 129 +---+---------+---+ 130 /|\ /|\ 131 | | 132 +-------------------+ | | +-------------------+ 133 | | | enhance | | | 134 | Location-specific | | | | Presence-specific | 135 | Policy |----+ +----| Policy | 136 | | | | 137 +-------------------+ +-------------------+ 139 Figure 1: Common Policy Enhancements 141 This document starts with an introduction to the terminology in 142 Section 2, an illustration of basic modes of operation in Section 3, 143 a description of goals (see Section 4) and non-goals (see Section 5) 144 of the policy framework, followed by the data model in Section 6. 145 The structure of a rule, namely conditions, actions and 146 transformations, are described in Section 7, in Section 8 and in 147 Section 9. The procedure for combining permissions is explained in 148 Section 10 and used when more than one rule fires. A short 149 description of meta policies is given in Section 11. An example is 150 provided in Section 12. The XML schema will be discussed in 151 Section 13. IANA considerations in Section 15 follow security 152 considerations Section 14. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [1]. 160 This document introduces the following terms: 162 PT - Presentity / Target: The PT is the entity about whom 163 information has been requested. 165 RM - Rule Maker: RM is an entity which creates the authorization 166 rules which restrict access to data items. 168 PS - (Authorization) Policy Server: This entity has access to both 169 the authorization policies and to the data items. In location- 170 specific applications, the entity PS is labeled as location server 171 (LS). 173 WR - Watcher / Recipient: This entity requests access to data items 174 of the PT. An access operation might be either be a read, write 175 or be any other operation. In case of access to location 176 information it might be a read operation. 178 A policy is given by a 'rule set' that contains an unordered list of 179 'rules'. A 'rule' has a 'conditions', an 'actions' and a 180 'transformations' part. 182 The term 'permission' indicates the action and transformation 183 components of a 'rule'. 185 The term 'using protocol' is defined in [9]. It refers to the 186 protocol which is used to request access to and to return privacy 187 sensitive data items. 189 3. Modes of Operation 191 The abstract sequence of operations can roughly be described as 192 follows. The PS receives a query for data items for a particular PT, 193 via the using protocol. The using protocol (or more precisely the 194 authentication protocol) provides the identity of the requestor, 195 either at the time of the query or at the subscription time. The 196 authenticated identity of the WR, together with other information 197 provided by the using protocol or generally available to the server, 198 is then used for searching through the rule set. All matching rules 199 are combined according to a permission combining algorithm described 200 in Section 10. The combined rules are applied to the application 201 data, resulting in the application of privacy based on the 202 transformation policies. The resulting application data is returned 203 to the WR. 205 Three different modes of operation can be distinguished: 207 3.1. Passive Request-Response - PS as Server (Responder) 209 In a passive request-response mode, the WR queries the PS for data 210 items about the PT. Examples of protocols following this mode of 211 operation include HTTP, FTP, LDAP, finger or various RPC protocols, 212 including Sun RPC, DCE, DCOM, Corba and SOAP. The PS uses the 213 ruleset to determine whether the WR is authorized to access the PTs 214 information, refusing the request if necessary. Furthermore, the PS 215 might filter information by removing elements or by reducing the 216 resolution of elements. 218 3.2. Active Request-Response - PS as Client (Initiator) 220 Alternatively, the PS may contact the WR and convey data items. 221 Examples include HTTP, SIP session setup (INVITE request), H.323 222 session setup or SMTP. 224 3.3. Event Notification 226 Event notification adds a subscription phase to the "Active Request- 227 Response - PS as Client (Initiator)" mode of operation. A watcher or 228 subscriber asks to be added to the notification list for a particular 229 presentity or event. When the presentity changes state or the event 230 occurs, the PS sends a message to the WR containing the updated 231 state. (Presence is a special case of event notification; thus, we 232 often use the term interchangeably.) 234 In addition, the subscriber may itself add a filter to the 235 subscription, limiting the rate or content of the notifications. If 236 an event, after filtering by the rulemaker-provided rules and by the 237 subscriber-provided rules, only produces the same notification 238 content that was sent previously, no event notification is sent. 240 A single PS may authorize access to data items in more than one mode. 241 Rather than having different rule sets for different modes all three 242 modes are supported with a one rule set schema. Specific instances 243 of the rule set can omit elements that are only applicable to the 244 subscription model. 246 4. Goals and Assumptions 248 Below, we summarize our design goals and constraints. 250 Table representation: 252 Each rule must be representable as a row in a relational database. 253 This design goal should allow efficient policy implementation by 254 utilizing standard database optimization techniques. 256 Permit only: 258 Rules only provide permissions rather than denying them. Removing 259 a rule can never increase permissions. Allowing both 'permit' and 260 'deny' actions would require some rule ordering which had 261 implications on the update operations executed on these rules. 262 Additionally, it would make distributed rule sets more 263 complicated. Hence, only 'permit' actions are allowed which 264 result in more efficient rule processing. This also implies that 265 rule ordering is not important. Consequently, to make a policy 266 decision requires processing all rules. 268 Additive permissions: 270 A query for access to data items is matched against the rules in 271 the rule database. If several rules match, then the overall 272 permissions granted to the WR are the union of those permissions. 273 A more detailed discussion is provided inSection 10. 275 Upgradeable: 277 It should be possible to add additional rules later, without 278 breaking PSs that have not been upgraded. Any such upgrades must 279 not degrade privacy constraints, but PSs not yet upgraded may 280 reveal less information than the rulemaker would have chosen. 282 Capability support: 284 In addition to the previous goal, a RM should be able to determine 285 which extensions are supported by the PS. The mechanism used to 286 determine the capability of a PS is outside the scope of this 287 specification. 289 Protocol-independent: 291 The rule set supports constraints on both notifications or queries 292 as well as subscriptions for event-based systems such as presence 293 systems. 295 No false assurance: 297 It appears more dangerous to give the user the impression that the 298 system will prevent disclosure automatically, but fail to do so 299 with a significant probability of operator error or 300 misunderstanding, than to force the user to explicitly invoke 301 simpler rules. For example, rules based on weekday and time-of- 302 day ranges seem particularly subject to misinterpretation and 303 false assumptions on part of the RM. (For example, a non- 304 technical RM would probably assume that the rules are based on the 305 timezone of his current location, which may not be known to other 306 components of the system.) 308 5. Non-Goals 310 We explicitly decided that a number of possibly worthwhile 311 capabilities are beyond the scope of this first version. Future 312 versions may include these capabilities, using the extension 313 mechanism described in this document. Non-goals include: 315 No external references: 317 Attributes within specific rules cannot refer to external rule 318 sets, databases, directories or other network elements. Any such 319 external reference would make simple database implementation 320 difficult and hence they are not supported in this version. 322 No regular expression: 324 Conditions are matched on equality or 'greater-than'-style 325 comparisons, not regular expressions, partial matches such as the 326 SQL LIKE operator (e.g., LIKE "%foo%") or glob-style matches 327 ("*@example.com"). Most of these are better expressed as explicit 328 elements. 330 No repeat times: 332 Repeat times (e.g., every day from 9am to 4pm) are difficult to 333 make work correctly, due to the different time zones that PT, WR, 334 PS and RM may occupy. It appears that suggestions for including 335 time intervals are often based on supporting work/non-work 336 distinctions, which unfortunately are difficult to capture by time 337 alone. Note that this feature must not be confused with the 338 'Validity' element that provides a mechanism to restrict the 339 lifetime of a rule. 341 6. Basic Data Model and Processing 343 A rule set (or synonymously, a policy) consists of zero or more 344 rules. The ordering of these rules is irrelevant. The rule set can 345 be stored at the PS and conveyed from RM to PS as a single document, 346 in subsets or as individual rules. A rule consists of three parts - 347 conditions (see Section 7), actions (see Section 8), and 348 transformations (see Section 9). 350 The conditions part is a set of expressions, each of which evaluates 351 to either TRUE or FALSE, i.e. each of which is equipped with a value 352 of either TRUE or FALSE by the PS. When a WR asks for information 353 about a PT, the PS goes through each rule in the rule set. For each 354 rule, it evaluates the expressions in the conditions part. If all of 355 the expressions evaluate to TRUE, then the rule is applicable to this 356 request. Generally, each expression specifies a condition based on 357 some variable that is associated with the context of the request. 358 These variables can include the identity of the WR, the domain of the 359 WR, the time of day, or even external variables, such as the 360 temperature or the mood of the PT. 362 Assuming that the rule is applicable to the request, the actions and 363 transformations (commonly referred to as permissions) in the rule 364 specify how the PS is supposed to handle this request. If the 365 request is to view the location of the PT, or to view its presence, 366 the typical action is "permit", which allows the request to proceed. 368 Assuming the action allows the request to proceed, the 369 transformations part of the rule specifies how the information about 370 the PT - their location information, their presence, etc. - is 371 modified before being presented to the WR. These transformations are 372 in the form of positive permissions. That is, they always specify a 373 piece of information which is allowed to be seen by the WR. When a 374 PS processes a request, it takes the transformations specified across 375 all rules that match, and creates the union of them. For computing 376 this union the data type, such as Integer, Boolean, Set, or the Undef 377 data type, plays a role. The details of the algorithm for combining 378 permissions is described in Section 10. The resulting union 379 effectively represents a "mask" - it defines what information is 380 exposed to the WR. This mask is applied to the actual location or 381 presence data for the PT, and the data which is permitted by the mask 382 is shown to the WR. If the WR request a subset of information only 383 (such as city-level civil location data only, instead of the full 384 civil location information), the information delivered to the WR MUST 385 be the intersection of the permissions granted to the WR and the data 386 requested by the WR. 388 In accordance to this document, rules are encoded in XML. To this 389 end, Section 13 contains an XML schema defining the Common Policy 390 Markup Language. This, however, is purely an exchange format between 391 RM and PS. The format does not imply that the RM or the PS use this 392 format internally, e.g., in matching a query with the policy rules. 393 The rules are designed so that a PS can translate the rules into a 394 relational database table, with each rule represented by one row in 395 the database. The database representation is by no means mandatory; 396 we will use it as a convenient and widely-understood example of an 397 internal representation. The database model has the advantage that 398 operations on rows have tightly defined meanings. In addition, it 399 appears plausible that larger-scale implementations will employ a 400 backend database to store and query rules, as they can then benefit 401 from existing optimized indexing, access control, scaling and 402 integrity constraint mechanisms. Smaller-scale implementations may 403 well choose different implementations, e.g., a simple traversal of 404 the set of rules. 406 6.1. Identification of Rules 408 Each rule is equipped with a parameter that identifies the rule. 409 This rule identifier is an opaque token chosen by the RM. A RM MUST 410 NOT use the same identifier for two rules that are available to the 411 PS at the same time for a given PT. If more than one RM modifies the 412 same rule set then it needs to be ensured that a unique identifier is 413 chosen for each rule. A RM can accomplish this goal by retrieving 414 the already specified ruleset and to choose a new identifier for a 415 rule that is different from the existing rule set. 417 6.2. Extensions 419 The policy framework defined in this document is meant to be 420 extensible towards specific application domains. Such an extension 421 is accomplished by defining conditions, actions and transformations 422 that are specific to the desired application domain. Each extension 423 MUST define its own namespace. 425 Extensions cannot change the schema defined in this document, and 426 this schema is not expected to change excepting a revision to this 427 specification, and that no versioning procedures for this schema or 428 namespace are therfore provided. 430 7. Conditions 432 The access to data items needs to be matched with the rule set stored 433 at the PS. Each instance of a request has different attributes 434 (e.g., the identity of the requestor) that are used for 435 authorization. A rule in a rule set might have a number of 436 conditions that need to be met before executing the remaining parts 437 of a rule (i.e., actions and transformations). Details about rule 438 matching are described in Section 10. This document specifies only a 439 few conditions (i.e., identity, sphere, and validity). Further 440 condition elements can be added via extensions to this document. 442 As noted in Section 5, conditions are matched on equality or "greater 443 than" style comparisons, rather than regular expressions. Equality 444 is determined according to the rules for the data type associated 445 with the element in the schema given in Section 13, unless explicit 446 comparison steps are included in this document. For xs:anyURI types, 447 readers may wish to consult [2] for its discussion xs:anyURI, as well 448 as the text in Section 13. 450 7.1. Identity Condition 452 7.1.1. Overview 454 The identity condition restricts matching of a rule either to a 455 single entity or a group of entitites. Only authenticated entities 456 can be matched; acceptable means of authentication are defined in 457 protocol-specific documents. If the element is absent, or 458 it is present but is empty (meaning that there are no child 459 elements), identities are not considered, and thus, other conditions 460 in the rule apply to any user, authenticated or not. 462 The condition is considered TRUE if any of its child 463 elements (e.g., the and the elements defined in this 464 document) evaluate to TRUE, i.e., the results of the individual child 465 element are combined using a logical OR. 467 If a child element of is in a namespace that is not known 468 or not supported, it can be ignored. 470 7.1.2. Matching One Entity 472 The element matches the authenticated identity (as contained in 473 the 'id' attribute) of exactly one entity or user. For 474 considerations regarding the 'id' attribute refer to Section 7.2. 476 An example is shown below: 478 479 481 482 483 484 485 486 487 488 489 490 491 493 495 This example matches if the authenticated identity of the WR is 496 either sip:alice@example.com, tel:+1-212-555-1234 or 497 mailto:bob@example.net. 499 7.1.3. Matching Multiple Entities 501 The element is a mechanism to perform authorization decisions 502 based on the domain part of the authenticated identity. As such, it 503 allows to match a large and possibly unknown number of users within a 504 domain. 506 Furthermore, it is possible to include one or multiple 507 elements to exclude either individual users or users belonging to a 508 specific domain. Excluding individual entities is implemented using 509 a statement. The semantic of the 'id' attribute 510 of the element has the same meaning as the 'id' attribute of 511 the element (see Section 7.2). Excluding users belonging to a 512 specific domain is implemented using the 513 element that excludes any user from the indicated domain. 515 If multiple elements are listed as child elements of the 516 element then the result of each element is combined 517 using a logical OR. 519 Common policy MUST either use UTF-8 or UTF-16 to store domain names 520 in the 'domain' attribute. For non-IDNs, lower-case ASCII SHOULD be 521 used. For the comparison operation between the value stored in the 522 'domain' attribute and the domain value provided via the using 523 protocol (referred as "protocol domain identifier") the following 524 rules are applicable: 526 1. Translate percent-encoding for either string. 528 2. Convert both domain strings using the toASCII operation described 529 in RFC 3490 [3]. 531 3. Compare the two domain strings for ASCII equality, for each 532 label. If the string comparison for each label indicates 533 equality, the comparison succeeds. Otherwise, the domains are 534 not equal. 536 If the conversion fails in step (2), the domains are not equal. 538 7.1.3.1. Matching Any Authenticated Identity 540 The element without any child elements or attributes matches 541 any authenticated user. 543 The following example shows such a rule that matches any 544 authenticated user: 546 547 549 550 551 552 553 554 555 556 557 559 561 The following rule, in comparison, would match any user, 562 authenticated and unauthenticated: 564 565 567 568 569 570 571 572 573 575 577 7.1.3.2. Matching Any Authenticated Identity Excepting Enumerated 578 Domains/Identities 580 The element enclosing one or more 581 elements matches any user from any domain except those enumerated. 582 The element excludes particular users. The 583 semantic of the 'id' attribute of the element is described 584 in Section 7.2. The results of the child elements of the 585 element are combined using a logical OR. 587 An example is shown below: 589 590 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 2003-12-24T17:00:00+01:00 607 2003-12-24T19:00:00+01:00 608 609 610 611 612 614 616 This example matches all users except any user in example.com, or any 617 user in example.org or the particular users alice@bad.example.net, 618 bob@good.example.net and the user with the telephone number 619 'tel:+1-212-555-1234'. The last 'except' element is redundant since 620 alice@example.com is already excluded through the first line. 622 7.1.3.3. Matching Any Authenticated Identity Within a Domain Excepting 623 Enumerated Identities 625 The element with a 'domain' attribute and zero or more elements matches any authenticated user from the indicated 627 domain except those explicitly enumerated. The semantic of the 'id' 628 attribute of the element is described in Section 7.2. 630 It is nonsensical to have domains in the 'id' attribute that do not 631 match the value of the 'domain' attribute in the enclosing 632 element. 634 An example is shown below: 636 637 639 640 641 642 643 644 645 646 647 648 649 650 652 654 This example matches any user within example.com (such as 655 carol@example.com) except alice@example and bob@example.com. 657 7.2. Single Entity 659 The 'id' attribute used in the and in the element 660 refers to a single entity. In the subsequent text we use the term 661 'single-user' entity as a placeholder for the and the 662 element. The element fulfills the purpose of excluding 663 elements from the solution set. 665 A single-user entity matches the authenticated identity (as contained 666 in the 'id' attribute) of exactly one entity or user. If there is a 667 match, the single-user entity is considered TRUE. The single- user 668 entity MUST NOT contain a 'domain' attribute. 670 The 'id' attribute contains an identity that MUST first be expressed 671 as a URI. Applications using this framework must describe how the 672 identities they are using can be expressed as a URIs. 674 7.3. Sphere 676 The element belongs to the group of condition elements. It 677 can be used to indicate a state (e.g., 'work', 'home', 'meeting', 678 'travel') the PT is currently in. A sphere condition matches only if 679 the PT is currently in the state indicated. The state may be 680 conveyed by manual configuration or by some protocol. For example, 681 RPID [10] provides the ability to inform the PS of its current 682 sphere. The application domain needs to describe in more detail how 683 the sphere state is determined. Switching from one sphere to another 684 causes a switch between different modes of visibility. As a result 685 different subsets of rules might be applicable. 687 The content of the 'value' attribute of the element MAY 688 contain more than one token. The individual tokens MUST be separated 689 by a blank character. A logical OR is used for the matching the 690 tokens against the sphere settings of the PT. As an example, if the 691 the content of the 'value' attribute in the sphere attribute contains 692 two tokens 'work' and 'home' then this part of the rule matches if 693 the sphere for a particular PT is either 'work' OR 'home'. To 694 compare the content of the 'value' attribute in the element 695 with the stored state information about the PT's sphere setting a 696 case insensitive string comparison MUST be used for each individual 697 token. There is no registry for these values nor a language specific 698 indication of the sphere content. As such, the tokens are treated as 699 opaque strings. 701 702 704 705 706 707 708 709 710 711 712 713 715 716 717 718 719 720 721 722 723 724 726 727 728 729 730 731 732 733 734 735 736 738 The rule example above illustrates that the rule with the entity 739 andrew@example.com matches if the sphere is been set to 'work'. In 740 the second rule with the entity allison@example.com matches if the 741 sphere is set to 'home'. The third rule also matches since the the 742 value in the sphere element also contains the token 'home'. 744 7.4. Validity 746 The element is the third condition element specified in 747 this document. It expresses the rule validity period by two 748 attributes, a starting and a ending time. The validity condition is 749 TRUE if the current time is greater than or equal to at least one 750 child, but less than the child after it. This 751 represents a logical OR operation across each and 752 pair. Times are expressed in XML dateTime format. A rule maker 753 might not have always access to the PS to invalidate some rules which 754 grant permissions. Hence this mechanism allows to invalidate granted 755 permissions automatically without further interaction between the 756 rule maker and the PS. The PS does not remove the rules instead the 757 rule maker has to clean them up. 759 An example of a rule fragment is shown below: 761 762 764 765 766 767 2003-08-15T10:20:00.000-05:00 768 2003-09-15T10:20:00.000-05:00 769 770 771 772 773 774 776 The element MUST have the and subelements 777 in pairs. Multiple and elements might appear in pairs 778 (i.e., without nesting of and elements). Using 779 multiple elements as subelements of the 780 element is not useful since all subelements of the 781 element are combined as a logical AND. 783 8. Actions 785 While conditions are the 'if'-part of rules, actions and 786 transformations build the 'then'-part of them. The actions and 787 transformations parts of a rule determine which operations the PS 788 MUST execute after having received from a WR a data access request 789 that matches all conditions of this rule. Actions and 790 transformations only permit certain operations; there is no 'deny' 791 functionality. Transformations exclusively specify PS-side 792 operations that lead to a modification of the data items requested by 793 the WR. Regarding location data items, for instance, a 794 transformation could force the PS to lower the precision of the 795 location information which is returned to the WR. 797 Actions, on the other hand, specify all remaining types of operations 798 the PS is obliged to execute, i.e., all operations that are not of 799 transformation type. Actions are defined by application specific 800 usages of this framework. The reader is referred to the 801 corresponding extensions to see examples of such elements. 803 9. Transformations 805 Two sub-parts follow the conditions part of a rule: transformations 806 and actions. As defined in Section 8, transformations specify 807 operations that the PS MUST execute and that modify the result which 808 is returned to the WR. This functionality is particularly helpful in 809 reducing the granularity of information provided to the WR, as for 810 example required for location privacy. Transformations are defined 811 by application specific usages of this framework. 813 A simple transformation example is provided in Section 10. 815 10. Procedure for Combining Permissions 817 10.1. Introduction 819 This section describes the mechanism to evaluate the final result of 820 a rule evaluation. The result is reflected in the action and 821 transformation part of a rule. This procedure is sometimes referred 822 as conflict resolution. 824 We use the following terminology (which in parts has already been 825 introduced in previous sections): The term 'permission' stands for an 826 action or a transformation. The notion 'attribute' terms a 827 condition, an action, or a transformation. An attribute has a name, 828 and a certain data type. A value may be assigned to an attribute or 829 it may be undefined, in case it does not have a value associated with 830 the attribute. For example, the name of the attribute 831 discussed in Section 7 is 'sphere', its data type is 'string', and 832 its value may be set to 'home'. To evaluate a condition means to 833 associate either TRUE or FALSE to the condition. Please note that 834 the element is a condition whereas the element is a 835 parameter of that condition. A rule matches if all conditions 836 contained in the conditions part of a rule evaluate to TRUE. 838 When the PS receives a request for access to privacy-sensitive data 839 then it needs to be matched against a rule set. The conditions part 840 of each individual rule is evaluated and as a result one or more 841 rules might match. If only a single rule matches then the result is 842 determined by executing the actions and the transformations part 843 following the conditions part of a rule. However, it can also be the 844 case that two or more matching rules contain a permission of the same 845 name (e.g., two rules contain a permission named 'precision of 846 geospatial location information'), but do not specify the same value 847 for that permission (e.g., the two rule might specify values of '10 848 km' and '200 km', respectively, for the permission named 'precision 849 of geospatial location information'). This section describes the 850 procedure for combining permissions in such cases. 852 10.2. Algorithm 854 The combining rules are simple and depend on the data types of the 855 values of permissions: Let P be a policy. Let M be the subset of P 856 consisting of rules r in P that match with respect to a given 857 request. Let n be a name of a permission contained in a rule r in M, 858 and let M(n) be the subset of M consisting of rules r in M that have 859 a permission of name n. For each rule r in M(n), let v(r,n) and 860 d(r,n) be the value and the data type, respectively, of the attribute 861 of r with name n. Finally, let V(n) be the combined value of all the 862 permissions values v(r,n), r in M(n). The combining rules that lead 863 to the resulting value V(n) are the following: 865 CR 1: If d(r,n)=Boolean for all r in M(n), then V(n) is given as 866 follows: If there is a r in M(n) with v(r,n)=TRUE, then V(n)=TRUE. 867 Otherwise, V(n)=FALSE. 869 CR 2: If d(r,n)=Integer for all r in M(n), then V(n) is given as 870 follows: If v(r,n)=undefined for all r in M(n), then V(n) is not 871 specified by this specification. Otherwise, V(n)=max{v(r,n) | r 872 in M(n)}. 874 CR 3: If d(r,n)=Set for all r in M(n), then V(n) is given as 875 follows: V(n)=union of all v(r,n), the union to be computed over all 876 r in M(n) with v(r,n)!=undefined. 878 The combining operation will result in the largest value for an 879 Integral type, the OR operation for boolean, and union for set. 881 As a result, applications should define values such that, for 882 integers, the lowest value corresponds to the most privacy, for 883 booleans, false corresponds to the most privacy, and for sets, the 884 empty set corresponds to the most privacy. 886 10.3. Example 888 In the following example we illustrate the process of combining 889 permissions. We will consider three conditions for our purpose, 890 namely those of name identity, sphere, and validity. For editorial 891 reasons the rule set in this example is represented in a table. 892 Furthermore, the domain part of the identity of the WR is omitted. 893 For actions we use two permissions with names X and Y. The values of 894 X and Y are of data types Boolean and Integer, respectively. 895 Permission X might, for example, represent the action. 896 For transformations we use the attribute with the name Z whose value 897 can be set either to '+'(or 1), 'o' (or 2) or '-' (or 3). Permission 898 Z allows us to show the granularity reduction whereby a value of '+' 899 shows the corresponding information unrestricted and '-' shows 900 nothing. This permission might be related to location information or 901 other presence attributes like mood. Internally we use the data type 902 Integer for computing the permission of this attribute. 904 Conditions Actions/Transformations 905 +---------------------------------+---------------------+ 906 | Id WR-ID sphere from until | X Y Z | 907 +---------------------------------+---------------------+ 908 | 1 bob home A1 A2 | TRUE 10 o | 909 | 2 alice work A1 A2 | FALSE 5 + | 910 | 3 bob work A1 A2 | TRUE 3 - | 911 | 4 tom work A1 A2 | TRUE 5 + | 912 | 5 bob work A1 A3 | undef 12 o | 913 | 6 bob work B1 B2 | FALSE 10 - | 914 +---------------------------------+---------------------+ 916 Again for editorial reasons, we use the following abbreviations for 917 the two attributes 'from' and 'until': 919 A1=2003-12-24T17:00:00+01:00 920 A2=2003-12-24T21:00:00+01:00 921 A3=2003-12-24T23:30:00+01:00 922 B1=2003-12-22T17:00:00+01:00 923 B2=2003-12-23T17:00:00+01:00 925 Note that B1 < B2 < A1 < A2 < A3. 927 The entity 'bob' acts as a WR and requests data items. The policy P 928 consists of the six rules shown in the table and identified by the 929 values 1 to 6 in the 'Id' column. The PS receives the query at 2003- 930 12-24T17:15:00+01:00 which falls between A1 and A2. The value of the 931 attribute with name 'sphere' indicating the state the PT is currently 932 in is set to 'work'. 934 Rule 1 does not match since the sphere condition does not match. 935 Rule 2 does not match as the identity of the WR (here 'alice') does 936 not equal 'bob'. Rule 3 matches since all conditions evaluate to 937 TRUE. Rule 4 does not match as the identity of the WR (here 'tom') 938 does not equal 'bob'. Rule 5 matches. Rule 6 does not match since 939 the rule is not valid anymore. Therefore, the set M of matching 940 rules consists of the rules 3 and 5. These two rules are used to 941 compute the combined permission V(X), V(Y), and V(Z) for each of the 942 permissions X, Y, and Z: 944 Actions/Transformations 945 +-----+-----------------------+ 946 | Id | X Y Z | 947 +-----+-----------------------+ 948 | 3 | TRUE 3 - | 949 | 5 | undef 12 o | 950 +-----+-----------------------+ 952 The results of the permission combining algorithm is shown below. 953 The combined value V(X) regarding the permission with name X equals 954 TRUE according to the first combining rule listed above. The maximum 955 of 3 and 12 is 12, so that V(Y)=12. For the attribute Z in this 956 example the maximum between 'o' and '-' (i.e., between 2 and 3) is 957 '-'. 959 Actions/Transformations 960 +-----+-----------------------+ 961 | Id | X Y Z | 962 +-----+-----------------------+ 963 | 5 | TRUE 12 - | 964 +-----+-----------------------+ 966 11. Meta Policies 968 Meta policies authorize a rulemaker to insert, update or delete a 969 particular rule or an entire rule set. Some authorization policies 970 are required to prevent unauthorized modification of rule sets. Meta 971 policies are outside the scope of this document. 973 A simple implementation could restrict access to the rule set only to 974 the PT but more sophisticated mechanisms could be useful. As an 975 example of such policies one could think of parents configuring the 976 policies for their children. 978 12. Example 980 This section gives an example of an XML document valid with respect 981 to the XML schema defined in Section 13. Semantically richer 982 examples can be found in documents which extend this schema with 983 application domain specific data (e.g., location or presence 984 information). 986 Below a rule is shown with a condition that matches for a given 987 authenticated identity (bob@example.com) and within a given time 988 period. Additionally, the rule matches only if the target has set 989 its sphere to 'work'. 991 992 994 995 996 997 998 999 1000 1001 2003-12-24T17:00:00+01:00 1002 2003-12-24T19:00:00+01:00 1003 1004 1005 1006 1007 1008 1010 13. XML Schema Definition 1012 This section provides the XML schema definition for the common policy 1013 markup language described in this document. 1015 1016 1020 1021 1022 1023 1024 1025 1026 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1040 1042 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1056 1058 1060 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1085 1086 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1099 1100 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1137 1138 1139 1140 1141 1142 14. Security Considerations 1144 This document describes a framework for policies. This framework is 1145 intended to be enhanced elsewhere towards application domain specific 1146 data. Security considerations are to a great extent application data 1147 dependent, and therefore need to be covered by documents that extend 1148 the framework defined in this specification. However, new action and 1149 transformation permissions along with their allowed values must be 1150 defined in a way so that the usage of the permissions combining rules 1151 of Section 10 does not lower the level of privacy protection. See 1152 Section 10 for more details on this privacy issue. 1154 15. IANA Considerations 1156 This section registers a new XML namespace, a new XML schema and a 1157 new MIME-type. This section registers a new XML namespace per the 1158 procedures in [4]. 1160 15.1. Common Policy Namespace Registration 1162 URI: urn:ietf:params:xml:ns:common-policy 1164 Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne 1165 (hgs+geopriv@cs.columbia.edu). 1167 XML: 1169 BEGIN 1170 1171 1173 1174 1175 1177 Common Policy Namespace 1178 1179 1180

Namespace for Common Authorization Policies

1181

urn:ietf:params:xml:ns:common-policy

1182

See RFCXXXX 1183 [NOTE TO IANA/RFC-EDITOR: 1184 Please replace XXXX with the RFC number of this 1185 specification.].

1186 1187 1188 END 1190 15.2. Content-type registration for 'application/auth-policy+xml' 1192 This specification requests the registration of a new MIME type 1193 according to the procedures of RFC 4288 [5] and guidelines in RFC 1194 3023 [6]. 1196 MIME media type name: application 1197 MIME subtype name: auth-policy+xml 1199 Mandatory parameters: none 1201 Optional parameters: charset 1203 Indicates the character encoding of enclosed XML. 1205 Encoding considerations: 1207 Uses XML, which can employ 8-bit characters, depending on the 1208 character encoding used. See RFC 3023 [6], Section 3.2. 1210 Security considerations: 1212 This content type is designed to carry authorization policies. 1213 Appropriate precautions should be adopted to limit disclosure of 1214 this information. Please refer to Section 14 of RFCXXXX [NOTE TO 1215 IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this 1216 specification.] and to the security considerations described in 1217 Section 10 of RFC 3023 [6] for more information. 1219 Interoperability considerations: None 1221 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 1222 replace XXXX with the RFC number of this specification.] this 1223 document 1225 Applications which use this media type: 1227 Presence- and location-based systems 1229 Additional information: 1231 Magic Number: None 1232 File Extension: .apxml 1234 Macintosh file type code: 'TEXT' 1236 Personal and email address for further information: Hannes 1237 Tschofenig, Hannes.Tschofenig@siemens.com 1239 Intended usage: LIMITED USE 1241 Author: 1243 This specification is a work item of the IETF GEOPRIV working 1244 group, with mailing list address . 1246 Change controller: 1248 The IESG 1250 15.3. Common Policy Schema Registration 1252 URI: urn:ietf:params:xml:schema:common-policy 1254 Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne 1255 (hgs+geopriv@cs.columbia.edu). 1257 XML: The XML schema to be registered is contained in Section 13. 1258 Its first line is 1260 1262 and its last line is 1264 1266 16. References 1268 16.1. Normative References 1270 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1271 Levels", March 1997. 1273 [2] Duerst, M. and M. Suignard, "Internationalized Resource 1274 Identifiers (IRIs)", RFC 3987, January 2005. 1276 [3] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing 1277 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 1279 [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1280 January 2004. 1282 [5] Freed, N. and J. Klensin, "Media Type Specifications and 1283 Registration Procedures", BCP 13, RFC 4288, December 2005. 1285 [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1286 RFC 3023, January 2001. 1288 16.2. Informative References 1290 [7] Rosenberg, J., "Presence Authorization Rules", 1291 draft-ietf-simple-presence-rules-07 (work in progress), 1292 June 2006. 1294 [8] Schulzrinne, H., "A Document Format for Expressing Privacy 1295 Preferences for Location Information", 1296 draft-ietf-geopriv-policy-08 (work in progress), February 2006. 1298 [9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1299 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1301 [10] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, 1302 "RPID: Rich Presence Extensions to the Presence Information 1303 Data Format (PIDF)", RFC 4480, July 2006. 1305 Appendix A. Contributors 1307 We would like to thank Christian Guenther for his help with initial 1308 versions of this document. 1310 Appendix B. Acknowledgments 1312 This document is partially based on the discussions within the IETF 1313 GEOPRIV working group. Discussions at the Geopriv Interim Meeting 1314 2003 in Washington, D.C., helped the working group to make progress 1315 on the authorization policies based on the discussions among the 1316 participants. 1318 We particularly want to thank Allison Mankin , 1319 Randall Gellens , Andrew Newton 1320 , Ted Hardie and Jon 1321 Peterson for discussing a number of 1322 details with us. They helped us to improve the quality of this 1323 document. Allison, Ted and Andrew also helped us to make good 1324 progress with the internationalization support of the identifier/ 1325 domain attributes. 1327 Furthermore, we would like to thank the IETF SIMPLE working group for 1328 their discussions of J. Rosenberg's draft on presence authorization 1329 policies. We would also like to thank Stefan Berg, Murugaraj 1330 Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki 1331 Niemi, Eva Maria Leppanen and Mark Baker for their comments. Martin 1332 Thomson helped us with the XML schema. Mark Baker provided a review 1333 of the media type. Scott Brim provided a review on behalf of the 1334 General Area Review Team. 1336 Authors' Addresses 1338 Henning Schulzrinne 1339 Columbia University 1340 Department of Computer Science 1341 450 Computer Science Building 1342 New York, NY 10027 1343 USA 1345 Phone: +1 212 939 7042 1346 Email: schulzrinne@cs.columbia.edu 1347 URI: http://www.cs.columbia.edu/~hgs 1349 Hannes Tschofenig 1350 Siemens 1351 Otto-Hahn-Ring 6 1352 Munich, Bavaria 81739 1353 Germany 1355 Email: Hannes.Tschofenig@siemens.com 1356 URI: http://www.tschofenig.com 1358 John B. Morris, Jr. 1359 Center for Democracy and Technology 1360 1634 I Street NW, Suite 1100 1361 Washington, DC 20006 1362 USA 1364 Email: jmorris@cdt.org 1365 URI: http://www.cdt.org 1367 Jorge R. Cuellar 1368 Siemens 1369 Otto-Hahn-Ring 6 1370 Munich, Bavaria 81739 1371 Germany 1373 Email: Jorge.Cuellar@siemens.com 1374 James Polk 1375 Cisco 1376 2200 East President George Bush Turnpike 1377 Richardson, Texas 75082 1378 USA 1380 Email: jmpolk@cisco.com 1382 Jonathan Rosenberg 1383 Cisco Systems 1384 600 Lanidex Plaza 1385 Parsippany, New York 07054 1386 USA 1388 Email: jdrosen@cisco.com 1389 URI: http://www.jdrosen.net 1391 Full Copyright Statement 1393 Copyright (C) The Internet Society (2006). 1395 This document is subject to the rights, licenses and restrictions 1396 contained in BCP 78, and except as set forth therein, the authors 1397 retain all their rights. 1399 This document and the information contained herein are provided on an 1400 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1401 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1402 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1403 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1404 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1405 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1407 Intellectual Property 1409 The IETF takes no position regarding the validity or scope of any 1410 Intellectual Property Rights or other rights that might be claimed to 1411 pertain to the implementation or use of the technology described in 1412 this document or the extent to which any license under such rights 1413 might or might not be available; nor does it represent that it has 1414 made any independent effort to identify any such rights. Information 1415 on the procedures with respect to rights in RFC documents can be 1416 found in BCP 78 and BCP 79. 1418 Copies of IPR disclosures made to the IETF Secretariat and any 1419 assurances of licenses to be made available, or the result of an 1420 attempt made to obtain a general license or permission for the use of 1421 such proprietary rights by implementers or users of this 1422 specification can be obtained from the IETF on-line IPR repository at 1423 http://www.ietf.org/ipr. 1425 The IETF invites any interested party to bring to its attention any 1426 copyrights, patents or patent applications, or other proprietary 1427 rights that may cover technology that may be required to implement 1428 this standard. Please address the information to the IETF at 1429 ietf-ipr@ietf.org. 1431 Acknowledgment 1433 Funding for the RFC Editor function is provided by the IETF 1434 Administrative Support Activity (IASA).