idnits 2.17.00 (12 Aug 2021) /tmp/idnits2860/draft-cuellar-geopriv-scenarios-03.txt: 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 2 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 503 has weird spacing: '... use of a lim...' -- 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 (Mar 2003) is 7006 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) == Missing Reference: 'RFC-2119' is mentioned on line 154, but not defined == Missing Reference: 'Class' is mentioned on line 800, but not defined == Unused Reference: 'RFC2119' is defined on line 1605, but no explicit reference was found in the text -- 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 (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Cuellar 3 Document: draft-cuellar-geopriv-scenarios-03.txt Siemens AG 5 J. Morris 6 Center for Democracy & Technology 8 T. Kanai 9 Fujitsu Laboratories 11 Expires in six months Mar 2003 13 Geopriv Scenarios and Use Cases 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document describes location-based service scenarios for Geopriv. 41 It complements the Geopriv Requirements document by providing a set 42 of examples in which the Geopriv Location Object (LO) may be used. 43 Thus this documents serves as a basis to discuss and analyze the 44 security (authentication, authorization, integrity and 45 confidentiality) and privacy issues and requirements associated with 46 location-based services. To be useful, these scenarios include 47 details of location computation, which helps to identify the entities 48 involved on an abstract level and where privacy issues like control, 49 consent, access, and security arise. 51 Cuellar, Morris, Kanai Geopriv Scenarios 1 52 Table of Contents 54 1. Overview........................................................3 55 2. Conventions used in this document...............................4 56 3. Terminology.....................................................4 57 3.1. Foundational Definitions...................................4 58 3.1.1. Location Information (LI) and Sighting................4 59 3.1.2. The Location Object...................................5 60 3.1.3. Location Object vs. Using Protocol....................6 61 3.1.4. Trusted vs. Non-trusted Data Flows....................6 62 3.2. Geopriv Entities and Functions.............................7 63 3.2.1. Primary Geopriv Entities..............................7 64 3.2.2. Secondary Geopriv Entities............................8 65 3.2.3. Geopriv Data Storage Functions........................9 66 3.3. Privacy Rules..............................................9 67 3.4. Identifiers, Authentication and Authorization.............10 68 3.4.1. Identifiers..........................................11 69 3.4.2. Authentication.......................................11 70 3.4.3. Authorization........................................12 71 4. Three Frameworks to Classify Use Cases and Scenarios...........12 72 4.1. Classifications "Push", "Pull", and "Translate/Query".....13 73 4.1.1. Push Model...........................................13 74 4.1.2. Pull Model...........................................13 75 4.1.3. Translate/Query Model................................14 76 4.2. Overlap of Geopriv Roles (Classif. A-1 through A-9).......15 77 4.3. Initial Location Computation (Classif. B-1 through B-12)..15 78 5. Services From a User Point of View.............................17 79 5.1. Network Management and Computer Services..................18 80 5.1.1. Location Based Charging or Billing...................18 81 5.1.2. Enhanced Call Routing................................18 82 5.1.3. Ubiquitous computing applications....................19 83 5.2. Emergency and Security Services...........................19 84 5.2.1. Emergency Call Services..............................19 85 5.2.2. Emergency Alert and other Public Safety Services.....19 86 5.2.3. Evacuation navigation service........................19 87 5.2.4. Location-based services to drivers...................19 88 5.2.5. Tracking services for Security.......................20 89 5.3. Resource Management Services..............................20 90 5.3.1. Tracking services for Resource Management............20 91 5.3.2. Package Tracking.....................................20 92 5.3.3. Taxi dispatch system - location of the customer......20 93 5.3.4. Taxi dispatch system - location of the taxi..........21 94 5.4. Geographic Based Content Services.........................21 95 5.4.1. Navigation...........................................21 96 5.4.2. City Sightseeing.....................................22 97 5.4.3. Mobile Yellow Pages..................................22 99 Cuellar, Morris, Kanai Geopriv Scenarios 2 100 5.4.4. Traffic Monitoring...................................22 101 5.4.5. Traffic jam information..............................22 102 5.5. Content Provider-Initiated Information Services...........23 103 5.5.1. Location Dependent Content Broadcast.................23 104 5.6. Entertainment and Community Services......................23 105 The services in this subsection could arise with either the 106 Push, Pull, or Translate/Query Models, and conceivably in 107 almost any of the classifications A-1 through A-9...........23 108 5.6.1. Mobile Communities or Locate a Person................23 109 5.6.2. Gaming...............................................23 110 5.6.3. Rendezvous service...................................23 111 6. Scenarios......................................................23 112 6.1. Scenario 1................................................24 113 6.2. Scenario 2................................................24 114 6.3. Scenario 3................................................25 115 6.4. Scenario 4................................................26 116 6.5. Scenario 5................................................27 117 6.6. Scenario 6................................................28 118 6.7. Scenario 7................................................29 119 6.8. Scenario 8................................................31 120 7. Implications and Conclusions...................................32 121 8. Security Considerations........................................32 122 9. Acknowledgements...............................................32 123 10. References....................................................32 124 11. Author's Addresses............................................33 125 12. Full Copyright Statement......................................33 127 1. Overview 129 Location based systems are an emerging field, and all possible 130 services or relationships cannot be identified or even imagined 131 today. Over the next few years, location based services and 132 applications are likely to come in a huge array of shapes, sizes, 133 structures, paradigms, and approaches. This document attempts to 134 articulate the range and types of applications that are possible 135 using location services, although the use cases and scenarios below 136 are unavoidably incomplete. 138 This document includes 4 main sections below. Section 3 contains 139 terminology and definitions, largely drawn from the similar section 140 in the Geopriv Requirements draft. Section 4 advances three 141 different and incomplete (individually or collectively) analytical 142 frameworks with which to consider Geopriv uses and scenarios. 143 Section 5 lists, and briefly discusses, a range of possible use 144 cases. Section 6 looks at a subset of these use cases 145 diagrammatically, in an effort to identify the entities and data 146 flows involved. 148 Cuellar, Morris, Kanai Geopriv Scenarios 3 149 2. Conventions used in this document 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC-2119]. 155 3. Terminology 157 The terminology and definitions detailed below include both (1) 158 primary or essential terms used in the Requirements document, and (2) 159 secondary terms that provide additional detail about the usage model 160 envisioned for the Geopriv Location Object. 162 Most of the definitions below are drawn directly from the 163 Requirements Document. The focus of that document, however, is on 164 the requirements for the Geopriv Location Object. This document, in 165 contrast, looks more broadly at Geopriv scenarios and data flows. It 166 thus uses some additional terms not used in the Requirements 167 Document. These additional terms are indicated by a "Not in 168 Requirements Document" designation. 170 3.1. Foundational Definitions 172 3.1.1. Location Information (LI) and Sighting 174 The focus of the Geopriv working group is on information about a 175 Target's location that is NOT based on generally or publicly 176 available sources, but instead on private information provided or 177 created by a Target, a Target's Device, or a Target's network or 178 service provider. Notwithstanding this focus on private location 179 information, the Geopriv Location Object could certainly be used to 180 convey location information from publicly available sources. 182 Location Information (LI): 183 A relatively specific way of describing where a Device is 184 located. 186 In general, Location Information is (a) derived or computed from 187 information generally not available to the general public (such as 188 information mainly available to a network or service provider), (b) 189 determined by a Device that may be not generally publicly addressable 190 or accessible, or (c) input or otherwise provided by a Target. 192 As examples, LI could include (a) information calculated by 193 triangulating on a wireless signal with respect to cell phone towers, 194 (b) longitude and latitude information determined by a Device with 195 GPS (global positioning satellite) capabilities, (c) information 196 manually entered into a cell phone or laptop by a Target in response 197 to a query, or (d) automatically delivered by some other IP protocol, 198 such as at device configuration via DHCP. 200 Cuellar, Morris, Kanai Geopriv Scenarios 4 201 Excluded from this definition is the determination of location 202 information wholly without the knowledge or consent of the Target (or 203 the Target's network or access service provider), based on generally 204 available information such as an IP or e-mail address. In some cases 205 information like IP address can enable someone to estimate (at least 206 roughly) a location. Commercial services exist that offer to provide 207 rough location information based on IP address. Currently, this type 208 of location information is typically less precise and has a coarser 209 granularity than the type of location information addressed in this 210 document. Although this type of location computation still raises 211 significant potential privacy and public Policy concerns, such 212 scenarios are generally outside the scope of this document. 214 Within any given location-based transaction, the INITIAL 215 determination of location (and thus the initial creation of Location 216 Information) is termed a Sighting: 218 Sighting: 219 The initial determination of location based on non-public 220 information (as discussed in the definition of Location 221 Information), and the initial creation of Location Information. 223 Some variant of the sighting information is included in the Location 224 Object. Abstractly, it consists of two separate data fields: 226 (Identifier, Location) 228 where Identifier is the identifier assigned to a Target being 229 sighted, and Location is the current position of that Target being 230 sighted. Not all entities may have access to exactly the same piece 231 of sighting information. A sighting may be transformed to a new 232 sighting pair: 234 (Identifier-1, Location-1) 236 before it is provided by a Location Generator or Location Server to 237 another Location Recipient (for instance, another Location Server). 238 In this case, Identifier-1 may be Pseudonym, and Location-1 may have 239 less accuracy or granularity than the original value. 241 3.1.2. The Location Object 243 A main goal of the Geopriv working group is to define a Location 244 Object (LO), to be used to convey both Location Information and basic 245 privacy-protecting instructions: 247 Location Object (LO): This data contains the Location Information 248 of the Target, and other fields including an identity or 249 pseudonym of the Target, time information, core Privacy Rules, 250 authenticators, etc. Most of the fields are optional, 251 including the Location Information itself. 253 Cuellar, Morris, Kanai Geopriv Scenarios 5 254 Nothing is said about the semantics of a missing field. For 255 instance, a partially filled object MAY be understood implicitly as 256 the request to complete it. Or, if no time information is included, 257 this MAY implicitly mean "at the current time" or "at a very recent 258 time", but it could be interpreted in a different way, depending on 259 the context. 261 3.1.3. Location Object vs. Using Protocol 263 The security and privacy enhancing mechanisms used to protect the LO 264 are of two types: First, the Location Object definition MUST include 265 (optional) fields or mechanisms used to secure the LO as such. The 266 LO MAY be secured, for example, using cryptographic checksums or 267 encryption as part of the LO itself. 269 Second, the "using protocol" (that is, the protocol that uses the 270 Location Object) may also provide security mechanisms to securely 271 transport the Location Object. 273 The "using protocol" is the protocol that uses (creates, reads or 274 modifies) the Location Object. A protocol that just transports the 275 LO as a string of bits, without looking at them (like an IP storage 276 protocol could do), is not a using protocol, but only a transport 277 protocol. Nevertheless, the entity or protocol that caused the 278 transport protocol to move the LO is responsible of the appropriate 279 distribution, protection, usage, retention, and storage of the LO 280 based on the rules that apply to that LO. 282 The security mechanisms of the Location Object itself are to be 283 preferred. The using protocol has to obey the privacy and security 284 instructions coded in the Location Object and in the corresponding 285 Privacy Rules regarding the transmission and storage of the LO in 286 order to ensure that the rules established by the Rule-Maker are 287 observed. Other requirements on the using protocol are out of the 288 scope of this document. . 293 3.1.4. Trusted vs. Non-trusted Data Flows 295 Location information can be used in very different environments. In 296 some cases the participants will have longstanding relationships, 297 while in others participants may have discrete interactions with no 298 prior contractual or other contact. 300 The different relationships raise different concerns for the 301 implementation of Privacy Rules, including the need to communicate 302 Privacy Rules. A public Rule Holder, for example, may be unnecessary 303 in a trusted environment where more efficient methods of addressing 304 privacy issues exist. The following terms distinguish between the 305 two basic types of data flows: 307 Cuellar, Morris, Kanai Geopriv Scenarios 6 308 Trusted Data Flow: 309 A data flow that is governed by a pre-existing contractual 310 relationship that addresses location privacy. 312 Non-trusted Data Flow: 313 The data flow is not governed by a pre-existing contractual 314 relationship that addresses location privacy. 316 3.2. Geopriv Entities and Functions 318 The entities of a Geopriv application or transaction may be given 319 explicit roles: 321 3.2.1. Primary Geopriv Entities 323 Certain entities and roles are involved in most (and in some cases 324 all) Geopriv transactions: 326 Target: 327 The entity whose location is desired by the Location Recipient. 328 In many cases the Target will be the human "user" of a Device 329 or an object such as a vehicle or shipping container to which 330 the Device is attached. In some instances the Target will be 331 the Device itself. 333 Device: 334 The technical device the location of which is tracked as a 335 proxy for the location of a Target. 337 A Device might, for example, be a cell phone, a Global Positioning 338 Satellite (GPS) receiver, a laptop equipped with a wireless access 339 Device, or a transmitter that emits a signal that can be tracked or 340 located. In some situations, such as when a Target manually inputs 341 location information (perhaps with a web browser), the Target is 342 effectively performing the function of a Device. 344 Rule Maker (RM): 345 The individual or entity that has the authorization to set the 346 applicable Privacy Rules for a potential Geopriv Target. In 347 many cases this will be the owner of the Device, and in other 348 cases this may be the user who is in possession of the Device. 349 For example, parents may control what happens to the location 350 information derived from a child's cell phone. A company, in 351 contrast, may own and provide a cell phone to an employee but 352 permit the employee to set the Privacy Rules. 354 Location Recipient (LR): 355 An individual or entity who seeks to receive location data 356 about a Target. 358 Cuellar, Morris, Kanai Geopriv Scenarios 7 359 A Location Recipient may act in one or more of the following more 360 specialized roles: as the Location Generator, a Location Server, or 361 as a Viewer: 363 Location Generator (LG): The LG is an element responsible for 364 creating the Location Object for a specific Target. LGs publish 365 Location Objects to Location Servers. The manner in which the 366 Location Generator learns of Location Information is outside 367 the scope of the Geopriv protocol. 369 Location Server (LS): 370 The LS is an element that receives publications of Location 371 Objects from Location Generators and may receive subscriptions 372 from Location Recipients. The LS applies the rules (which it 373 learns from the Rule Holder) to LOs it receives from LGs, and 374 then notifies LRs of resulting LOs as necessary. 376 Some location tracking scenarios may involve a Target, Device, or 377 Device user performing the function of a Location Server. 379 Viewer (Viewer): 380 An individual or entity who receives location data about a 381 Target and does not transmit the location information or 382 information based on the Target's location (such as driving 383 directions to or from the Target) to any party OTHER than the 384 Target or the Rule Maker. 386 3.2.2. Secondary Geopriv Entities 388 Certain entities and functions are present or involved in only a 389 subset of Geopriv transactions: 391 Unintended Target [Not in Requirements Document]: 392 A person or object tracked by proximity to the Target. This 393 special case most frequently occurs if the Target is not a 394 person. For example, the Target may be a rental car equipped 395 with a GPS Device, used to track car inventory. The rental 396 company may not care about the driver's location, but the 397 driver's privacy is implicitly affected. Geopriv may or may 398 not protect or affect the privacy of Unintended Targets, but 399 the impact on Unintended Targets should be acknowledged. 401 Data Transporter: 402 An entity or network that receives and forwards data without 403 processing or altering it. A Data Transporter could 404 theoretically be involved in almost any transmission between a 405 Device and a Location Server, a Location Server and a second 406 Location Server, or a Location Server and a Viewer. Some 407 location tracking scenarios may not involve a Data Transporter. 409 Access Provider (AP): 410 The domain that provides the initial network access or other 412 Cuellar, Morris, Kanai Geopriv Scenarios 8 413 data communications services essential for the operation of 414 communications functions of the Device or computer equipment in 415 which the Device operates. Often, the AP -- which will be a 416 wireless carrier, an Internet Service Provider, or an internal 417 corporate network -- contains the LG. Sometimes the AP has 418 a "dumb" LG, one that transmits Geopriv LOs but does not use 419 any part of the Geopriv Location Object. Other cases may not 420 involve any AP, or the AP may only act as a Data Transporter. 422 Service Initiator [Not in Requirements Document]: 423 Entity that initiates the service and submits a request to 424 disclose the Location Information to the Location Recipient. 425 In most cases, this entity will overlap with one of the other 426 Geopriv entities, such as the Target, the Rule Maker, or the 427 Location Recipient. 429 3.2.3. Geopriv Data Storage Functions 431 Within the Geopriv framework, certain data may be stored in 432 various functional entities: 434 Rule Holder (RH): The RH is an element that houses Privacy Rules 435 for receiving, filtering and distributing Location Objects for 436 specific Targets. A LS may query an RH for a set of rules, or 437 rules may be pushed from the RH to an LS. The rules in the Rule 438 Holder are populated by the Rule Maker. 440 Private Rule Holder [Not in Requirements Document]: 441 A non-public Rule Holder used to store private (authenticated, 442 but not signed) or public (signed) Rules, identifiers, keys, 443 and perhaps also requests. A Private Rule Holder could be 444 operated by a Device, a Location Server, or a third party 445 service provider. 447 Public Rule Holder [Not in Requirements Document]: 448 A public repository where signed Rules are stored. 450 Location Storage: 451 A Device or entity that stores raw or processed Location 452 Information, such as a database, for any period of time longer 453 than the duration necessary to complete an immediate 454 transaction regarding the LI. 456 The existence and data storage practices of Location Storage is 457 crucial to privacy considerations, because this may influence what 458 Location Information could eventually be revealed (through later 459 distribution, technical breach, or legal processes). 461 3.3. Privacy Rules 463 Cuellar, Morris, Kanai Geopriv Scenarios 9 464 Privacy Rules are rules that regulate an entity's activities with 465 respect to location and other information, including, but not limited 466 to, the collection, use, disclosure, and retention of location 467 information. Such rules are generally based on fair information 468 practices, as detailed in (for example) the OECD Guidelines on the 469 Protection of Privacy and Transporter Flows of Personal Data [OECD]. 471 Privacy Rule: 472 A rule or set of rules that regulate an entity's activities 473 with respect to location information, including the collection, 474 use, disclosure, and retention of location information. In 475 particular, the Rule describes how location information may be 476 used by an entity and which transformed location information 477 may be released to which entities under which conditions. 478 Rules must be obeyed; they are not advisory. 480 A full set of Privacy Rules will likely include both rules that have 481 only one possible technical meaning, and rules that will be affected 482 by a locality's prevailing laws and customs. For example, a 483 distribution rule of the form "my location can only be disclosed to 484 the owner of such credentials and in such accuracy" has clear-cut 485 implications for the protocol that uses the LO. But other rules, like 486 retention or usage Rules, may have unclear technical consequences for 487 the protocol or for the involved entities. For example, the precise 488 scope of a retention rule stating "you may not store my location for 489 more than 2 days" may in part turn on local laws or customs. 491 The Privacy Rules of the Rule Maker regarding the location of the 492 Target may be accessible to a Location Server in Private or Public 493 Rules Repositories, or they may be carried by the Location Object, or 494 they may be presented by the Location Recipient as capabilities or 495 tokens: 497 Public Rule [Not in Requirements Document]: 498 A Rule, digitally signed by the Rule Maker, and stored in a 499 Rule Holder for the use of one or several Location Servers. 501 Private Rule [Not in Requirements Document]: 502 An authenticated Rule, consented by the Rule Maker, and stored 503 in Private Rule Storage for the private use of a limited set 504 of Location Servers. 506 Geopriv Token [Not in Requirements Document]: 507 A token or ticket issued and secured (authenticated or signed) 508 by the Rule Maker to a Location Recipient, expressing the 509 explicit consent of the Rule Maker to access his location 510 information. This Geopriv Token is thus, logically, a rule of 511 the Rule Maker. 513 3.4. Identifiers, Authentication and Authorization 515 Cuellar, Morris, Kanai Geopriv Scenarios 10 516 This subsection introduces terms and concepts used in the 517 Requirements Section. 519 3.4.1. Identifiers 521 Anonymity is the property of being not identifiable (within a set of 522 subjects). Anonymity serves as the base case for privacy: without 523 the ability to remain anonymous, individuals may be unable to control 524 their own privacy. Unlinkability ensures that a user may make 525 multiple uses of resources or services without others being able to 526 link these uses together. Unlinkability requires that entities are 527 unable to determine whether the same user caused certain specific 528 operations in the system. [ISO99]: A pseudonym is simply a bit string 529 which is unique as ID and is suitable to be used for end-point 530 authentication. 532 Unlinked Pseudonym: 533 A pseudonym where the linking between the pseudonym and its 534 holder is, at least initially, not known to anybody with the 535 possible exception of the holder himself or a trusted server of 536 the user. See [Pfi01] (there the term is called Initially 537 Unlinked Pseudonym) 539 The use of Unlinked Pseudonyms is necessary to obtain anonymity. But 540 also it is necessary to change the used pseudonyms regularly, because 541 identifying the user behind an unlinked pseudonym can be very simple. 543 In order to remain anonymous, an entity may use private identifiers. 544 Private identifiers convey less information than public identities, 545 because they are meaningful to a smaller number of entities and in 546 use for a shorter duration. Thus if A discloses a private identifier 547 to B, B is less likely to associate this information with a known 548 individual or entity than if a public identifier was disclosed. 550 Short-lived Identifier [Not in Requirements Document]: 551 An identifier that is used only for one or a limited number of 552 "sessions". 554 Using protocols should be able to handle LOs with identifiers, LOs 555 without identifiers, and LOs with pseudonyms. The identity of the 556 requester may be irrelevant in some cases, whereas the identity of 557 the Target may be irrelevant in others. 559 Entity-Identifier [Not in Requirements Document]: 560 The names used by the Geopriv entities to identify, 561 authenticate or authorize themselves to other entities. Rules 562 also use entity-identifiers to express which Location 563 Recipients may receive which transformed sighting information. 565 3.4.2. Authentication 567 Cuellar, Morris, Kanai Geopriv Scenarios 11 568 The word authentication is used in different meanings. Some assert 569 that authentication associates an entity with a more or less well- 570 known identity. This basically means that if A authenticates another 571 entity B as being "id-B", then the label "id-B" is not a pseudonym, 572 but a persistent or at least linkable identity of the entity. In 573 this case, the label "id-B" is called a publicly known identifier, 574 and the authentication is "explicit": 576 Explicit Authentication: 577 The act of verifying a claimed identity as the sole originator 578 of a message (message authentication) or as the end-point of a 579 channel (entity authentication). Moreover, this identity is 580 easily linked back to the real identity of the entity in 581 question, for instance being a pre-existing static label from a 582 predefined name space (telephone number, name, etc.). 584 3.4.3. Authorization 586 Authorization 587 The act of determining if a particular right, such as access to 588 some resource, can be granted to the presenter of a particular 589 credential. 591 Depending on the type of credential, authorization may imply Explicit 592 Authentication or not. 594 4. Three Frameworks to Classify Use Cases and Scenarios 596 There are many different ways to conceptualize or classify the 597 possible Geopriv scenarios. Among the possible approaches can be: 599 A. How is the location information transaction being triggered: is 600 it a "push" or a "pull" model, or a "query" to translate a 601 location or find a location in a context? 602 B. What are the relevant entities, devices, and roles, and how do 603 they interrelate and (often) overlap? 604 C. What entity first has control over the initial sighted data, and 605 over the initial computation and distribution of the location 606 information? 608 These three classifications are discussed briefly in this section. 610 A fourth approach to considering the full range of possible Geopriv 611 scenarios is to analyze the use cases from the user's perspective, 612 looking at what service is bring provided from the point of view of 613 the user. A range of these use cases are described in Section 5, 614 with references back to the three classification schemes discussed in 615 this section. 617 Cuellar, Morris, Kanai Geopriv Scenarios 12 618 None of these classifications alone is fully sufficient to identify 619 the full range of possible location services. Other ways to consider 620 the possible uses and scenarios are discussed in Section 7. 622 4.1. Classifications "Push", "Pull", and "Translate/Query" 624 One classification of scenarios is according to who is the Service 625 Initiator and whether the service triggering is done on demand or on 626 subscription mode, and if the Rule Maker is granted positioning 627 consent or not. A Target, Rule Maker, Location Recipient, or another 628 party may trigger the actions, depending on the service being 629 provided. They may be triggered on demand or as a periodical 630 subscription (periodical updates). Also it is possible for location 631 services to support conditional positioning. Under these conditions, 632 an application that is granted conditional positioning authorization 633 must notify and obtain positioning authorization from the Rule Maker 634 of the Target prior to performing the positioning process. The Rule 635 Maker is able to accept or reject the positioning attempt. 637 In Japan for instance, all major mobile carriers provide the 638 following types of well-known commercial services: 640 1. "Here I am!" (Subscribers may send their location information 641 to other subscribers or to Internet users via e-mail or other 642 means.) 643 2. "Where is he/she?" (Carriers tell users where someone is 644 located.) 645 3. "Where am I?" service (Carriers tell subscribers where they 646 are located on a map.) 648 Those three correspond roughly to 3 query modes described below: Push 649 Model, Pull Model, and Translate/Query Model. Note than many 650 scenarios will involve both Push and Translate, or both Pull and 651 Translate. 653 4.1.1. Push Model 655 In the Push Model, the Target typically acts as the Location 656 Initiator (instead of responding to a request). For example, after 657 locating himself, the Target may send his location to the Viewer or 658 another Location Recipient. Similarly, the Target may ask a Location 659 Generator to locate the Target and transmit the location to a Viewer 660 or other Location Recipient. 662 4.1.2. Pull Model 664 In the Pull Model, a Viewer or other Location Recipient wants to know 665 where a given Target is, and thus is the Service Initiator. As one 666 example of the Pull Model, a Location Server: 668 Cuellar, Morris, Kanai Geopriv Scenarios 13 669 1. receives Location Information from the Location Generator 670 or from another Location Server, 672 2. receives, directly or through a repository or a trusted 673 third party, the Privacy Rules associated with the Target, 675 3. accepts services requests from Location Recipients 676 (including other Location Servers), 678 4. matches the location request to the Rules for the Target 679 and processes the Location Information accordingly, and 681 5. returns Location Information (sometimes filtered) of the 682 Target. 684 4.1.3. Translate/Query Model 686 Those are services where some entity (such as a Target or other 687 Location Recipient) provides Location Information and obtains a 688 function of that information as response. For instance, he may want 689 to translate a location from one format to another (say from 690 coordinates to civil), or to see in a map where certain coordinates 691 are, or given the distance from a point to 2 or more fixed locations, 692 to find the possible locations of the point. 694 This service may be invoked by a mobile Target that knows where he 695 is, or where he plans to be this afternoon, but needs additional 696 information about the location or needs the location in a different 697 format. 699 In one example, a Target knows his location (say, using a GPS chip), 700 but not in the form that he needs it (say, as a street address). In 701 this case, the Target asks an external Location Server to translate 702 the information to a street address or position on a map. The 703 Location Server obtains the location from the Location Generator 704 (which is the Target itself), converts the Location Information to 705 the requested form, and sends it back to the Location Recipient (also 706 the Target). 708 Cuellar, Morris, Kanai Geopriv Scenarios 14 709 4.2. Overlap of Geopriv Roles (Classif. A-1 through A-9). 711 In many Geopriv scenarios the different entities can overlap. 712 Sometimes a Device is a proxy for a Target, and sometimes the Device 713 is the Target. In some cases, the Rule Maker and the Target are the 714 same individual or entity; in other cases, they are different. If 715 the Target/Device knows his location (through GPS, for example), the 716 Target/Device may also be the Location Generator. If the Target's 717 Device has the capabilities and bandwidth, that Device may serve as 718 the Location Server, or may rely on an external Location Server. 720 The following is an admittedly incomplete breakdown of different 721 overlaps among the Geopriv roles (where LS stands for Location 722 Server, LG for Location Generator, and Sinitiator for Service 723 Initiator): 725 A-1: LS = RM = Target = LG / Viewer = SInitiator 726 A-2: LS = RM = Target / LG / Viewer = Sinitiator 727 A-3: LS / RM = Target = LG = Viewer = SInitiator 728 A-4: LS / RM = Target = LG / Viewer = SInitiator 729 A-5: LS / RM = Target / LG / Viewer = SInitiator 730 A-6: LS / RM / Target / LG / Viewer / SInitiator 731 A-7: LS / RM = Viewer = SInitiator / Target = LG 732 A-8: LS = RM = Target = SInitiator / LG / Viewer 733 A-9: LS = LG / RM = SInitiator / Target = Viewer 735 For instance in group A-1 there are 2 physical entities (one entity 736 is the Location Server, Rule Maker, Target and Location Generator, 737 while the other entity has the roles of Viewer and Service 738 Initiator). In A-5 there are 4 different physical entities (only the 739 Rule Maker and the Target are the same). The A-6 group has different 740 entities playing the 6 roles. 742 Where possible in the use cases and scenarios in Sections 5 and 6 743 below, the classifications A-1 through A-9 will be given for each use 744 case or scenario. 746 4.3. Initial Location Computation (Classif. B-1 through B-12) 748 The location computation process contains two steps: 1) obtaining raw 749 data about the Target's location, and 2) deriving or computing the 750 Target's location using this raw data. One example of such a 751 location computation process is signal triangulation. The raw data 752 (Step 1) includes the direction a cell phone is from certain cell 753 towers and where those cell towers are located. Given this 754 information, one can compute the cell phone's location (Step 2). 756 Thus two important questions raised by the initial location 757 computation scenarios are (a) which entity has control over the raw 758 data, and (b) the site of the location computation. On the first 759 question (who has control over the raw data), there are two main 761 Cuellar, Morris, Kanai Geopriv Scenarios 15 762 likely answers: the Target's Device or the Target's (wired or 763 wireless) Access Provider (AP). In this framework, if the Target 764 cannot control the dissemination of the raw data (such as with a cell 765 phone that transmits information from a GPS chip to the wireless 766 carrier without regard to the user's preferences), then the correct 767 value would be the AP. 769 For the second question (the site of the initial location 770 computation), there are three main likely answers: the Target's 771 Device, the AP of the Target's Device, or a third party who is 772 neither the Target nor the AP. 774 In considering the use cases and scenarios set out later in this 775 document, it is important to consider which entities have access to 776 the raw data, to ensure that those entities comply with the relevant 777 Privacy Rules. 779 In addition to the two questions raised in this classification, there 780 is value in noting a third question: whether the scenario involves a 781 a Device (and Target) that are mobile or fixed. Although in many 782 (perhaps most) the functioning of the Geopriv Location Object will 783 not depend on whether a scenario if fixed or mobile, in considering 784 the scenarios it is instructive to acknowledge the existence of the 785 fixed scenarios. 787 The three questions and their possible values yield a total of 12 788 basic scenarios, as illustrated below: 790 mobility - mobility of the Device 791 raw data - who controls or has access to raw location data 792 computation - who performs the location computation 793 AP - Access Provider for the Target's Device 794 Target - the Target or the Target's Device 795 > - direction of raw data flow 796 >> - direction of processed location data flow 798 Cuellar, Morris, Kanai Geopriv Scenarios 16 800 [Class] [mobility] [raw data] [computation] 802 B-1 fixed target -->-+-- target ------->> 803 | 804 B-2 fixed +-- AP ----------->> 805 | 806 B-3 fixed +-- third party -->> 808 B-4 fixed AP ------>-+-- target ------->> 809 | 810 B-5 fixed +-- AP ----------->> 811 | 812 B-6 fixed +-- third party -->> 814 B-7 mobile target -->-+-- target ------->> 815 | 816 B-8 mobile +-- AP ----------->> 817 | 818 B-9 mobile +-- third party -->> 820 B-10 mobile AP ------>-+-- target ------->> 821 | 822 B-11 mobile +-- AP ----------->> 823 | 824 B-12 mobile +-- third party -->> 826 In general, classifications B-1 through B-6 could apply in any use 827 case or scenario involving a fixed location, and B-7 through B-12 828 could apply whenever a mobile location is involved. Thus, these 829 classifications are not useful for distinguishing between different 830 use cases and scenarions. 832 Instead, these classifications are important to consider when 833 assessing the security and privacy of the initial stages of any 834 Geopriv transaction. In designing the Geopriv protocol, it is 835 important that it be effective in all of these cases under this 836 classification scheme. 838 5. Services From a User Point of View 840 There is a huge diversity of possible location based services that 841 may be offered. This section describes a sample of the possible 842 location services, grouping them into rough and somewhat arbitrary 843 categories. Many of the services listed below will be commercial 844 services offered by network access providers or third parties. 846 Where possible, the most appropriate classification designations from 847 Section 4 above are offered for each use case. In some cases, the 848 classifications offered are not the only possible classification for 850 Cuellar, Morris, Kanai Geopriv Scenarios 17 851 the service. 854 5.1. Network Management and Computer Services 856 Most wireless service providers (which act as the Access Providers in 857 the Geopriv context) already use extensive location based services 858 for internal operations, such as location assisted handover, traffic 859 and coverage measurement, O&M related tasks, network planning, 860 network QoS improvements, improved radio resource management, etc. 861 Assuming that the information is entirely internal within a single 862 network, privacy implications are likely governed by laws or 863 contract, and many of the location services would be outside of the 864 scope of Geopriv. 866 5.1.1. Location Based Charging or Billing 868 This location based service can be used to charge users (for example, 869 for wireless access) depending on the their location. Different 870 rates may be applied at country clubs, golf courses, or shopping 871 malls. This service may apply also for instance to business groups, 872 which obtain preferential rates within corporate campuses. In many 873 cases, subscribers should be notified of the zone or billing rate 874 currently applicable, and be notified when the rate changes. 875 Depending on implementation, this type of service may or may not come 876 within the scope of Geopriv. 878 This service could arise with either the Push or Pull Models, and 879 most likely in classifications A-1, 2, 4, 5, or 8. 881 5.1.2. Enhanced Call Routing 883 This service allows user calls to be routed to the closest service 884 client based on the location of the originating and terminating point 885 of the call. The user may for instance dial a feature or service 886 code to invoke the service (*GAS for closest gas station, etc). ECR 887 services may be offered, for example, through menu driven access that 888 allows users to interactively select from a variety of services. 890 If the implementation of the location based aspects of this service 891 is entirely within a single wireless network provider, then this 892 service may not utilize Geopriv. Even within one network, however, 893 Geopriv may offer an effective way to implement this type of service. 894 Similar forms of this service offered by third parties are discussed 895 below. 897 This service could arise with either the Push or Pull Models, and 898 most likely in classification A-8. 900 Cuellar, Morris, Kanai Geopriv Scenarios 18 901 5.1.3. Ubiquitous computing applications 903 The determination of access to bandwidth, devices and information 904 sources and sinks can utilize location information. The location can 905 provide information about the devices that are available to the user, 906 which allows determination of what will be an effective means of 907 communicating with him/her. 909 This service could arise with either the Push or Pull Models, and 910 most likely in classification A-8. 912 5.2. Emergency and Security Services 914 5.2.1. Emergency Call Services 916 This location based service supplies location information to an 917 emergency service provider to assist them in their response. This 918 service is mandatory in some jurisdictions, for instance in the 919 United States for mobile voice providers (E911 service). 921 This service could arise with either the Push or Pull Models, and 922 conceivably in almost any of the classifications A-1 through A-9. 924 5.2.2. Emergency Alert and other Public Safety Services 926 Emergency Alert Services are used to notify subscribers within a 927 specific geographic location of emergency alerts, including tornado 928 or flooding warnings, evacuation instructions, police information 929 broadcast, etc. 931 This service could arise with either the Push or Pull Models, and 932 conceivably in almost any of the classifications A-1 through A-9. 934 5.2.3. Evacuation navigation service 936 In case of an emergency in a hotel, such as fire, the hotel initiates 937 a navigation service to tell its customers about the evacuation 938 routes. Each room has a mobile Device, similar to a PDA, with 939 positioning functionality. A customer leaves his room along with the 940 PDA. The system obtains customer's current location through the PDA 941 and displays the safest evacuation route on it. The hotel is the 942 Service Initiator, and both the Target and Viewer are the Device. 944 This service could arise with either the Push or Pull Models, and 945 most likely in classification A-9. 947 5.2.4. Location-based services to drivers 949 Assistance for vehicle breakdown (Emergency Roadside Service) and 950 personalized information on traffic conditions. This service may be 952 Cuellar, Morris, Kanai Geopriv Scenarios 19 953 used in complement to an enhanced call routing service, which calls 954 the nearest Emergency Roadside Service of a certain type and delivers 955 the location information of the Target to the Roadside Service. This 956 could be used for the purpose of dispatching service agents. 958 This service could arise with either the Push or Pull Models, and 959 most likely in classification A-8. 961 5.2.5. Tracking services for Security 963 The Rule Maker wants to protect his car with a location provider 964 anti-theft device or to track the position of his children (or a 965 pet). The network may provide the last known location and timestamp. 966 If information is unavailable in real-time, a reason may be provided. 968 This service could arise most likely under the Pull Model, but most 969 probably under scenarios other than classifications A-1 through A-9. 971 5.3. Resource Management Services 973 5.3.1. Tracking services for Resource Management 975 This service allows the tracking of location and status of specific 976 service group users. One example is a supervisor in the role of Rule 977 Maker and main Location Recipient who manages a delivery service and 978 needs to know the location and status of employees. The supervisor 979 may also be able to relay messages to the employees or other people 980 involved in the service (for instance, customers). Another example 981 is an enterprise tracking the location of vehicles (cars, trucks, 982 etc.) and use location information to optimize services (Fleet 983 Management). 985 This service could arise most likely under the Pull Model, and most 986 likely in classification A-6. 988 5.3.2. Package Tracking 990 A delivery company (Rule Maker) launches a service to notify a 991 customer 'C' (Viewer) about a package 'B' (Target) that it is now at 992 the closest hub. The sighting might be triggered by an employee of 993 the delivery company, or by the sender or the receiver of the 994 package. 996 This service could arise with either the Push or Pull Models, and 997 most likely in classification A-6. 999 5.3.3. Taxi dispatch system - location of the customer 1001 Cuellar, Morris, Kanai Geopriv Scenarios 20 1002 A customer calls a taxi company for a taxi by his cellular. A 1003 dispatch operator initiates their taxi dispatch system to find the 1004 most appropriate taxi. First, the system obtains customer's current 1005 location from a Location Generator (maybe a cellular carrier). Then 1006 it searches the closest and available taxi based on location 1007 information that he has. When it finds one, it displays a map around 1008 the customer to the taxi driver. 1010 This service could arise most likely under the Pull Model, and most 1011 likely in classifications A-1, 2, 4, or 5. 1013 5.3.4. Taxi dispatch system - location of the taxi 1015 After a customer calls a taxi company for a taxi and the dispatch 1016 operator already knows his location, it searches the closest and 1017 available taxi based on location information. This is an particular 1018 example of a Target Information Disclosure Service. This kind of 1019 service inputs Location Information and outputs a Target ID (or 1020 processed information). In our case the Location Server should have 1021 a functionality to obtain a Target ID (a taxi) by using the Location 1022 Information of the customer. When it finds a taxi, it displays a map 1023 around the customer to the taxi driver 1025 Note: the location of the customer is sent or the taxi, but the 1026 location of the taxi is sent (by LG) to the Operator, the taxi knows 1027 his own location. 1029 This service could arise most likely under the Pull Model, and most 1030 likely in classifications A-1, 2, 4, 5, or 7. 1032 5.4. Geographic Based Content Services 1034 Location based information services allow subscribers to access 1035 information for which the information is filtered and tailored based 1036 on the location of the requesting user. Subscribers will likely 1037 initiate service requests on demand, but such services may be 1038 triggered automatically when certain user-set conditions are met. 1040 5.4.1. Navigation 1042 The purpose of the navigation application is to provide directions to 1043 guide the target to his/her destination. Depending on the context 1044 this could be driving or walking directions, traffic update, public 1045 transport services, or others. The information may be in the form of 1046 plain text, SMS messages, symbols with text information (e.g. 1047 distances and turns), voice, or symbols on a map display. 1049 For example, a user is driving a car with a navigation Device which 1050 can access to the Internet. He initiates an online navigation 1051 service from the Device to get the fastest route to his destination. 1053 Cuellar, Morris, Kanai Geopriv Scenarios 21 1054 The online system obtains his location with the Device. Then 1055 searches traffic information around him and finds the fastest route. 1056 And it shows a direction on his Device. 1058 This service could arise most likely under the Translate/Query Model, 1059 and most likely in classification A-3. 1060 5.4.2. City Sightseeing 1062 City Sightseeing would enable the delivery of location specific 1063 information to a tourist. Such information might describe historical 1064 sites, providing navigation directions between sites, facilitate 1065 finding the nearest museum, bank, airport, bus terminal, restroom 1066 facility, etc. 1068 This service could arise most likely under the Translate/Query Model, 1069 and most likely in classification A-3. 1071 5.4.3. Mobile Yellow Pages 1073 Mobile Yellow Pages services provide the user with the address and 1074 phone number of the nearest location of a certain type or all 1075 locations within a chosen area (e.g. all Chinese restaurants within 1076 three kilometers). 1078 The information can be provided to the users in text format (e.g. 1079 name of the restaurant, address and telephone number) or in graphical 1080 format (map showing the location of the user and the restaurants). 1082 This service could arise most likely under the Translate/Query Model, 1083 and most likely in classification A-3. 1085 5.4.4. Traffic Monitoring 1087 Mobiles in automobiles on freeways may be sampled to determine 1088 average velocity of vehicles. 1090 This service could arise most likely under the Pull Model, and most 1091 likely in classifications A-1, 2, 4, or 5. 1093 5.4.5. Traffic jam information 1095 This is a particular case of an Area Information Disclosure Service. 1096 This service type, a variant of the Target Information Disclosure 1097 Services, comprehends services which input Area information, instead 1098 of Location, and output a Target ID (or processed information). 1100 A traffic information system inputs area information (e.g. location 1101 with range) to a Location Server. Then the Location Server returns 1102 number of targets which are within the area right now. 1104 This service could arise most likely under the Pull Model, but most 1105 probably under scenarios other than classifications A-1 through A-9. 1107 Cuellar, Morris, Kanai Geopriv Scenarios 22 1108 5.5. Content Provider-Initiated Information Services 1110 Another form of location based information services can transmit 1111 information to users based on their location, but at the request or 1112 initiation of entities other than the user. Users will likely need 1113 to subscribe or opt in to the services (and thus the services are in 1114 some ways user initiated). The delivery of such services may be 1115 triggered automatically when certain user-set conditions are met. 1117 5.5.1. Location Dependent Content Broadcast 1119 The main characteristic of this service category is that the network 1120 automatically broadcasts information to terminals in a certain 1121 geographical area. The information may be broadcast to all terminals 1122 in a given area, or only to members of specific group (perhaps only 1123 to members of a specific organization). The user may disable the 1124 functionality totally from the terminal or select only the 1125 information categories that the user is interested in. An example of 1126 such a service may be localized advertising; merchants could 1127 broadcast coupons and advertisements to people passing by. 1129 This service could arise most likely under the Push Model, but most 1130 probably under scenarios other than classifications A-1 through A-9. 1132 5.6. Entertainment and Community Services 1134 The services in this subsection could arise with either the Push, Pull, 1135 or Translate/Query Models, and conceivably in almost any of the 1136 classifications A-1 through A-9. 1138 5.6.1. Mobile Communities or Locate a Person 1140 Find friends or share my position with my friends and interact 1142 5.6.2. Gaming 1144 Play games based on playersÆ location. 1145 5.6.3. Rendezvous service 1147 A user initiates a rendezvous service from his cellular. The system 1148 obtains his current location from a Location Generator, maybe a 1149 cellular carrier. The system sends his friend an e-mail to describe 1150 how to reach him. 1152 6. Scenarios 1154 Cuellar, Morris, Kanai Geopriv Scenarios 23 1155 6.1. Scenario 1 1157 Target Seeks Own Location with GPS Device with Computing Power 1159 In this very simple example, the Target wishes to know his/her 1160 location using GPS, and has a device that is capable of processing 1161 the raw data to determine a useful location. The location is derived 1162 as follows: the device receives transmissions from GPS satellites, 1163 and internally computes and displays the location. This is a wholly 1164 closed system. 1166 One Way GPS Satellites 1167 | 1168 V 1169 +---------------------------------------------+ 1170 | GPS Device with processing power: | 1171 | | 1172 | Rule Maker = Target = Location Recipient | 1173 | = Viewer | 1174 | | 1175 +---------------------------------------------+ 1177 In this closed system no external entity is granted access to 1178 location information. This minimizes the privacy concerns. But, 1179 because the device can be lost, stolen or accessed through legal 1180 process, questions about data retention and data security remain. 1181 What information is stored on the device? For how long? What 1182 security protects it? 1184 This scenario could arise most likely under the Translate/Query 1185 Model, but most probably under scenarios other than classifications 1186 A-1 through A-9. 1188 6.2. Scenario 2 1190 Target Seeks Own Location with GPS Device with No Computing Power 1192 In this example (an instance of B-8 or B-9), usable Location 1193 Information is computed by an outside entity based on GPS data. In 1194 this example, the outside entity is NOT the wireless carrier 1195 providing network access, but is instead a third party. The location 1196 is derived as follows: the Device receives GPS transmissions, and 1197 sends (using the wireless carriers network, which acts as a simple 1198 Data Transporter) the raw data to a third party Location Server. 1199 That server processes the data and sends it back to the Device. The 1200 third party Location Server may or may not store the Location 1201 Information for later use in accordance with the Privacy Rules set by 1202 the Rule Maker. 1204 Cuellar, Morris, Kanai Geopriv Scenarios 24 1205 One Way GPS Satellites 1206 | 1207 V 1208 +--------------------------+ +-----------+ 1209 | GPS Device: | 1. Raw GPS Data | Wireless | 1210 | | ---------------------> | Carrier: | 1211 | Rule Maker = Target = | | | 1212 | Location Recipient | | Data | 1213 | = Viewer | <--------------------- | Trans- | 1214 | | 4. Location Inform. | porter | 1215 +--------------------------+ +-----------+ 1216 2. Raw | ^ 3. 1217 Data | | Loc. 1218 | | Inf. 1219 V | 1220 +-------------------------------+ 1221 | Third Party Service Provider: | 1222 | | 1223 | Location Server | 1224 | | 1225 +-------------------------------+ 1227 The same concerns raised in Scenario 6.1 (about the security of 1228 information contained in the Device) remain. A host of additional 1229 concerns are raised, including about the security of information as 1230 it passes through the Data Transporter. The most significant 1231 additional concerns are about the third party Location Server, 1232 including the length of data retention, the ability to reuse and 1233 disclose, and the security of any data storage. 1235 This scenario could arise most likely under the Translate/Query 1236 Model, but most probably under scenarios other than classifications 1237 A-1 through A-9. 1239 6.3. Scenario 3 1241 Fleet Owner Seeks Location of Rental Cars with GPS Device 1243 In this example (an instance of classification B-9), a rental car 1244 company wants to track its vehicles using GPS, solely for purposes of 1245 fleet management (and not as a service to the rental customer). The 1246 Target is the rental car and the Unintended Target is the driver. 1247 The location of the Target (and the Unintended Target as well) is 1248 derived as follows: the rental car receives GPS transmissions, and on 1249 a regular basis transmits the raw GPS data via a wireless network to 1250 a third party Location Server, which in turn determines the Location 1251 Information in a useful format and forwards that LI to the car rental 1252 company. 1254 Cuellar, Morris, Kanai Geopriv Scenarios 25 1255 One Way GPS Satellites 1256 | 1257 V 1258 +--------------------------+ +-----------+ 1259 | GPS Device: | 1. Raw GPS Data | Wireless | 1260 | | ---------------------> | Carrier: | 1261 | Rental Car = Target | | | 1262 | | | Data | 1263 | Driver = Unintended | | Trans- | 1264 | Target | | porter | 1265 +--------------------------+ +-----------+ 1266 2. Raw | 1267 Data | 1268 | 1269 V 1270 +-----------------------+ +-----------------------+ 1271 | Rental Car Company | 3. Location | Third Party | 1272 | | Information | Service Provider: | 1273 | Rule Maker = Viewer |<--------------| | 1274 | | | Location Server | 1275 +-----------------------+ +-----------------------+ 1277 All of the same concerns raised in Scenario 6.2 are raised here, plus 1278 additional concerns (in particular concerning the threat to the 1279 privacy of the Unintended Target, the car rental customer driving the 1280 rental car). That threat is reduced (but far from eliminated) if the 1281 information transmitted to the third party Location Server does not 1282 carry any identifier related to the customer/driver. In general, the 1283 threats to the Unintended Target are outside the scope of Geopriv, 1284 but the risk to the Unintended Target nevertheless warrants note. 1286 This scenario could arise most likely under the Pull Model, and most 1287 likely in classification A-6. 1289 6.4. Scenario 4 1291 Target in Fixed Location Purchases Regionally Restricted Content 1293 In this example (an instance of classification B-5), the Target has 1294 in his or her home a desktop computer continuously connected to the 1295 Internet over a wire-line DSL connection. The Target seeks to 1296 purchase certain audio or video content from a World Wide Web based 1297 content provider. For contractual or legal reasons, the content 1298 provider will only sell the content to users located in a particular 1299 country or region. The content provider (as the Location Recipient) 1300 requests that the Target's Access Provider (the Target's DSL ISP) 1301 provide the Target's Location to the content provider. 1303 Cuellar, Morris, Kanai Geopriv Scenarios 26 1304 +------------------------+ +-----------+ 1305 | Home Computer: | 1. Content Request | DSL | 1306 | | ------------------>| Provider | 1307 | Rule Maker = Target | | | 1308 | | | Location | 1309 | | <----------------- | Server | 1310 | | 6. Content | | 1311 +------------------------+ +-----------+ 1312 | ^ | ^ 1313 | | | | 1314 | | | | 1315 +---------------------+ 2. Content Request | | | | 1316 | Content Provider: | <-----------------------/ | | | 1317 | | 3. Location Request | | | 1318 | Location Recipient | ---------------------------/ | | 1319 | Location | 4. Location Information | | 1320 | Recipient | <-----------------------------/ | 1321 | | 5. Content | 1322 | | ---------------------------------/ 1323 +---------------------+ 1325 This scenario could arise with either the Push or Pull Models, and 1326 most likely in classifications A-1, 2, 4, 5, or 8. 1328 6.5. Scenario 5 1330 Third Party Seeks Location of Target with Device with Computing Power 1331 and Location Awareness 1333 In this case, a mobile node (laptop or handheld) is at the same time 1334 is the Target, Rule Maker, Location Server, and Location Generator. 1335 The mobile node knows or discovers its own position using a GPS 1336 mechanism, a manual input from the user, or a co-located sensor that 1337 recognizes the relative position of some active badges or other 1338 reference points. An application running in the mobile node delivers 1339 its location to some Viewers. 1341 A Viewer that wants to know the position of the mobile node sends a 1342 Location Requests to the application running on the mobile node. 1343 After authenticating the Location Recipient, the application checks 1344 which Rule rule matches, translates the location information to the 1345 appropriate form and sends back this Filtered Location Information to 1346 the Viewer. 1348 Cuellar, Morris, Kanai Geopriv Scenarios 27 1349 +--------------------------+ +-----------+ 1350 | Smart Mobile Device: | 2. Location Request | Wireless | 1351 | | <--------------------- | Carrier: | 1352 | Rule Maker = Target = | | | 1353 | Location Generator = | | Data | 1354 | Location Server | ---------------------> | Trans- | 1355 | | 3. Location Inform. | porter | 1356 +--------------------------+ +-----------+ 1357 4. Loc. | ^ 1. 1358 Inf. | | Loc. 1359 | | Req. 1360 V | 1361 +-------------------------------+ 1362 | Requesting entity: | 1363 | | 1364 | Location Recipient = | 1365 | Viewer | 1366 | | 1367 +-------------------------------+ 1369 Notice that in this case the Rules are only for internal use of the 1370 mobile node and as such do not have to be standardized. Only the 1371 interface to the Viewers has to be standardized. The Location 1372 Recipient, however, must obey the Rule Maker's Privacy Rules, which 1373 are either conveyed or referenced in the Location Object 1375 This scenario could arise most likely under the Pull Model, and most 1376 likely in classifications A-1 or 4. 1378 6.6. Scenario 6 1380 Third Party Seeks Location of Target with Device with Computing Power 1381 But No Location Awareness 1383 This scenario is very similar to the prior one, but instead of the 1384 mobile node discovering his position by himself, it requests its 1385 wireless carrier (its Access Provider) to determine the location of 1386 the mobile note (the Device), and send it back to the mobile node for 1387 service to the Viewer. 1389 Cuellar, Morris, Kanai Geopriv Scenarios 28 1390 +------------------+ +---------------------+ 1391 | Mobile Device: | 2. Location Request | Wireless Carrier | 1392 | | <--------------------- | | 1393 | | 3. Location Request | Data Transporter | 1394 | Rule Maker = | ---------------------> | for 1-2, 5-6 | 1395 | Target = | 4. Location Inform. | | 1396 | Location | <--------------------- | Location Gen. & | 1397 | Server | 5. Location Inform. | Server for 3-4 | 1398 | | ---------------------> | | 1399 +------------------+ +---------------------+ 1400 6. Loc. | ^ 1. 1401 Inf. | | Loc. 1402 | | Req. 1403 V | 1404 +-------------------------------+ 1405 | Requesting entity: | 1406 | | 1407 | Location Recipient = | 1408 | Viewer | 1409 | | 1410 +-------------------------------+ 1412 Notice that in this scenario no Location Recipient exists, besides 1413 the Rule Maker and the Viewers served by the Rule Maker. Thus, the 1414 Rule Maker is in full control of its private information. 1416 There is a significant privacy concern raised by the uncertainty of 1417 how the Rule Maker makes sure that the Location Generator (here, the 1418 Access Provider) does not provide location information to other 1419 location recipients. Either the AP is aware of the full Rules of the 1420 owner, or a default (set by law, contract, or protocol design) 1421 prohibits disclosure. A precise requirement should be formulated to 1422 guarantee this privacy protection. 1424 Another concern is that, depending on the sensing infrastructure and 1425 its trusts relationships to the user, authenticating the supplied 1426 location information is difficult for the following reasons: 1428 o some sensor systems only detect active badges that can be 1429 removed from the mobile object they represent. 1431 o sensor systems are not equipped with proper keys or key 1432 distribution software. 1434 This scenario could arise most likely under the Pull Model, and most 1435 likely in classifications A-2 or 5. 1437 6.7. Scenario 7 1439 Target with Location Aware Device Using Third Party Location Server 1440 to Obtain Location Based Service From a Fourth Party Service Provider 1442 Cuellar, Morris, Kanai Geopriv Scenarios 29 1443 In this case, a mobile node (laptop or handheld) is at the same time 1444 is the Target, Rule Maker, Location Server, and Location Generator. 1445 The mobile node knows or discovers its own position using a GPS 1446 mechanism, a manual input from the user, etc., and periodically sends 1447 that location to a third party Location Server with which the Rule 1448 Maker has a prior contractual arrangement. The Target sends the 1449 Location Server its Privacy Rules in advance. When the Target then 1450 seeks a location service, it requests the service from the service 1451 provider. The service provider requests the Target's location from 1452 the Location Server, and then fills the Target's request for a 1453 service. 1455 +----------------------+ Periodically Sent +-----------------+ 1456 | Mobile Device: | b. Location Inform. | Wireless | 1457 | | ---------------------> | Carrier: | 1458 | Rule Maker = Target | | | 1459 | | 1. Service Request | Data | 1460 | | ---------------------> | Transporter | 1461 | | 6. Location Service | | 1462 | | <--------------------- | | 1463 +----------------------+ +-----------------+ 1464 | | | | 1465 | a. Privacy Rules | | | 1466 | (sent external to | | | 1467 | and in advance of | | | 1468 | location service | | | 1469 | transaction) Periodically | | | 1470 V Sent Location| | | 1471 +--------------------------+ c. Information | | | 1472 | Third Party Location | <---------------/ | | 1473 | Server: | | | 1474 | | | | 1475 | Location Server | | | 1476 | | | | 1477 +--------------------------+ | | 1478 ^ | | | 1479 3. Location | | 4. Location | | 1480 Request | | Information | | 1481 | V | | 1482 +---------------------+ | | 1483 | Location Service | 2. Service Request | | 1484 | Provider | <-----------------------/ | 1485 | | | 1486 | Location Recipient | 5. Location Service | 1487 | = Viewer | ---------------------------/ 1488 +---------------------+ 1490 This scenario could arise most likely under the Pull Model, but most 1491 probably under scenarios other than classifications A-1 through A-9. 1493 Cuellar, Morris, Kanai Geopriv Scenarios 30 1494 6.8. Scenario 8 1496 Target with Non-Aware Device Using Third Party Location Server to 1497 Obtain Location Based Service From a Fourth Party Service Provider 1499 This final scenario is the same as the prior scenario except that the 1500 Target's Device does NOT know its location and must instead have its 1501 Location Server ask for its location from the Target's Access 1502 Provider: 1504 +----------------------+ +-----------------+ 1505 | Mobile Device: | | Wireless | 1506 | | | Carrier: | 1507 | Rule Maker = Target | | Data Transport | 1508 | | 1. Service Request | for 1-2,7-8 | 1509 | | ---------------------> | Location Gen. | 1510 | | 8. Location Service | Server for 4-5 | 1511 | | <--------------------- | | 1512 +----------------------+ +-----------------+ 1513 | ^ | | ^ 1514 | a. Privacy Rules | | | | 1515 | (sent external to | | | | 1516 | and in advance of | | | | 1517 | location service | | | | 1518 | transaction) | | | | 1519 V | | | | 1520 +--------------------------+ 4. Loc. Request | | | | 1521 | Third Party Location | ----------------/ | | | 1522 | Server: | | | | 1523 | | 5. Location | | | 1524 | Location Server | Information | | | 1525 | | <------------------/ | | 1526 +--------------------------+ | | 1527 ^ | | | 1528 3. Location | | 6. Location | | 1529 Request | | Information | | 1530 | V | | 1531 +---------------------+ | | 1532 | Location Service | 2. Service Request | | 1533 | Provider | <--------------------------/ | 1534 | | | 1535 | Location Recipient | 7. Location Service | 1536 | = Viewer | ------------------------------/ 1537 +---------------------+ 1539 Note that the Access Provider also acts as a Location Server to 1540 provide the initial Location Sighting to the third party Location 1541 Server, which then in turn fills the request for location. 1543 This scenario could arise most likely under the Pull Model, but most 1544 probably under scenarios other than classifications A-1 through A-9. 1546 Cuellar, Morris, Kanai Geopriv Scenarios 31 1547 7. Implications and Conclusions 1549 Critical privacy issues illustrated by the location computation 1550 scenarios are who controls the data and how, who computes or derives 1551 the location information, and who stores uses and discloses the data. 1553 All examples apart from the closed system represented by Scenario 1 1554 present many privacy issues. The more entities involved, the more 1555 difficult it is to make sure the Privacy Rules of the Rule Maker are 1556 implemented. In cases where there is a pre-existing relationship, 1557 technology may not be necessary to transmit Privacy Rules. Instead, 1558 the Rule Maker and AP might reach a contractual agreement about 1559 privacy. But, the Rule Maker will not always have a contractual 1560 relationship with the AP or all involved entities. In some instances 1561 the Target will have no choice but to use a single AP. Sometimes "a 1562 chain" from the AP to other entities to enforce the Privacy Rules may 1563 work. Therefore, technologies that address these issues must be 1564 developed. 1566 Entities may be constrained by national or local laws regarding how 1567 they handle information. For example, in some relevant situations 1568 within some countries, "Customer Proprietary Network Information" 1569 (CPNI) rules require that telecommunications carriers obtain customer 1570 approval before using, disclosing, or permitting access to 1571 individually identifiable CPNI. 1573 8. Security Considerations 1575 The purpose of the Geopriv Location Object is to allow a Rule- 1576 controlled disclosure of location information for location services. 1577 The information carried within the Location Object is secured in a 1578 way compliant with the privacy and security Rules of the Rule Maker, 1579 but other information, carried in other objects or headers are in 1580 general not secured in the same way. The scenarios included in this 1581 draft can serve to illustrate security concerns that must be 1582 addressed by Geopriv. 1584 9. Acknowledgements 1586 Important elements of this draft were inspired by a prior scenarios 1587 draft by Kenji Takahashi and his colleagues. 1589 10. References 1591 [ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/. 1593 [OECD] OECD Guidelines on the Protection of Privacy and Transborder 1594 Flows of Personal Data, http://www.oecd.org. 1596 Cuellar, Morris, Kanai Geopriv Scenarios 32 1598 [Pfi01] Pfitzmann, Andreas; K÷hntopp, Marit: Anonymity, 1599 Unobservability, and Pseudonymity - A Proposal for Terminology; 1600 in: H Federrath (Ed.): Designing Privacy Enhancing Technologies; 1601 Proc. Workshop on Design Issues in Anonymity and Unobservability; 1602 LNCS 2009; 2001; 1-9. Newer versions available at 1603 http://www.koehntopp.de/marit/pub/anon 1605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1606 Requirement Levels", BCP 14, RFC 2119, March 1997 1608 11. Author's Addresses 1610 Jorge R. Cuellar 1611 Siemens AG 1612 Otto-Hahn Ring 6 1613 81730 Munich Email: jorge.cuellar@mchp.siemens.de 1614 Germany 1616 John B. Morris, Jr. 1617 Director, Internet Standards, Technology & Policy Project 1618 Center for Democracy and Technology 1619 1634 I Street NW, Suite 1100 1620 Washington, DC 20006 Email: jmorris@cdt.org 1621 USA 1623 Tsuyoshi Go Kanai 1624 Fujitsu Laboratories, Ltd. 1625 64 Nishiwaki, Okubo-cho, 1626 Akashi 674-8555 Email: kanai.go@jp.fujitsu.com 1627 Japan 1629 12. Full Copyright Statement 1631 Copyright (C) The Internet Society (date). All Rights Reserved. 1633 This document and translations of it may be copied and furnished to 1634 others, and derivative works that comment on or otherwise explain it 1635 or assist in its implementation may be prepared, copied, published 1636 and distributed, in whole or in part, without restriction of any 1637 kind, provided that the above copyright notice and this paragraph are 1638 included on all such copies and derivative works. However, this 1639 document itself may not be modified in any way, such as by removing 1640 the copyright notice or references to the Internet Society or other 1641 Internet organizations, except as needed for the purpose of 1642 developing Internet standards in which case the procedures for 1643 copyrights defined in the Internet Standards process must be 1644 followed, or as required to translate it into languages other than 1645 English. 1647 Cuellar, Morris, Kanai Geopriv Scenarios 33 1648 The limited permissions granted above are perpetual and will not be 1649 revoked by the Internet Society or its successors or assigns. 1651 This document and the information contained herein is provided on an 1652 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1653 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1654 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1655 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1656 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1658 Cuellar, Morris, Kanai Geopriv Scenarios 34