idnits 2.17.00 (12 Aug 2021) /tmp/idnits24714/draft-ietf-geopriv-policy-12.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 1248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1272. 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 (May 22, 2007) is 5477 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. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: draft-ietf-geopriv-revised-civic-lo has been published as RFC 5139 == Outdated reference: draft-ietf-simple-xcap has been published as RFC 4825 == Outdated reference: draft-ietf-simple-presence-rules has been published as RFC 5025 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '12') (Obsoleted by RFC 5226) 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: November 23, 2007 Nokia Siemens Networks 6 J. Morris 7 CDT 8 J. Cuellar 9 Siemens 10 J. Polk 11 Cisco 12 May 22, 2007 14 Geolocation Policy: A Document Format for Expressing Privacy Preferences 15 for Location Information 16 draft-ietf-geopriv-policy-12.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 November 23, 2007. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 This document defines an authorization policy language for controling 50 access to location information. It extends the Common Policy 51 authorization framework to provide location-specific access control. 52 More specifically, this document defines condition elements specific 53 to location information in order to restrict access based on the 54 current location of the Target. Furthermore, it offers location- 55 specific transformation elements to reduce the granularity of the 56 returned location information. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Structure of Geolocation Authorization Documents . . . . . 8 64 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 8 65 4. Location-specific Conditions . . . . . . . . . . . . . . . . . 9 66 4.1. Geodetic Location Condition Profile . . . . . . . . . . . 9 67 4.2. Civic Location Condition Profile . . . . . . . . . . . . . 10 68 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 12 71 6.2. Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 12 72 6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 12 73 6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 13 74 6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 13 75 6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 14 76 6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 15 77 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.1. Rule Example with Civic Location Condition . . . . . . . . 16 79 7.2. Rule Example with Geodetic Location Condition . . . . . . 17 80 7.3. Rule Example with Civic and Geodetic Location Condition . 18 81 7.4. Rule Example with Location-based Transformations . . . . . 19 82 8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 22 83 9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 23 84 10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 25 86 10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 25 87 10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 25 88 10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 25 89 10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 25 90 10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 25 91 10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 25 92 10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 26 93 10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 26 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 11.1. Geolocation Policy XML Schema Registration . . . . . . . . 27 97 11.2. Geolocation Policy Namespace Registration . . . . . . . . 27 98 11.3. Geolocation Policy Location Profile Registry . . . . . . . 28 99 11.4. Basic Location Profile XML Schema Registration . . . . . . 28 100 11.5. Basic Location Profile Namespace Registration . . . . . . 29 101 11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 29 102 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 105 13.2. Informative References . . . . . . . . . . . . . . . . . . 32 106 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 108 Intellectual Property and Copyright Statements . . . . . . . . . . 37 110 1. Introduction 112 Location information needs to be protected against unauthorized 113 access to preserve the privacy of humans. In RFC 3693 [6], a 114 protocol-independent model for access to geographic information is 115 defined. The model includes a Location Generator (LG) that 116 determines location information, a Location Server (LS) that 117 authorizes access to location information, a Location Recipient (LR) 118 that requests and receives location information, and a Rule Maker 119 (RM) that writes authorization policies. An authorization policy is 120 a set of rules that regulates an entity's activities with respect to 121 privacy-sensitive information, such as location information. 123 The data object containing location information in the context of 124 this document is referred to as a Location Object (LO). The basic 125 rule set defined in the Presence Information Data Format Location 126 Object (PIDF-LO) [7] can restrict how long the Location Recipient is 127 allowed to retain the information, and it can prohibit further 128 distribution. It also contains a reference to an enhanced rule set 129 and a human readable privacy policy. The basic rule set, however, 130 does not allow to control access to location information based on 131 specific Location Recipients. This document describes an enhanced 132 rule set that provides richer constraints on the distribution of LOs. 134 The rule set allows the entity that uses the rules defined in this 135 document to restrict the retention and to enforce access restrictions 136 on location data, including prohibiting any dissemination to 137 particular individuals, during particular times or when the Target is 138 located in a specific region. The RM can also stipulate that only 139 certain parts of the Location Object are to be distributed to 140 recipients or that the resolution of parts of the Location Object is 141 reduced. 143 The typical sequence of operations is as follows. A Location Server 144 receives a query for location information for a particular Target, 145 via the using protocol [6]. The using protocol provides the identity 146 of the requestor, either at the time of the query or when subscribing 147 to the location information. The authenticated identity of the 148 Location Recipient, together with other information provided by the 149 using protocol or generally available to the server, is then used for 150 searching through the rule set. If more than one rule matches the 151 condition element, then the combined permission is evaluated 152 according to the description in Section 10 of [1]. The result of the 153 rule evalation is applied to the location information, yielding a 154 possibly modified Location Object that is delivered to the Location 155 Recipient. 157 This document does not describe the protocol used to convey location 158 information from the Location Server to the Location Recipient (i.e., 159 the using protocol; see RFC 3693 [6]). 161 This document extends the Common Policy framework defined in [1]. 162 That document provides an abstract framework for expressing 163 authorization rules. As specified there, each such rule consists of 164 conditions, actions and transformations. Conditions determine under 165 which circumstances the entity executing the rules, for example a 166 Location Server, is permitted to apply actions and transformations. 167 Transformations regulate in a location information context how a 168 Location Server modifies the information elements that are returned 169 to the requestor, for example, by reducing the granularity of 170 returned location information. 172 The XML schema defined in Section 9 extends the Common Policy schema 173 by introducing new child elements to the condition and transformation 174 elements. This document does not define child elements for the 175 action part of a rule. 177 2. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [2]. 183 This document reuses the terminology of RFC 3693 [6], such as 184 Location Server (LS), Location Recipient (LR), Rule Maker (RM), 185 Target, Location Generator (LG) and Location Object (LO). This 186 document uses the following terminology: 188 Presentity or Target: 190 RFC 3693 [6] uses the term Target to identify the object or person 191 of which location information is required. The presence model 192 described in RFC 2778 [8] uses the term presentity to describe the 193 entity that provides presence information to a presence service. 194 A Presentity in a presence system is a Target in a location 195 information system. 197 Watcher or Location Recipient: 199 The receiver of location information is the Location Recipient 200 (LR) in the terminology of RFC 3693 [6]. A watcher in a presence 201 system, i.e., an entity that requests presence information about a 202 presentity, is a Location Recipient in a location information 203 system. 205 Authorization policy: 207 An authorization policy is given by a rule set. A rule set 208 contains an unordered list of (policy) rules. Each rule has a 209 condition, an action and a transformation component. 211 Permission: 213 The term permission refers to the action and transformation 214 components of a rule. 216 The term 'using protocol' is defined in [6] and refers to the 217 protocol that is used to request access to and to return privacy 218 sensitive data items. 220 In this document we use the term Location Servers as the entities 221 that evaluate the geolocation authorization policies. The 222 geolocation privacy architecture is, as motivated in RFC 4079 [9], 223 aligned with the presence architecture and a Presence Server is 224 therefore an entity that distributes location information along with 225 other presence-specific XML data elements. 227 3. Generic Processing 229 3.1. Structure of Geolocation Authorization Documents 231 A geolocation authorization document is an XML document, formatted 232 according to the schema defined in [1]. Geolocation authorization 233 documents inherit the MIME type of common policy documents, 234 application/auth-policy+xml. As described in [1], this document is 235 composed of rules which contain three parts - conditions, actions, 236 and transformations. Each action or transformation, which is also 237 called a permission, has the property of being a positive grant of 238 information to the Location Recipient. As a result, there is a well- 239 defined mechanism for combining actions and transformations obtained 240 from several sources. This mechanism is privacy safe, since the lack 241 of any action or transformation can only result in less information 242 being presented to a Location Recipient. 244 3.2. Rule Transport 246 There are two ways how the authorization rules described in this 247 document may be conveyed between different parties: 249 o RFC 4119 [7] allows enhanced authorization policies to be 250 referenced via a Uniform Resource Locator (URL) in the 'ruleset- 251 reference' element. The ruleset-reference' element is part of the 252 basic rules that always travel with the Location Object. 254 o Authorization policies might, for example, also be stored at a 255 Location Server / Presence Server. The Rule Maker therefore needs 256 to use a protocol to create, modify and delete the authorization 257 policies defined in this document. Such a protocol is available 258 with the Extensible Markup Language (XML) Configuration Access 259 Protocol (XCAP) [10]. 261 4. Location-specific Conditions 263 This section describes the location-specific conditions of a rule, 264 namely the civic and geodetic location conditions. The 265 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 268 of the element must evaluate to TRUE in order for the 269 element to be TRUE. The element 270 MUST contain at least one child element. The element evaluates to TRUE if any of its child elements is 272 TRUE, i.e., a logical OR. 274 A location profile needs to describe under what conditions each 275 element evaluates to TRUE. This document defines two 276 location profiles, one civic and one geodetic location profile. 278 The and the elements provide 279 extension points. If an extension is not understood by the entity 280 evaluating the rules then this rule evaluates to FALSE. 282 4.1. Geodetic Location Condition Profile 284 The geodetic location profile is identified by the token 'geodetic- 285 condition'. Rule Makers use this profile by placing a GML [3] 286 element within the element. 288 The element containing the information for the geodetic 289 location profile evaluates to TRUE if the current location of the 290 Target is within the described Polygon. This might require a point- 291 in-polygon, polygon-in-polygon, or a similar computation. If the 292 geodetic location of the Target is unknown then the 293 element containing the information for the geodetic location profile 294 evaluates to FALSE. 296 The polygon that uses the "gml:Polygon" element is specified by a 297 sequence of points. A polygon requires at least four points, where 298 the first and last point MUST be the same. 300 Implementations are REQUIRED to support the following coordinate 301 reference systems based on WGS 84 [4]. These are identified using 302 the European Petroleum Survey Group (EPSG) Geodetic Parameter 303 Dataset, as formalized by the Open Geospatial Consortium (OGC): 305 2D: WGS 84 (latitude, longitude), as identified by the URN 306 "urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS. 308 3D: WGS 84 (latitude, longitude, altitude), as identified by the URN 309 "urn:ogc:def:crs:EPSG::4979". This is a three dimensional CRS. 311 A CRS MUST be specified using the above URN notation only, 312 implementations do not need to support user-defined CRSs. 314 Implementations MUST specify the CRS using the "srsName" attribute on 315 the outermost geometry element. The CRS MUST NOT be changed for any 316 sub-elements. The "srsDimension" attribute MUST be omitted, since 317 the number of dimensions in these CRSs is known. 319 Points specified in a polygon MUST be coplanar. However, 320 implementations SHOULD be prepared to accept small variations that 321 might occur depending on whether the the polygon is specified on a 322 plane in space, or only relative to the ellipsoid. To avoid 323 implementation complexity, implementations MAY choose to not support 324 polygons that include varying altitude. Therefore, two polygon forms 325 are permitted: polygons specified using EPSG 4326, and polygons 326 specified using EPSG 4979 with a constant altitude value. 328 Interpolation between points is linear, as defined for the "gml: 329 LinearRing" element. Implementations SHOULD minimize this 330 interpolation error by ensuring that the sides of polygons are as 331 short as possible. 333 4.2. Civic Location Condition Profile 335 The civic location profile is identified by the token 'civic- 336 condition'. Rule Makers use this profile by placing a 337 element, defined in [5], within the element. 339 All child elements of element that carry civicAddress 340 elements MUST evaluate to TRUE (i.e., logical AND) in order for the 341 element to evaluate to TRUE. For each element value a 342 string-by-string comparison is performed. 344 If the civic location of the Target is unknown, then the 345 element containing the information for the civic location profile 346 evaluates to FALSE. This case may occur, for example, if location 347 information has been removed by earlier transmitters of location 348 information or if only the geodetic location is known. 350 5. Actions 352 This document does not define location-specific actions. 354 6. Transformations 356 This document defines several elements that allow Rule Makers to 357 specify transformations that 359 o reduce the accuracy of the returned location information, and 361 o set the basic authorization policies carried inside the PIDF-LO. 363 6.1. Set Retransmission-Allowed 365 This element asks the LS to change or set the value of the 366 element in the PIDF-LO. The data type of 367 the element is a boolean. 369 If the value of the element is set to 370 TRUE then the element in the PIDF-LO MUST be 371 set to TRUE. If the value of the 372 element is set to FALSE, then the element in 373 the PIDF-LO MUST be set to FALSE. 375 If the element is absent then the value 376 of the element in the PIDF-LO MUST be kept 377 unchanged or, if the PIDF-LO is created for the first time, then the 378 value MUST be set to FALSE. 380 6.2. Set Retention-Expiry 382 This transformation asks the LS to change or set the value of the 383 element in the PIDF-LO. The data type of the 384 element is an integer. 386 The value provided with the element indicates 387 seconds and these seconds are added to the current date. 389 If the element is absent then the value of the 390 element in the PIDF-LO is kept unchanged or, if 391 the PIDF-LO is created for the first time, then the value MUST be set 392 to the current date. 394 6.3. Set Note-Well 396 This transformation asks the LS to change or set the value of the 397 element in the PIDF-LO. The data type of the element is a string. 400 The value provided with the element contains a 401 privacy statement as a human readable text string and an 'xml:lang' 402 attribute denotes the language of the human readable text. 404 If the element is absent, then the value of the 405 element in the PIDF-LO is kept unchanged or, if the 406 PIDF-LO is created for the first time, then no content is provided 407 for the element. 409 6.4. Keep Ruleset Reference 411 This transformation allows to influence whether the element in the PIDF-LO carries the extended authorization 413 rules defined in [1]. The data type of the 414 element is Boolean. 416 If the value of the element is set to TRUE, 417 then the element in the PIDF-LO is kept unchanged 418 when included. If the value of the element is 419 set to FALSE, then the element in the PIDF-LO MUST 420 NOT contain a reference. The reference to the ruleset is removed and 421 no rules are carried as MIME bodies (in case of CID URIs). 423 If the element is absent, then the value of the 424 element in the PIDF-LO is kept unchanged when 425 available or, if the PIDF-LO is created for the first time then the 426 element MUST NOT be included. 428 6.5. Provide Location 430 The element contains child elements of a specific 431 location profile that controls the granularity of returned location 432 information. This document defines two location profiles, namely: 434 o If the element has a child 435 element then civic location information is disclosed as described 436 in Section 6.5.1, subject to availability. 438 o If the element has a child 439 element then geodetic location information is disclosed as 440 described in Section 6.5.2, subject to availability. 442 The element MUST contain the 'profile' attribute 443 if it contains child elements and the 'profile' attribute MUST match 444 with the contained child elements. The element 445 MUST contain the 'profile' attribute if it contains child elements. 447 If the element has no child elements then civic, 448 as well as, geodetic location information is disclosed without 449 reducing its granularity, subject to availability. In this case the 450 profile attribute MUST NOT be included. 452 6.5.1. Civic Location Profile 454 This profile uses the token 'civic-transformation'. This profile 455 allows civic location transformations to be specified by means of the 456 element that restricts the level of civic location 457 information the LS is permitted to disclose. The symbols of these 458 levels are: 'country', 'region', 'city', 'building', 'full'. Each 459 level is given by a set of civic location data items such as 460 and , ..., , as defined in [5]. Each level 461 includes all elements included by the lower levels. 463 The 'country' level includes only the element; the 'region' 464 level adds the element; the 'city' level adds the and 465 elements; the 'building' level and the 'full' level add further civic 466 location data as shown below. 468 full 469 {, , , , , , , , , 470 , , , , , , , , 471 ,,,, , , , 472 , , , , } 473 | 474 | 475 building 476 {, , , , , , , 477 , , , , , , 478 , , , , } 479 | 480 | 481 city 482 {, , , } 483 | 484 | 485 region 486 {, } 487 | 488 | 489 country 490 {} 491 | 492 | 493 none 494 {} 496 The default value is "none". 498 The schema of the element is defined in Section 8. 500 6.5.2. Geodetic Location Profile 502 This profile uses the token 'geodetic-transformation' and refers only 503 to the Coordinate Reference System (CRS) WGS 84 504 (urn:ogc:def:crs:EPSG::4326, 2D) and WGS 84 505 (urn:ogc:def:crs:EPSG::4979, 3D). This profile allows geodetic 506 location transformations to be specified by means of the element that restricts the resolution of geodetic location 508 information based on the value provided in the , 509 and child elements of 510 the element. The resolution is specified as a real 511 number r. Assume that the variable n represents the nominal 512 coordinate value (longitude, latitude or altitude), the rounded value 513 is computed as 515 n'=FLOOR(n*r + 0.5) * 1/r 517 Small r values indicate that the granularity of the returned location 518 information will be reduced. The smaller the value r is the larger 519 is the granularity reduction. The value '0' is used to indicate that 520 location MUST NOT be distributed. Per default the value '0' is 521 assumed. A large r value indicates that a large amount of the 522 available location information will be distributed. The larger the 523 value r is the more precise the returned location information is. 524 The maximum is infinity, the symbol "INF", indicating that the 525 available information is disclosed without reduction of the 526 granularity. 528 Next, we show an example where we assume a nominal latitude value of 529 n=38.89868. 531 Value r Computed n' 532 --------------------------- 533 0.01 89.0000 534 0.1 43.9000 535 1 39.4000 536 10 38.9490 537 100 38.9037 539 The schema of the element is defined in Section 8. 541 7. Examples 543 This section provides a few examples for authorization rules using 544 the extensions defined in this document. 546 7.1. Rule Example with Civic Location Condition 548 This example illustrates a single rule that employs the civic 549 location condition. It matches if the current location of the Target 550 equal the content of the child elements of the element. 551 Requests match only if the Target is at a civic location with country 552 set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to 553 'Munich', city division (A4) set to 'Perlach', street name (A6) set 554 to 'Otto-Hahn-Ring' and house number (HNO) set to '6'. 556 No actions and transformation child elements are provided in this 557 rule example. The actions and transformation could include presence 558 specific information when the Geolocation Policy framework is applied 559 to the Presence Policy framework (see [11]). 561 562 565 566 567 568 570 DE 571 Bavaria 572 Munich 573 Perlach 574 Otto-Hahn-Ring 575 6 576 577 578 579 580 581 582 584 7.2. Rule Example with Geodetic Location Condition 586 This example illustrates a rule that employs the geodetic location 587 condition. The rule matches if the current location of the Target is 588 inside the area specified by the polygon. The polygon uses the EPSG 589 4326 coordinate reference system. No altitude is included in this 590 example. 592 593 596 597 598 599 600 603 604 605 42.556844 -73.248157 606 42.549631 -73.237283 607 42.539087 -73.240328 608 42.535756 -73.254242 609 42.542969 -73.265115 610 42.553513 -73.262075 611 42.556844 -73.248157 612 613 614 615 616 617 618 619 620 622 The following alternative example shows the same polygon with a 623 constant altitude included that is specified using EPSG 4979 and the 624 "gml:posList" element. The "gml:posList" element is interpreted as a 625 list with the dimension of the CRS indicating how many values are 626 required for each point. 628 629 632 633 634 635 636 639 640 641 642 42.556844 -73.248157 36.6 643 42.549631 -73.237283 36.6 644 42.539087 -73.240328 36.6 645 42.535756 -73.254242 36.6 646 42.542969 -73.265115 36.6 647 42.553513 -73.262075 36.6 648 42.556844 -73.248157 36.6 649 650 651 652 653 654 655 656 657 658 659 661 7.3. Rule Example with Civic and Geodetic Location Condition 663 This example illustrates a rule that employs a mixed civic and 664 geodetic location condition. Depending on the available type of 665 location information, namely civic or geodetic location information, 666 one of the location elements may match. 668 669 672 673 674 675 677 DE 678 Bavaria 679 Munich 680 Perlach 681 Otto-Hahn-Ring 682 6 683 684 685 688 689 690 42.556844 -73.248157 691 42.549631 -73.237283 692 42.539087 -73.240328 693 42.535756 -73.254242 694 42.542969 -73.265115 695 42.553513 -73.262075 696 42.556844 -73.248157 697 698 699 700 701 702 703 704 705 706 708 7.4. Rule Example with Location-based Transformations 710 This example shows the transformations specified in this document. 711 The element indicates that the available civic 712 location information is reduced to building level granularity. If 713 geodetic location information is requested then a granularity 714 reduction is provided as well. 716 717 721 722 723 724 725 false 726 727 86400 728 My privacy policy goes in here. 729 730 false 731 733 735 building 736 738 740 741 0.01 742 743 0.01 744 745 0.01 746 747 749 751 752 753 755 The following rule describes the short-hand notation for making the 756 current location of the Target available to Location Recipients 757 without granularity reduction. 759 760 763 764 765 766 767 768 769 770 772 8. XML Schema for Basic Location Profiles 774 This section defines the location profiles used as child elements of 775 the transformation element. 777 778 784 786 787 788 789 790 791 792 793 794 795 796 797 799 801 802 803 804 807 810 813 814 815 817 819 9. XML Schema for Geolocation Policy 821 This section presents the XML schema that defines the Geolocation 822 Policy schema described in this document. The Geolocation Policy 823 schema extends the Common Policy schema (see [1]) by introducing new 824 members of the 'condition' and 'transformation' substitution groups 825 whose heads (namely the elements and ). 827 828 835 836 838 839 842 844 847 848 849 850 851 853 855 856 857 858 860 861 862 863 864 867 868 869 870 871 873 874 876 878 880 883 886 887 888 889 890 891 892 894 895 896 897 898 900 901 902 903 904 906 908 10. XCAP Usage 910 The following section defines the details necessary for clients to 911 manipulate geolocation privacy documents from a server using XCAP. 912 If used as part of a presence system, it uses the same AUID as those 913 rules. See [11] for a description of the XCAP usage in context with 914 presence authorization rules. 916 10.1. Application Unique ID 918 XCAP requires application usages to define a unique application usage 919 ID (AUID) in either the IETF tree or a vendor tree. This 920 specification defines the "geolocation-policy" AUID within the IETF 921 tree, via the IANA registration in Section 11. 923 10.2. XML Schema 925 XCAP requires application usages to define a schema for their 926 documents. The schema for geolocation authorization documents is 927 described in Section 9. 929 10.3. Default Namespace 931 XCAP requires application usages to define the default namespace for 932 their documents. The default namespace is 933 urn:ietf:params:xml:ns:geolocation-policy. 935 10.4. MIME Type 937 XCAP requires application usages to defined the MIME type for 938 documents they carry. Geolocation privacy authorization documents 939 inherit the MIME type of common policy documents, application/ 940 auth-policy+xml. 942 10.5. Validation Constraints 944 This specification does not define additional constraints. 946 10.6. Data Semantics 948 This document discusses the semantics of a geolocation privacy 949 authorization. 951 10.7. Naming Conventions 953 When a Location Server receives a request to access location 954 information of some user foo, it will look for all documents within 955 http://[xcaproot]/geolocation-policy/users/foo, and use all documents 956 found beneath that point to guide authorization policy. 958 10.8. Resource Interdependencies 960 This application usage does not define additional resource 961 interdependencies. 963 10.9. Authorization Policies 965 This application usage does not modify the default XCAP authorization 966 policy, which is that only a user can read, write or modify his/her 967 own documents. A server can allow privileged users to modify 968 documents that they do not own, but the establishment and indication 969 of such policies is outside the scope of this document. 971 11. IANA Considerations 973 There are several IANA considerations associated with this 974 specification. 976 11.1. Geolocation Policy XML Schema Registration 978 URI: urn:ietf:params:xml:schema:geolocation-policy 980 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 981 (hannes.tschofenig@nsn.com). 983 XML: The XML schema to be registered is contained in Section 9. Its 984 first line is 986 988 and its last line is 990 992 11.2. Geolocation Policy Namespace Registration 994 URI: urn:ietf:params:xml:ns:geolocation-policy 996 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 997 (hannes.tschofenig@nsn.com). 999 XML: 1001 BEGIN 1002 1003 1005 1006 1007 1009 Geolocation Policy Namespace 1010 1011 1012

Namespace for Geolocation Authorization Policies

1013

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

1014

See RFCXXXX 1015 [NOTE TO IANA/RFC-EDITOR: 1016 Please replace XXXX with the RFC number of this 1017 specification.].

1018 1019 1020 END 1022 11.3. Geolocation Policy Location Profile Registry 1024 This document seeks to create a registry of location profile names 1025 for the Geolocation Policy framework. Profile names are XML tokens. 1026 This registry will operate in accordance with RFC 2434 [12], 1027 Standards Action. 1029 This document defines the following profile names: 1031 geodetic-condition: Defined in Section 4.1. 1033 civic-condition: Defined in Section 4.2. 1035 geodetic-transformation: Defined in Section 6.5.2. 1037 civic-transformation: Defined in Section 6.5.1. 1039 11.4. Basic Location Profile XML Schema Registration 1041 URI: urn:ietf:params:xml:schema:basic-location-profiles 1043 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 1044 (hannes.tschofenig@nsn.com). 1046 XML: The XML schema to be registered is contained in Section 8. Its 1047 first line is 1049 1051 and its last line is 1053 1055 11.5. Basic Location Profile Namespace Registration 1057 URI: urn:ietf:params:xml:ns:basic-location-profiles 1059 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 1060 (hannes.tschofenig@nsn.com). 1062 XML: 1064 BEGIN 1065 1066 1068 1069 1070 1072 Basic Location Profile Namespace 1073 1074 1075

Namespace for Basic Location Profile

1076

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

1077

See RFCXXXX 1078 [NOTE TO IANA/RFC-EDITOR: 1079 Please replace XXXX with the RFC number of this 1080 specification.].

1081 1082 1083 END 1085 11.6. XCAP Application Usage ID 1087 This section registers an XCAP Application Usage ID (AUID) according 1088 to the IANA procedures defined in [10]. 1090 Name of the AUID: geolocation-policy 1092 Description: Geolocation privacy rules are documents that describe 1093 the permissions that a Target has granted to Location Recipients that 1094 access information about his/her geographic location. 1096 12. Security Considerations 1098 This document aims to make it simple for users to prevent the 1099 unintended disclosure of private information to third parties. This 1100 is accomplished through the usage of authorization policies. 1101 Security requirements are described in [6] and a discussion of 1102 generic security threats is available with [13]. Aspects of 1103 combining permissions in cases of multiple occurrence are treated in 1104 [1]). The concept of location-based conditions are introduced in 1105 Section 4 and mechanisms to reduce the granularity of returned 1106 location information is specified in Section 6. 1108 13. References 1110 13.1. Normative References 1112 [1] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 1113 J., and J. Rosenberg, "Common Policy: A Document Format for 1114 Expressing Privacy Preferences", RFC 4745, February 2007. 1116 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1117 Levels", March 1997. 1119 [3] OpenGIS, "OpenGIS Geography Markup Language (GML) 1120 Implementation Specification, Version 3.00, OGC 02 023r4", 1121 http://www.opengeospatial.org/docs/02-023r4.pdf, January 2003. 1123 [4] OpenGIS, "US National Imagery and Mapping Agency, "Department 1124 of Defense (DoD) World Geodetic System 1984 (WGS 84), Third 1125 Edition, NIMA TR8350.2", , January 2000. 1127 [5] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 1128 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in 1129 progress), February 2007. 1131 13.2. Informative References 1133 [6] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1134 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1136 [7] Peterson, J., "A Presence-based GEOPRIV Location Object 1137 Format", RFC 4119, December 2005. 1139 [8] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 1140 and Instant Messaging", RFC 2778, February 2000. 1142 [9] Peterson, J., "A Presence Architecture for the Distribution of 1143 GEOPRIV Location Objects", RFC 4079, July 2005. 1145 [10] Rosenberg, J., "The Extensible Markup Language (XML) 1146 Configuration Access Protocol (XCAP)", 1147 draft-ietf-simple-xcap-12 (work in progress), October 2006. 1149 [11] Rosenberg, J., "Presence Authorization Rules", 1150 draft-ietf-simple-presence-rules-09 (work in progress), 1151 March 2007. 1153 [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1154 Considerations Section in RFCs", BCP 26, RFC 2434, 1155 October 1998. 1157 [13] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat 1158 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 1160 [14] Thomson, M., "Geodetic Shapes for the Representation of 1161 Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03 1162 (work in progress), December 2006. 1164 Appendix A. Acknowledgments 1166 This document is informed by the discussions within the IETF GEOPRIV 1167 working group, including discussions at the GEOPRIV interim meeting 1168 in Washington, D.C., in 2003. 1170 We particularly want to thank Allison Mankin , 1171 Randall Gellens , Andrew Newton 1172 , Ted Hardie , Jon 1173 Peterson for their help in improving the 1174 quality of this document. 1176 We would like to thank Christian Guenther for his help with an 1177 earlier version of this document. Furthermore, we would like to 1178 thank Johnny Vrancken for his document reviews in September 2006, 1179 December 2006 and January 2007. James Winterbottom provided a 1180 detailed review in November 2006. 1182 This document uses text from [14]. Therefore, we would like to thank 1183 Martin Thomson for his work in [14]. 1185 We would like to thank Dan Romascanu, Yoshiko Chong and Jari 1186 Urpalainen for their last call comments. 1188 Authors' Addresses 1190 Henning Schulzrinne (editor) 1191 Columbia University 1192 Department of Computer Science 1193 450 Computer Science Building 1194 New York, NY 10027 1195 USA 1197 Phone: +1 212 939 7042 1198 Email: schulzrinne@cs.columbia.edu 1199 URI: http://www.cs.columbia.edu/~hgs 1201 Hannes Tschofenig (editor) 1202 Nokia Siemens Networks 1203 Otto-Hahn-Ring 6 1204 Munich, Bavaria 81739 1205 Germany 1207 Email: Hannes.Tschofenig@nsn.com 1208 URI: http://www.tschofenig.com 1210 John B. Morris, Jr. 1211 Center for Democracy and Technology 1212 1634 I Street NW, Suite 1100 1213 Washington, DC 20006 1214 USA 1216 Email: jmorris@cdt.org 1217 URI: http://www.cdt.org 1219 Jorge R. Cuellar 1220 Siemens 1221 Otto-Hahn-Ring 6 1222 Munich, Bavaria 81739 1223 Germany 1225 Email: Jorge.Cuellar@siemens.com 1226 James Polk 1227 Cisco 1228 2200 East President George Bush Turnpike 1229 Richardson, Texas 75082 1230 USA 1232 Email: jmpolk@cisco.com 1234 Full Copyright Statement 1236 Copyright (C) The IETF Trust (2007). 1238 This document is subject to the rights, licenses and restrictions 1239 contained in BCP 78, and except as set forth therein, the authors 1240 retain all their rights. 1242 This document and the information contained herein are provided on an 1243 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1244 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1245 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1246 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1247 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1248 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1250 Intellectual Property 1252 The IETF takes no position regarding the validity or scope of any 1253 Intellectual Property Rights or other rights that might be claimed to 1254 pertain to the implementation or use of the technology described in 1255 this document or the extent to which any license under such rights 1256 might or might not be available; nor does it represent that it has 1257 made any independent effort to identify any such rights. Information 1258 on the procedures with respect to rights in RFC documents can be 1259 found in BCP 78 and BCP 79. 1261 Copies of IPR disclosures made to the IETF Secretariat and any 1262 assurances of licenses to be made available, or the result of an 1263 attempt made to obtain a general license or permission for the use of 1264 such proprietary rights by implementers or users of this 1265 specification can be obtained from the IETF on-line IPR repository at 1266 http://www.ietf.org/ipr. 1268 The IETF invites any interested party to bring to its attention any 1269 copyrights, patents or patent applications, or other proprietary 1270 rights that may cover technology that may be required to implement 1271 this standard. Please address the information to the IETF at 1272 ietf-ipr@ietf.org. 1274 Acknowledgment 1276 Funding for the RFC Editor function is provided by the IETF 1277 Administrative Support Activity (IASA).