idnits 2.17.1 draft-ietf-geopriv-reqs-04.txt: -(233): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(712): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 531 has weird spacing: '...traints on th...' -- 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 (Oct 2003) is 7496 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. 'Bra00' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cha85' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO99' -- Possible downref: Non-RFC (?) normative reference: ref. 'OECD' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pfi01' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Jorge Cuellar 3 Document: draft-ietf-geopriv-reqs-04.txt Siemens AG 5 John B. Morris, Jr. 6 Center for Democracy and Technology 8 Deirdre Mulligan 9 Samuelson Law, Technology, and Public Privacy Clinic 11 Jon Peterson 12 NeuStar 14 James Polk 15 Cisco 17 Expires in six months Oct 2003 19 Geopriv requirements 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 43 Copyright (C) The Internet Society (2001). All Rights Reserved. 45 Abstract 47 Location-based services, navigation applications, emergency 48 services, management of equipment in the field, and other location- 49 dependent services need geographic location information about a 51 Cuellar, Morris, Mulligan, Peterson, Polk 1 52 Target (such as a user, resource or other entity). There is a need 53 to securely gather and transfer location information for location 54 services, while at the same time protecting the privacy of the 55 individuals involved. 57 This document focuses on the authorization, security and privacy 58 requirements for such location-dependent services. Specifically, it 59 describes the requirements for the Geopriv Location Object (LO) and 60 for the protocols that use this Location Object. This LO is 61 envisioned to be the main object defined by the Geopriv WG, used in 62 all Geopriv exchanges and in particular used to securely transfer 63 location data. 65 Table of Contents 67 1. Overview.......................................................3 68 2. Conventions used in this document..............................4 69 3. Glossary.......................................................4 70 4. Primary Geopriv Entities.......................................6 71 5. Further Geopriv Terminology....................................7 72 5.1. Location Information and Sighting.........................7 73 5.2. The Location Object and Using Protocol....................8 74 5.3. Trusted vs. Non-trusted Data Flows........................9 75 5.4. Further Geopriv Principals...............................10 76 5.5. Privacy Rules............................................12 77 5.6. Identifiers, Authentication and Authorization............12 78 6. Scenarios and Explanatory Discussion..........................13 79 7. Requirements..................................................17 80 7.1. Location Object..........................................17 81 7.2. The Using Protocol.......................................19 82 7.3. Rule based Location Data Transfer........................20 83 7.4. Location Object Privacy and Security.....................21 84 7.4.1. Identity Protection.................................21 85 7.4.2. Authentication Requirements.........................21 86 7.4.3. Actions to be secured...............................21 87 7.5. Non-Requirements.........................................22 88 8. Security Considerations.......................................22 89 8.1. Traffic Analysis.........................................22 90 8.2. Securing the Privacy Rules...............................22 91 8.3. Emergency Case...........................................23 92 8.4. Identities and Anonymity.................................23 93 8.5. Unintended Target........................................24 94 9. Protocol and LO Issues for later Consideration................24 95 9.1. Multiple Locations in one LO.............................24 96 9.2. Translation Fields.......................................24 97 9.3. Truth Flag...............................................25 98 9.4. Timing Information Format................................25 100 Cuellar, Morris, Mulligan, Peterson, Polk 2 101 9.5. The Name Space of Identifiers............................25 102 10. Acknowledgements.............................................25 103 11. References...................................................25 104 12. Author's Addresses...........................................26 105 13. Full Copyright Statement.....................................27 107 1. Overview 109 Location-based services (applications that require geographic 110 location information as input) are becoming increasingly common. 111 The collection and transfer of location information about a 112 particular Target can have important privacy implications. A key 113 goal of the protocol described in this document is to facilitate the 114 protection of privacy pursuant to Privacy Rules set by the 115 "user/owner of the Target" (or, more precisely in the terminology of 116 this document given in Section 3 and 5.4 below, the "Rule Maker"). 118 The ability to gather and generate a Target's location, and access 119 to the derived or computed location, are key elements of the 120 location-based services privacy equation. Central to a Target's 121 privacy are (a) the identity of entities that have access to raw 122 location data, derive or compute location, and/or have access to 123 derived or computed location information, and (b) whether those 124 entities can be trusted to know and follow the Privacy Rules of the 125 user. 127 The main principles guiding the requirements described in this 128 document are: 130 1) Security of the transmission of Location Object is essential to 131 guarantee the integrity and confidentiality of the location 132 information. This includes authenticating the sender and 133 receiver of the Location Object, and securing the Location Object 134 itself. 136 2) A critical role is played by user-controlled Privacy Rules, which 137 describe the restrictions imposed or permissions given by the 138 "user" (or, as defined below, the "Rule Maker"). The Privacy 139 Rules specify the necessary conditions that allow a Location 140 Server to forward Location Information to a Location Recipient, 141 and the conditions under which and purposes for which the 142 Location Information can be used. 144 3) One type of Privacy Rules specify in particular how location 145 information should be filtered, depending on who the recipient 146 is. Filtering is the process of reducing the precision or 147 resolution of the data. A typical rule may be of the form: "my 148 location can only be disclosed to the owner of such credentials 149 in such precision or resolution" (e.g., "my co-workers can be 150 told the city I am currently in"). 152 Cuellar, Morris, Mulligan, Peterson, Polk 3 153 4) The Location Object should be able to carry a limited but core 154 set of Privacy Rules. The exact form or expressiveness of those 155 Rules in the core set or in the full set is not further discussed 156 in this document, but will be discussed more extensively in 157 future documents produced by this working group. 159 5) Whenever appropriate, the location information should not be 160 linked to the real identity of the user or a static identifier 161 easily linked back to the real identity of the user (i.e., 162 Personally Identifiable Information such as a name, mailing 163 address, phone number, social security number, or email address 164 or username). Rather, the user should be able to specify which 165 local identifier, unlinked pseudonym, or private identifier is to 166 be bound to the location information. 168 6) The user may want to hide the real identities of himself and his 169 partners not only to eavesdroppers but also to other entities 170 participating in the protocol. 172 Although complete anonymity may not be appropriate for some 173 applications because of legal constraints or because some location 174 services may in fact need explicit identifications, in most cases 175 the location services only need some type of authorization 176 information and/or perhaps anonymous identifiers of the entities in 177 question. 179 2. Conventions used in this document 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 183 this document are to be interpreted as described in [RFC2119]. 185 Note that the requirements discussed here are requirements on the 186 generic Location Object and on the using protocols for location 187 services. Thus, for the most part, the requirements discussed in 188 this document refer to capabilities that are mandatory-to-implement. 189 For example, requiring that implementations support integrity is not 190 the same thing as requiring that all protocol traffic be 191 authenticated. In contrast, an example of a mandatory-to-use (not 192 just mandatory-to-implement) requirement might be one that states 193 that the user always receives a notice when his location data was 194 not authenticated. This practice is mandatory-to-use, not just to 195 implement. 197 3. Glossary 199 For easy reference and readability, below are basic terms that will 200 be defined more formally and fully later in this document. 202 Location Generator (LG): The entity that initially determines or 203 gathers the location of the Target and creates Location 204 Objects describing the location of the Target. 206 Cuellar, Morris, Mulligan, Peterson, Polk 4 207 Location Object (LO): An object conveying location information 208 (and possibly privacy rules) to which Geopriv security 209 mechanisms and privacy rules are to be applied. 211 Location Recipient (LR): The entity that receives location 212 information. It may have asked for this location explicitly 213 (by sending a query to a location server), or it may receive 214 this location asynchronously. 216 Location Server (LS): The entity to which a LG publishes location 217 objects, the recipient of queries from location receivers, and 218 the entity that applies rules designed by the rule maker. 220 Precision: The number of significant digits to which a value has 221 been reliably measured. 223 Principal: The holder/subject of the credentials, e.g. a 224 workstation user or a network server. 226 Resolution: The fineness of detail that can be distinguished in 227 measured area. Applied to Geopriv this means the fineness of 228 area within provided, and closed, borders (ex. Latitude and 229 Longitude boundaries). 231 Rule Holder: The entity that provides the rules associated with a 232 particular target for the distribution of location 233 information. It may either �push� rules to a location server, 234 or a location server may �pull� rules from the Rule Holder. 236 Rule Maker: The authority that creates rules governing access to 237 location information for a target (typically, this it the 238 target themselves). 240 Rule, or Privacy Rule: A directive that regulates an entity's 241 activities with respect to location information, including the 242 collection, use, disclosure, and retention of location 243 information. 245 Target: A person or other entity whose location is communicated 246 by a Geopriv Location Object. 248 Using Protocol: A protocol that carries a Location Object. 250 Viewer: A Principal that consumes location information that is 251 communicated by a Geopriv Location Object, but does not pass 252 this information further. 254 Resolution and Precision are very close terms. Either quality can 255 be 'reduced' to coarsen location information: 'resolution' by 256 defining a off-center perimeter around a user's location or 258 Cuellar, Morris, Mulligan, Peterson, Polk 5 259 otherwise enlarging the area in consideration (from state to 260 country, say) and 'precision' by discarding significant digits of 261 positioning information (rounding off longitude and latitude from 262 seconds to minutes, say). Another WG document treats this topic in 263 much more detail. 265 4. Primary Geopriv Entities 267 The following picture shows the primary Geopriv entities in a simple 268 and basic architecture, without claim of completeness nor any 269 suggestion that the entities identified must in all cases be 270 physically separate entities. 272 +----------+ 273 | Rule | 274 | Holder | 275 | | 276 +----+-----+ 277 | 278 rule|interface 279 V 280 +----------+ +----------+ +----------+ 281 |Location | publication | Location | notification |Location | 282 |Generator +-------------->| Server +-------------->|Recipient | 283 | | interface | | interface | | 284 +----------+ +----------+ +----------+ 286 The four primary Entities are described as follows: 288 Location Generator (LG): The entity that initially determines or 289 gathers the location of the Target and creates Location 290 Objects describing that location. LGs publish Location 291 Objects to Location Servers. The manner in which the Location 292 Generator learns of Location Information is outside the scope 293 of the Geopriv Protocol.. 295 Location Server (LS): The LS is an element that receives 296 publications of Location Objects from Location Generators and 297 may receive subscriptions from Location Recipients. The LS 298 applies the rules (which it learns from the Rule Holder) to 299 LOs it receives from LGs, and then notifies LRs of resulting 300 LOs as necessary. 302 Location Recipient (LR): The LR is an element that receives 303 notifications of Location Objects from Location Servers. The 304 LR may render these LOs to a user or automaton in some 305 fashion. 307 Cuellar, Morris, Mulligan, Peterson, Polk 6 308 Rule Holder (RH): The RH is an element that houses Privacy Rules 309 for receiving, filtering and distributing Location Objects for 310 specific Targets. A LS may query an RH for a set of rules, or 311 rules may be pushed from the RH to an LS. The rules in the 312 Rule Holder are populated by the Rule Maker. 314 Thus Location Generation is the process of gathering Location 315 Information, perhaps from multiple sources, at an IP-based Geopriv 316 Entity, the LG, which communicates with other Geopriv Entities. 318 Rules MUST be authenticated and protected. How this is done and in 319 particular how to distribute the keys to the RM and other 320 authorities is outside of the scope of this document. See also 321 Section 8.2 "Securing the Privacy Rules". 323 The interfaces between the Geopriv entities are not necessarily 324 protocol interfaces; they could be internal interfaces within a 325 single composed device. In some architectures, the Location 326 Generator, Rule Holder, and Location Server might all be implemented 327 in the same device. There may be several Rule Holders that enforce 328 the Privacy Rules at a particular Location Server. 330 5. Further Geopriv Terminology 332 The terminology and definitions detailed below include both terms 333 that, besides the primary Geopriv entities, (1) are used in the 334 requirements section of this document, and (2) provide additional 335 detail about the usage model envisioned for the Geopriv Location 336 Object. These latter terms will be utilized in a separate scenarios 337 document and elsewhere. 339 5.1. Location Information and Sighting 341 The focus of the Geopriv working group is on information about a 342 Target's location that is NOT based on generally or publicly 343 available sources, but instead on private information provided or 344 created by a Target, a Target's Device, or a Target's network or 345 service provider. Notwithstanding this focus on private location 346 information, the Geopriv Location Object could certainly be used to 347 convey location information from publicly available sources. 349 Location Information: A relatively specific way of describing 350 where a Device is located. 352 This Location Information may have determined in many different 353 ways, including: 354 (a) derived or computed from information generally not available to 355 the general public (such as information mainly available to a 356 network or service provider), (b) determined by a Device that may be 357 not generally publicly addressable or accessible, or (c) input or 358 otherwise provided by a Target. 360 Cuellar, Morris, Mulligan, Peterson, Polk 7 361 As examples, the Location Information could include (a) information 362 calculated by triangulating on a wireless signal with respect to 363 cell phone towers, (b) longitude and latitude information determined 364 by a Device with GPS (global positioning satellite) capabilities, 365 (c) information manually entered into a cell phone or laptop by a 366 Target in response to a query, or (d) automatically delivered by 367 some other IP protocol, such as at device configuration via DHCP. 369 Excluded from this definition is the determination of location 370 information wholly without the knowledge or consent of the Target 371 (or the Target's network or access service provider), based on 372 generally available information such as an IP or e-mail address. In 373 some cases information like IP address can enable someone to 374 estimate (at least roughly) a location. Commercial services exist 375 that offer to provide rough location information based on IP 376 address. Currently, this type of location information is typically 377 less precise than the type of location information addressed in this 378 document. Although this type of location computation still raises 379 significant potential privacy and public privacy concerns, such 380 scenarios are generally outside the scope of this document. 382 Within any given location-based transaction, the INITIAL 383 determination of location (and thus the initial creation of Location 384 Information) is termed a Sighting: 386 Sighting: 387 The initial determination of location based on non-public 388 information (as discussed in the definition of Location 389 Information), and the initial creation of Location 390 Information. 392 Some variant of the sighting information is included in the Location 393 Object. Abstractly, it consists of two separate data fields: 395 (Identifier, Location) 397 where Identifier is the identifier assigned to a Target being 398 sighted, and Location is the current position of that Target being 399 sighted. Not all entities may have access to exactly the same piece 400 of sighting information. A sighting may be transformed to a new 401 sighting pair: 403 (Identifier-1, Location-1) 405 before it is provided by a Location Generator or Location Server to 406 Location Recipient. In this case, Identifier-1 may be Pseudonym, 407 and Location-1 may have less precision or resolution than the 408 original value. 410 5.2. The Location Object and Using Protocol 412 Cuellar, Morris, Mulligan, Peterson, Polk 8 413 A main goal of the Geopriv working group is to define a Location 414 Object (LO), to be used to convey both Location Information and 415 basic privacy-protecting instructions: 417 Location Object (LO): This data contains the Location Information 418 of the Target, and other fields including an identity or 419 pseudonym of the Target, time information, core Privacy Rules, 420 authenticators, etc. Most of the fields are optional, 421 including the Location Information itself. 423 Nothing is said about the semantics of a missing field. For 424 instance, a partially filled object MAY be understood implicitly as 425 the request to complete it. Or, if no time information is included, 426 this MAY implicitly mean "at the current time" or "at a very recent 427 time", but it could be interpreted in a different way, depending on 428 the context. 430 The "using protocol" is the protocol that uses (reads or modifies) 431 the Location Object. A protocol that just transports the LO as a 432 string of bits, without looking at them (like an IP storage protocol 433 could do), is not a using protocol, but only a transport protocol. 434 Nevertheless, the entity or protocol that caused the transport 435 protocol to move the LO is responsible for the appropriate 436 distribution, protection, usage, retention, and storage of the LO 437 based on the rules that apply to that LO. 439 The security and privacy enhancing mechanisms used to protect the LO 440 are of two types: First, the Location Object definition MUST 441 include the fields or mechanisms used to secure the LO as such. The 442 LO MAY be secured, for example, using cryptographic checksums or 443 encryption as part of the LO itself. Second, the using protocol may 444 also provide security mechanisms to securely transport the Location 445 Object. 447 When defining the LO, the design should observe that the security 448 mechanisms of the Location Object itself are to be preferred. Thus 449 the definition of the LO MUST include some minimal crypto 450 functionality (Req. 14 and 15). Moreover, if the RM specifies the 451 use of a particular LO security mechanism, it MUST be used (Req. 4). 453 5.3. Trusted vs. Non-trusted Data Flows 455 Location information can be used in very different environments. In 456 some cases the participants will have longstanding relationships, 457 while in others the participants may have discrete interactions with 458 no prior contractual or other contact. 460 The different relationships raise different concerns for the 461 implementation of privacy rules, including the need to communicate 462 Privacy Rules. A public Rule Holder, for example, may be 463 unnecessary in a trusted environment where more efficient methods of 465 Cuellar, Morris, Mulligan, Peterson, Polk 9 466 addressing privacy issues exist. The following terms distinguish 467 between the two basic types of data flows: 469 Trusted Data Flow: 470 A data flow that is governed by a pre-existing contractual 471 relationship that addresses location privacy. 473 Non-trusted Data Flow: 474 The data flow is not governed by a pre-existing contractual 475 relationship that addresses location privacy. 477 5.4. Further Geopriv Principals 479 Target: 480 The entity whose location is desired by the Location 481 Recipient. In many cases the Target will be the human "user" 482 of a Device or an object such as a vehicle or shipping 483 container to which the Device is attached. In some instances 484 the Target will be the Device itself. 486 Device: 487 The technical device the location of which is tracked as a 488 proxy for the location of a Target. 490 A Device might, for example, be a cell phone, a Global Positioning 491 Satellite (GPS) receiver, a laptop equipped with a wireless access 492 Device, or a transmitter that emits a signal that can be tracked or 493 located. In some situations, such as when a Target manually inputs 494 location information (perhaps with a web browser), the Target is 495 effectively performing the function of a Device. 497 Rule Maker (RM): 498 The individual or entity that has the authorization to set the 499 applicable Privacy Rules for a potential Geopriv Target. In 500 many cases this will be the owner of the Device, and in other 501 cases this may be the user who is in possession of the Device. 502 For example, parents may control what happens to the location 503 information derived from a child's cell phone. A company, in 504 contrast, may own and provide a cell phone to an employee but 505 permit the employee to set the privacy rules. 507 There are four scenarios in which some form of constraint or 508 override might be placed on the Privacy Rules of the Rule 509 Maker: 511 1. In the case of emergency services (such as E911 within the 512 United States), local or national laws may require that 513 accurate location information be transmitted in certain 514 defined emergency call situations. The Geopriv Working Group 515 MUST facilitate this situation. 517 Cuellar, Morris, Mulligan, Peterson, Polk 10 518 2. In the case of legal interception, the RM may not be aware 519 of an override directive imposed by a legal authority. It is 520 not the expectation of the Working Group that particular 521 accommodation will be made to facilitate this situation. 523 3. In the context of an employment relationship or other 524 contractual relationship, the owner of a particular location 525 (such as a corporate campus) may impose constraints on the use 526 of Privacy Rules by a Rule Maker. It is not the expectation 527 of the Working Group that particular accommodation will be 528 made to facilitate this situation. 530 4. It is conceivable that a governmental authority may seek to 531 impose constraints on the use of Privacy Rules by a Rule 532 Maker in non-emergency situations. It is not the expectation 533 of the Working Group that particular accommodation will be 534 made to facilitate this situation. 536 Viewer: 537 An individual or entity who receives location data about a 538 Target and does not transmit the location information or 539 information based on the Target's location (such as driving 540 directions to or from the Target) to any party OTHER than the 541 Target or the Rule Maker. 543 Data Transporter: 544 An entity or network that receives and forwards data without 545 processing or altering it. A Data Transporter could 546 theoretically be involved in almost any transmission between a 547 Device and a Location Server, a Location Server and a second 548 Location Server, or a Location Server and an Viewer. Some 549 location tracking scenarios may not involve a Data 550 Transporter. 552 Access Provider (AP): 553 The domain that provides the initial network access or other 554 data communications services essential for the operation of 555 communications functions of the Device or computer equipment 556 in which the Device operates. Often, the AP -- which will be 557 a wireless carrier, an Internet Service Provider, or an 558 internal corporate network -- contains the LG. Sometimes the 559 AP has a "dumb" LG, one that transmits Geopriv LOs but does 560 not use any part of the Geopriv Location Object. Other cases 561 may not involve any AP, or the AP may only act as a Data 562 Transporter. 564 Location Storage: 565 A Device or entity that stores raw or processed Location 566 Information, such as a database, for any period of time longer 567 than the duration necessary to complete an immediate 568 transaction regarding the Location Information. 570 Cuellar, Morris, Mulligan, Peterson, Polk 11 571 The existence and data storage practices of Location Storage is 572 crucial to privacy considerations, because this may influence what 573 Location Information could eventually be revealed (through later 574 distribution, technical breach, or legal processes). 576 5.5. Privacy Rules 578 Privacy Rules are rules that regulate an entity's activities with 579 respect to location and other information, including, but not 580 limited to, the collection, use, disclosure, and retention of 581 location information. Such rules are generally based on fair 582 information practices, as detailed in (for example) the OECD 583 Guidelines on the Protection of Privacy and Transporter Flows of 584 Personal Data [OECD]. 586 Privacy Rule: 587 A rule or set of rules that regulate an entity's activities 588 with respect to location information, including the 589 collection, use, disclosure, and retention of location 590 information. In particular, the Rule describes how location 591 information may be used by an entity and which transformed 592 location information may be released to which entities under 593 which conditions. Rules must be obeyed; they are not 594 advisory. 596 A full set of Privacy Rules will likely include both rules that have 597 only one possible technical meaning, and rules that will be affected 598 by a locality's prevailing laws and customs. For example, a 599 distribution rule of the form "my location can only be disclosed to 600 the owner of such credentials and in such precision or resolution" 601 has clear-cut implications for the protocol that uses the LO. But 602 other rules, like retention or usage Rules, may have unclear 603 technical consequences for the protocol or for the involved 604 entities. For example, the precise scope of a retention rule 605 stating "you may not store my location for more than 2 days" may in 606 part turn on local laws or customs. 608 5.6. Identifiers, Authentication and Authorization 610 Anonymity is the property of being not identifiable (within a set of 611 subjects). Anonymity serves as the base case for privacy: without 612 the ability to remain anonymous, individuals may be unable to 613 control their own privacy. Unlinkability ensures that a user may 614 make multiple uses of resources or services without others being 615 able to link these uses to each other. Unlinkability requires that 616 entities are unable to determine whether the same user caused 617 certain specific operations in the system. [ISO99] A pseudonym is 618 simply a bit string which is unique as ID and is suitable to be used 619 for end-point authentication. 621 Cuellar, Morris, Mulligan, Peterson, Polk 12 622 Unlinked Pseudonym: 623 A pseudonym where the linking between the pseudonym and its 624 holder is, at least initially, not known to anybody with the 625 possible exception of the holder himself or a trusted server 626 of the user. See [Pfi01] (there the term is called Initially 627 Unlinked Pseudonym) 629 The word authentication is used in different meanings. Some require 630 that authentication associates an entity with a more or less well- 631 known identity. This basically means that if A authenticates 632 another entity B as being "id-B", then the label "id-B" is a well- 633 known, or at least a linkable identity of the entity. In this case, 634 the label "id-B" is called a publicly known identifier, and the 635 authentication is "explicit": 637 Explicit Authentication: 638 The act of verifying a claimed identity as the sole originator 639 of a message (message authentication) or as the end-point of a 640 channel (entity authentication). Moreover, this identity is 641 easily linked back to the real identity of the entity in 642 question, for instance being a pre-existing static label from 643 a predefined name space (telephone number, name, etc.). 645 Authorization: 646 The act of determining if a particular right, such as access 647 to some resource, can be granted to the presenter of a 648 particular credential. 650 Depending on the type of credential, authorization may imply 651 Explicit Authentication or not. 653 6. Scenarios and Explanatory Discussion 655 In this subsection we introduce short scenarios to illustrate how 656 these terms and attributes describe location information 657 transactions. Additional illustrative scenarios are discussed in a 658 separate Document. 660 SCENARIO 1: GPS Device with Internal Computing Power: Closed System 662 In this example, the Target wishes to know his/her location using 663 Global Positioning System (GPS) and the Device is capable of 664 independently processing the raw data to determine its location. 665 The location is derived as follows: the Device receives 666 transmissions from the GPS satellites, internally computes and 667 displays location. This is a closed system. For the purpose of this 668 and subsequent examples, it is assumed that the GPS satellite 669 broadcasts some signal, and has no information about the identity or 670 whereabouts of Devices using the signal. 672 Cuellar, Morris, Mulligan, Peterson, Polk 13 673 GPS Satellite 674 | 675 | Sighting (not a Geopriv Interface) 676 | 677 | 678 | 679 V GPS Device 680 -------------------------------------------------- 681 / \ 682 | Location ----- Location ----- Location | 683 | Generator Server Storage | 684 \ | / 685 -------------------------------------------|------ 686 | 687 | Notification 688 | Interface 689 | 690 ------------|------ 691 / V \ 692 / Target Location \ 693 | Recipient | 694 | | 695 \ Rule Maker / 696 \ / 697 ------------------- 699 In this scenario the GPS Device is both the AP and the LG. The 700 interaction occurs in a Trusted environment because it occurs in the 701 Rule Maker�s Device. 703 SCENARIO 2: Cell Phone Roaming 705 In this example, a cell phone is used outside its home service area 706 (roaming). Also, the cell phone service provider (cell phone Corp 2) 707 outsourced the accounting of cell phone usage. The cell phone is not 708 GPS-enabled. Location is derived by the cell phone network in which 709 the Target and Device are roaming. When the Target wishes to use 710 the cell phone, cell phone Corp 1 (AP) provides the roaming service 711 for the Target, which sends the raw data about usage (e.g., duration 712 of call, location � roaming network, etc.) to cell phone Corp 2, the 713 home service provider. Cell phone Corp 2 submits the raw data to 714 the accounting company, which processes the raw data for the 715 accounting statements. Finally, the raw data is sent to a data 716 warehouse where the raw data is stored in a Location Server (e.g., 717 computer server). 719 Cuellar, Morris, Mulligan, Peterson, Polk 14 720 Cell Phone Corp 1 Cell Phone Corp 2 721 ----------------- ----------------- 722 Sighting / \ Publish / \ 723 Device ----- | Data Transporter | --------- | Data Transporter | 724 Target \ / Interface \ / 725 ----------------- / ----------------- 726 / | 727 / | Notification 728 / | Interface 729 ----------- | 730 / V 731 ------------ / ---------- 732 / \ / / \ 733 / Location \ / | Location | 734 | Storage | Location Info | Storage | 735 | |<----------------- | | 736 | Location | | Location | 737 | Recipient | | Recipient | 738 \ / \ / 739 ------------- ---------- 741 Here cell phone Corp 1 is the AP and the LG. In this scenario, Cell 742 phone Corp 2 is likely to be a Trusted entity, but cell phone Corp 743 1 may be Non-trusted. 745 SCENARIO 3: Mobile Communities and Location-Based Services 747 The figure below shows a common scenario, where a user wants to find 748 his friends or colleagues or wants to share his position with them 749 or with a Location-Based Service Provider. Some of the messages use 750 a Location Object to carry, for instance, identities or pseudonyms, 751 credentials and proof-of-possession of them, Rules and Location Data 752 Information, including Data Types and Precision or Resolution. 753 Messages that do not use the Location Object and are outside of the 754 scope of the Geopriv WG, but should be mentioned for 755 understandability, are shown in the figure as starred arrows 756 ("***>"). 758 Cuellar, Morris, Mulligan, Peterson, Polk 15 759 +---------+ +------------+ 760 | | | | 761 | Location|<** | Public | 762 |Generator| * | Rule Holder| 763 | | * | | 764 +---------+\ * +------------+ 765 \ *3 1a* * 766 \ * * * 767 \ ** * 768 \ * * *1a 769 \* * * 770 * \ * * 771 * \ * * 772 * \4 * * 773 * \ * V 774 * \->+-----------+ 775 +----------+ 1 | Location | 776 | Rule |--------------------->| Server + | 777 | Maker | | Private | 778 +----------+ |Rule Holder| 779 +-----------+ 780 ^ | 781 3| |5 782 | V 783 +----------+ 784 | Location | 785 | Recipient| 786 +----------+ 788 Assume that the Rule Maker and the Target are registered with the 789 Location Server. The RM has somehow proven to the LS that he indeed 790 is the owner of the privacy rights of the Target (the Target is 791 usually a Device owned by the Rule Maker). The Rule Maker and the 792 Location Server have agreed on the set of keys or credentials and 793 cryptographic material that they will use to authenticate each 794 other, and in particular, to authenticate or sign the Rules. How 795 this has been done is outside of the scope of the document. 797 1: Rule Transfer: 798 The Rule Maker sends a Rule to the Location Server. This Rule 799 may be a field in a Location Object or not. 801 1a:Signed Rule: 802 As an alternative, the Rule Maker may write a Rule and place 803 it in a Public Rule Holder. The entities access the 804 repository to read the signed Rules. 806 2: Location Information Request: 807 The Location Recipient requests location information for a 809 Cuellar, Morris, Mulligan, Peterson, Polk 16 810 Target. In this request, the Location Recipient may select 811 which location information data type it prefers. One way of 812 requesting Location Information MAY be sending a partially 813 filled Location Object, including only the identities of the 814 Target and Location Recipient and the desired Data Type and 815 precision or resolution, and providing proof of possession of 816 the required credentials. But whether the using protocol 817 understands this partially filled object as a request, this 818 MAY depend on the using protocol or on the context. The 819 Location Recipient could also specify the need for periodic 820 location information updates, but this is probably out of the 821 scope of Geopriv. 823 3: Locate: 824 When a Location Server receives an Location Information 825 Request for a Target for which has no current location 826 information, the server may send ask the Location Generator to 827 locate the Target. 829 4: Location Information: 830 The Location Generator sends the "full" location information 831 to the Location Server. This Location Information may be 832 embedded in a Location Object or not. 834 5: Filtered Location Information: 835 Then the Location Server sends the location information to the 836 Location Recipient. The information may be filtered in the 837 sense that in general a less precise or a computed version of 838 the information is being delivered. 840 7. Requirements 842 7.1. Location Object 844 Recall that this document is primarily specifying requirements on 845 how the definition of the LO. Some Requirements read like this: 846 "The LO definition MUST contain Field 'A' as an optional field." 847 This requirement just states that 849 o the document that defines the LO MUST define the LO field 'A', 850 o the field 'A' MUST be defined as optional to use (an instance of a 851 LO MAY contain the field 'A' or not). 853 Some Requirements read like this: "The LO definition MUST contain 854 Field 'A', which MAY be an optional field." This requirement states 855 that 857 o the document that defines the LO MUST define the LO field 'A', 858 o the field 'A' MAY be defined as optional or not to use. If it is 859 defined as optional to use, any instance of a LO MAY contain the 860 field 'A' or not; if it is not optional, all instances of LOs MUST 861 contain the field 'A'. 863 Cuellar, Morris, Mulligan, Peterson, Polk 17 864 Req. 1. (Location Object generalities) 866 1.1) Geopriv MUST define one Location Object (LO) -- both in 867 syntax and semantics -- that must be supported by all Geopriv 868 entities. 870 1.2) Some fields of the Location Object MAY be optional. This 871 means that an instance of a Location Object MAY contain the 872 fields or not. 874 1.3) Some fields of the Location Object MAY be defined as 875 "extensions". This means that the syntax or semantics of these 876 fields is not fully defined in the basic Location Object 877 definition, but their use may be private to one or more using 878 protocols. 880 1.4) The Location Object MUST be extensible, allowing the 881 definition of new attributes or fields. 883 1.5) The object MUST be suitable for requesting and receiving a 884 location. 886 1.6) The object MUST permit (but not require) the Privacy Rules 887 to be enforced by a third party. 889 1.7) The object MUST be usable in a variety of protocols, such as 890 HTTP and SIP, as well as local APIs. 892 1.8) The object MUST be usable in a secure manner even by 893 applications on constrained devices. 895 Req. 2. (Location Object fields) The Location Object definition 896 MUST contain the following Fields, which MAY be optional to use: 898 2.1) Target Identifier 900 2.2) Location Recipient Identity 902 This identity may be a multicast or group identity, used to 903 include the Location Object in multicast-based using protocols. 905 2.3) Location Recipient Credential 907 2.4) Location Recipient Proof-of-Possession of the Credential 909 2.5) Location Field. 911 2.5.1) Motion and direction vectors. This field MUST be 912 optional. 914 Cuellar, Morris, Mulligan, Peterson, Polk 18 915 2.6) Location Data Type 917 When transmitting the Location Object, the sender and the 918 receiver must agree on the data type of the location information. 919 The using protocol may specify that the data type information is 920 part of the Location Object or that sender and receiver have 921 agreed on it before the actual data transfer. 923 2.7) Timing information: 924 (a) When was the Location Information accurate? (sighting time) 925 (b) Until when considered current? TTL (Time-to-live) (This is 926 different than a privacy rule setting a limit on data retention) 928 2.8) Rule Field: this field MAY be a referral to an applicable 929 Rule (for instance, an URI to a full Rule), or it MAY contain a 930 Limited Rule (see Req. 11), or both. 932 2.9) Security-headers and -trailers (for instance encryption 933 information, hashes, or signatures) (see Req. 14 and 15). 935 2.10) Version number 937 Req. 3. (Location Data Types) 939 3.1) The Location Object MUST define at least one Location Data 940 Type to be supported by all Geopriv receivers (entities that 941 receive LOs). 943 3.2) The Location Object SHOULD define two Location Data Types: 944 one for latitude / longitude / altitude coordinates and one for 945 civil locations (City, Street, Number) supported by all Geopriv 946 receivers (entities that receive LOs). 948 3.3) The latitude / longitude / altitude Data Type SHOULD also 949 support a delta format in addition to an absolute one, used for 950 the purpose of reducing the size of the packages or the security 951 and confidentiality needs. 953 3.4) The Location Object definition SHOULD agree on further 954 Location Data Types supported by some Geopriv entities and 955 defined by other organizations. 957 7.2. The Using Protocol 959 Req. 4. The using protocol has to obey the privacy and security 960 instructions coded in the Location Object and in the 961 corresponding Rules regarding the transmission and storage of the 962 LO. 964 Req. 5. The using protocol will typically facilitate that the keys 965 associated with the credentials are transported to the respective 967 Cuellar, Morris, Mulligan, Peterson, Polk 19 968 parties, that is, key agreement is responsibility of the using 969 protocol. 971 Req. 6. (Single Message Transfer) In particular for tracking of 972 small target devices, the design should allow a single 973 message/packet transmission of location as a complete 974 transaction. 976 Other requirements on the using protocol are out of the scope of 977 this document, but might be the subject of future efforts from this 978 working group. See also Section 9 (Protocol and LO Issues for later 979 Consideration) 981 7.3. Rule based Location Data Transfer 983 Req. 7. (LS Rules) The decision of a Location Server to provide a 984 Location Recipient access to Location Information MUST be based 985 on Rule Maker-defined Privacy Rules. 987 It is outside of our scope how Privacy Rules are managed and how a 988 Location Server has access to the Privacy Rules. Note that it might 989 be that some rules contain private information not intended for 990 untrusted parties. 992 Req. 8. (LG Rules) Even if a Location Generator is unaware of and 993 lacks access to the full Privacy Rules defined by the Rule Maker, 994 the Location Generator MUST transmit Location Information in 995 compliance with instructions set by the Rule Maker. Such 996 compliance MAY be accomplished by the Location Generator 997 transmitting the LO only to a URI designated by the Rule Maker. 999 Req. 9. (Viewer Rules) An Viewer does not need to be aware of the 1000 full Rules defined by the Rule Maker (because an Viewer SHOULD 1001 NOT retransmit Location Information), and thus an Viewer SHOULD 1002 receive only the subset of Privacy Rules necessary for the Viewer 1003 to handle the LO in compliance with the full Privacy Rules (such 1004 as, for example, an instruction on the time period for which then 1005 the LO can be retained). 1007 Req. 10. (Full Rule language) Geopriv MAY specify a Rule language 1008 capable of expressing a wide range of privacy rules concerning 1009 location information. This Rule language MAY be an existing one, 1010 an adaptation of an existing one or a new Rule language, and it 1011 SHOULD be as simple as possible. 1013 Req. 11. (Limited Rule language) Geopriv MUST specify a limited 1014 Rule language capable of expressing a limited set of privacy 1015 rules concerning location information. This Rule language MAY be 1016 an existing one, an adaptation of an existing one or a new Rule 1017 language. The Location Object MUST include sufficient fields and 1018 data to express the limited set of privacy rules. 1020 Cuellar, Morris, Mulligan, Peterson, Polk 20 1021 7.4. Location Object Privacy and Security 1023 7.4.1. Identity Protection 1025 Req. 12. (Identity Protection) The Location Object MUST support use 1026 of Unlinked Pseudonyms in the corresponding identification fields 1027 of Rule Maker, Target, Device, and Location Recipient. Since 1028 Unlinked Pseudonyms are simply bit strings that are not linked 1029 initially to a well-known identity, this requirement boils down 1030 to saying that the name space for Identifiers used in the LO has 1031 to be large enough to contain many unused strings. 1033 7.4.2. Authentication Requirements 1035 Req. 13. (Credential Requirements) The using protocol and the 1036 Location Object SHOULD allow the use of different credentials 1037 types, including privacy-enhancing credentials (like for instance 1038 the ones described in [Bra00] or [Cha85]). 1040 7.4.3. Actions to be secured 1042 Req. 14. (Security Features) The Location Object MUST support 1043 fields suitable for protecting the Object to provide the 1044 following security features: 1046 14.1) Mutual end-point authentication: the using protocol is 1047 able to authenticate both parties in a Location Object 1048 transmission, 1050 14.2) Data object integrity: the LO is secured from 1051 modification by unauthorized entities during transmission and 1052 during storage, 1054 14.3) Data object confidentiality: the LO is secured from 1055 eavesdropping (unauthorized reading) during transmission and 1056 during storage, and 1058 14.4) Replay protection: an old LO may not be replayed by an 1059 adversary or by the same entity that used the LO itself (except 1060 perhaps during a small window of time that is configurable or 1061 accepted by the Rule Maker). 1063 Req. 15. (Minimal Crypto) 1065 15.1) Geopriv MUST specify a minimum mandatory to implement 1066 Location Object security including mandatory to implement crypto 1067 algorithms, for digital signature algorithms and encryption 1068 algorithms. 1070 15.2) It MAY also define further mandatory to implement 1071 Location Object security mechanisms for message authentication 1072 codes (MACs) or other purposes. 1074 Cuellar, Morris, Mulligan, Peterson, Polk 21 1075 15.3) The protocol SHOULD allow a bypass if authentication 1076 fails in an emergency call. 1078 The issue addressed in the last point is that an emergency call in 1079 some unfavorable situations may not be completed if the minimal 1080 authentication fails. This is probably not what the user would like 1081 to happen. The user may prefer an unauthenticated call to an 1082 unauthenticated emergency server over no call completion at all, 1083 even at the risk that he is talking to an attacker or that his 1084 information is not secured. 1086 7.5. Non-Requirements 1088 Non-Req. 1. (Bridging to non-IP networks) The Geopriv specification 1089 SHOULD NOT specify the bridging to non-IP networks (PSTN, etc). 1091 8. Security Considerations 1093 The purpose of the Geopriv Location Object and the requirements on 1094 the using protocol are to allow a Privacy Rule-controlled disclosure 1095 of location information for location services. 1097 8.1. Traffic Analysis 1099 The information carried within the Location Object is secured in a 1100 way compliant with the privacy and security Rules of the Rule Maker, 1101 but other information, carried in other objects or headers are in 1102 general not secured in the same way. This means that Geopriv may 1103 not as a general matter secure the Target against general traffic 1104 analysis attacks or other forms of privacy violations. 1106 8.2. Securing the Privacy Rules 1108 The Privacy Rules of the Rule Maker regarding the location of the 1109 Target may be accessible to a Location Server in a public or non- 1110 public Rule Holder, or they may be carried by the Location Object, 1111 or they may be presented by the Location Recipient as capabilities 1112 or tokens. Each of this types of Rule has to be secured it's own 1113 particular way. 1115 The rules in a non-public Rule Holder are typically authenticated 1116 using a MAC (Message Authentication Code) or a signature, depending 1117 on the type of keys used. The rules in a public Rule Holder (one 1118 that in principle may be accessed directly by several entities, for 1119 instance several Location Servers) are typically digitally signed. 1120 Rule Fields in a LO are secured as part of the LO itself. A Geopriv 1121 Token (a token or ticket issued by the Rule Maker to a Location 1122 Recipient, expressing the explicit consent of the Rule Maker to 1123 access his location information) is authenticated or signed. 1125 Cuellar, Morris, Mulligan, Peterson, Polk 22 1126 8.3. Emergency Case 1128 Let us consider the situation where the authentication fails in an 1129 emergency call because the authentication center fails to 1130 authenticate itself. In this case, one way of implementing the 1131 authentication bypass for emergency calls, mentioned in Req 15.3) is 1132 to let the user have the choice of writing a Rule that says: 1133 - "If the emergency server does not authenticate itself, send the 1134 location information anyway", or 1135 - "If the emergency server does not authenticate itself, let the 1136 call fail". 1138 Second, in the case where the authentication of the emergency call 1139 fails because the user may not authenticate itself, the question 1140 arises: whose Rule to use? It is reasonable to use a default one: 1141 this location information can only be sent to an emergency center. 1143 The third situation, which should be studied in more detail, is: 1144 what to do if not only the user fails to authenticate itself, but 1145 also the emergency center is not authenticable? It is reasonable to 1146 send the Location Information anyway, but are there in this case any 1147 security threats that must be considered? 1149 8.4. Identities and Anonymity 1151 The use of Unlinked Pseudonyms is necessary to obtain anonymity. 1153 The purpose of the use of Unlinked Pseudonyms is the following: the 1154 using protocol should be able to hide the real identity of the Rule 1155 Maker, the Target, and the Device, to Location Servers or Location 1156 Recipients, if required by the RM. Also, the using protocol SHOULD 1157 be able to hide the real identity of the Location Recipient to the 1158 Location Server. 1160 In this last case, the Target is not concerned about the Server 1161 identifying him and knowing his location, but identifying his 1162 business partners, and therefore his habits, etc. Reasons for 1163 hiding the real identities of the Location Recipients include (a) 1164 that this knowledge may be used to infer the identity of the Target, 1165 (b) that knowledge of the identity of the Location Recipient may 1166 embarrass the Target or breach confidential information, and (c) 1167 that the dossier telling who has obtained a Target's location 1168 information over a long period of time can give information on 1169 habits, movements, etc. Even if the location service providers 1170 agree to respect the privacy of the user, are compelled by laws or 1171 regulations to protect the privacy of the user, and misbehavior or 1172 negligence of the Location Server can be ruled out, there is still 1173 risk that personal data may become available to unauthorized persons 1174 through attacks from outsiders, unauthorized access from insiders, 1175 technical or human errors, or legal processes. 1177 Cuellar, Morris, Mulligan, Peterson, Polk 23 1178 In some occasions a Location Server has to know who is supplying the 1179 Privacy Rules for a particular Target, but in other situations it 1180 could be enough to know that the supplier of the Rules is authorized 1181 to do so. 1183 8.5. Unintended Target 1185 An Unintended Target is a person or object tracked by proximity to 1186 the Target. This special case most frequently occurs if the Target 1187 is not a person. For example, the Target may be a rental car 1188 equipped with a GPS Device, used to track car inventory. The rental 1189 company may not care about the driver's location, but the driver's 1190 privacy is implicitly affected. 1192 Geopriv may or may not protect or affect the privacy of Unintended 1193 Targets, but the impact on Unintended Targets should be 1194 acknowledged. 1196 9. Protocol and LO Issues for later Consideration 1198 This section briefly discusses issues relating to the Location 1199 Object or the protocol that have emerged during the discussion of 1200 earlier versions of this document. 1202 9.1. Multiple Locations in one LO 1204 A location Field is intended to represent one point or one region in 1205 space (either 1, 2, or 3 dimensionally). The possibility of 1206 inclusion of multiple locations is discussed in another document. 1207 The current rough consensus is the following: the LO definition MAY 1208 allow the Location Field to be optional, to appear exactly one time 1209 or to occur several times. Each Location Field may contain one or 1210 more "Location Representations", each of which is intended to 1211 represent a different measurement or a different formatting of the 1212 same position. But there are other possibilities for using multiple 1213 Location Fields and multiple representations: maybe several Location 1214 Fields would be used to report the same sighting in different 1215 formats, or multiple sightings at different times, or multiple 1216 sensor locations for the same device, or other purposes, which could 1217 also depend on the using protocol. This all is for further 1218 discussion. 1220 9.2. Translation Fields 1222 It is possible to include fields to indicate that one of the 1223 locations is a translation of another. If this is done, it is also 1224 possible to have a field to identify the translator, as identity and 1225 method. 1227 Cuellar, Morris, Mulligan, Peterson, Polk 24 1228 9.3. Truth Flag 1230 Geopriv MUST be silent on the truth or lack-of-truth of the location 1231 information contained in the LO. Thus, the LO MUST NOT provide an 1232 attribute in object saying "I am (or am not) telling you the whole 1233 truth." 1235 9.4. Timing Information Format 1237 The format of timing information is out of the scope of this 1238 document. 1240 9.5. The Name Space of Identifiers 1242 Who defines the Identities: may the using protocol define the 1243 Identifiers or must the using protocol use and authenticate 1244 Pseudonyms proposed by the Rules, chosen independently of the using 1245 protocol? Of course, if the using protocol has an appropriate 1246 namespace, containing many unused names that may be used as 1247 pseudonyms and may be replaced by new ones regularly, then the 1248 Location Object may be able to use the name space. For this purpose, 1249 the user would probably have to write his Rules using this name 1250 space. Note that it is necessary to change the used pseudonyms 1251 regularly, because identifying the user behind an unlinked pseudonym 1252 can be very simple. 1254 There are several advantages of letting the using protocol to define 1255 the name space: 1256 o the embedded authentication would be easier, as the using protocol 1257 has often already the credentials for the authentication identity 1258 in place and the "embedded" authentication would be independent on 1259 the form of Identifiers, 1260 o the size of the names would be fixed. 1262 On the other hand, the benefits of the Rule choosing the identifiers 1263 are: 1264 o the user has a control of his anonymity, and 1265 o the interworking of multiple systems with Location object across 1266 protocol boundaries is facilitated. 1268 10. Acknowledgements 1270 We wish to thank the members of the IETF Geopriv WG for their 1271 comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison 1272 Mankin, Randall Gellens, and the participants of the Geopriv 1273 meetings in San Diego and Yokohama provided detailed comments or 1274 text. 1276 11. References 1278 Cuellar, Morris, Mulligan, Peterson, Polk 25 1280 [Bra00] Stefan A.: Rethinking Public Key Infrastructures and Digital 1281 Certificates : Building in Privacy, MIT Press; ISBN: 1282 0262024918; 1st edition, August, 2000 1284 [Cha85] Chaum, David: Security without Identification, Card 1285 Computers to make Big Brother Obsolete. Original Version 1286 appeared in: Communications of the ACM, vol. 28 no. 10, 1287 October 1985 pp. 1030-1044. Revised version available at 1288 http://www.chaum.com/articles/ 1290 [ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/. 1292 [OECD] OECD Guidelines on the Protection of Privacy and Transborder 1293 Flows of Personal Data, http://www.oecd.org. 1295 [Pfi01] Pfitzmann, Andreas; K�hntopp, Marit: Anonymity, 1296 Unobservability, and Pseudonymity - A Proposal for 1297 Terminology; in: H Federrath (Ed.): Designing Privacy 1298 Enhancing Technologies; Proc. Workshop on Design Issues in 1299 Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer 1300 versions available at http://www.koehntopp.de/marit/pub/anon 1302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1303 Requirement Levels", BCP 14, RFC 2119, March 1997. 1305 12. Author's Addresses 1307 Jorge R Cuellar 1308 Siemens AG 1309 Corporate Technology 1310 CT IC 3 1311 81730 Munich Email: Jorge.Cuellar@mchp.siemens.de 1312 Germany 1314 John B. Morris, Jr. 1315 Director, Internet Standards, Technology & Privacy Project 1316 Center for Democracy and Technology 1317 1634 I Street NW, Suite 1100 1318 Washington, DC 20006 Email: jmorris@cdt.org 1319 USA http://www.cdt.org 1321 Deirdre K. Mulligan 1322 Samuelson Law, Technology and Public Privacy Clinic 1323 Boalt Hall School of Law 1324 University of California 1325 Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu 1326 USA 1328 Jon Peterson 1329 NeuStar, Inc. 1330 1800 Sutter St 1331 Suite 5707 Email: jon.peterson@neustar.biz 1333 Cuellar, Morris, Mulligan, Peterson, Polk 26 1334 Concord, CA 94520 http://www.neustar.biz/ 1335 USA 1337 James M. Polk 1338 Cisco Systems 1339 2200 East President George Bush Turnpike 1340 Richardson, Texas 75082 USA7 Email: jmpolk@cisco.com 1342 13. Full Copyright Statement 1344 Copyright (C) The Internet Society (date). All Rights Reserved. 1346 This document and translations of it may be copied and furnished to 1347 others, and derivative works that comment on or otherwise explain it 1348 or assist in its implementation may be prepared, copied, published 1349 and distributed, in whole or in part, without restriction of any 1350 kind, provided that the above copyright notice and this paragraph 1351 are included on all such copies and derivative works. However, this 1352 document itself may not be modified in any way, such as by removing 1353 the copyright notice or references to the Internet Society or other 1354 Internet organizations, except as needed for the purpose of 1355 developing Internet standards in which case the procedures for 1356 copyrights defined in the Internet Standards process must be 1357 followed, or as required to translate it into languages other than 1358 English. 1360 The limited permissions granted above are perpetual and will not be 1361 revoked by the Internet Society or its successors or assigns. 1363 This document and the information contained herein is provided on an 1364 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1365 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1366 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1367 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1368 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1370 Cuellar, Morris, Mulligan, Peterson, Polk 27