idnits 2.17.1 draft-ietf-geopriv-policy-27.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (August 21, 2012) is 4256 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 1781 -- Looks like a reference, but probably isn't: '1' on line 1781 -- Possible downref: Non-RFC (?) normative reference: ref. 'GML' -- Possible downref: Non-RFC (?) normative reference: ref. 'OGC-06-103r4' == 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 (~~), 3 warnings (==), 7 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: February 22, 2013 Nokia Siemens Networks 6 J. Cuellar 7 Siemens 8 J. Polk 9 Cisco 10 J. Morris 12 M. Thomson 13 Microsoft 14 August 21, 2012 16 Geolocation Policy: A Document Format for Expressing Privacy Preferences 17 for Location Information 18 draft-ietf-geopriv-policy-27 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 to data 27 based on 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 February 22, 2013. 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 . . . . . . . . . . . . . . . . . . . 44 124 Appendix B. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . 45 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 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 enabling, since the lack of any action or transformation can 270 only result in less information being presented to a Location 271 Recipient. 273 3.2. Rule Transport 275 There are two ways the authorization rules described in this document 276 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 or more 294 child element(s). The >conditions> element only evaluates to TRUE if 295 all child elements evaluate to TRUE, therefore multiple elements are not normally useful. 298 The element MUST contain at least one 299 child element. The element evaluates to TRUE if 300 any of its child >location> elements matches the location of the 301 target, i.e., >location> elements are combined using a logical OR. 303 The three attributes of are 'profile', 'xml:lang' and 304 'label'. The 'profile' indicates the location profile that is 305 included as child elements in the element. Two location 306 profiles, geodetic and civic, are defined in Section 4.1 and 307 Section 4.2. Each profile describes under what conditions a 308 element evaluates to TRUE. 310 The 'label' attribute allows a human readable description to be added 311 to each element. The 'xml:lang' attribute contains a 312 language tag providing further information for rendering of the 313 content of the 'label' attribute. 315 The and the elements provide 316 extension points. An extension that is not understood by the entity 317 evaluating the rules then this rule evaluates to FALSE. This causes 318 a >conditions> element to evaluate to FALSE if a >location-condition> 319 element is unsupported, but allows a >location-condition> to be TRUE 320 if an child >location> is not understood as long as an understoof 321 >location> is TRUE. 323 4.1. Geodetic Location Condition Profile 325 The geodetic location profile is identified by the token 'geodetic- 326 condition'. Rule Makers use this profile by placing a GML [GML] 327 element within the element (as described in 328 Section 5.2.3 of [RFC5491]). 330 The element containing the information for the geodetic 331 location profile evaluates to TRUE if the current location of the 332 Target is completely within the described location (see Section 333 6.1.15.3 of [OGC-06-103r4]). Note that the Target's actual location 334 might be represented by any of the location shapes described in 335 [RFC5491]. If the geodetic location of the Target is unknown then 336 the element containing the information for the geodetic 337 location profile evaluates to FALSE. 339 Implementations MUST support the WGS 84 [NIMA.TR8350.2-3e] coordinate 340 reference system using the formal identifier from the European 341 Petroleum Survey Group (EPSG) Geodetic Parameter Dataset (as 342 formalized by the Open Geospatial Consortium (OGC)): 344 2D: WGS 84 (latitude, longitude), as identified by the URN 345 "urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS. 347 A CRS MUST be specified using the above URN notation only, 348 implementations do not need to support user-defined CRSs. 350 Implementations MUST specify the CRS using the "srsName" attribute on 351 the outermost geometry element. The CRS MUST NOT be changed for any 352 sub-elements. The "srsDimension" attribute MUST be omitted, since 353 the number of dimensions in these CRSs is known. 355 4.2. Civic Location Condition Profile 357 The civic location profile is identified by the token 'civic- 358 condition'. Rule Makers use this profile by placing a 359 element, defined in [RFC5139], within the element. 361 All child elements of element that carry 362 elements MUST evaluate to TRUE (i.e., logical AND) in order for the 363 element to evaluate to TRUE. For each child element, the 364 value of that element is compared to the value of the same element in 365 the Target's civic location. The child element evaluates to TRUE if 366 the two values are identical based on a octet-by-octet comparison. 368 A element containing a >civic-condition> profile evaluates 369 to FALSE if a civic address is not present for the Target. For 370 example, this could occur if location information has been removed by 371 other rules or other transmitters of location information or if only 372 the geodetic location is known. In general, it is RECOMMENDED 373 behavior for a LS not to apply a translation from geodetic location 374 to civic location (i.e., geocode the location). 376 5. Actions 378 This document does not define location-specific actions. 380 6. Transformations 382 This document defines several elements that allow Rule Makers to 383 specify transformations that 385 o reduce the accuracy of the returned location information, and 387 o set the basic authorization policies carried inside the PIDF-LO. 389 6.1. Set Retransmission-Allowed 391 This element specifies a change to or the creation of a value for the 392 element in the PIDF-LO. The data type of 393 the element is a boolean. 395 If the value of the element is set to 396 TRUE then the element in the PIDF-LO MUST be 397 set to TRUE. If the value of the 398 element is set to FALSE, then the element in 399 the PIDF-LO MUST be set to FALSE. 401 If the element is absent then the value 402 of the element in the PIDF-LO MUST be kept 403 unchanged or, if the PIDF-LO is created for the first time, then the 404 value MUST be set to FALSE. 406 6.2. Set Retention-Expiry 408 This transformation asks the LS to change or set the value of the 409 element in the PIDF-LO. The data type of the 410 element is a non-negative integer. 412 The value provided with the element indicates 413 seconds and these seconds are added to the time that the LS provides 414 location. A value of zero requests that the information is not 415 retained. 417 If the element is absent then the value of the 418 element in the PIDF-LO is kept unchanged or, if 419 the PIDF-LO is created for the first time, then the value MUST be set 420 to the current date. 422 6.3. Set Note-Well 424 This transformation asks the LS to change or set the value of the 425 element in the PIDF-LO. The data type of the element is a string. 428 The value provided with the element contains a 429 privacy statement as a human readable text string and an 'xml:lang' 430 attribute denotes the language of the human readable text. 432 If the element is absent, then the value of the 433 element in the PIDF-LO is kept unchanged or, if the 434 PIDF-LO is created for the first time, then no content is provided 435 for the element. 437 6.4. Keep Ruleset Reference 439 This transformation specifies whether the element 440 in the PIDF-LO carries the extended authorization rules defined in 441 [RFC4745]. The data type of the element is 442 Boolean. 444 If the value of the element is set to TRUE, 445 then the element in the PIDF-LO is kept unchanged 446 when included. If the value of the element is 447 set to FALSE, then the element in the PIDF-LO MUST 448 NOT contain a reference to an external rule set. The reference to 449 the ruleset is removed and no rules are carried as MIME bodies (in 450 case of Content-ID (cid:) URIs [RFC2392]). 452 If the element is absent, then the value of the 453 element in the PIDF-LO is kept unchanged when 454 available or, if the PIDF-LO is created for the first time then the 455 element MUST NOT be included. 457 6.5. Provide Location 459 The element contains child elements of a specific 460 location profile that controls the granularity of returned location 461 information. This form of location granularity reduction is also 462 called 'obfuscation' and is defined in [duckham05] as 464 "the means of deliberately degrading the quality of information 465 about an individual's location in order to protect that 466 individual's location privacy." 468 Location obscuring presents a number of technical challenges. The 469 algorithms provided in this document are provided as examples only. 470 A discussion of the technical constraints on location obscuring is 471 included in Section 13.5. 473 The functionality of location granularity reduction depends on the 474 type of location provided as input. This document defines two 475 profiles for reduction, namely: 477 o If the element has a child 478 element then civic location information is disclosed as described 479 in Section 6.5.1, subject to availability. 481 o If the element has a child 482 element then geodetic location information is disclosed as 483 described in Section 6.5.2, subject to availability. 485 The element MUST contain the 'profile' attribute 486 if it contains child elements and the 'profile' attribute MUST match 487 with the contained child elements. 489 If the element has no child elements then civic, 490 as well as, geodetic location information is disclosed without 491 reducing its granularity, subject to availability. In this case the 492 profile attribute MUST NOT be included. 494 6.5.1. Civic Location Profile 496 This profile uses the token 'civic-transformation'. This profile 497 allows civic location transformations to be specified by means of the 498 element that restricts the level of civic location 499 information the LS is permitted to disclose. The symbols of these 500 levels are: 'country', 'region', 'city', 'building', 'full'. Each 501 level is given by a set of civic location data items such as 502 and , ..., , as defined in [RFC5139]. Each level 503 includes all elements included by the lower levels. 505 The 'country' level includes only the element; the 'region' 506 level adds the element; the 'city' level adds the and 507 elements; the 'building' level and the 'full' level add further civic 508 location data as shown below. 510 full 511 {, , , , , , , , , 512 , , , , , , , , 513 ,,,, , , , 514 , , , , , } 515 | 516 | 517 building 518 {, , , , , , , 519 , , , , , , 520 , , , , } 521 | 522 | 523 city 524 {, , , } 525 | 526 | 527 region 528 {, } 529 | 530 | 531 country 532 {} 533 | 534 | 535 none 536 {} 538 The default value is "none". 540 The schema of the element is defined in Section 8. 542 6.5.2. Geodetic Location Profile 544 This profile uses the token 'geodetic-transformation' and refers only 545 to the Coordinate Reference System (CRS) WGS 84 546 (urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic 547 location transformations to be specified by means of the element that may restrict the returned geodetic location 549 information based on the value provided in the 'radius' attribute. 550 The value of the 'radius' attribute expresses the radius in meters. 552 The schema of the element is defined in Section 8. 554 The algorithm proceeds in 6 steps. The first two steps are 555 independent of the measured position to be obscured. Those two steps 556 should be run only once or rather seldom (for every region and 557 desired uncertainty). The steps are: 559 1. Choose a geodesic projection with Cartesian coordinates and a 560 surface you want to cover. The maximal distortion of the map may 561 not be too much (see notes below). 563 2. Given uncertainty "d", choose a grid of so called "landmarks" at 564 a distance (maximal) d of each other. 566 3. Given a measured location M=(m,n) in the surface, calculate its 4 567 closest landmarks on the grid, with coordinates: SW = (l,b), 568 SE=(r,b), NW=(l,t), NE=(r,t). Thus l<=m element. 639 Requests match only if the Target is at a civic location with country 640 set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to 641 'Munich', city division (A4) set to 'Perlach', street name (A6) set 642 to 'Otto-Hahn-Ring' and house number (HNO) set to '6'. 644 No actions and transformation child elements are provided in this 645 rule example. The actions and transformation could include presence 646 specific information when the Geolocation Policy framework is applied 647 to the Presence Policy framework (see [RFC5025]). 649 650 653 654 655 656 661 DE 662 Bavaria 663 Munich 664 Perlach 665 Otto-Hahn-Ring 666 6 667 668 669 670 671 672 673 675 7.2. Rule Example with Geodetic Location Condition 677 This example illustrates a rule that employs the geodetic location 678 condition. The rule matches if the current location of the Target is 679 inside the area specified by the polygon. The polygon uses the EPSG 680 4326 coordinate reference system. No altitude is included in this 681 example. 683 684 690 691 692 693 697 698 -33.8570029378 151.2150070761 699 1500 700 701 702 703 704 705 706 707 709 7.3. Rule Example with Civic and Geodetic Location Condition 711 This example illustrates a rule that employs a mixed civic and 712 geodetic location condition. Depending on the available type of 713 location information, namely civic or geodetic location information, 714 one of the location elements may match. 716 717 723 724 725 726 728 DE 729 Bavaria 730 Munich 731 Perlach 732 Otto-Hahn-Ring 733 6 734 735 736 737 -34.410649 150.87651 738 1500 739 740 741 742 743 744 745 746 747 749 7.4. Rule Example with Location-based Transformations 751 This example shows the transformations specified in this document. 752 The element indicates that the available civic 753 location information is reduced to building level granularity. If 754 geodetic location information is requested then a granularity 755 reduction is provided as well. 757 758 762 763 764 765 766 false 767 768 86400 769 My privacy policy goes in here. 770 771 false 772 774 776 building 777 779 781 782 784 785 786 788 The following rule describes the short-hand notation for making the 789 current location of the Target available to Location Recipients 790 without granularity reduction. 792 793 796 797 798 799 800 801 802 803 805 7.5. Location Obfuscation Example 807 Suppose you want to obscure positions in the continental USA. 809 Step 1: 811 First you choose a geodesic projection. If you are measuring 812 location as latitude and longitude, a natural choice is to take a 813 rectangular projection. One latitudinal degree corresponds 814 approximately to 110.6 kilometers, while a good approximation of a 815 longitudinal degree at latitude phi is (pi/180)*M*cos(phi), where 816 pi is approximately 3.1415, and M is the Earth's average 817 meridional radius, approximately 6,367.5 km. For instance, one 818 longitudinal degree at 30 degrees (say, New Orleans) is 96.39 km, 819 while the formula given offers an estimation of 96.24, which is 820 good for our purposes. 822 We will set up a grid not only for the continental US, but for the 823 whole earth between latitudes 25 and 50 degrees, and thus will 824 cover also the Mediterranean, South Europe, Japan and the north of 825 China. As will be seen below, the grid distortion (for not too 826 large grids in this region) is approx cos(25)/cos(50), which is 827 1.4099. 829 As origin of our grid, we choose the point at latitude 25 degrees 830 and longitude 0 (Greenwich). The latitude 25 degrees is chosen to 831 be just south of Florida and thus south of the continental US. 832 (On the south hemisphere the origin should be north of the region 833 to be covered; if the region crosses the Equator, the origin 834 should be on the Equator. In this way it is guaranteed that the 835 latitudinal degree has largest distance at the latitude of the 836 origin). 838 At 25 degrees one degree in east-west direction corresponds approx 839 to (pi/180)*M*cos(25) = 100.72 km. 841 The same procedure, basically, produces grids for 843 * 45 degrees south to 45 degrees north Tropics and subtropics 845 * 25 to 50 degrees (both north or south) Continental US 847 * 35 to 55 degrees (both north or south) South and Central Europe 849 * 45 to 60 degrees (both north or south) Central and North Europe 851 * 55 to 65 degrees (both north or south) Scandinavia 852 * 60 to 70 degrees (both north or south) 854 Since we do not want to often change grid system (this would leak 855 more information about obscured locations when they are repeatedly 856 visited), the algorithm should prefer to use the grids discussed 857 above, with origin at the Greenwich meridian and at latitudes o=0, 858 o=25, o=35, o=45, 0=55, and o=60 degrees (north) or at latitudes 859 o=-25, o=-35, o=-45, 0=-55, and o=-60 degrees (the minus to 860 indicate "south"). 862 Our choice for the continental USA is o=25. 864 For locations close to the poles, a different projection should be 865 used (not discussed here). 867 Step 2: 869 To construct the grid points, we start with our chosen origin and 870 place the along the main axes (NS and EW) grid points at a 871 distance d of each other. 873 We will now construct a grid for a desired uncertainty of d = 874 100km. At our origin, 100 km correspond roughly to d1 = 100/ 875 100.72 = 0.993 degrees on east-west direction and to d2 = 100/ 876 110.6 = 0.904 degrees in north-south direction. 878 The (i,j)-point in the grid (i and j are integers) has longitude 879 d1*i and latitude 25+d2*j, measured in degrees. More generally, 880 if the grid has origin at coordinates (0,o), measured in degrees, 881 the (i,j)-point in the grid has coordinates (longitude = d1*i, 882 latitude = o+d2*j). The grid has almost no distorsion at the 883 latitude of the origin, but it has as we go further away from it. 885 The distance between two points in the grid at 25 degrees latitude 886 is indeed approx 100 km, but just above the Canadian border, on 887 the 50th degree, it is 0.993*(pi/180)*M*cos(50) = 70.92km. Thus, 888 the grid distortion is 100/70.92 = 1.41, which is acceptable 889 (<1.5). (On north-south direction the grid has roughly no 890 distortion, the vertical distance between two neighboring grid 891 points is approximately 100 km). 893 Step 3: 895 Now suppose you measure a position at M, with longitude -105 (the 896 minus sign is used to denote 105 degrees *west*; without minus, 897 the point is in China, 105 degrees east) and latitude 40 degrees 898 (just north of Denver, CO). The point M is 105 degrees west and 899 15 degrees north of our origin (which has longitude 0 and latitude 900 25). 902 Let "floor" be the function that returns the largest integer 903 smaller or equal to a floating point number. To calculate SW, the 904 closest point of the grid on the south-west of M=(m,n), we 905 calculate 907 i= floor(m/d1) = floor(-105/0.993) = -106 909 j= floor(n-o/d2) = floor(15/0.904) = 16 911 Those are the indexes of SW on the grid. The coordinates of SW 912 are then: (d1*i, 25+d2*j) = (-105.242, 39.467). 914 Thus: 916 l=d1*floor(m/d1) = -105.243 918 r=l+d1 = -105.243+0.993 = -104.250 920 b=o+d2*floor(n-o/d2) = 39.467 922 t=b+d2 = 39.467+0.904 = 40.371 924 These are the formulas for l,r,b, and t in the general case of 925 Cartesian projections based on latitude and longitude. 927 Step 4: 929 Calculate x and y, the local coordinates of the point M in the 930 small grid square that contains it. This is easy: 932 x=(m-l)/(r-l) = [-105 -(-105.243)]/0.993 = 0.245 934 y=(n-b)/(t-b) = [40 - 39.467]/0.904 = 0.590 936 Step 5: 938 First compare x with p (0.2887) and (0.7113). x is smaller than p. 939 Therefore, only cases 1,4 or 6 could hold. 941 Also compare y with p (0.2887) and (0.7113). y is between them: p 942 <= y < q. Thus, we must be in case 4. To check, compare y (0.59) 943 with x (0.245) and 1-x. y is larger than x and smaller than 1-x. 945 We are in case C4 (p <= y < q and x <= y and y < 1-x). 947 Step 6: 949 Now we choose either SW or NW as the center of the circle. 951 The obscured location is the Circle with radius 100 km and center 952 in SW (coordinates: -105.243, 39.467), or NW (coordinates: 953 -105.243, 40.371). 955 8. XML Schema for Basic Location Profiles 957 This section defines the location profiles used as child elements of 958 the transformation element. 960 961 967 969 970 971 972 973 974 975 976 977 978 979 980 982 984 985 986 987 988 990 992 9. XML Schema for Geolocation Policy 994 This section presents the XML schema that defines the Geolocation 995 Policy schema described in this document. The Geolocation Policy 996 schema extends the Common Policy schema (see [RFC4745]). 998 999 1006 1007 1009 1010 1013 1015 1018 1019 1020 1021 1022 1024 1026 1027 1028 1029 1031 1032 1033 1034 1035 1037 1038 1039 1040 1041 1042 1043 1045 1046 1048 1050 1052 1055 1058 1059 1060 1061 1062 1063 1064 1066 1067 1068 1069 1070 1072 1073 1074 1075 1076 1078 1080 10. XCAP Usage 1082 The following section defines the details necessary for clients to 1083 manipulate geolocation privacy documents from a server using XCAP. 1084 If used as part of a presence system, it uses the same AUID as those 1085 rules. See [RFC5025] for a description of the XCAP usage in context 1086 with presence authorization rules. 1088 10.1. Application Unique ID 1090 XCAP requires application usages to define a unique application usage 1091 ID (AUID) in either the IETF tree or a vendor tree. This 1092 specification defines the "geolocation-policy" AUID within the IETF 1093 tree, via the IANA registration in Section 11. 1095 10.2. XML Schema 1097 XCAP requires application usages to define a schema for their 1098 documents. The schema for geolocation authorization documents is 1099 described in Section 9. 1101 10.3. Default Namespace 1103 XCAP requires application usages to define the default namespace for 1104 their documents. The default namespace is 1105 urn:ietf:params:xml:ns:geolocation-policy. 1107 10.4. MIME Media Type 1109 XCAP requires application usages to define the MIME media type for 1110 documents they carry. Geolocation privacy authorization documents 1111 inherit the MIME type of common policy documents, application/ 1112 auth-policy+xml. 1114 10.5. Validation Constraints 1116 This specification does not define additional constraints. 1118 10.6. Data Semantics 1120 This document discusses the semantics of a geolocation privacy 1121 authorization. 1123 10.7. Naming Conventions 1125 When a Location Server receives a request to access location 1126 information of some user foo, it will look for all documents within 1127 http://[xcaproot]/geolocation-policy/users/foo, and use all documents 1128 found beneath that point to guide authorization policy. 1130 10.8. Resource Interdependencies 1132 This application usage does not define additional resource 1133 interdependencies. 1135 10.9. Authorization Policies 1137 This application usage does not modify the default XCAP authorization 1138 policy, which is that only a user can read, write or modify his/her 1139 own documents. A server can allow privileged users to modify 1140 documents that they do not own, but the establishment and indication 1141 of such policies is outside the scope of this document. 1143 11. IANA Considerations 1145 There are several IANA considerations associated with this 1146 specification. 1148 11.1. Geolocation Policy XML Schema Registration 1150 This section registers an XML schema in the IETF XML Registry as per 1151 the guidelines in [RFC3688]. 1153 URI: urn:ietf:params:xml:schema:geolocation-policy 1155 Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), 1156 Hannes Tschofenig (hannes.tschofenig@nsn.com). 1158 XML: The XML schema to be registered is contained in Section 9. Its 1159 first line is 1161 1163 and its last line is 1165 1167 11.2. Geolocation Policy Namespace Registration 1169 This section registers a new XML namespace in the IETF XML Registry 1170 as per the guidelines in [RFC3688]. 1172 URI: urn:ietf:params:xml:ns:geolocation-policy 1174 Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), 1175 Hannes Tschofenig (hannes.tschofenig@nsn.com). 1177 XML: 1179 BEGIN 1180 1181 1183 1184 1185 1187 Geolocation Policy Namespace 1188 1189 1190

Namespace for Geolocation Authorization Policies

1191

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

1192

See RFCXXXX 1193 [NOTE TO IANA/RFC-EDITOR: 1194 Please replace XXXX with the RFC number of this 1195 specification.].

1196 1197 1198 END 1200 11.3. Geolocation Policy Location Profile Registry 1202 This document creates a registry of location profile names for the 1203 Geolocation Policy framework. Profile names are XML tokens. This 1204 registry will operate in accordance with RFC 5226 [RFC5226], 1205 Specification Required. 1207 This document defines the following profile names: 1209 geodetic-condition: Defined in Section 4.1. 1211 civic-condition: Defined in Section 4.2. 1213 geodetic-transformation: Defined in Section 6.5.2. 1215 civic-transformation: Defined in Section 6.5.1. 1217 11.4. Basic Location Profile XML Schema Registration 1219 This section registers an XML schema in the IETF XML Registry as per 1220 the guidelines in [RFC3688]. 1222 URI: urn:ietf:params:xml:schema:basic-location-profiles 1223 Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), 1224 Hannes Tschofenig (hannes.tschofenig@nsn.com). 1226 XML: The XML schema to be registered is contained in Section 8. Its 1227 first line is 1229 1231 and its last line is 1233 1235 11.5. Basic Location Profile Namespace Registration 1237 This section registers a new XML namespace in the IETF XML Registry 1238 as per the guidelines in [RFC3688]. 1240 URI: urn:ietf:params:xml:ns:basic-location-profiles 1242 Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), 1243 Hannes Tschofenig (hannes.tschofenig@nsn.com). 1245 XML: 1247 BEGIN 1248 1249 1251 1252 1253 1255 Basic Location Profile Namespace 1256 1257 1258

Namespace for Basic Location Profile

1259

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

1260

See RFCXXXX 1261 [NOTE TO IANA/RFC-EDITOR: 1262 Please replace XXXX with the RFC number of this 1263 specification.].

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