idnits 2.17.00 (12 Aug 2021) /tmp/idnits51421/draft-ietf-geopriv-policy-22.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 24, 2010) is 4226 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'GML' == Outdated reference: draft-ietf-geopriv-pdif-lo-profile has been published as RFC 5491 == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-05 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 27, 2011 Nokia Siemens Networks 6 J. Morris 7 CDT 8 J. Cuellar 9 Siemens 10 J. Polk 11 Cisco 12 October 24, 2010 14 Geolocation Policy: A Document Format for Expressing Privacy Preferences 15 for Location Information 16 draft-ietf-geopriv-policy-22.txt 18 Abstract 20 This document defines an authorization policy language for 21 controlling access to location information. It extends the Common 22 Policy authorization framework to provide location-specific access 23 control. More specifically, this document defines condition elements 24 specific to location information in order to restrict access based on 25 the current location of the Target. Furthermore, it offers location- 26 specific transformation elements to reduce the granularity of the 27 returned location information. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 27, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1. Structure of Geolocation Authorization Documents . . . . . 8 67 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 8 68 4. Location-specific Conditions . . . . . . . . . . . . . . . . . 9 69 4.1. Geodetic Location Condition Profile . . . . . . . . . . . 9 70 4.2. Civic Location Condition Profile . . . . . . . . . . . . . 10 71 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 12 73 6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 12 74 6.2. Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 12 75 6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 12 76 6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 13 77 6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 13 78 6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 14 79 6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 15 80 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 7.1. Rule Example with Civic Location Condition . . . . . . . . 18 82 7.2. Rule Example with Geodetic Location Condition . . . . . . 19 83 7.3. Rule Example with Civic and Geodetic Location Condition . 19 84 7.4. Rule Example with Location-based Transformations . . . . . 20 85 7.5. Location Obfuscation Example . . . . . . . . . . . . . . . 22 86 8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 26 87 9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 27 88 10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 29 90 10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 29 91 10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 29 92 10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 29 93 10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 29 94 10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 29 95 10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 29 96 10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 30 97 10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 30 98 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 99 11.1. Geolocation Policy XML Schema Registration . . . . . . . . 31 100 11.2. Geolocation Policy Namespace Registration . . . . . . . . 31 101 11.3. Geolocation Policy Location Profile Registry . . . . . . . 32 102 11.4. Basic Location Profile XML Schema Registration . . . . . . 32 103 11.5. Basic Location Profile Namespace Registration . . . . . . 33 104 11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 33 105 12. Internationalization Considerations . . . . . . . . . . . . . 35 106 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 107 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 108 14.1. Normative References . . . . . . . . . . . . . . . . . . . 38 109 14.2. Informative References . . . . . . . . . . . . . . . . . . 38 110 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 113 1. Introduction 115 Location information needs to be protected against unauthorized 116 access to preserve the privacy of humans. In RFC 3693 [RFC3693], a 117 protocol-independent model for access to geographic information is 118 defined. The model includes a Location Generator (LG) that 119 determines location information, a Location Server (LS) that 120 authorizes access to location information, a Location Recipient (LR) 121 that requests and receives location information, and a Rule Maker 122 (RM) that writes authorization policies. An authorization policy is 123 a set of rules that regulates an entity's activities with respect to 124 privacy-sensitive information, such as location information. 126 The data object containing location information in the context of 127 this document is referred to as a Location Object (LO). The basic 128 rule set defined in the Presence Information Data Format Location 129 Object (PIDF-LO) [RFC4119] can restrict how long the Location 130 Recipient is allowed to retain the information, and it can prohibit 131 further distribution. It also contains a reference to an enhanced 132 rule set and a human readable privacy policy. The basic rule set, 133 however, does not allow to control access to location information 134 based on specific Location Recipients. This document describes an 135 enhanced rule set that provides richer constraints on the 136 distribution of LOs. 138 The rule set allows the entity that uses the rules defined in this 139 document to restrict the retention and to enforce access restrictions 140 on location data, including prohibiting any dissemination to 141 particular individuals, during particular times or when the Target is 142 located in a specific region. The RM can also stipulate that only 143 certain parts of the Location Object are to be distributed to 144 recipients or that the resolution of parts of the Location Object is 145 reduced. 147 The typical sequence of operations is as follows. A Location Server 148 receives a query for location information for a particular Target, 149 via the using protocol [RFC3693]. The using protocol provides the 150 identity of the requestor, either at the time of the query or when 151 subscribing to the location information. The authenticated identity 152 of the Location Recipient, together with other information provided 153 by the using protocol or generally available to the server, is then 154 used for searching through the rule set. If more than one rule 155 matches the condition element, then the combined permission is 156 evaluated according to the description in Section 10 of [RFC4745]. 157 The result of the rule evalation is applied to the location 158 information, yielding a possibly modified Location Object that is 159 delivered to the Location Recipient. 161 This document does not describe the protocol used to convey location 162 information from the Location Server to the Location Recipient (i.e., 163 the using protocol; see RFC 3693 [RFC3693]). 165 This document extends the Common Policy framework defined in 166 [RFC4745]. That document provides an abstract framework for 167 expressing authorization rules. As specified there, each such rule 168 consists of conditions, actions and transformations. Conditions 169 determine under which circumstances the entity executing the rules, 170 for example a Location Server, is permitted to apply actions and 171 transformations. Transformations regulate in a location information 172 context how a Location Server modifies the information elements that 173 are returned to the requestor, for example, by reducing the 174 granularity of returned location information. 176 The XML schema defined in Section 9 extends the Common Policy schema 177 by introducing new child elements to the condition and transformation 178 elements. This document does not define child elements for the 179 action part of a rule. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 This document reuses the terminology of RFC 3693 [RFC3693], such as 188 Location Server (LS), Location Recipient (LR), Rule Maker (RM), 189 Target, Location Generator (LG) and Location Object (LO). This 190 document uses the following terminology: 192 Presentity or Target: 194 RFC 3693 [RFC3693] uses the term Target to identify the object or 195 person of which location information is required. The presence 196 model described in RFC 2778 [RFC2778] uses the term presentity to 197 describe the entity that provides presence information to a 198 presence service. A Presentity in a presence system is a Target 199 in a location information system. 201 Watcher or Location Recipient: 203 The receiver of location information is the Location Recipient 204 (LR) in the terminology of RFC 3693 [RFC3693]. A watcher in a 205 presence system, i.e., an entity that requests presence 206 information about a presentity, is a Location Recipient in a 207 location information system. 209 Authorization policy: 211 An authorization policy is given by a rule set. A rule set 212 contains an unordered list of (policy) rules. Each rule has a 213 condition, an action and a transformation component. 215 Permission: 217 The term permission refers to the action and transformation 218 components of a rule. 220 The term 'using protocol' is defined in [RFC3693] and refers to the 221 protocol that is used to request access to and to return privacy 222 sensitive data items. 224 In this document we use the term Location Servers as the entities 225 that evaluate the geolocation authorization policies. The 226 geolocation privacy architecture is, as motivated in RFC 4079 227 [RFC4079], aligned with the presence architecture and a Presence 228 Server is therefore an entity that distributes location information 229 along with other presence-specific XML data elements. 231 3. Generic Processing 233 3.1. Structure of Geolocation Authorization Documents 235 A geolocation authorization document is an XML document, formatted 236 according to the schema defined in [RFC4745]. Geolocation 237 authorization documents inherit the MIME type of common policy 238 documents, application/auth-policy+xml. As described in [RFC4745], 239 this document is composed of rules which contain three parts - 240 conditions, actions, and transformations. Each action or 241 transformation, which is also called a permission, has the property 242 of being a positive grant of information to the Location Recipient. 243 As a result, there is a well-defined mechanism for combining actions 244 and transformations obtained from several sources. This mechanism is 245 privacy safe, since the lack of any action or transformation can only 246 result in less information being presented to a Location Recipient. 248 3.2. Rule Transport 250 There are two ways how the authorization rules described in this 251 document may be conveyed between different parties: 253 o RFC 4119 [RFC4119] allows enhanced authorization policies to be 254 referenced via a Uniform Resource Locator (URL) in the 'ruleset- 255 reference' element. The ruleset-reference' element is part of the 256 basic rules that always travel with the Location Object. 258 o Authorization policies might, for example, also be stored at a 259 Location Server / Presence Server. The Rule Maker therefore needs 260 to use a protocol to create, modify and delete the authorization 261 policies defined in this document. Such a protocol is available 262 with the Extensible Markup Language (XML) Configuration Access 263 Protocol (XCAP) [RFC4825]. 265 4. Location-specific Conditions 267 This section describes the location-specific conditions of a rule. 268 The element contains zero, one or an unbounded number of 269 child element(s). Providing more than one 270 element may not be useful since all child 271 elements of the element must evaluate to TRUE in order 272 for the element to be TRUE. The 273 element MUST contain at least one child element. The 274 element evaluates to TRUE if any of its child 275 elements is TRUE, i.e., a logical OR. 277 The element has three attributes, namely 'profile', 'xml: 278 lang' and 'label'. The 'profile' attribute allows to indicate the 279 location profile that is included as child elements in the 280 element and each profile needs to describe under what conditions each 281 element evaluates to TRUE. This document defines two 282 location profiles, one civic and one geodetic location profile, see 283 Section 4.1 and Section 4.2. The 'label' attribute allows a human 284 readable description to be added to each lt;location> element. The 285 'xml:lang' attribute contains a language tag providing further 286 information for rendering of the content of the 'label' attribute. 288 The and the elements provide 289 extension points. If an extension is not understood by the entity 290 evaluating the rules then this rule evaluates to FALSE. 292 4.1. Geodetic Location Condition Profile 294 The geodetic location profile is identified by the token 'geodetic- 295 condition'. Rule Makers use this profile by placing a GML [GML] 296 element within the element (as described in 297 Section 5.2.3 of [I-D.ietf-geopriv-pdif-lo-profile]). 299 The element containing the information for the geodetic 300 location profile evaluates to TRUE if the current location of the 301 Target is within the described location. Note that the Target's 302 actual location might be represented by any of the location shapes 303 described in [I-D.ietf-geopriv-pdif-lo-profile]. If the geodetic 304 location of the Target is unknown then the element 305 containing the information for the geodetic location profile 306 evaluates to FALSE. 308 Implementations are REQUIRED to support the following coordinate 309 reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the 310 European Petroleum Survey Group (EPSG) Geodetic Parameter Dataset (as 311 formalized by the Open Geospatial Consortium (OGC)): 313 2D: WGS 84 (latitude, longitude), as identified by the URN 314 "urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS. 316 A CRS MUST be specified using the above URN notation only, 317 implementations do not need to support user-defined CRSs. 319 Implementations MUST specify the CRS using the "srsName" attribute on 320 the outermost geometry element. The CRS MUST NOT be changed for any 321 sub-elements. The "srsDimension" attribute MUST be omitted, since 322 the number of dimensions in these CRSs is known. 324 4.2. Civic Location Condition Profile 326 The civic location profile is identified by the token 'civic- 327 condition'. Rule Makers use this profile by placing a 328 element, defined in [RFC5139], within the element. 330 All child elements of element that carry civicAddress 331 elements MUST evaluate to TRUE (i.e., logical AND) in order for the 332 element to evaluate to TRUE. For each child element, the 333 value of that element is compared to the value of the same element in 334 the Target's civic location. The child element evaluates to TRUE if 335 the two values are identical based on a bit-by-bit comparison. 337 If the civic location of the Target is unknown, then the 338 element containing the information for the civic location profile 339 evaluates to FALSE. This case may occur, for example, if location 340 information has been removed by earlier transmitters of location 341 information or if only the geodetic location is known. In general, 342 it is RECOMMENDED behavior for a LS not to apply a translation from 343 geodetic location to civic location (i.e., geocode the location). 345 5. Actions 347 This document does not define location-specific actions. 349 6. Transformations 351 This document defines several elements that allow Rule Makers to 352 specify transformations that 354 o reduce the accuracy of the returned location information, and 356 o set the basic authorization policies carried inside the PIDF-LO. 358 6.1. Set Retransmission-Allowed 360 This element asks the LS to change or set the value of the 361 element in the PIDF-LO. The data type of 362 the element is a boolean. 364 If the value of the element is set to 365 TRUE then the element in the PIDF-LO MUST be 366 set to TRUE. If the value of the 367 element is set to FALSE, then the element in 368 the PIDF-LO MUST be set to FALSE. 370 If the element is absent then the value 371 of the element in the PIDF-LO MUST be kept 372 unchanged or, if the PIDF-LO is created for the first time, then the 373 value MUST be set to FALSE. 375 6.2. Set Retention-Expiry 377 This transformation asks the LS to change or set the value of the 378 element in the PIDF-LO. The data type of the 379 element is an integer. 381 The value provided with the element indicates 382 seconds and these seconds are added to the current date. 384 If the element is absent then the value of the 385 element in the PIDF-LO is kept unchanged or, if 386 the PIDF-LO is created for the first time, then the value MUST be set 387 to the current date. 389 6.3. Set Note-Well 391 This transformation asks the LS to change or set the value of the 392 element in the PIDF-LO. The data type of the element is a string. 395 The value provided with the element contains a 396 privacy statement as a human readable text string and an 'xml:lang' 397 attribute denotes the language of the human readable text. 399 If the element is absent, then the value of the 400 element in the PIDF-LO is kept unchanged or, if the 401 PIDF-LO is created for the first time, then no content is provided 402 for the element. 404 6.4. Keep Ruleset Reference 406 This transformation allows to influence whether the element in the PIDF-LO carries the extended authorization 408 rules defined in [RFC4745]. The data type of the element is Boolean. 411 If the value of the element is set to TRUE, 412 then the element in the PIDF-LO is kept unchanged 413 when included. If the value of the element is 414 set to FALSE, then the element in the PIDF-LO MUST 415 NOT contain a reference to an external rule set. The reference to 416 the ruleset is removed and no rules are carried as MIME bodies (in 417 case of CID URIs). 419 If the element is absent, then the value of the 420 element in the PIDF-LO is kept unchanged when 421 available or, if the PIDF-LO is created for the first time then the 422 element MUST NOT be included. 424 6.5. Provide Location 426 The element contains child elements of a specific 427 location profile that controls the granularity of returned location 428 information. This form of location granularity reduction is also 429 called 'obfuscation' and is defined in [duckham05] as 431 the means of deliberately degrading the quality of information 432 about an individual's location in order to protect that 433 individual's location privacy. 435 The functionality of location granularity reduction depends on the 436 type of location provided as input. This document defines two 437 profiles for reduction, namely: 439 o If the element has a child 440 element then civic location information is disclosed as described 441 in Section 6.5.1, subject to availability. 443 o If the element has a child 444 element then geodetic location information is disclosed as 445 described in Section 6.5.2, subject to availability. 447 The element MUST contain the 'profile' attribute 448 if it contains child elements and the 'profile' attribute MUST match 449 with the contained child elements. 451 If the element has no child elements then civic, 452 as well as, geodetic location information is disclosed without 453 reducing its granularity, subject to availability. In this case the 454 profile attribute MUST NOT be included. 456 6.5.1. Civic Location Profile 458 This profile uses the token 'civic-transformation'. This profile 459 allows civic location transformations to be specified by means of the 460 element that restricts the level of civic location 461 information the LS is permitted to disclose. The symbols of these 462 levels are: 'country', 'region', 'city', 'building', 'full'. Each 463 level is given by a set of civic location data items such as 464 and , ..., , as defined in [RFC5139]. Each level 465 includes all elements included by the lower levels. 467 The 'country' level includes only the element; the 'region' 468 level adds the element; the 'city' level adds the and 469 elements; the 'building' level and the 'full' level add further civic 470 location data as shown below. 472 full 473 {, , , , , , , , , 474 , , , , , , , , 475 ,,,, , , , 476 , , , , , } 477 | 478 | 479 building 480 {, , , , , , , 481 , , , , , , 482 , , , , } 483 | 484 | 485 city 486 {, , , } 487 | 488 | 489 region 490 {, } 491 | 492 | 493 country 494 {} 495 | 496 | 497 none 498 {} 500 The default value is "none". 502 The schema of the element is defined in Section 8. 504 6.5.2. Geodetic Location Profile 506 This profile uses the token 'geodetic-transformation' and refers only 507 to the Coordinate Reference System (CRS) WGS 84 508 (urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic 509 location transformations to be specified by means of the element that may restrict the returned geodetic location 511 information based on the value provided in the 'radius' attribute. 512 The value of the 'radius' attribute expresses the radius in meters. 514 The schema of the element is defined in Section 8. 516 The algorithm proceeds in 6 steps. The first two steps are 517 independent of the measured position to be obscured. Those two steps 518 should be run only once or rather seldom (for every region and 519 desired uncertainty). The steps are: 521 1. Choose a geodesic projection with Cartesian coordinates and a 522 surface you want to cover. The maximal distortion of the map may 523 not be too much (see notes below). 525 2. Given uncertainty "d", choose a grid of so called "landmarks" at 526 a distance (maximal) d of each other. 528 3. Given a measured location M=(m,n) in the surface, calculate its 4 529 closest landmarks on the grid, with coordinates: SE=(b,l), 530 SW=(b,r), NE=(t,l), NW=(t,r). Thus l<=m element. 601 Requests match only if the Target is at a civic location with country 602 set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to 603 'Munich', city division (A4) set to 'Perlach', street name (A6) set 604 to 'Otto-Hahn-Ring' and house number (HNO) set to '6'. 606 No actions and transformation child elements are provided in this 607 rule example. The actions and transformation could include presence 608 specific information when the Geolocation Policy framework is applied 609 to the Presence Policy framework (see [RFC5025]). 611 612 615 616 617 618 623 DE 624 Bavaria 625 Munich 626 Perlach 627 Otto-Hahn-Ring 628 6 629 630 631 632 633 634 635 637 7.2. Rule Example with Geodetic Location Condition 639 This example illustrates a rule that employs the geodetic location 640 condition. The rule matches if the current location of the Target is 641 inside the area specified by the polygon. The polygon uses the EPSG 642 4326 coordinate reference system. No altitude is included in this 643 example. 645 646 652 653 654 655 659 660 -33.8570029378 151.2150070761 661 1500 662 663 664 665 666 667 668 669 671 7.3. Rule Example with Civic and Geodetic Location Condition 673 This example illustrates a rule that employs a mixed civic and 674 geodetic location condition. Depending on the available type of 675 location information, namely civic or geodetic location information, 676 one of the location elements may match. 678 679 685 686 687 688 690 DE 691 Bavaria 692 Munich 693 Perlach 694 Otto-Hahn-Ring 695 6 696 697 698 699 -34.410649 150.87651 700 1500 701 702 703 704 705 706 707 708 709 711 7.4. Rule Example with Location-based Transformations 713 This example shows the transformations specified in this document. 714 The element indicates that the available civic 715 location information is reduced to building level granularity. If 716 geodetic location information is requested then a granularity 717 reduction is provided as well. 719 720 724 725 726 727 728 false 729 730 86400 731 My privacy policy goes in here. 732 733 false 734 736 738 building 739 741 743 744 746 747 748 750 The following rule describes the short-hand notation for making the 751 current location of the Target available to Location Recipients 752 without granularity reduction. 754 755 758 759 760 761 762 763 764 765 767 7.5. Location Obfuscation Example 769 Suppose you want a to obscure positions in the continental USA. 771 Step 1: 773 First you choose a geodesic projection. If you are measuring 774 location as latitude and longitude, a natural choice is to take a 775 rectangular projection. One latitudinal degree corresponds 776 approximately to 110.6 kilometers, while a good approximation of a 777 longitudinal degree at latitude phi is (pi/180)*M*cos(phi), where 778 pi is approximately 3.1415, and M is the Earth's average 779 meridional radius, approximately 6,367.5 km. For instance, one 780 longitudinal degree at 30 degrees (say, New Orleans) is 96.39 km, 781 while the formula given offers an estimation of 96.24, which is 782 good for our purposes. 784 We will set up a grid not only for the continental US, but for the 785 whole earth between latitudes 25 and 50 degrees, and thus will 786 cover also the Mediterranean, South Europe, Japan and the north of 787 China. As will be seen below, the grid distortion (for not too 788 large grids in this region) is approx cos(25)/cos(50), which is 789 1.4099. 791 As origin of our grid, we choose the point at latitude 25 degrees 792 and longitude 0 (Greenwich). The latitude 25 degrees is chosen to 793 be just south of Florida and thus south of the continental US. 794 (On the south hemisphere the origin should be north of the region 795 to be covered; if the region crosses the Equator, the origin 796 should be on the Equator. In his way it is guaranteed that the 797 latitudinal degree has largest distance at the latitude of the 798 origin). 800 At 25 degrees one degree in east-west direction corresponds approx 801 to (pi/180)*M*cos(25) = 100.72 km. 803 The same procedure, basically, produces grids for 805 * 45 degrees south to 45 degrees north Tropics and subtropics 807 * 25 to 50 degrees (both north or south) Continental US 809 * 35 to 55 degrees (both north or south) South and Central Europe 811 * 45 to 60 degrees (both north or south) Central and North Europe 813 * 55 to 65 degrees (both north or south) Scandinavia 814 * 60 to 70 degrees (both north or south) 816 Since we do not want to often change grid system (this would leak 817 more information about obscured locations when they are repeatedly 818 visited), the algorithm should prefer to use the grids discussed 819 above, with origin at the Greenwich meridian and at latitudes o=0, 820 o=25, o=35, o=45, 0=55, and o=60 degrees (north) or at latitudes 821 o=-25, o=-35, o=-45, 0=-55, and o=-60 degrees (the minus to 822 indicate "south"). 824 Our choice for the continental USA is o=25. 826 For locations close to the poles, a different projection should be 827 used (not discussed here). 829 Step 2: 831 To construct the grid points, we start with our chosen origin and 832 place the along the main axes (NS and EW) grid points at a 833 distance d of each other. 835 We will now construct a grid for a desired uncertainty of d = 836 100km. At our origin, 100 km correspond roughly to d1 = 100/ 837 100.72 = 0.993 degrees on east-west direction and to d2 = 100/ 838 110.6 = 0.904 degrees in north-south direction. 840 The (i,j)-point in the grid (i and j are integers) has longitude 841 d1*i and latitude 25+d2*j, measured in degrees. More generally, 842 if the grid has origin at coordinates (0,o), measured in degrees, 843 the (i,j)-point in the grid has coordinates (longitude = d1*i, 844 latitude = o+d2*j). The grid has almost no distorsion at the 845 latitude of the origin, but it has as we go further away from it. 847 The distance between two points in the grid at 25 degrees latitude 848 is indeed approx 100 km, but just above the Canadian border, on 849 the 50th degree, it is 0.993*(pi/180)*M*cos(50) = 70.92km. Thus, 850 the grid distortion is 100/70.92 = 1.41, which is acceptable 851 (<1.5). (On north-south direction the grid has roughly no 852 distortion, the vertical distance between two neighboring grid 853 points is approximately 100 km). 855 Step 3: 857 Now suppose you measure a position at M, with longitude -105 (the 858 minus sign is used to denote 105 degrees *west*; without minus, 859 the point is in China, 105 degrees east) and latitude 40 degrees 860 (just north of Denver, CO). The point M is 105 degrees west and 861 15 degrees north of our origin (which has longitude 0 and latitude 862 25). 864 Let "floor" be the function that returns the largest integer 865 smaller or equal to a floating point number. To calculate SW, the 866 closest point of the grid on the south-west of M=(m,n), we 867 calculate 869 i= floor(m/d1) = floor(-105/0.993) = -106 871 j= floor(n-o/d2) = floor(15/0.904) = 16 873 Those are the indexes of SW on the grid. The coordinates of SW 874 are then: (d1*i, 25+d2*j) = (-105.242, 39.467). 876 Thus: 878 l=d1*floor(m/d1) = -105.243 880 r=l+d1 = -105.243+0.993 = -104.250 882 b=o+d2*floor(n-o/d2) = 39.467 884 t=b+d2 = 39.467+0.904 = 40.371 886 These are the formulas for l,r,b, and t in the general case of 887 Cartesian projections based on latitude and longitude. 889 Step 4: 891 Calculate x and y, the local coordinates of the point M in the 892 small grid square that contains it. This is easy: 894 x=(m-l)/(r-l) = [-105 -(-105.243)]/0.993 = 0.245 896 y=(n-b)/(t-b) = [40 - 39.467]/0.904 = 0.590 898 Step 5: 900 First compare x with p (0.2887) and (0.7113). x is smaller than p. 901 Therefore, only cases 1,4 or 6 could hold. 903 Also compare y with p (0.2887) and (0.7113). y is between them: p 904 <= y < q. Thus, we must be in case 4. To check, compare y (0.59) 905 with x (0.245) and 1-x. y is larger than x and smaller than 1-x. 907 We are in case C4 (p <= y < q and x <= y and y < 1-x). 909 Step 6: 911 Now we choose either SW or NW as the center of the circle. 913 The obscured location is the Circle with radius 100 km and center 914 in SW (coordinates: -105.243, 39.467), or NW (coordinates: 915 -105.243, 40.371). 917 8. XML Schema for Basic Location Profiles 919 This section defines the location profiles used as child elements of 920 the transformation element. 922 923 929 931 932 933 934 935 936 937 938 939 940 941 942 944 946 947 948 949 950 952 954 9. XML Schema for Geolocation Policy 956 This section presents the XML schema that defines the Geolocation 957 Policy schema described in this document. The Geolocation Policy 958 schema extends the Common Policy schema (see [RFC4745]). 960 961 968 969 971 972 975 977 980 981 982 983 984 986 988 989 990 991 993 994 995 996 997 999 1000 1001 1002 1003 1004 1005 1007 1008 1010 1012 1014 1017 1020 1021 1022 1023 1024 1025 1026 1028 1029 1030 1031 1032 1034 1035 1036 1037 1038 1040 1042 10. XCAP Usage 1044 The following section defines the details necessary for clients to 1045 manipulate geolocation privacy documents from a server using XCAP. 1046 If used as part of a presence system, it uses the same AUID as those 1047 rules. See [RFC5025] for a description of the XCAP usage in context 1048 with presence authorization rules. 1050 10.1. Application Unique ID 1052 XCAP requires application usages to define a unique application usage 1053 ID (AUID) in either the IETF tree or a vendor tree. This 1054 specification defines the "geolocation-policy" AUID within the IETF 1055 tree, via the IANA registration in Section 11. 1057 10.2. XML Schema 1059 XCAP requires application usages to define a schema for their 1060 documents. The schema for geolocation authorization documents is 1061 described in Section 9. 1063 10.3. Default Namespace 1065 XCAP requires application usages to define the default namespace for 1066 their documents. The default namespace is 1067 urn:ietf:params:xml:ns:geolocation-policy. 1069 10.4. MIME Type 1071 XCAP requires application usages to defined the MIME type for 1072 documents they carry. Geolocation privacy authorization documents 1073 inherit the MIME type of common policy documents, application/ 1074 auth-policy+xml. 1076 10.5. Validation Constraints 1078 This specification does not define additional constraints. 1080 10.6. Data Semantics 1082 This document discusses the semantics of a geolocation privacy 1083 authorization. 1085 10.7. Naming Conventions 1087 When a Location Server receives a request to access location 1088 information of some user foo, it will look for all documents within 1089 http://[xcaproot]/geolocation-policy/users/foo, and use all documents 1090 found beneath that point to guide authorization policy. 1092 10.8. Resource Interdependencies 1094 This application usage does not define additional resource 1095 interdependencies. 1097 10.9. Authorization Policies 1099 This application usage does not modify the default XCAP authorization 1100 policy, which is that only a user can read, write or modify his/her 1101 own documents. A server can allow privileged users to modify 1102 documents that they do not own, but the establishment and indication 1103 of such policies is outside the scope of this document. 1105 11. IANA Considerations 1107 There are several IANA considerations associated with this 1108 specification. 1110 11.1. Geolocation Policy XML Schema Registration 1112 URI: urn:ietf:params:xml:schema:geolocation-policy 1114 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 1115 (hannes.tschofenig@nsn.com). 1117 XML: The XML schema to be registered is contained in Section 9. Its 1118 first line is 1120 1122 and its last line is 1124 1126 11.2. Geolocation Policy Namespace Registration 1128 URI: urn:ietf:params:xml:ns:geolocation-policy 1130 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 1131 (hannes.tschofenig@nsn.com). 1133 XML: 1135 BEGIN 1136 1137 1139 1140 1141 1143 Geolocation Policy Namespace 1144 1145 1146

Namespace for Geolocation Authorization Policies

1147

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

1148

See RFCXXXX 1149 [NOTE TO IANA/RFC-EDITOR: 1150 Please replace XXXX with the RFC number of this 1151 specification.].

1152 1153 1154 END 1156 11.3. Geolocation Policy Location Profile Registry 1158 This document seeks to create a registry of location profile names 1159 for the Geolocation Policy framework. Profile names are XML tokens. 1160 This registry will operate in accordance with RFC 2434 [RFC2434], 1161 Standards Action. 1163 This document defines the following profile names: 1165 geodetic-condition: Defined in Section 4.1. 1167 civic-condition: Defined in Section 4.2. 1169 geodetic-transformation: Defined in Section 6.5.2. 1171 civic-transformation: Defined in Section 6.5.1. 1173 11.4. Basic Location Profile XML Schema Registration 1175 URI: urn:ietf:params:xml:schema:basic-location-profiles 1177 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 1178 (hannes.tschofenig@nsn.com). 1180 XML: The XML schema to be registered is contained in Section 8. Its 1181 first line is 1183 1185 and its last line is 1187 1189 11.5. Basic Location Profile Namespace Registration 1191 URI: urn:ietf:params:xml:ns:basic-location-profiles 1193 Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig 1194 (hannes.tschofenig@nsn.com). 1196 XML: 1198 BEGIN 1199 1200 1202 1203 1204 1206 Basic Location Profile Namespace 1207 1208 1209

Namespace for Basic Location Profile

1210

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

1211

See RFCXXXX 1212 [NOTE TO IANA/RFC-EDITOR: 1213 Please replace XXXX with the RFC number of this 1214 specification.].

1215 1216 1217 END 1219 11.6. XCAP Application Usage ID 1221 This section registers an XCAP Application Usage ID (AUID) according 1222 to the IANA procedures defined in [RFC4825]. 1224 Name of the AUID: geolocation-policy 1226 Description: Geolocation privacy rules are documents that describe 1227 the permissions that a Target has granted to Location Recipients that 1228 access information about his/her geographic location. 1230 12. Internationalization Considerations 1232 The policies described in this document are mostly meant for machine- 1233 to-machine communications; as such, many of its elements are tokens 1234 not meant for direct human consumption. If these tokens are 1235 presented to the end user, some localization may need to occur. The 1236 policies are, however, supposed to be created with the help of humans 1237 and some of the elements and attributes are subject to 1238 internationalization considerations. The content of the