idnits 2.17.00 (12 Aug 2021) /tmp/idnits39194/draft-ietf-geopriv-policy-25.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors 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 (October 14, 2011) is 3871 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) -- Looks like a reference, but probably isn't: '0' on line 1725 -- Looks like a reference, but probably isn't: '1' on line 1725 -- Possible downref: Non-RFC (?) normative reference: ref. 'GML' == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-06 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 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: April 16, 2012 Nokia Siemens Networks 6 J. Cuellar 7 Siemens 8 J. Polk 9 Cisco 10 J. Morris 12 M. Thomson 13 Commscope 14 October 14, 2011 16 Geolocation Policy: A Document Format for Expressing Privacy Preferences 17 for Location Information 18 draft-ietf-geopriv-policy-25.txt 20 Abstract 22 This document defines an authorization policy language for 23 controlling access to location information. It extends the Common 24 Policy authorization framework to provide location-specific access 25 control. More specifically, this document defines condition elements 26 specific to location information in order to restrict access based on 27 the current location of the Target. 29 Furthermore, this document defines two algorithms for reducing the 30 granularity of returned location information. The first algorithm is 31 defined for usage with civic location information while the other one 32 applies to geodetic location information. Both algorithms come with 33 limitations, i.e. they provide location obfuscation under certain 34 conditions and may therefore not be appropriate for all application 35 domains. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 16, 2012. 54 Copyright Notice 56 Copyright (c) 2011 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 8 74 3.1. Structure of Geolocation Authorization Documents . . . . . 8 75 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 8 76 4. Location-specific Conditions . . . . . . . . . . . . . . . . . 9 77 4.1. Geodetic Location Condition Profile . . . . . . . . . . . 9 78 4.2. Civic Location Condition Profile . . . . . . . . . . . . . 10 79 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 12 82 6.2. Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 12 83 6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 12 84 6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 13 85 6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 13 86 6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 14 87 6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 15 88 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 7.1. Rule Example with Civic Location Condition . . . . . . . . 18 90 7.2. Rule Example with Geodetic Location Condition . . . . . . 19 91 7.3. Rule Example with Civic and Geodetic Location Condition . 19 92 7.4. Rule Example with Location-based Transformations . . . . . 20 93 7.5. Location Obfuscation Example . . . . . . . . . . . . . . . 22 94 8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 26 95 9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 27 96 10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 29 97 10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 29 98 10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 29 99 10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 29 100 10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 29 101 10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 29 102 10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 29 103 10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 29 104 10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 30 105 10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 30 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 107 11.1. Geolocation Policy XML Schema Registration . . . . . . . . 31 108 11.2. Geolocation Policy Namespace Registration . . . . . . . . 31 109 11.3. Geolocation Policy Location Profile Registry . . . . . . . 32 110 11.4. Basic Location Profile XML Schema Registration . . . . . . 32 111 11.5. Basic Location Profile Namespace Registration . . . . . . 33 112 11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 33 113 12. Internationalization Considerations . . . . . . . . . . . . . 35 114 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 115 13.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 36 116 13.2. Obfuscation . . . . . . . . . . . . . . . . . . . . . . . 36 117 13.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 38 118 13.4. Location Obscuring Limitations . . . . . . . . . . . . . . 39 119 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 120 14.1. Normative References . . . . . . . . . . . . . . . . . . . 40 121 14.2. Informative References . . . . . . . . . . . . . . . . . . 40 122 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42 123 Appendix B. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . 43 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 126 1. Introduction 128 Location information needs to be protected against unauthorized 129 access to preserve the privacy of humans. In RFC 3693 [RFC3693], a 130 protocol-independent model for access to geographic information is 131 defined. The model includes a Location Generator (LG) that 132 determines location information, a Location Server (LS) that 133 authorizes access to location information, a Location Recipient (LR) 134 that requests and receives location information, and a Rule Maker 135 (RM) that writes authorization policies. An authorization policy is 136 a set of rules that regulates an entity's activities with respect to 137 privacy-sensitive information, such as location information. 139 The data object containing location information in the context of 140 this document is referred to as a Location Object (LO). The basic 141 rule set defined in the Presence Information Data Format Location 142 Object (PIDF-LO) [RFC4119] can restrict how long the Location 143 Recipient is allowed to retain the information, and it can prohibit 144 further distribution. It also contains a reference to an enhanced 145 rule set and a human readable privacy policy. The basic rule set, 146 however, does not allow to control access to location information 147 based on specific Location Recipients. This document describes an 148 enhanced rule set that provides richer constraints on the 149 distribution of LOs. 151 The rule set allows the entity that uses the rules defined in this 152 document to restrict the retention and to enforce access restrictions 153 on location data, including prohibiting any dissemination to 154 particular individuals, during particular times or when the Target is 155 located in a specific region. The RM can also stipulate that only 156 certain parts of the Location Object are to be distributed to 157 recipients or that the resolution of parts of the Location Object is 158 reduced. 160 The typical sequence of operations is as follows. A Location Server 161 receives a query for location information for a particular Target. 162 The requestor's identity will likely be revealed as part of this 163 request for location information. The authenticated identity of the 164 Location Recipient, together with other information provided with the 165 request or generally available to the server, is then used for 166 searching through the rule set. If more than one rule matches the 167 condition element, then the combined permission is evaluated 168 according to the description in Section 10 of [RFC4745]. The result 169 of the rule evalation is applied to the location information, 170 yielding a possibly modified Location Object that is delivered to the 171 Location Recipient. 173 This document does not describe the protocol used to convey location 174 information from the Location Server to the Location Recipient. 176 This document extends the Common Policy framework defined in 177 [RFC4745]. That document provides an abstract framework for 178 expressing authorization rules. As specified there, each such rule 179 consists of conditions, actions and transformations. Conditions 180 determine under which circumstances the entity executing the rules, 181 for example a Location Server, is permitted to apply actions and 182 transformations. Transformations regulate in a location information 183 context how a Location Server modifies the information elements that 184 are returned to the requestor, for example, by reducing the 185 granularity of returned location information. 187 This document defines two algorithms for reducing the granularity of 188 returned location information. The first algorithm is defined for 189 usage with civic location information (see Section 6.5.1) while the 190 other one applies to geodetic location information (see 191 Section 6.5.2). Both algorithms come with limitations, i.e. they 192 provide location obfuscation under certain conditions and may 193 therefore not be appropriate for all application domains. These 194 limitations are documented within the security consideration section 195 (see Section 13). It is worth pointing out that the geodetic 196 transformation algorithm Section 6.5.2 deals with privacy risks 197 related to targets that are stationary, as well as to moving targets. 198 However, with respect to movement there are restriction as to what 199 information can be hidden from an adversary. To cover applications 200 that have more sophisticated privacy requirements additional 201 algorithms may need to be defined. This document forsees extensions 202 in the form of new algorithms and therefore defines a registy (see 203 Section 11.3). 205 The XML schema defined in Section 9 extends the Common Policy schema 206 by introducing new child elements to the condition and transformation 207 elements. This document does not define child elements for the 208 action part of a rule. 210 2. Terminology 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 214 document are to be interpreted as described in RFC 2119 [RFC2119]. 216 This document reuses the terminology of RFC 3693 [RFC3693], such as 217 Location Server (LS), Location Recipient (LR), Rule Maker (RM), 218 Target, Location Generator (LG) and Location Object (LO). This 219 document uses the following terminology: 221 Presentity or Target: 223 RFC 3693 [RFC3693] uses the term Target to identify the object or 224 person of which location information is required. The presence 225 model described in RFC 2778 [RFC2778] uses the term presentity to 226 describe the entity that provides presence information to a 227 presence service. A Presentity in a presence system is a Target 228 in a location information system. 230 Watcher or Location Recipient: 232 The receiver of location information is the Location Recipient 233 (LR) in the terminology of RFC 3693 [RFC3693]. A watcher in a 234 presence system, i.e., an entity that requests presence 235 information about a presentity, is a Location Recipient in a 236 location information system. 238 Authorization policy: 240 An authorization policy is given by a rule set. A rule set 241 contains an unordered list of (policy) rules. Each rule has a 242 condition, an action and a transformation component. 244 Permission: 246 The term permission refers to the action and transformation 247 components of a rule. 249 In this document we use the term Location Servers as the entities 250 that evaluate the geolocation authorization policies. The 251 geolocation privacy architecture is, as motivated in RFC 4079 252 [RFC4079], aligned with the presence architecture and a Presence 253 Server is therefore an entity that distributes location information 254 along with other presence-specific XML data elements. 256 3. Generic Processing 258 3.1. Structure of Geolocation Authorization Documents 260 A geolocation authorization document is an XML document, formatted 261 according to the schema defined in [RFC4745]. Geolocation 262 authorization documents inherit the MIME type of common policy 263 documents, application/auth-policy+xml. As described in [RFC4745], 264 this document is composed of rules which contain three parts - 265 conditions, actions, and transformations. Each action or 266 transformation, which is also called a permission, has the property 267 of being a positive grant of information to the Location Recipient. 268 As a result, there is a well-defined mechanism for combining actions 269 and transformations obtained from several sources. This mechanism is 270 privacy safe, since the lack of any action or transformation can only 271 result in less information being presented to a Location Recipient. 273 3.2. Rule Transport 275 There are two ways how the authorization rules described in this 276 document may be conveyed between different parties: 278 o RFC 4119 [RFC4119] allows enhanced authorization policies to be 279 referenced via a Uniform Resource Locator (URL) in the 'ruleset- 280 reference' element. The ruleset-reference' element is part of the 281 basic rules that always travel with the Location Object. 283 o Authorization policies might, for example, also be stored at a 284 Location Server / Presence Server. The Rule Maker therefore needs 285 to use a protocol to create, modify and delete the authorization 286 policies defined in this document. Such a protocol is available 287 with the Extensible Markup Language (XML) Configuration Access 288 Protocol (XCAP) [RFC4825]. 290 4. Location-specific Conditions 292 This section describes the location-specific conditions of a rule. 293 The element contains zero, one or an unbounded number of 294 child element(s). Providing more than one 295 element may not be useful since all child 296 elements of the element must evaluate to TRUE in order 297 for the element to be TRUE. The 298 element MUST contain at least one child element. The 299 element evaluates to TRUE if any of its child 300 elements is TRUE, i.e., a logical OR. 302 The element has three attributes, namely 'profile', 'xml: 303 lang' and 'label'. The 'profile' attribute allows to indicate the 304 location profile that is included as child elements in the 305 element and each profile needs to describe under what conditions each 306 element evaluates to TRUE. This document defines two 307 location profiles, one civic and one geodetic location profile, see 308 Section 4.1 and Section 4.2. The 'label' attribute allows a human 309 readable description to be added to each element. The 310 'xml:lang' attribute contains a language tag providing further 311 information for rendering of the content of the 'label' attribute. 313 The and the elements provide 314 extension points. If an extension is not understood by the entity 315 evaluating the rules then this rule evaluates to FALSE. 317 4.1. Geodetic Location Condition Profile 319 The geodetic location profile is identified by the token 'geodetic- 320 condition'. Rule Makers use this profile by placing a GML [GML] 321 element within the element (as described in 322 Section 5.2.3 of [RFC5491]). 324 The element containing the information for the geodetic 325 location profile evaluates to TRUE if the current location of the 326 Target is within the described location. Note that the Target's 327 actual location might be represented by any of the location shapes 328 described in [RFC5491]. If the geodetic location of the Target is 329 unknown then the element containing the information for 330 the geodetic location profile evaluates to FALSE. 332 Implementations are REQUIRED to support the following coordinate 333 reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the 334 European Petroleum Survey Group (EPSG) Geodetic Parameter Dataset (as 335 formalized by the Open Geospatial Consortium (OGC)): 337 2D: WGS 84 (latitude, longitude), as identified by the URN 338 "urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS. 340 A CRS MUST be specified using the above URN notation only, 341 implementations do not need to support user-defined CRSs. 343 Implementations MUST specify the CRS using the "srsName" attribute on 344 the outermost geometry element. The CRS MUST NOT be changed for any 345 sub-elements. The "srsDimension" attribute MUST be omitted, since 346 the number of dimensions in these CRSs is known. 348 4.2. Civic Location Condition Profile 350 The civic location profile is identified by the token 'civic- 351 condition'. Rule Makers use this profile by placing a 352 element, defined in [RFC5139], within the element. 354 All child elements of element that carry 355 elements MUST evaluate to TRUE (i.e., logical AND) in order for the 356 element to evaluate to TRUE. For each child element, the 357 value of that element is compared to the value of the same element in 358 the Target's civic location. The child element evaluates to TRUE if 359 the two values are identical based on a bit-by-bit comparison. 361 If the civic location of the Target is unknown, then the 362 element containing the information for the civic location profile 363 evaluates to FALSE. This case may occur, for example, if location 364 information has been removed by earlier transmitters of location 365 information or if only the geodetic location is known. In general, 366 it is RECOMMENDED behavior for a LS not to apply a translation from 367 geodetic location to civic location (i.e., geocode the location). 369 5. Actions 371 This document does not define location-specific actions. 373 6. Transformations 375 This document defines several elements that allow Rule Makers to 376 specify transformations that 378 o reduce the accuracy of the returned location information, and 380 o set the basic authorization policies carried inside the PIDF-LO. 382 6.1. Set Retransmission-Allowed 384 This element asks the LS to change or set the value of the 385 element in the PIDF-LO. The data type of 386 the element is a boolean. 388 If the value of the element is set to 389 TRUE then the element in the PIDF-LO MUST be 390 set to TRUE. If the value of the 391 element is set to FALSE, then the element in 392 the PIDF-LO MUST be set to FALSE. 394 If the element is absent then the value 395 of the element in the PIDF-LO MUST be kept 396 unchanged or, if the PIDF-LO is created for the first time, then the 397 value MUST be set to FALSE. 399 6.2. Set Retention-Expiry 401 This transformation asks the LS to change or set the value of the 402 element in the PIDF-LO. The data type of the 403 element is an integer. 405 The value provided with the element indicates 406 seconds and these seconds are added to the current date. 408 If the element is absent then the value of the 409 element in the PIDF-LO is kept unchanged or, if 410 the PIDF-LO is created for the first time, then the value MUST be set 411 to the current date. 413 6.3. Set Note-Well 415 This transformation asks the LS to change or set the value of the 416 element in the PIDF-LO. The data type of the element is a string. 419 The value provided with the element contains a 420 privacy statement as a human readable text string and an 'xml:lang' 421 attribute denotes the language of the human readable text. 423 If the element is absent, then the value of the 424 element in the PIDF-LO is kept unchanged or, if the 425 PIDF-LO is created for the first time, then no content is provided 426 for the element. 428 6.4. Keep Ruleset Reference 430 This transformation allows to influence whether the element in the PIDF-LO carries the extended authorization 432 rules defined in [RFC4745]. The data type of the element is Boolean. 435 If the value of the element is set to TRUE, 436 then the element in the PIDF-LO is kept unchanged 437 when included. If the value of the element is 438 set to FALSE, then the element in the PIDF-LO MUST 439 NOT contain a reference to an external rule set. The reference to 440 the ruleset is removed and no rules are carried as MIME bodies (in 441 case of CID URIs). 443 If the element is absent, then the value of the 444 element in the PIDF-LO is kept unchanged when 445 available or, if the PIDF-LO is created for the first time then the 446 element MUST NOT be included. 448 6.5. Provide Location 450 The element contains child elements of a specific 451 location profile that controls the granularity of returned location 452 information. This form of location granularity reduction is also 453 called 'obfuscation' and is defined in [duckham05] as 455 "the means of deliberately degrading the quality of information 456 about an individual's location in order to protect that 457 individual's location privacy." 459 Location obscuring presents a number of technical challenges. The 460 algorithms provided in this document are provided as examples only. 461 A discussion of the technical constraints on location obscuring is 462 included in Section 13.4. 464 The functionality of location granularity reduction depends on the 465 type of location provided as input. This document defines two 466 profiles for reduction, namely: 468 o If the element has a child 469 element then civic location information is disclosed as described 470 in Section 6.5.1, subject to availability. 472 o If the element has a child 473 element then geodetic location information is disclosed as 474 described in Section 6.5.2, subject to availability. 476 The element MUST contain the 'profile' attribute 477 if it contains child elements and the 'profile' attribute MUST match 478 with the contained child elements. 480 If the element has no child elements then civic, 481 as well as, geodetic location information is disclosed without 482 reducing its granularity, subject to availability. In this case the 483 profile attribute MUST NOT be included. 485 6.5.1. Civic Location Profile 487 This profile uses the token 'civic-transformation'. This profile 488 allows civic location transformations to be specified by means of the 489 element that restricts the level of civic location 490 information the LS is permitted to disclose. The symbols of these 491 levels are: 'country', 'region', 'city', 'building', 'full'. Each 492 level is given by a set of civic location data items such as 493 and , ..., , as defined in [RFC5139]. Each level 494 includes all elements included by the lower levels. 496 The 'country' level includes only the element; the 'region' 497 level adds the element; the 'city' level adds the and 498 elements; the 'building' level and the 'full' level add further civic 499 location data as shown below. 501 full 502 {, , , , , , , , , 503 , , , , , , , , 504 ,,,, , , , 505 , , , , , } 506 | 507 | 508 building 509 {, , , , , , , 510 , , , , , , 511 , , , , } 512 | 513 | 514 city 515 {, , , } 516 | 517 | 518 region 519 {, } 520 | 521 | 522 country 523 {} 524 | 525 | 526 none 527 {} 529 The default value is "none". 531 The schema of the element is defined in Section 8. 533 6.5.2. Geodetic Location Profile 535 This profile uses the token 'geodetic-transformation' and refers only 536 to the Coordinate Reference System (CRS) WGS 84 537 (urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic 538 location transformations to be specified by means of the element that may restrict the returned geodetic location 540 information based on the value provided in the 'radius' attribute. 541 The value of the 'radius' attribute expresses the radius in meters. 543 The schema of the element is defined in Section 8. 545 The algorithm proceeds in 6 steps.The first two steps are independent 546 of the measured position to be obscured. Those two steps should be 547 run only once or rather seldom (for every region and desired 548 uncertainty). The steps are: 550 1. Choose a geodesic projection with Cartesian coordinates and a 551 surface you want to cover. The maximal distortion of the map may 552 not be too much (see notes below). 554 2. Given uncertainty "d", choose a grid of so called "landmarks" at 555 a distance (maximal) d of each other. 557 3. Given a measured location M=(m,n) in the surface, calculate its 4 558 closest landmarks on the grid, with coordinates: SW = (l,b), 559 SE=(r,b), NW=(l,t), NE=(r,t). Thus l<=m element. 635 Requests match only if the Target is at a civic location with country 636 set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to 637 'Munich', city division (A4) set to 'Perlach', street name (A6) set 638 to 'Otto-Hahn-Ring' and house number (HNO) set to '6'. 640 No actions and transformation child elements are provided in this 641 rule example. The actions and transformation could include presence 642 specific information when the Geolocation Policy framework is applied 643 to the Presence Policy framework (see [RFC5025]). 645 646 649 650 651 652 657 DE 658 Bavaria 659 Munich 660 Perlach 661 Otto-Hahn-Ring 662 6 663 664 665 666 667 668 669 671 7.2. Rule Example with Geodetic Location Condition 673 This example illustrates a rule that employs the geodetic location 674 condition. The rule matches if the current location of the Target is 675 inside the area specified by the polygon. The polygon uses the EPSG 676 4326 coordinate reference system. No altitude is included in this 677 example. 679 680 686 687 688 689 693 694 -33.8570029378 151.2150070761 695 1500 696 697 698 699 700 701 702 703 705 7.3. Rule Example with Civic and Geodetic Location Condition 707 This example illustrates a rule that employs a mixed civic and 708 geodetic location condition. Depending on the available type of 709 location information, namely civic or geodetic location information, 710 one of the location elements may match. 712 713 719 720 721 722 724 DE 725 Bavaria 726 Munich 727 Perlach 728 Otto-Hahn-Ring 729 6 730 731 732 733 -34.410649 150.87651 734 1500 735 736 737 738 739 740 741 742 743 745 7.4. Rule Example with Location-based Transformations 747 This example shows the transformations specified in this document. 748 The element indicates that the available civic 749 location information is reduced to building level granularity. If 750 geodetic location information is requested then a granularity 751 reduction is provided as well. 753 754 758 759 760 761 762 false 763 764 86400 765 My privacy policy goes in here. 766 767 false 768 770 772 building 773 775 777 778 780 781 782 784 The following rule describes the short-hand notation for making the 785 current location of the Target available to Location Recipients 786 without granularity reduction. 788 789 792 793 794 795 796 797 798 799 801 7.5. Location Obfuscation Example 803 Suppose you want a to obscure positions in the continental USA. 805 Step 1: 807 First you choose a geodesic projection. If you are measuring 808 location as latitude and longitude, a natural choice is to take a 809 rectangular projection. One latitudinal degree corresponds 810 approximately to 110.6 kilometers, while a good approximation of a 811 longitudinal degree at latitude phi is (pi/180)*M*cos(phi), where 812 pi is approximately 3.1415, and M is the Earth's average 813 meridional radius, approximately 6,367.5 km. For instance, one 814 longitudinal degree at 30 degrees (say, New Orleans) is 96.39 km, 815 while the formula given offers an estimation of 96.24, which is 816 good for our purposes. 818 We will set up a grid not only for the continental US, but for the 819 whole earth between latitudes 25 and 50 degrees, and thus will 820 cover also the Mediterranean, South Europe, Japan and the north of 821 China. As will be seen below, the grid distortion (for not too 822 large grids in this region) is approx cos(25)/cos(50), which is 823 1.4099. 825 As origin of our grid, we choose the point at latitude 25 degrees 826 and longitude 0 (Greenwich). The latitude 25 degrees is chosen to 827 be just south of Florida and thus south of the continental US. 828 (On the south hemisphere the origin should be north of the region 829 to be covered; if the region crosses the Equator, the origin 830 should be on the Equator. In his way it is guaranteed that the 831 latitudinal degree has largest distance at the latitude of the 832 origin). 834 At 25 degrees one degree in east-west direction corresponds approx 835 to (pi/180)*M*cos(25) = 100.72 km. 837 The same procedure, basically, produces grids for 839 * 45 degrees south to 45 degrees north Tropics and subtropics 841 * 25 to 50 degrees (both north or south) Continental US 843 * 35 to 55 degrees (both north or south) South and Central Europe 845 * 45 to 60 degrees (both north or south) Central and North Europe 847 * 55 to 65 degrees (both north or south) Scandinavia 848 * 60 to 70 degrees (both north or south) 850 Since we do not want to often change grid system (this would leak 851 more information about obscured locations when they are repeatedly 852 visited), the algorithm should prefer to use the grids discussed 853 above, with origin at the Greenwich meridian and at latitudes o=0, 854 o=25, o=35, o=45, 0=55, and o=60 degrees (north) or at latitudes 855 o=-25, o=-35, o=-45, 0=-55, and o=-60 degrees (the minus to 856 indicate "south"). 858 Our choice for the continental USA is o=25. 860 For locations close to the poles, a different projection should be 861 used (not discussed here). 863 Step 2: 865 To construct the grid points, we start with our chosen origin and 866 place the along the main axes (NS and EW) grid points at a 867 distance d of each other. 869 We will now construct a grid for a desired uncertainty of d = 870 100km. At our origin, 100 km correspond roughly to d1 = 100/ 871 100.72 = 0.993 degrees on east-west direction and to d2 = 100/ 872 110.6 = 0.904 degrees in north-south direction. 874 The (i,j)-point in the grid (i and j are integers) has longitude 875 d1*i and latitude 25+d2*j, measured in degrees. More generally, 876 if the grid has origin at coordinates (0,o), measured in degrees, 877 the (i,j)-point in the grid has coordinates (longitude = d1*i, 878 latitude = o+d2*j). The grid has almost no distorsion at the 879 latitude of the origin, but it has as we go further away from it. 881 The distance between two points in the grid at 25 degrees latitude 882 is indeed approx 100 km, but just above the Canadian border, on 883 the 50th degree, it is 0.993*(pi/180)*M*cos(50) = 70.92km. Thus, 884 the grid distortion is 100/70.92 = 1.41, which is acceptable 885 (<1.5). (On north-south direction the grid has roughly no 886 distortion, the vertical distance between two neighboring grid 887 points is approximately 100 km). 889 Step 3: 891 Now suppose you measure a position at M, with longitude -105 (the 892 minus sign is used to denote 105 degrees *west*; without minus, 893 the point is in China, 105 degrees east) and latitude 40 degrees 894 (just north of Denver, CO). The point M is 105 degrees west and 895 15 degrees north of our origin (which has longitude 0 and latitude 896 25). 898 Let "floor" be the function that returns the largest integer 899 smaller or equal to a floating point number. To calculate SW, the 900 closest point of the grid on the south-west of M=(m,n), we 901 calculate 903 i= floor(m/d1) = floor(-105/0.993) = -106 905 j= floor(n-o/d2) = floor(15/0.904) = 16 907 Those are the indexes of SW on the grid. The coordinates of SW 908 are then: (d1*i, 25+d2*j) = (-105.242, 39.467). 910 Thus: 912 l=d1*floor(m/d1) = -105.243 914 r=l+d1 = -105.243+0.993 = -104.250 916 b=o+d2*floor(n-o/d2) = 39.467 918 t=b+d2 = 39.467+0.904 = 40.371 920 These are the formulas for l,r,b, and t in the general case of 921 Cartesian projections based on latitude and longitude. 923 Step 4: 925 Calculate x and y, the local coordinates of the point M in the 926 small grid square that contains it. This is easy: 928 x=(m-l)/(r-l) = [-105 -(-105.243)]/0.993 = 0.245 930 y=(n-b)/(t-b) = [40 - 39.467]/0.904 = 0.590 932 Step 5: 934 First compare x with p (0.2887) and (0.7113). x is smaller than p. 935 Therefore, only cases 1,4 or 6 could hold. 937 Also compare y with p (0.2887) and (0.7113). y is between them: p 938 <= y < q. Thus, we must be in case 4. To check, compare y (0.59) 939 with x (0.245) and 1-x. y is larger than x and smaller than 1-x. 941 We are in case C4 (p <= y < q and x <= y and y < 1-x). 943 Step 6: 945 Now we choose either SW or NW as the center of the circle. 947 The obscured location is the Circle with radius 100 km and center 948 in SW (coordinates: -105.243, 39.467), or NW (coordinates: 949 -105.243, 40.371). 951 8. XML Schema for Basic Location Profiles 953 This section defines the location profiles used as child elements of 954 the transformation element. 956 957 963 965 966 967 968 969 970 971 972 973 974 975 976 978 980 981 982 983 984 986 988 9. XML Schema for Geolocation Policy 990 This section presents the XML schema that defines the Geolocation 991 Policy schema described in this document. The Geolocation Policy 992 schema extends the Common Policy schema (see [RFC4745]). 994 995 1002 1003 1005 1006 1009 1011 1014 1015 1016 1017 1018 1020 1022 1023 1024 1025 1027 1028 1029 1030 1031 1033 1034 1035 1036 1037 1038 1039 1041 1042 1044 1046 1048 1051 1054 1055 1056 1057 1058 1059 1060 1062 1063 1064 1065 1066 1068 1069 1070 1071 1072 1074 1076 10. XCAP Usage 1078 The following section defines the details necessary for clients to 1079 manipulate geolocation privacy documents from a server using XCAP. 1080 If used as part of a presence system, it uses the same AUID as those 1081 rules. See [RFC5025] for a description of the XCAP usage in context 1082 with presence authorization rules. 1084 10.1. Application Unique ID 1086 XCAP requires application usages to define a unique application usage 1087 ID (AUID) in either the IETF tree or a vendor tree. This 1088 specification defines the "geolocation-policy" AUID within the IETF 1089 tree, via the IANA registration in Section 11. 1091 10.2. XML Schema 1093 XCAP requires application usages to define a schema for their 1094 documents. The schema for geolocation authorization documents is 1095 described in Section 9. 1097 10.3. Default Namespace 1099 XCAP requires application usages to define the default namespace for 1100 their documents. The default namespace is 1101 urn:ietf:params:xml:ns:geolocation-policy. 1103 10.4. MIME Type 1105 XCAP requires application usages to defined the MIME type for 1106 documents they carry. Geolocation privacy authorization documents 1107 inherit the MIME type of common policy documents, application/ 1108 auth-policy+xml. 1110 10.5. Validation Constraints 1112 This specification does not define additional constraints. 1114 10.6. Data Semantics 1116 This document discusses the semantics of a geolocation privacy 1117 authorization. 1119 10.7. Naming Conventions 1121 When a Location Server receives a request to access location 1122 information of some user foo, it will look for all documents within 1123 http://[xcaproot]/geolocation-policy/users/foo, and use all documents 1124 found beneath that point to guide authorization policy. 1126 10.8. Resource Interdependencies 1128 This application usage does not define additional resource 1129 interdependencies. 1131 10.9. Authorization Policies 1133 This application usage does not modify the default XCAP authorization 1134 policy, which is that only a user can read, write or modify his/her 1135 own documents. A server can allow privileged users to modify 1136 documents that they do not own, but the establishment and indication 1137 of such policies is outside the scope of this document. 1139 11. IANA Considerations 1141 There are several IANA considerations associated with this 1142 specification. 1144 11.1. Geolocation Policy XML Schema Registration 1146 URI: urn:ietf:params:xml:schema:geolocation-policy 1148 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 1149 (hannes.tschofenig@nsn.com). 1151 XML: The XML schema to be registered is contained in Section 9. Its 1152 first line is 1154 1156 and its last line is 1158 1160 11.2. Geolocation Policy Namespace Registration 1162 URI: urn:ietf:params:xml:ns:geolocation-policy 1164 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 1165 (hannes.tschofenig@nsn.com). 1167 XML: 1169 BEGIN 1170 1171 1173 1174 1175 1177 Geolocation Policy Namespace 1178 1179 1180

Namespace for Geolocation Authorization Policies

1181

urn:ietf:params:xml:schema:geolocation-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 11.3. Geolocation Policy Location Profile Registry 1192 This document seeks to create a registry of location profile names 1193 for the Geolocation Policy framework. Profile names are XML tokens. 1194 This registry will operate in accordance with RFC 2434 [RFC2434], 1195 Standards Action. 1197 This document defines the following profile names: 1199 geodetic-condition: Defined in Section 4.1. 1201 civic-condition: Defined in Section 4.2. 1203 geodetic-transformation: Defined in Section 6.5.2. 1205 civic-transformation: Defined in Section 6.5.1. 1207 11.4. Basic Location Profile XML Schema Registration 1209 URI: urn:ietf:params:xml:schema:basic-location-profiles 1211 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 1212 (hannes.tschofenig@nsn.com). 1214 XML: The XML schema to be registered is contained in Section 8. Its 1215 first line is 1217 1219 and its last line is 1221 1223 11.5. Basic Location Profile Namespace Registration 1225 URI: urn:ietf:params:xml:ns:basic-location-profiles 1227 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 1228 (hannes.tschofenig@nsn.com). 1230 XML: 1232 BEGIN 1233 1234 1236 1237 1238 1240 Basic Location Profile Namespace 1241 1242 1243

Namespace for Basic Location Profile

1244

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

1245

See RFCXXXX 1246 [NOTE TO IANA/RFC-EDITOR: 1247 Please replace XXXX with the RFC number of this 1248 specification.].

1249 1250 1251 END 1253 11.6. XCAP Application Usage ID 1255 This section registers an XCAP Application Usage ID (AUID) according 1256 to the IANA procedures defined in [RFC4825]. 1258 Name of the AUID: geolocation-policy 1260 Description: Geolocation privacy rules are documents that describe 1261 the permissions that a Target has granted to Location Recipients that 1262 access information about his/her geographic location. 1264 12. Internationalization Considerations 1266 The policies described in this document are mostly meant for machine- 1267 to-machine communications; as such, many of its elements are tokens 1268 not meant for direct human consumption. If these tokens are 1269 presented to the end user, some localization may need to occur. The 1270 policies are, however, supposed to be created with the help of humans 1271 and some of the elements and attributes are subject to 1272 internationalization considerations. The content of the