idnits 2.17.00 (12 Aug 2021) /tmp/idnits6437/draft-ietf-geopriv-policy-17.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1213. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 26, 2008) is 5077 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) == Unused Reference: '16' is defined on line 1089, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: draft-ietf-geopriv-pdif-lo-profile has been published as RFC 5491 -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '13') (Obsoleted by RFC 5226) == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV H. Schulzrinne, Ed. 3 Internet-Draft Columbia University 4 Intended status: Standards Track H. Tschofenig, Ed. 5 Expires: December 28, 2008 Nokia Siemens Networks 6 J. Morris 7 CDT 8 J. Cuellar 9 Siemens 10 J. Polk 11 Cisco 12 June 26, 2008 14 Geolocation Policy: A Document Format for Expressing Privacy Preferences 15 for Location Information 16 draft-ietf-geopriv-policy-17.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on December 28, 2008. 43 Abstract 45 This document defines an authorization policy language for 46 controlling access to location information. It extends the Common 47 Policy authorization framework to provide location-specific access 48 control. More specifically, this document defines condition elements 49 specific to location information in order to restrict access based on 50 the current location of the Target. Furthermore, it offers location- 51 specific transformation elements to reduce the granularity of the 52 returned location information. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 8 59 3.1. Structure of Geolocation Authorization Documents . . . . . 8 60 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 8 61 4. Location-specific Conditions . . . . . . . . . . . . . . . . . 9 62 4.1. Geodetic Location Condition Profile . . . . . . . . . . . 9 63 4.2. Civic Location Condition Profile . . . . . . . . . . . . . 10 64 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 12 66 6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 12 67 6.2. Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 12 68 6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 12 69 6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 13 70 6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 13 71 6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 14 72 6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 15 73 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 7.1. Rule Example with Civic Location Condition . . . . . . . . 16 75 7.2. Rule Example with Geodetic Location Condition . . . . . . 17 76 7.3. Rule Example with Civic and Geodetic Location Condition . 17 77 7.4. Rule Example with Location-based Transformations . . . . . 18 78 8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 20 79 9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 21 80 10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 23 82 10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 23 83 10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 23 84 10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 23 85 10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 23 86 10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 23 87 10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 23 88 10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 24 89 10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 24 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 11.1. Geolocation Policy XML Schema Registration . . . . . . . . 25 93 11.2. Geolocation Policy Namespace Registration . . . . . . . . 25 94 11.3. Geolocation Policy Location Profile Registry . . . . . . . 26 95 11.4. Basic Location Profile XML Schema Registration . . . . . . 26 96 11.5. Basic Location Profile Namespace Registration . . . . . . 27 97 11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 27 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 13.1. Normative References . . . . . . . . . . . . . . . . . . . 30 101 13.2. Informative References . . . . . . . . . . . . . . . . . . 30 102 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 32 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 104 Intellectual Property and Copyright Statements . . . . . . . . . . 35 106 1. Introduction 108 Location information needs to be protected against unauthorized 109 access to preserve the privacy of humans. In RFC 3693 [7], a 110 protocol-independent model for access to geographic information is 111 defined. The model includes a Location Generator (LG) that 112 determines location information, a Location Server (LS) that 113 authorizes access to location information, a Location Recipient (LR) 114 that requests and receives location information, and a Rule Maker 115 (RM) that writes authorization policies. An authorization policy is 116 a set of rules that regulates an entity's activities with respect to 117 privacy-sensitive information, such as location information. 119 The data object containing location information in the context of 120 this document is referred to as a Location Object (LO). The basic 121 rule set defined in the Presence Information Data Format Location 122 Object (PIDF-LO) [8] can restrict how long the Location Recipient is 123 allowed to retain the information, and it can prohibit further 124 distribution. It also contains a reference to an enhanced rule set 125 and a human readable privacy policy. The basic rule set, however, 126 does not allow to control access to location information based on 127 specific Location Recipients. This document describes an enhanced 128 rule set that provides richer constraints on the distribution of LOs. 130 The rule set allows the entity that uses the rules defined in this 131 document to restrict the retention and to enforce access restrictions 132 on location data, including prohibiting any dissemination to 133 particular individuals, during particular times or when the Target is 134 located in a specific region. The RM can also stipulate that only 135 certain parts of the Location Object are to be distributed to 136 recipients or that the resolution of parts of the Location Object is 137 reduced. 139 The typical sequence of operations is as follows. A Location Server 140 receives a query for location information for a particular Target, 141 via the using protocol [7]. The using protocol provides the identity 142 of the requestor, either at the time of the query or when subscribing 143 to the location information. The authenticated identity of the 144 Location Recipient, together with other information provided by the 145 using protocol or generally available to the server, is then used for 146 searching through the rule set. If more than one rule matches the 147 condition element, then the combined permission is evaluated 148 according to the description in Section 10 of [1]. The result of the 149 rule evalation is applied to the location information, yielding a 150 possibly modified Location Object that is delivered to the Location 151 Recipient. 153 This document does not describe the protocol used to convey location 154 information from the Location Server to the Location Recipient (i.e., 155 the using protocol; see RFC 3693 [7]). 157 This document extends the Common Policy framework defined in [1]. 158 That document provides an abstract framework for expressing 159 authorization rules. As specified there, each such rule consists of 160 conditions, actions and transformations. Conditions determine under 161 which circumstances the entity executing the rules, for example a 162 Location Server, is permitted to apply actions and transformations. 163 Transformations regulate in a location information context how a 164 Location Server modifies the information elements that are returned 165 to the requestor, for example, by reducing the granularity of 166 returned location information. 168 The XML schema defined in Section 9 extends the Common Policy schema 169 by introducing new child elements to the condition and transformation 170 elements. This document does not define child elements for the 171 action part of a rule. 173 2. Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [2]. 179 This document reuses the terminology of RFC 3693 [7], such as 180 Location Server (LS), Location Recipient (LR), Rule Maker (RM), 181 Target, Location Generator (LG) and Location Object (LO). This 182 document uses the following terminology: 184 Presentity or Target: 186 RFC 3693 [7] uses the term Target to identify the object or person 187 of which location information is required. The presence model 188 described in RFC 2778 [9] uses the term presentity to describe the 189 entity that provides presence information to a presence service. 190 A Presentity in a presence system is a Target in a location 191 information system. 193 Watcher or Location Recipient: 195 The receiver of location information is the Location Recipient 196 (LR) in the terminology of RFC 3693 [7]. A watcher in a presence 197 system, i.e., an entity that requests presence information about a 198 presentity, is a Location Recipient in a location information 199 system. 201 Authorization policy: 203 An authorization policy is given by a rule set. A rule set 204 contains an unordered list of (policy) rules. Each rule has a 205 condition, an action and a transformation component. 207 Permission: 209 The term permission refers to the action and transformation 210 components of a rule. 212 The term 'using protocol' is defined in [7] and refers to the 213 protocol that is used to request access to and to return privacy 214 sensitive data items. 216 In this document we use the term Location Servers as the entities 217 that evaluate the geolocation authorization policies. The 218 geolocation privacy architecture is, as motivated in RFC 4079 [10], 219 aligned with the presence architecture and a Presence Server is 220 therefore an entity that distributes location information along with 221 other presence-specific XML data elements. 223 3. Generic Processing 225 3.1. Structure of Geolocation Authorization Documents 227 A geolocation authorization document is an XML document, formatted 228 according to the schema defined in [1]. Geolocation authorization 229 documents inherit the MIME type of common policy documents, 230 application/auth-policy+xml. As described in [1], this document is 231 composed of rules which contain three parts - conditions, actions, 232 and transformations. Each action or transformation, which is also 233 called a permission, has the property of being a positive grant of 234 information to the Location Recipient. As a result, there is a well- 235 defined mechanism for combining actions and transformations obtained 236 from several sources. This mechanism is privacy safe, since the lack 237 of any action or transformation can only result in less information 238 being presented to a Location Recipient. 240 3.2. Rule Transport 242 There are two ways how the authorization rules described in this 243 document may be conveyed between different parties: 245 o RFC 4119 [8] allows enhanced authorization policies to be 246 referenced via a Uniform Resource Locator (URL) in the 'ruleset- 247 reference' element. The ruleset-reference' element is part of the 248 basic rules that always travel with the Location Object. 250 o Authorization policies might, for example, also be stored at a 251 Location Server / Presence Server. The Rule Maker therefore needs 252 to use a protocol to create, modify and delete the authorization 253 policies defined in this document. Such a protocol is available 254 with the Extensible Markup Language (XML) Configuration Access 255 Protocol (XCAP) [11]. 257 4. Location-specific Conditions 259 This section describes the location-specific conditions of a rule, 260 namely the civic and geodetic location conditions. The 261 element contains zero, one or an unbounded number of child element(s). Providing more than one child element may not be useful since all child elements 264 of the element must evaluate to TRUE in order for the 265 element to be TRUE. The element 266 MUST contain at least one child element. The element evaluates to TRUE if any of its child elements is 268 TRUE, i.e., a logical OR. 270 A location profile needs to describe under what conditions each 271 element evaluates to TRUE. This document defines two 272 location profiles, one civic and one geodetic location profile. 274 The and the elements provide 275 extension points. If an extension is not understood by the entity 276 evaluating the rules then this rule evaluates to FALSE. 278 4.1. Geodetic Location Condition Profile 280 The geodetic location profile is identified by the token 'geodetic- 281 condition'. Rule Makers use this profile by placing a GML [3] 282 element within the element (as described in 283 Section 5.2.3 of [4]). 285 The element containing the information for the geodetic 286 location profile evaluates to TRUE if the current location of the 287 Target is within the described location. Note that the Target's 288 actual location might be represented by any of the location shapes 289 described in [4]. If the geodetic location of the Target is unknown 290 then the element containing the information for the 291 geodetic location profile evaluates to FALSE. 293 Implementations are REQUIRED to support the following coordinate 294 reference system based on WGS 84 [5] based on the European Petroleum 295 Survey Group (EPSG) Geodetic Parameter Dataset (as formalized by the 296 Open Geospatial Consortium (OGC)): 298 2D: WGS 84 (latitude, longitude), as identified by the URN 299 "urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS. 301 A CRS MUST be specified using the above URN notation only, 302 implementations do not need to support user-defined CRSs. 304 Implementations MUST specify the CRS using the "srsName" attribute on 305 the outermost geometry element. The CRS MUST NOT be changed for any 306 sub-elements. The "srsDimension" attribute MUST be omitted, since 307 the number of dimensions in these CRSs is known. 309 4.2. Civic Location Condition Profile 311 The civic location profile is identified by the token 'civic- 312 condition'. Rule Makers use this profile by placing a 313 element, defined in [6], within the element. 315 All child elements of element that carry civicAddress 316 elements MUST evaluate to TRUE (i.e., logical AND) in order for the 317 element to evaluate to TRUE. For each child element, the 318 value of that element is compared to the value of the same element in 319 the Target's civic location. The child element evaluates to TRUE if 320 the two values are identical based on a bit-by-bit comparison. 322 If the civic location of the Target is unknown, then the 323 element containing the information for the civic location profile 324 evaluates to FALSE. This case may occur, for example, if location 325 information has been removed by earlier transmitters of location 326 information or if only the geodetic location is known. In general, 327 it is RECOMMENDED behavior for a LS not to apply a translation from 328 geodetic location to civic location (i.e., geocode the location). 330 5. Actions 332 This document does not define location-specific actions. 334 6. Transformations 336 This document defines several elements that allow Rule Makers to 337 specify transformations that 339 o reduce the accuracy of the returned location information, and 341 o set the basic authorization policies carried inside the PIDF-LO. 343 6.1. Set Retransmission-Allowed 345 This element asks the LS to change or set the value of the 346 element in the PIDF-LO. The data type of 347 the element is a boolean. 349 If the value of the element is set to 350 TRUE then the element in the PIDF-LO MUST be 351 set to TRUE. If the value of the 352 element is set to FALSE, then the element in 353 the PIDF-LO MUST be set to FALSE. 355 If the element is absent then the value 356 of the element in the PIDF-LO MUST be kept 357 unchanged or, if the PIDF-LO is created for the first time, then the 358 value MUST be set to FALSE. 360 6.2. Set Retention-Expiry 362 This transformation asks the LS to change or set the value of the 363 element in the PIDF-LO. The data type of the 364 element is an integer. 366 The value provided with the element indicates 367 seconds and these seconds are added to the current date. 369 If the element is absent then the value of the 370 element in the PIDF-LO is kept unchanged or, if 371 the PIDF-LO is created for the first time, then the value MUST be set 372 to the current date. 374 6.3. Set Note-Well 376 This transformation asks the LS to change or set the value of the 377 element in the PIDF-LO. The data type of the element is a string. 380 The value provided with the element contains a 381 privacy statement as a human readable text string and an 'xml:lang' 382 attribute denotes the language of the human readable text. 384 If the element is absent, then the value of the 385 element in the PIDF-LO is kept unchanged or, if the 386 PIDF-LO is created for the first time, then no content is provided 387 for the element. 389 6.4. Keep Ruleset Reference 391 This transformation allows to influence whether the element in the PIDF-LO carries the extended authorization 393 rules defined in [1]. The data type of the 394 element is Boolean. 396 If the value of the element is set to TRUE, 397 then the element in the PIDF-LO is kept unchanged 398 when included. If the value of the element is 399 set to FALSE, then the element in the PIDF-LO MUST 400 NOT contain a reference to an external rule set. The reference to 401 the ruleset is removed and no rules are carried as MIME bodies (in 402 case of CID URIs). 404 If the element is absent, then the value of the 405 element in the PIDF-LO is kept unchanged when 406 available or, if the PIDF-LO is created for the first time then the 407 element MUST NOT be included. 409 6.5. Provide Location 411 The element contains child elements of a specific 412 location profile that controls the granularity of returned location 413 information. This document defines two location profiles, namely: 415 o If the element has a child 416 element then civic location information is disclosed as described 417 in Section 6.5.1, subject to availability. 419 o If the element has a child 420 element then geodetic location information is disclosed as 421 described in Section 6.5.2, subject to availability. 423 The element MUST contain the 'profile' attribute 424 if it contains child elements and the 'profile' attribute MUST match 425 with the contained child elements. The element 426 MUST contain the 'profile' attribute if it contains child elements. 428 If the element has no child elements then civic, 429 as well as, geodetic location information is disclosed without 430 reducing its granularity, subject to availability. In this case the 431 profile attribute MUST NOT be included. 433 6.5.1. Civic Location Profile 435 This profile uses the token 'civic-transformation'. This profile 436 allows civic location transformations to be specified by means of the 437 element that restricts the level of civic location 438 information the LS is permitted to disclose. The symbols of these 439 levels are: 'country', 'region', 'city', 'building', 'full'. Each 440 level is given by a set of civic location data items such as 441 and , ..., , as defined in [6]. Each level 442 includes all elements included by the lower levels. 444 The 'country' level includes only the element; the 'region' 445 level adds the element; the 'city' level adds the and 446 elements; the 'building' level and the 'full' level add further civic 447 location data as shown below. 449 full 450 {, , , , , , , , , 451 , , , , , , , , 452 ,,,, , , , 453 , , , , , } 454 | 455 | 456 building 457 {, , , , , , , 458 , , , , , , 459 , , , , } 460 | 461 | 462 city 463 {, , , } 464 | 465 | 466 region 467 {, } 468 | 469 | 470 country 471 {} 472 | 473 | 474 none 475 {} 477 The default value is "none". 479 The schema of the element is defined in Section 8. 481 6.5.2. Geodetic Location Profile 483 This profile uses the token 'geodetic-transformation' and refers only 484 to the Coordinate Reference System (CRS) WGS 84 485 (urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic 486 location transformations to be specified by means of the element that may restrict the returned geodetic location 488 information based on the value provided in the 'radius' attribute. 489 The value of the 'radius' attribute expresses the radius in meters. 491 The schema of the element is defined in Section 8. 493 For each rule in the policy specification containing a 494 element, the LS chooses a circle with a radius F given by the 495 'radius' attribute of the element. The center of the 496 circle is chosen randomly, under the constraint that the circle MUST 497 contain the Target's location, which may be a point or another 498 location shape. In response to queries matching this rule, the LS 499 MUST return a shape containing this circle; while the returned shape 500 may change from one query to another, the chosen circle remains 501 constant as long as the Target's location (whether a point or a 502 region) remains completely within the circle. An LS may, for 503 example, store the location of the center or compute it based on a 504 hash function that includes the target's identity. If the Target's 505 location moves within the chosen circle, the LS MAY choose a new 506 random center point, but when the Target's location moves outside the 507 chosen circle, the LS MUST choose a new random center point. 509 The above-described procedure aims to satisfy the following design 510 goals: 512 1. The circle returned must contain the actual location of the 513 Target. 515 2. In general, no point in the circle must be more likely than 516 others to contain the Target. 518 3. Repeated queries must not reveal the likely location of the 519 Target. 521 7. Examples 523 This section provides a few examples for authorization rules using 524 the extensions defined in this document. 526 7.1. Rule Example with Civic Location Condition 528 This example illustrates a single rule that employs the civic 529 location condition. It matches if the current location of the Target 530 equal the content of the child elements of the element. 531 Requests match only if the Target is at a civic location with country 532 set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to 533 'Munich', city division (A4) set to 'Perlach', street name (A6) set 534 to 'Otto-Hahn-Ring' and house number (HNO) set to '6'. 536 No actions and transformation child elements are provided in this 537 rule example. The actions and transformation could include presence 538 specific information when the Geolocation Policy framework is applied 539 to the Presence Policy framework (see [12]). 541 542 545 546 547 548 550 DE 551 Bavaria 552 Munich 553 Perlach 554 Otto-Hahn-Ring 555 6 556 557 558 559 560 561 562 564 7.2. Rule Example with Geodetic Location Condition 566 This example illustrates a rule that employs the geodetic location 567 condition. The rule matches if the current location of the Target is 568 inside the area specified by the polygon. The polygon uses the EPSG 569 4326 coordinate reference system. No altitude is included in this 570 example. 572 573 579 580 581 582 583 584 -34.410649 150.87651 585 1500 586 587 588 589 590 591 592 593 595 7.3. Rule Example with Civic and Geodetic Location Condition 597 This example illustrates a rule that employs a mixed civic and 598 geodetic location condition. Depending on the available type of 599 location information, namely civic or geodetic location information, 600 one of the location elements may match. 602 603 609 610 611 612 614 DE 615 Bavaria 616 Munich 617 Perlach 618 Otto-Hahn-Ring 619 6 620 621 622 623 -34.410649 150.87651 624 1500 625 626 627 628 629 630 631 632 633 635 7.4. Rule Example with Location-based Transformations 637 This example shows the transformations specified in this document. 638 The element indicates that the available civic 639 location information is reduced to building level granularity. If 640 geodetic location information is requested then a granularity 641 reduction is provided as well. 643 644 648 649 650 651 652 false 653 654 86400 655 My privacy policy goes in here. 656 657 false 658 660 662 building 663 665 667 668 670 671 672 674 The following rule describes the short-hand notation for making the 675 current location of the Target available to Location Recipients 676 without granularity reduction. 678 679 682 683 684 685 686 687 688 689 691 8. XML Schema for Basic Location Profiles 693 This section defines the location profiles used as child elements of 694 the transformation element. 696 697 703 705 706 707 708 709 710 711 712 713 714 715 716 718 720 721 722 723 724 726 728 9. XML Schema for Geolocation Policy 730 This section presents the XML schema that defines the Geolocation 731 Policy schema described in this document. The Geolocation Policy 732 schema extends the Common Policy schema (see [1]). 734 735 742 743 745 746 749 751 754 755 756 757 758 760 762 763 764 765 767 768 769 770 771 773 774 776 777 778 780 781 783 785 787 790 793 794 795 796 797 798 799 801 802 803 804 805 807 808 809 810 811 813 815 10. XCAP Usage 817 The following section defines the details necessary for clients to 818 manipulate geolocation privacy documents from a server using XCAP. 819 If used as part of a presence system, it uses the same AUID as those 820 rules. See [12] for a description of the XCAP usage in context with 821 presence authorization rules. 823 10.1. Application Unique ID 825 XCAP requires application usages to define a unique application usage 826 ID (AUID) in either the IETF tree or a vendor tree. This 827 specification defines the "geolocation-policy" AUID within the IETF 828 tree, via the IANA registration in Section 11. 830 10.2. XML Schema 832 XCAP requires application usages to define a schema for their 833 documents. The schema for geolocation authorization documents is 834 described in Section 9. 836 10.3. Default Namespace 838 XCAP requires application usages to define the default namespace for 839 their documents. The default namespace is 840 urn:ietf:params:xml:ns:geolocation-policy. 842 10.4. MIME Type 844 XCAP requires application usages to defined the MIME type for 845 documents they carry. Geolocation privacy authorization documents 846 inherit the MIME type of common policy documents, application/ 847 auth-policy+xml. 849 10.5. Validation Constraints 851 This specification does not define additional constraints. 853 10.6. Data Semantics 855 This document discusses the semantics of a geolocation privacy 856 authorization. 858 10.7. Naming Conventions 860 When a Location Server receives a request to access location 861 information of some user foo, it will look for all documents within 862 http://[xcaproot]/geolocation-policy/users/foo, and use all documents 863 found beneath that point to guide authorization policy. 865 10.8. Resource Interdependencies 867 This application usage does not define additional resource 868 interdependencies. 870 10.9. Authorization Policies 872 This application usage does not modify the default XCAP authorization 873 policy, which is that only a user can read, write or modify his/her 874 own documents. A server can allow privileged users to modify 875 documents that they do not own, but the establishment and indication 876 of such policies is outside the scope of this document. 878 11. IANA Considerations 880 There are several IANA considerations associated with this 881 specification. 883 11.1. Geolocation Policy XML Schema Registration 885 URI: urn:ietf:params:xml:schema:geolocation-policy 887 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 888 (hannes.tschofenig@nsn.com). 890 XML: The XML schema to be registered is contained in Section 9. Its 891 first line is 893 895 and its last line is 897 899 11.2. Geolocation Policy Namespace Registration 901 URI: urn:ietf:params:xml:ns:geolocation-policy 903 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 904 (hannes.tschofenig@nsn.com). 906 XML: 908 BEGIN 909 910 912 913 914 916 Geolocation Policy Namespace 917 918 919

Namespace for Geolocation Authorization Policies

920

urn:ietf:params:xml:schema:geolocation-policy

921

See RFCXXXX 922 [NOTE TO IANA/RFC-EDITOR: 923 Please replace XXXX with the RFC number of this 924 specification.].

925 926 927 END 929 11.3. Geolocation Policy Location Profile Registry 931 This document seeks to create a registry of location profile names 932 for the Geolocation Policy framework. Profile names are XML tokens. 933 This registry will operate in accordance with RFC 2434 [13], 934 Standards Action. 936 This document defines the following profile names: 938 geodetic-condition: Defined in Section 4.1. 940 civic-condition: Defined in Section 4.2. 942 geodetic-transformation: Defined in Section 6.5.2. 944 civic-transformation: Defined in Section 6.5.1. 946 11.4. Basic Location Profile XML Schema Registration 948 URI: urn:ietf:params:xml:schema:basic-location-profiles 950 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 951 (hannes.tschofenig@nsn.com). 953 XML: The XML schema to be registered is contained in Section 8. Its 954 first line is 956 958 and its last line is 960 962 11.5. Basic Location Profile Namespace Registration 964 URI: urn:ietf:params:xml:ns:basic-location-profiles 966 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 967 (hannes.tschofenig@nsn.com). 969 XML: 971 BEGIN 972 973 975 976 977 979 Basic Location Profile Namespace 980 981 982

Namespace for Basic Location Profile

983

urn:ietf:params:xml:schema:basic-location-profiles

984

See RFCXXXX 985 [NOTE TO IANA/RFC-EDITOR: 986 Please replace XXXX with the RFC number of this 987 specification.].

988 989 990 END 992 11.6. XCAP Application Usage ID 994 This section registers an XCAP Application Usage ID (AUID) according 995 to the IANA procedures defined in [11]. 997 Name of the AUID: geolocation-policy 999 Description: Geolocation privacy rules are documents that describe 1000 the permissions that a Target has granted to Location Recipients that 1001 access information about his/her geographic location. 1003 12. Security Considerations 1005 This document aims to make it simple for users to prevent the 1006 unintended disclosure of private information to third parties. This 1007 is accomplished through the usage of authorization policies. 1008 Security requirements are described in [7] and a discussion of 1009 generic security threats is available with [14]. Aspects of 1010 combining permissions in cases of multiple occurrence are treated in 1011 [1]). 1013 When the Target is moving then the location transformations reveal 1014 information when switching from one privacy region to another one. 1015 For example, when a transformation indicates that civic location is 1016 provided at a 'building' level of granularity. Hence, room numbers, 1017 floors etc. would be hidden. However, when the Target moves from one 1018 building to the next one then the movement would still be 1019 recognizable as the disclosed location information would be reflected 1020 by the new civic location information indicating the new building. 1021 With additional knowledge about building entrances and streets it 1022 would be possible to learn a certain amont of information. It is 1023 therefore important to ensure that selected privacy regions are not 1024 chosen too small when mobility is a concern and that a random number 1025 to is added to the position of the Target, with an absolute value of 1026 half the privacy region. The latter aspect is only applicable for 1027 geodetic information or when geodetic information is translated to 1028 civic information by the Location Server. 1030 13. References 1032 13.1. Normative References 1034 [1] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 1035 J., and J. Rosenberg, "Common Policy: A Document Format for 1036 Expressing Privacy Preferences", RFC 4745, February 2007. 1038 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1039 Levels", March 1997. 1041 [3] OpenGIS, "OpenGIS Geography Markup Language (GML) 1042 Implementation Specification, Version 3.00, OGC 02 023r4", 1043 http://www.opengeospatial.org/docs/02-023r4.pdf, January 2003. 1045 [4] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1046 PIDF-LO Usage Clarification, Considerations and 1047 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work 1048 in progress), February 2008. 1050 [5] OpenGIS, "US National Imagery and Mapping Agency, "Department 1051 of Defense (DoD) World Geodetic System 1984 (WGS 84), Third 1052 Edition, NIMA TR8350.2", , January 2000. 1054 [6] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 1055 for Presence Information Data Format Location Object 1056 (PIDF-LO)", RFC 5139, February 2008. 1058 13.2. Informative References 1060 [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1061 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1063 [8] Peterson, J., "A Presence-based GEOPRIV Location Object 1064 Format", RFC 4119, December 2005. 1066 [9] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 1067 and Instant Messaging", RFC 2778, February 2000. 1069 [10] Peterson, J., "A Presence Architecture for the Distribution of 1070 GEOPRIV Location Objects", RFC 4079, July 2005. 1072 [11] Rosenberg, J., "The Extensible Markup Language (XML) 1073 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1075 [12] Rosenberg, J., "Presence Authorization Rules", RFC 5025, 1076 December 2007. 1078 [13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1079 Considerations Section in RFCs", BCP 26, RFC 2434, 1080 October 1998. 1082 [14] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat 1083 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 1085 [15] Thomson, M., "Geodetic Shapes for the Representation of 1086 Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03 1087 (work in progress), December 2006. 1089 [16] Thomson, M. and J. Winterbottom, "Representation of Uncertainty 1090 and Confidence in PIDF-LO", 1091 draft-thomson-geopriv-uncertainty-01 (work in progress), 1092 June 2008. 1094 Appendix A. Acknowledgments 1096 This document is informed by the discussions within the IETF GEOPRIV 1097 working group, including discussions at the GEOPRIV interim meeting 1098 in Washington, D.C., in 2003. 1100 We particularly want to thank Allison Mankin , 1101 Randall Gellens , Andrew Newton 1102 , Ted Hardie , Jon 1103 Peterson for their help in improving the 1104 quality of this document. 1106 We would like to thank Christian Guenther for his help with an 1107 earlier version of this document. Furthermore, we would like to 1108 thank Johnny Vrancken for his document reviews in September 2006, 1109 December 2006 and January 2007. James Winterbottom provided a 1110 detailed review in November 2006. Richard Barnes gave a detailed 1111 review in February 2008. 1113 This document uses text from [15]. Therefore, we would like to thank 1114 Martin Thomson for his work in [15]. We would also like to thank 1115 Martin Thomson, Matt Lepinski and Richard Barnes for their comments 1116 regarding the geodetic location transformation procedure. Richard 1117 provided us with a detailed text proposal. 1119 We would like to thank Dan Romascanu, Yoshiko Chong and Jari 1120 Urpalainen for their last call comments. 1122 Finally, we would like to thank the following individuals for their 1123 feedback as part of the IESG, GenArt, and SecDir review: Jari Arkko, 1124 Eric Gray, Russ Housley, Carl Reed, Martin Thomson, Lisa Dusseault, 1125 Chris Newman, Jon Peterson, Sam Hartman, Cullen Jennings, Tim Polk, 1126 and Brian Rosen. 1128 Authors' Addresses 1130 Henning Schulzrinne (editor) 1131 Columbia University 1132 Department of Computer Science 1133 450 Computer Science Building 1134 New York, NY 10027 1135 USA 1137 Phone: +1 212 939 7042 1138 Email: schulzrinne@cs.columbia.edu 1139 URI: http://www.cs.columbia.edu/~hgs 1141 Hannes Tschofenig (editor) 1142 Nokia Siemens Networks 1143 Linnoitustie 6 1144 Espoo 02600 1145 Finland 1147 Phone: +358 (50) 4871445 1148 Email: Hannes.Tschofenig@gmx.net 1149 URI: http://www.tschofenig.priv.at 1151 John B. Morris, Jr. 1152 Center for Democracy and Technology 1153 1634 I Street NW, Suite 1100 1154 Washington, DC 20006 1155 USA 1157 Email: jmorris@cdt.org 1158 URI: http://www.cdt.org 1160 Jorge R. Cuellar 1161 Siemens 1162 Otto-Hahn-Ring 6 1163 Munich, Bavaria 81739 1164 Germany 1166 Email: Jorge.Cuellar@siemens.com 1167 James Polk 1168 Cisco 1169 2200 East President George Bush Turnpike 1170 Richardson, Texas 75082 1171 USA 1173 Email: jmpolk@cisco.com 1175 Full Copyright Statement 1177 Copyright (C) The IETF Trust (2008). 1179 This document is subject to the rights, licenses and restrictions 1180 contained in BCP 78, and except as set forth therein, the authors 1181 retain all their rights. 1183 This document and the information contained herein are provided on an 1184 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1185 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1186 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1187 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1188 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1189 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1191 Intellectual Property 1193 The IETF takes no position regarding the validity or scope of any 1194 Intellectual Property Rights or other rights that might be claimed to 1195 pertain to the implementation or use of the technology described in 1196 this document or the extent to which any license under such rights 1197 might or might not be available; nor does it represent that it has 1198 made any independent effort to identify any such rights. Information 1199 on the procedures with respect to rights in RFC documents can be 1200 found in BCP 78 and BCP 79. 1202 Copies of IPR disclosures made to the IETF Secretariat and any 1203 assurances of licenses to be made available, or the result of an 1204 attempt made to obtain a general license or permission for the use of 1205 such proprietary rights by implementers or users of this 1206 specification can be obtained from the IETF on-line IPR repository at 1207 http://www.ietf.org/ipr. 1209 The IETF invites any interested party to bring to its attention any 1210 copyrights, patents or patent applications, or other proprietary 1211 rights that may cover technology that may be required to implement 1212 this standard. Please address the information to the IETF at 1213 ietf-ipr@ietf.org.