idnits 2.17.00 (12 Aug 2021) /tmp/idnits33500/draft-ietf-geopriv-policy-26.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 (June 5, 2012) is 3636 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 1763 -- Looks like a reference, but probably isn't: '1' on line 1763 -- Possible downref: Non-RFC (?) normative reference: ref. 'GML' == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-07 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) 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: December 7, 2012 Nokia Siemens Networks 6 J. Cuellar 7 Siemens 8 J. Polk 9 Cisco 10 J. Morris 12 M. Thomson 13 Microsoft 14 June 5, 2012 16 Geolocation Policy: A Document Format for Expressing Privacy Preferences 17 for Location Information 18 draft-ietf-geopriv-policy-26 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. There are circumstances where the amount of location 34 obfuscation provided is less than what is desired. These algorithms 35 might not be appropriate for all application 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 December 7, 2012. 54 Copyright Notice 56 Copyright (c) 2012 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 Media 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 . . . . . . . . . . . . . . . . 34 113 12. Internationalization Considerations . . . . . . . . . . . . . 35 114 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 115 13.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 36 116 13.2. Obfuscation . . . . . . . . . . . . . . . . . . . . . . . 36 117 13.3. Algorithm Limitations . . . . . . . . . . . . . . . . . . 38 118 13.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 38 119 13.5. Location Obscuring Limitations . . . . . . . . . . . . . . 39 120 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 121 14.1. Normative References . . . . . . . . . . . . . . . . . . . 41 122 14.2. Informative References . . . . . . . . . . . . . . . . . . 41 123 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 43 124 Appendix B. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . 44 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 127 1. Introduction 129 Location information needs to be protected against unauthorized 130 access to preserve the privacy of humans. In RFC 6280 [RFC6280], a 131 protocol-independent model for access to geographic information is 132 defined. The model includes a Location Generator (LG) that 133 determines location information, a Location Server (LS) that 134 authorizes access to location information, a Location Recipient (LR) 135 that requests and receives location information, and a Rule Maker 136 (RM) that writes authorization policies. An authorization policy is 137 a set of rules that regulates an entity's activities with respect to 138 privacy-sensitive information, such as location information. 140 The data object containing location information in the context of 141 this document is referred to as a Location Object (LO). The basic 142 rule set defined in the Presence Information Data Format Location 143 Object (PIDF-LO) [RFC4119] can restrict how long the Location 144 Recipient is allowed to retain the information, and it can prohibit 145 further distribution. It also contains a reference to an enhanced 146 rule set and a human readable privacy policy. The basic rule set 147 does not access to location information. This document describes an 148 enhanced rule set that provides richer constraints on the 149 distribution of LOs. 151 The enhanced rule set allows the entity that uses the rules defined 152 in this document to restrict the retention and to enforce access 153 restrictions on location data, including prohibiting any 154 dissemination to particular individuals, during particular times or 155 when the Target is located in a specific region. The RM can also 156 stipulate that only certain parts of the Location Object are to be 157 distributed to recipients or that the resolution is reduced for parts 158 of the Location Object. 160 In the typical sequence of operations, a Location Server receives a 161 query for location information for a particular Target. The 162 requestor's identity will likely be revealed as part of this request 163 for location information. The authenticated identity of the Location 164 Recipient, together with other information provided with the request 165 or generally available to the server, is then used for searching 166 through the rule set. If more than one rule matches the condition 167 element, then the combined permission is evaluated according to the 168 description in Section 10 of [RFC4745]. The result of the rule 169 evalation is applied to the location information, yielding a possibly 170 modified Location Object that is delivered to the Location Recipient. 172 This document does not describe the protocol used to convey location 173 information from the Location Server to the Location Recipient. 175 This document extends the Common Policy framework defined in 176 [RFC4745]. That document provides an abstract framework for 177 expressing authorization rules. As specified there, each such rule 178 consists of conditions, actions and transformations. Conditions 179 determine under which circumstances the entity executing the rules, 180 such as a Location Server, is permitted to apply actions and 181 transformations. Transformations regulate in a location information 182 context how a Location Server modifies the information elements that 183 are returned to the requestor by, for example, reducing the 184 granularity of returned location information. 186 This document defines two algorithms for reducing the granularity of 187 returned location information. The first algorithm is defined for 188 usage with civic location information (see Section 6.5.1) while the 189 other one applies to geodetic location information (see 190 Section 6.5.2). Both algorithms come with limitations, i.e. they 191 provide location obfuscation under certain conditions and may 192 therefore not be appropriate for all application domains. These 193 limitations are documented within the security consideration section 194 (see Section 13). It is worth pointing out that the geodetic 195 transformation algorithm Section 6.5.2 deals with privacy risks 196 related to targets that are stationary, as well as to moving targets. 197 However, with respect to movement there are restriction as to what 198 information can be hidden from an adversary. To cover applications 199 that have more sophisticated privacy requirements additional 200 algorithms may need to be defined. This document forsees extensions 201 in the form of new algorithms and therefore defines a registy (see 202 Section 11.3). 204 The XML schema defined in Section 9 extends the Common Policy schema 205 by introducing new child elements to the condition and transformation 206 elements. This document does not define child elements for the 207 action part of a rule. 209 2. Terminology 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in RFC 2119 [RFC2119]. 215 This document reuses the terminology of RFC 6280 [RFC6280], such as 216 Location Server (LS), Location Recipient (LR), Rule Maker (RM), 217 Target, Location Generator (LG) and Location Object (LO). This 218 document uses the following terminology: 220 Presentity or Target: 222 RFC 6280 [RFC6280] uses the term Target to identify the object or 223 person of which location information is required. The presence 224 model described in RFC 2778 [RFC2778] uses the term presentity to 225 describe the entity that provides presence information to a 226 presence service. A Presentity in a presence system is a Target 227 in a location information system. 229 Watcher or Location Recipient: 231 The receiver of location information is the Location Recipient 232 (LR) in the terminology of RFC 6280 [RFC6280]. A watcher in a 233 presence system, i.e., an entity that requests presence 234 information about a presentity, is a Location Recipient in a 235 location information system. 237 Authorization policy: 239 An authorization policy is given by a rule set. A rule set 240 contains an unordered list of (policy) rules. Each rule has a 241 condition, an action and a transformation component. 243 Permission: 245 The term "permission" refers to the action and transformation 246 components of a rule. 248 In this document we use the term Location Servers as the entities 249 that evaluate the geolocation authorization policies. The 250 geolocation privacy architecture is, as described in RFC 4079 251 [RFC4079], aligned with the presence architecture and a Presence 252 Server is therefore an entity that distributes location information 253 along with other presence-specific XML data elements. 255 3. Generic Processing 257 3.1. Structure of Geolocation Authorization Documents 259 A geolocation authorization document is an XML document, formatted 260 according to the schema defined in [RFC4745]. Geolocation 261 authorization documents inherit the media type of common policy 262 documents, application/auth-policy+xml. As described in [RFC4745], 263 this document is composed of rules which contain three parts - 264 conditions, actions, and transformations. Each action or 265 transformation, which is also called a permission, has the property 266 of being a positive grant of information to the Location Recipient. 267 As a result, there is a well-defined mechanism for combining actions 268 and transformations obtained from several sources. This mechanism is 269 privacy safe, since the lack of any action or transformation can only 270 result in less information being presented to a Location Recipient. 272 3.2. Rule Transport 274 There are two ways how the authorization rules described in this 275 document may be conveyed between different parties: 277 o RFC 4119 [RFC4119] allows enhanced authorization policies to be 278 referenced via a Uniform Resource Locator (URL) in the 'ruleset- 279 reference' element. The ruleset-reference' element is part of the 280 basic rules that always travel with the Location Object. 282 o Authorization policies might, for example, also be stored at a 283 Location Server / Presence Server. The Rule Maker therefore needs 284 to use a protocol to create, modify and delete the authorization 285 policies defined in this document. Such a protocol is available 286 with the Extensible Markup Language (XML) Configuration Access 287 Protocol (XCAP) [RFC4825]. 289 4. Location-specific Conditions 291 This section describes the location-specific conditions of a rule. 292 The element contains zero, one or an unbounded number of 293 child element(s). Providing more than one 294 element may not be useful since all child 295 elements of the element must evaluate to TRUE in order 296 for the element to be TRUE. The 297 element MUST contain at least one child element. The 298 element evaluates to TRUE if any of its child 299 elements is TRUE, i.e., a logical OR. 301 The element has three attributes, namely 'profile', 'xml: 302 lang' and 'label'. The 'profile' attribute allows to indicate the 303 location profile that is included as child elements in the 304 element and each profile needs to describe under what conditions each 305 element evaluates to TRUE. This document defines two 306 location profiles, one civic and one geodetic location profile, see 307 Section 4.1 and Section 4.2. The 'label' attribute allows a human 308 readable description to be added to each element. The 309 'xml:lang' attribute contains a language tag providing further 310 information for rendering of the content of the 'label' attribute. 312 The and the elements provide 313 extension points. If an extension is not understood by the entity 314 evaluating the rules then this rule evaluates to FALSE. 316 4.1. Geodetic Location Condition Profile 318 The geodetic location profile is identified by the token 'geodetic- 319 condition'. Rule Makers use this profile by placing a GML [GML] 320 element within the element (as described in 321 Section 5.2.3 of [RFC5491]). 323 The element containing the information for the geodetic 324 location profile evaluates to TRUE if the current location of the 325 Target is within the described location. Note that the Target's 326 actual location might be represented by any of the location shapes 327 described in [RFC5491]. If the geodetic location of the Target is 328 unknown then the element containing the information for 329 the geodetic location profile evaluates to FALSE. 331 Implementations MUST support the WGS 84 [NIMA.TR8350.2-3e] coordinate 332 reference system using the formal identifier from the European 333 Petroleum Survey Group (EPSG) Geodetic Parameter Dataset (as 334 formalized by the Open Geospatial Consortium (OGC)): 336 2D: WGS 84 (latitude, longitude), as identified by the URN 337 "urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS. 339 A CRS MUST be specified using the above URN notation only, 340 implementations do not need to support user-defined CRSs. 342 Implementations MUST specify the CRS using the "srsName" attribute on 343 the outermost geometry element. The CRS MUST NOT be changed for any 344 sub-elements. The "srsDimension" attribute MUST be omitted, since 345 the number of dimensions in these CRSs is known. 347 4.2. Civic Location Condition Profile 349 The civic location profile is identified by the token 'civic- 350 condition'. Rule Makers use this profile by placing a 351 element, defined in [RFC5139], within the element. 353 All child elements of element that carry 354 elements MUST evaluate to TRUE (i.e., logical AND) in order for the 355 element to evaluate to TRUE. For each child element, the 356 value of that element is compared to the value of the same element in 357 the Target's civic location. The child element evaluates to TRUE if 358 the two values are identical based on a bit-by-bit comparison. 360 If the civic location of the Target is unknown, then the 361 element containing the information for the civic location profile 362 evaluates to FALSE. This case may occur, for example, if location 363 information has been removed by earlier transmitters of location 364 information or if only the geodetic location is known. In general, 365 it is RECOMMENDED behavior for a LS not to apply a translation from 366 geodetic location to civic location (i.e., geocode the location). 368 5. Actions 370 This document does not define location-specific actions. 372 6. Transformations 374 This document defines several elements that allow Rule Makers to 375 specify transformations that 377 o reduce the accuracy of the returned location information, and 379 o set the basic authorization policies carried inside the PIDF-LO. 381 6.1. Set Retransmission-Allowed 383 This element asks the LS to change or set the value of the 384 element in the PIDF-LO. The data type of 385 the element is a boolean. 387 If the value of the element is set to 388 TRUE then the element in the PIDF-LO MUST be 389 set to TRUE. If the value of the 390 element is set to FALSE, then the element in 391 the PIDF-LO MUST be set to FALSE. 393 If the element is absent then the value 394 of the element in the PIDF-LO MUST be kept 395 unchanged or, if the PIDF-LO is created for the first time, then the 396 value MUST be set to FALSE. 398 6.2. Set Retention-Expiry 400 This transformation asks the LS to change or set the value of the 401 element in the PIDF-LO. The data type of the 402 element is an integer. 404 The value provided with the element indicates 405 seconds and these seconds are added to the time that the LS provides 406 location. 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.5. 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 546 independent of the measured position to be obscured. Those two steps 547 should be run only once or rather seldom (for every region and 548 desired 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. 630 Requests match only if the Target is at a civic location with country 631 set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to 632 'Munich', city division (A4) set to 'Perlach', street name (A6) set 633 to 'Otto-Hahn-Ring' and house number (HNO) set to '6'. 635 No actions and transformation child elements are provided in this 636 rule example. The actions and transformation could include presence 637 specific information when the Geolocation Policy framework is applied 638 to the Presence Policy framework (see [RFC5025]). 640 641 644 645 646 647 652 DE 653 Bavaria 654 Munich 655 Perlach 656 Otto-Hahn-Ring 657 6 658 659 660 661 662 663 664 666 7.2. Rule Example with Geodetic Location Condition 668 This example illustrates a rule that employs the geodetic location 669 condition. The rule matches if the current location of the Target is 670 inside the area specified by the polygon. The polygon uses the EPSG 671 4326 coordinate reference system. No altitude is included in this 672 example. 674 675 681 682 683 684 688 689 -33.8570029378 151.2150070761 690 1500 691 692 693 694 695 696 697 698 700 7.3. Rule Example with Civic and Geodetic Location Condition 702 This example illustrates a rule that employs a mixed civic and 703 geodetic location condition. Depending on the available type of 704 location information, namely civic or geodetic location information, 705 one of the location elements may match. 707 708 714 715 716 717 719 DE 720 Bavaria 721 Munich 722 Perlach 723 Otto-Hahn-Ring 724 6 725 726 727 728 -34.410649 150.87651 729 1500 730 731 732 733 734 735 736 737 738 740 7.4. Rule Example with Location-based Transformations 742 This example shows the transformations specified in this document. 743 The element indicates that the available civic 744 location information is reduced to building level granularity. If 745 geodetic location information is requested then a granularity 746 reduction is provided as well. 748 749 753 754 755 756 757 false 758 759 86400 760 My privacy policy goes in here. 761 762 false 763 765 767 building 768 770 772 773 775 776 777 779 The following rule describes the short-hand notation for making the 780 current location of the Target available to Location Recipients 781 without granularity reduction. 783 784 787 788 789 790 791 792 793 794 796 7.5. Location Obfuscation Example 798 Suppose you want a to obscure positions in the continental USA. 800 Step 1: 802 First you choose a geodesic projection. If you are measuring 803 location as latitude and longitude, a natural choice is to take a 804 rectangular projection. One latitudinal degree corresponds 805 approximately to 110.6 kilometers, while a good approximation of a 806 longitudinal degree at latitude phi is (pi/180)*M*cos(phi), where 807 pi is approximately 3.1415, and M is the Earth's average 808 meridional radius, approximately 6,367.5 km. For instance, one 809 longitudinal degree at 30 degrees (say, New Orleans) is 96.39 km, 810 while the formula given offers an estimation of 96.24, which is 811 good for our purposes. 813 We will set up a grid not only for the continental US, but for the 814 whole earth between latitudes 25 and 50 degrees, and thus will 815 cover also the Mediterranean, South Europe, Japan and the north of 816 China. As will be seen below, the grid distortion (for not too 817 large grids in this region) is approx cos(25)/cos(50), which is 818 1.4099. 820 As origin of our grid, we choose the point at latitude 25 degrees 821 and longitude 0 (Greenwich). The latitude 25 degrees is chosen to 822 be just south of Florida and thus south of the continental US. 823 (On the south hemisphere the origin should be north of the region 824 to be covered; if the region crosses the Equator, the origin 825 should be on the Equator. In his way it is guaranteed that the 826 latitudinal degree has largest distance at the latitude of the 827 origin). 829 At 25 degrees one degree in east-west direction corresponds approx 830 to (pi/180)*M*cos(25) = 100.72 km. 832 The same procedure, basically, produces grids for 834 * 45 degrees south to 45 degrees north Tropics and subtropics 836 * 25 to 50 degrees (both north or south) Continental US 838 * 35 to 55 degrees (both north or south) South and Central Europe 840 * 45 to 60 degrees (both north or south) Central and North Europe 842 * 55 to 65 degrees (both north or south) Scandinavia 843 * 60 to 70 degrees (both north or south) 845 Since we do not want to often change grid system (this would leak 846 more information about obscured locations when they are repeatedly 847 visited), the algorithm should prefer to use the grids discussed 848 above, with origin at the Greenwich meridian and at latitudes o=0, 849 o=25, o=35, o=45, 0=55, and o=60 degrees (north) or at latitudes 850 o=-25, o=-35, o=-45, 0=-55, and o=-60 degrees (the minus to 851 indicate "south"). 853 Our choice for the continental USA is o=25. 855 For locations close to the poles, a different projection should be 856 used (not discussed here). 858 Step 2: 860 To construct the grid points, we start with our chosen origin and 861 place the along the main axes (NS and EW) grid points at a 862 distance d of each other. 864 We will now construct a grid for a desired uncertainty of d = 865 100km. At our origin, 100 km correspond roughly to d1 = 100/ 866 100.72 = 0.993 degrees on east-west direction and to d2 = 100/ 867 110.6 = 0.904 degrees in north-south direction. 869 The (i,j)-point in the grid (i and j are integers) has longitude 870 d1*i and latitude 25+d2*j, measured in degrees. More generally, 871 if the grid has origin at coordinates (0,o), measured in degrees, 872 the (i,j)-point in the grid has coordinates (longitude = d1*i, 873 latitude = o+d2*j). The grid has almost no distorsion at the 874 latitude of the origin, but it has as we go further away from it. 876 The distance between two points in the grid at 25 degrees latitude 877 is indeed approx 100 km, but just above the Canadian border, on 878 the 50th degree, it is 0.993*(pi/180)*M*cos(50) = 70.92km. Thus, 879 the grid distortion is 100/70.92 = 1.41, which is acceptable 880 (<1.5). (On north-south direction the grid has roughly no 881 distortion, the vertical distance between two neighboring grid 882 points is approximately 100 km). 884 Step 3: 886 Now suppose you measure a position at M, with longitude -105 (the 887 minus sign is used to denote 105 degrees *west*; without minus, 888 the point is in China, 105 degrees east) and latitude 40 degrees 889 (just north of Denver, CO). The point M is 105 degrees west and 890 15 degrees north of our origin (which has longitude 0 and latitude 891 25). 893 Let "floor" be the function that returns the largest integer 894 smaller or equal to a floating point number. To calculate SW, the 895 closest point of the grid on the south-west of M=(m,n), we 896 calculate 898 i= floor(m/d1) = floor(-105/0.993) = -106 900 j= floor(n-o/d2) = floor(15/0.904) = 16 902 Those are the indexes of SW on the grid. The coordinates of SW 903 are then: (d1*i, 25+d2*j) = (-105.242, 39.467). 905 Thus: 907 l=d1*floor(m/d1) = -105.243 909 r=l+d1 = -105.243+0.993 = -104.250 911 b=o+d2*floor(n-o/d2) = 39.467 913 t=b+d2 = 39.467+0.904 = 40.371 915 These are the formulas for l,r,b, and t in the general case of 916 Cartesian projections based on latitude and longitude. 918 Step 4: 920 Calculate x and y, the local coordinates of the point M in the 921 small grid square that contains it. This is easy: 923 x=(m-l)/(r-l) = [-105 -(-105.243)]/0.993 = 0.245 925 y=(n-b)/(t-b) = [40 - 39.467]/0.904 = 0.590 927 Step 5: 929 First compare x with p (0.2887) and (0.7113). x is smaller than p. 930 Therefore, only cases 1,4 or 6 could hold. 932 Also compare y with p (0.2887) and (0.7113). y is between them: p 933 <= y < q. Thus, we must be in case 4. To check, compare y (0.59) 934 with x (0.245) and 1-x. y is larger than x and smaller than 1-x. 936 We are in case C4 (p <= y < q and x <= y and y < 1-x). 938 Step 6: 940 Now we choose either SW or NW as the center of the circle. 942 The obscured location is the Circle with radius 100 km and center 943 in SW (coordinates: -105.243, 39.467), or NW (coordinates: 944 -105.243, 40.371). 946 8. XML Schema for Basic Location Profiles 948 This section defines the location profiles used as child elements of 949 the transformation element. 951 952 958 960 961 962 963 964 965 966 967 968 969 970 971 973 975 976 977 978 979 981 983 9. XML Schema for Geolocation Policy 985 This section presents the XML schema that defines the Geolocation 986 Policy schema described in this document. The Geolocation Policy 987 schema extends the Common Policy schema (see [RFC4745]). 989 990 997 998 1000 1001 1004 1006 1009 1010 1011 1012 1013 1015 1017 1018 1019 1020 1022 1023 1024 1025 1026 1028 1029 1030 1031 1032 1033 1034 1036 1037 1039 1041 1043 1046 1049 1050 1051 1052 1053 1054 1055 1057 1058 1059 1060 1061 1063 1064 1065 1066 1067 1069 1071 10. XCAP Usage 1073 The following section defines the details necessary for clients to 1074 manipulate geolocation privacy documents from a server using XCAP. 1075 If used as part of a presence system, it uses the same AUID as those 1076 rules. See [RFC5025] for a description of the XCAP usage in context 1077 with presence authorization rules. 1079 10.1. Application Unique ID 1081 XCAP requires application usages to define a unique application usage 1082 ID (AUID) in either the IETF tree or a vendor tree. This 1083 specification defines the "geolocation-policy" AUID within the IETF 1084 tree, via the IANA registration in Section 11. 1086 10.2. XML Schema 1088 XCAP requires application usages to define a schema for their 1089 documents. The schema for geolocation authorization documents is 1090 described in Section 9. 1092 10.3. Default Namespace 1094 XCAP requires application usages to define the default namespace for 1095 their documents. The default namespace is 1096 urn:ietf:params:xml:ns:geolocation-policy. 1098 10.4. MIME Media Type 1100 XCAP requires application usages to defined the MIME media type for 1101 documents they carry. Geolocation privacy authorization documents 1102 inherit the MIME type of common policy documents, application/ 1103 auth-policy+xml. 1105 10.5. Validation Constraints 1107 This specification does not define additional constraints. 1109 10.6. Data Semantics 1111 This document discusses the semantics of a geolocation privacy 1112 authorization. 1114 10.7. Naming Conventions 1116 When a Location Server receives a request to access location 1117 information of some user foo, it will look for all documents within 1118 http://[xcaproot]/geolocation-policy/users/foo, and use all documents 1119 found beneath that point to guide authorization policy. 1121 10.8. Resource Interdependencies 1123 This application usage does not define additional resource 1124 interdependencies. 1126 10.9. Authorization Policies 1128 This application usage does not modify the default XCAP authorization 1129 policy, which is that only a user can read, write or modify his/her 1130 own documents. A server can allow privileged users to modify 1131 documents that they do not own, but the establishment and indication 1132 of such policies is outside the scope of this document. 1134 11. IANA Considerations 1136 There are several IANA considerations associated with this 1137 specification. 1139 11.1. Geolocation Policy XML Schema Registration 1141 This section registers an XML schema in the IETF XML Registry as per 1142 the guidelines in [RFC3688]. 1144 URI: urn:ietf:params:xml:schema:geolocation-policy 1146 Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), 1147 Hannes Tschofenig (hannes.tschofenig@nsn.com). 1149 XML: The XML schema to be registered is contained in Section 9. Its 1150 first line is 1152 1154 and its last line is 1156 1158 11.2. Geolocation Policy Namespace Registration 1160 This section registers a new XML namespace in the IETF XML Registry 1161 as per the guidelines in [RFC3688]. 1163 URI: urn:ietf:params:xml:ns:geolocation-policy 1165 Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), 1166 Hannes Tschofenig (hannes.tschofenig@nsn.com). 1168 XML: 1170 BEGIN 1171 1172 1174 1175 1176 1178 Geolocation Policy Namespace 1179 1180 1181

Namespace for Geolocation Authorization Policies

1182

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

1183

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

1187 1188 1189 END 1191 11.3. Geolocation Policy Location Profile Registry 1193 This document creates a registry of location profile names for the 1194 Geolocation Policy framework. Profile names are XML tokens. This 1195 registry will operate in accordance with RFC 5226 [RFC5226], 1196 Specification Required. 1198 This document defines the following profile names: 1200 geodetic-condition: Defined in Section 4.1. 1202 civic-condition: Defined in Section 4.2. 1204 geodetic-transformation: Defined in Section 6.5.2. 1206 civic-transformation: Defined in Section 6.5.1. 1208 11.4. Basic Location Profile XML Schema Registration 1210 This section registers an XML schema in the IETF XML Registry as per 1211 the guidelines in [RFC3688]. 1213 URI: urn:ietf:params:xml:schema:basic-location-profiles 1214 Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), 1215 Hannes Tschofenig (hannes.tschofenig@nsn.com). 1217 XML: The XML schema to be registered is contained in Section 8. Its 1218 first line is 1220 1222 and its last line is 1224 1226 11.5. Basic Location Profile Namespace Registration 1228 This section registers a new XML namespace in the IETF XML Registry 1229 as per the guidelines in [RFC3688]. 1231 URI: urn:ietf:params:xml:ns:basic-location-profiles 1233 Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), 1234 Hannes Tschofenig (hannes.tschofenig@nsn.com). 1236 XML: 1238 BEGIN 1239 1240 1242 1243 1244 1246 Basic Location Profile Namespace 1247 1248 1249

Namespace for Basic Location Profile

1250

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

1251

See RFCXXXX 1252 [NOTE TO IANA/RFC-EDITOR: 1253 Please replace XXXX with the RFC number of this 1254 specification.].

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