Internet Draft J. Cuellar Document: draft-cuellar-geopriv-scenarios-03.txt Siemens AG J. Morris Center for Democracy & Technology T. Kanai Fujitsu Laboratories Expires in six months Mar 2003 Geopriv Scenarios and Use Cases Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes location-based service scenarios for Geopriv. It complements the Geopriv Requirements document by providing a set of examples in which the Geopriv Location Object (LO) may be used. Thus this documents serves as a basis to discuss and analyze the security (authentication, authorization, integrity and confidentiality) and privacy issues and requirements associated with location-based services. To be useful, these scenarios include details of location computation, which helps to identify the entities involved on an abstract level and where privacy issues like control, consent, access, and security arise. Cuellar, Morris, Kanai Geopriv Scenarios 1 Expires in six months Mar 2003 Table of Contents 1. Overview........................................................3 2. Conventions used in this document...............................4 3. Terminology.....................................................4 3.1. Foundational Definitions...................................4 3.1.1. Location Information (LI) and Sighting................4 3.1.2. The Location Object...................................5 3.1.3. Location Object vs. Using Protocol....................6 3.1.4. Trusted vs. Non-trusted Data Flows....................6 3.2. Geopriv Entities and Functions.............................7 3.2.1. Primary Geopriv Entities..............................7 3.2.2. Secondary Geopriv Entities............................8 3.2.3. Geopriv Data Storage Functions........................9 3.3. Privacy Rules..............................................9 3.4. Identifiers, Authentication and Authorization.............10 3.4.1. Identifiers..........................................11 3.4.2. Authentication.......................................11 3.4.3. Authorization........................................12 4. Three Frameworks to Classify Use Cases and Scenarios...........12 4.1. Classifications "Push", "Pull", and "Translate/Query".....13 4.1.1. Push Model...........................................13 4.1.2. Pull Model...........................................13 4.1.3. Translate/Query Model................................14 4.2. Overlap of Geopriv Roles (Classif. A-1 through A-9).......15 4.3. Initial Location Computation (Classif. B-1 through B-12)..15 5. Services From a User Point of View.............................17 5.1. Network Management and Computer Services..................18 5.1.1. Location Based Charging or Billing...................18 5.1.2. Enhanced Call Routing................................18 5.1.3. Ubiquitous computing applications....................19 5.2. Emergency and Security Services...........................19 5.2.1. Emergency Call Services..............................19 5.2.2. Emergency Alert and other Public Safety Services.....19 5.2.3. Evacuation navigation service........................19 5.2.4. Location-based services to drivers...................19 5.2.5. Tracking services for Security.......................20 5.3. Resource Management Services..............................20 5.3.1. Tracking services for Resource Management............20 5.3.2. Package Tracking.....................................20 5.3.3. Taxi dispatch system - location of the customer......20 5.3.4. Taxi dispatch system - location of the taxi..........21 5.4. Geographic Based Content Services.........................21 5.4.1. Navigation...........................................21 5.4.2. City Sightseeing.....................................22 5.4.3. Mobile Yellow Pages..................................22 Cuellar, Morris, Kanai Geopriv Scenarios 2 Expires in six months Mar 2003 5.4.4. Traffic Monitoring...................................22 5.4.5. Traffic jam information..............................22 5.5. Content Provider-Initiated Information Services...........23 5.5.1. Location Dependent Content Broadcast.................23 5.6. Entertainment and Community Services......................23 The services in this subsection could arise with either the Push, Pull, or Translate/Query Models, and conceivably in almost any of the classifications A-1 through A-9...........23 5.6.1. Mobile Communities or Locate a Person................23 5.6.2. Gaming...............................................23 5.6.3. Rendezvous service...................................23 6. Scenarios......................................................23 6.1. Scenario 1................................................24 6.2. Scenario 2................................................24 6.3. Scenario 3................................................25 6.4. Scenario 4................................................26 6.5. Scenario 5................................................27 6.6. Scenario 6................................................28 6.7. Scenario 7................................................29 6.8. Scenario 8................................................31 7. Implications and Conclusions...................................32 8. Security Considerations........................................32 9. Acknowledgements...............................................32 10. References....................................................32 11. Author's Addresses............................................33 12. Full Copyright Statement......................................33 1. Overview Location based systems are an emerging field, and all possible services or relationships cannot be identified or even imagined today. Over the next few years, location based services and applications are likely to come in a huge array of shapes, sizes, structures, paradigms, and approaches. This document attempts to articulate the range and types of applications that are possible using location services, although the use cases and scenarios below are unavoidably incomplete. This document includes 4 main sections below. Section 3 contains terminology and definitions, largely drawn from the similar section in the Geopriv Requirements draft. Section 4 advances three different and incomplete (individually or collectively) analytical frameworks with which to consider Geopriv uses and scenarios. Section 5 lists, and briefly discusses, a range of possible use cases. Section 6 looks at a subset of these use cases diagrammatically, in an effort to identify the entities and data flows involved. Cuellar, Morris, Kanai Geopriv Scenarios 3 Expires in six months Mar 2003 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 3. Terminology The terminology and definitions detailed below include both (1) primary or essential terms used in the Requirements document, and (2) secondary terms that provide additional detail about the usage model envisioned for the Geopriv Location Object. Most of the definitions below are drawn directly from the Requirements Document. The focus of that document, however, is on the requirements for the Geopriv Location Object. This document, in contrast, looks more broadly at Geopriv scenarios and data flows. It thus uses some additional terms not used in the Requirements Document. These additional terms are indicated by a "Not in Requirements Document" designation. 3.1. Foundational Definitions 3.1.1. Location Information (LI) and Sighting The focus of the Geopriv working group is on information about a Target's location that is NOT based on generally or publicly available sources, but instead on private information provided or created by a Target, a Target's Device, or a Target's network or service provider. Notwithstanding this focus on private location information, the Geopriv Location Object could certainly be used to convey location information from publicly available sources. Location Information (LI): A relatively specific way of describing where a Device is located. In general, Location Information is (a) derived or computed from information generally not available to the general public (such as information mainly available to a network or service provider), (b) determined by a Device that may be not generally publicly addressable or accessible, or (c) input or otherwise provided by a Target. As examples, LI could include (a) information calculated by triangulating on a wireless signal with respect to cell phone towers, (b) longitude and latitude information determined by a Device with GPS (global positioning satellite) capabilities, (c) information manually entered into a cell phone or laptop by a Target in response to a query, or (d) automatically delivered by some other IP protocol, such as at device configuration via DHCP. Cuellar, Morris, Kanai Geopriv Scenarios 4 Expires in six months Mar 2003 Excluded from this definition is the determination of location information wholly without the knowledge or consent of the Target (or the Target's network or access service provider), based on generally available information such as an IP or e-mail address. In some cases information like IP address can enable someone to estimate (at least roughly) a location. Commercial services exist that offer to provide rough location information based on IP address. Currently, this type of location information is typically less precise and has a coarser granularity than the type of location information addressed in this document. Although this type of location computation still raises significant potential privacy and public Policy concerns, such scenarios are generally outside the scope of this document. Within any given location-based transaction, the INITIAL determination of location (and thus the initial creation of Location Information) is termed a Sighting: Sighting: The initial determination of location based on non-public information (as discussed in the definition of Location Information), and the initial creation of Location Information. Some variant of the sighting information is included in the Location Object. Abstractly, it consists of two separate data fields: (Identifier, Location) where Identifier is the identifier assigned to a Target being sighted, and Location is the current position of that Target being sighted. Not all entities may have access to exactly the same piece of sighting information. A sighting may be transformed to a new sighting pair: (Identifier-1, Location-1) before it is provided by a Location Generator or Location Server to another Location Recipient (for instance, another Location Server). In this case, Identifier-1 may be Pseudonym, and Location-1 may have less accuracy or granularity than the original value. 3.1.2. The Location Object A main goal of the Geopriv working group is to define a Location Object (LO), to be used to convey both Location Information and basic privacy-protecting instructions: Location Object (LO): This data contains the Location Information of the Target, and other fields including an identity or pseudonym of the Target, time information, core Privacy Rules, authenticators, etc. Most of the fields are optional, including the Location Information itself. Cuellar, Morris, Kanai Geopriv Scenarios 5 Expires in six months Mar 2003 Nothing is said about the semantics of a missing field. For instance, a partially filled object MAY be understood implicitly as the request to complete it. Or, if no time information is included, this MAY implicitly mean "at the current time" or "at a very recent time", but it could be interpreted in a different way, depending on the context. 3.1.3. Location Object vs. Using Protocol The security and privacy enhancing mechanisms used to protect the LO are of two types: First, the Location Object definition MUST include (optional) fields or mechanisms used to secure the LO as such. The LO MAY be secured, for example, using cryptographic checksums or encryption as part of the LO itself. Second, the "using protocol" (that is, the protocol that uses the Location Object) may also provide security mechanisms to securely transport the Location Object. The "using protocol" is the protocol that uses (creates, reads or modifies) the Location Object. A protocol that just transports the LO as a string of bits, without looking at them (like an IP storage protocol could do), is not a using protocol, but only a transport protocol. Nevertheless, the entity or protocol that caused the transport protocol to move the LO is responsible of the appropriate distribution, protection, usage, retention, and storage of the LO based on the rules that apply to that LO. The security mechanisms of the Location Object itself are to be preferred. The using protocol has to obey the privacy and security instructions coded in the Location Object and in the corresponding Privacy Rules regarding the transmission and storage of the LO in order to ensure that the rules established by the Rule-Maker are observed. Other requirements on the using protocol are out of the scope of this document. <Open Issue: "One Message" Transfer Issue. The requirements discussed in this document do not preclude a single message/packet transmission of location, but this is not an explicit requirement>. 3.1.4. Trusted vs. Non-trusted Data Flows Location information can be used in very different environments. In some cases the participants will have longstanding relationships, while in others participants may have discrete interactions with no prior contractual or other contact. The different relationships raise different concerns for the implementation of Privacy Rules, including the need to communicate Privacy Rules. A public Rule Holder, for example, may be unnecessary in a trusted environment where more efficient methods of addressing privacy issues exist. The following terms distinguish between the two basic types of data flows: Cuellar, Morris, Kanai Geopriv Scenarios 6 Expires in six months Mar 2003 Trusted Data Flow: A data flow that is governed by a pre-existing contractual relationship that addresses location privacy. Non-trusted Data Flow: The data flow is not governed by a pre-existing contractual relationship that addresses location privacy. 3.2. Geopriv Entities and Functions The entities of a Geopriv application or transaction may be given explicit roles: 3.2.1. Primary Geopriv Entities Certain entities and roles are involved in most (and in some cases all) Geopriv transactions: Target: The entity whose location is desired by the Location Recipient. In many cases the Target will be the human "user" of a Device or an object such as a vehicle or shipping container to which the Device is attached. In some instances the Target will be the Device itself. Device: The technical device the location of which is tracked as a proxy for the location of a Target. A Device might, for example, be a cell phone, a Global Positioning Satellite (GPS) receiver, a laptop equipped with a wireless access Device, or a transmitter that emits a signal that can be tracked or located. In some situations, such as when a Target manually inputs location information (perhaps with a web browser), the Target is effectively performing the function of a Device. Rule Maker (RM): The individual or entity that has the authorization to set the applicable Privacy Rules for a potential Geopriv Target. In many cases this will be the owner of the Device, and in other cases this may be the user who is in possession of the Device. For example, parents may control what happens to the location information derived from a child's cell phone. A company, in contrast, may own and provide a cell phone to an employee but permit the employee to set the Privacy Rules. Location Recipient (LR): An individual or entity who seeks to receive location data about a Target. Cuellar, Morris, Kanai Geopriv Scenarios 7 Expires in six months Mar 2003 A Location Recipient may act in one or more of the following more specialized roles: as the Location Generator, a Location Server, or as a Viewer: Location Generator (LG): The LG is an element responsible for creating the Location Object for a specific Target. LGs publish Location Objects to Location Servers. The manner in which the Location Generator learns of Location Information is outside the scope of the Geopriv protocol. Location Server (LS): The LS is an element that receives publications of Location Objects from Location Generators and may receive subscriptions from Location Recipients. The LS applies the rules (which it learns from the Rule Holder) to LOs it receives from LGs, and then notifies LRs of resulting LOs as necessary. Some location tracking scenarios may involve a Target, Device, or Device user performing the function of a Location Server. Viewer (Viewer): An individual or entity who receives location data about a Target and does not transmit the location information or information based on the Target's location (such as driving directions to or from the Target) to any party OTHER than the Target or the Rule Maker. 3.2.2. Secondary Geopriv Entities Certain entities and functions are present or involved in only a subset of Geopriv transactions: Unintended Target [Not in Requirements Document]: A person or object tracked by proximity to the Target. This special case most frequently occurs if the Target is not a person. For example, the Target may be a rental car equipped with a GPS Device, used to track car inventory. The rental company may not care about the driver's location, but the driver's privacy is implicitly affected. Geopriv may or may not protect or affect the privacy of Unintended Targets, but the impact on Unintended Targets should be acknowledged. Data Transporter: An entity or network that receives and forwards data without processing or altering it. A Data Transporter could theoretically be involved in almost any transmission between a Device and a Location Server, a Location Server and a second Location Server, or a Location Server and a Viewer. Some location tracking scenarios may not involve a Data Transporter. Access Provider (AP): The domain that provides the initial network access or other Cuellar, Morris, Kanai Geopriv Scenarios 8 Expires in six months Mar 2003 data communications services essential for the operation of communications functions of the Device or computer equipment in which the Device operates. Often, the AP -- which will be a wireless carrier, an Internet Service Provider, or an internal corporate network -- contains the LG. Sometimes the AP has a "dumb" LG, one that transmits Geopriv LOs but does not use any part of the Geopriv Location Object. Other cases may not involve any AP, or the AP may only act as a Data Transporter. Service Initiator [Not in Requirements Document]: Entity that initiates the service and submits a request to disclose the Location Information to the Location Recipient. In most cases, this entity will overlap with one of the other Geopriv entities, such as the Target, the Rule Maker, or the Location Recipient. 3.2.3. Geopriv Data Storage Functions Within the Geopriv framework, certain data may be stored in various functional entities: Rule Holder (RH): The RH is an element that houses Privacy Rules for receiving, filtering and distributing Location Objects for specific Targets. A LS may query an RH for a set of rules, or rules may be pushed from the RH to an LS. The rules in the Rule Holder are populated by the Rule Maker. Private Rule Holder [Not in Requirements Document]: A non-public Rule Holder used to store private (authenticated, but not signed) or public (signed) Rules, identifiers, keys, and perhaps also requests. A Private Rule Holder could be operated by a Device, a Location Server, or a third party service provider. Public Rule Holder [Not in Requirements Document]: A public repository where signed Rules are stored. Location Storage: A Device or entity that stores raw or processed Location Information, such as a database, for any period of time longer than the duration necessary to complete an immediate transaction regarding the LI. The existence and data storage practices of Location Storage is crucial to privacy considerations, because this may influence what Location Information could eventually be revealed (through later distribution, technical breach, or legal processes). 3.3. Privacy Rules Cuellar, Morris, Kanai Geopriv Scenarios 9 Expires in six months Mar 2003 Privacy Rules are rules that regulate an entity's activities with respect to location and other information, including, but not limited to, the collection, use, disclosure, and retention of location information. Such rules are generally based on fair information practices, as detailed in (for example) the OECD Guidelines on the Protection of Privacy and Transporter Flows of Personal Data [OECD]. Privacy Rule: A rule or set of rules that regulate an entity's activities with respect to location information, including the collection, use, disclosure, and retention of location information. In particular, the Rule describes how location information may be used by an entity and which transformed location information may be released to which entities under which conditions. Rules must be obeyed; they are not advisory. A full set of Privacy Rules will likely include both rules that have only one possible technical meaning, and rules that will be affected by a locality's prevailing laws and customs. For example, a distribution rule of the form "my location can only be disclosed to the owner of such credentials and in such accuracy" has clear-cut implications for the protocol that uses the LO. But other rules, like retention or usage Rules, may have unclear technical consequences for the protocol or for the involved entities. For example, the precise scope of a retention rule stating "you may not store my location for more than 2 days" may in part turn on local laws or customs. The Privacy Rules of the Rule Maker regarding the location of the Target may be accessible to a Location Server in Private or Public Rules Repositories, or they may be carried by the Location Object, or they may be presented by the Location Recipient as capabilities or tokens: Public Rule [Not in Requirements Document]: A Rule, digitally signed by the Rule Maker, and stored in a Rule Holder for the use of one or several Location Servers. Private Rule [Not in Requirements Document]: An authenticated Rule, consented by the Rule Maker, and stored in Private Rule Storage for the private use of a limited set of Location Servers. Geopriv Token [Not in Requirements Document]: A token or ticket issued and secured (authenticated or signed) by the Rule Maker to a Location Recipient, expressing the explicit consent of the Rule Maker to access his location information. This Geopriv Token is thus, logically, a rule of the Rule Maker. 3.4. Identifiers, Authentication and Authorization Cuellar, Morris, Kanai Geopriv Scenarios 10 Expires in six months Mar 2003 This subsection introduces terms and concepts used in the Requirements Section. 3.4.1. Identifiers Anonymity is the property of being not identifiable (within a set of subjects). Anonymity serves as the base case for privacy: without the ability to remain anonymous, individuals may be unable to control their own privacy. Unlinkability ensures that a user may make multiple uses of resources or services without others being able to link these uses together. Unlinkability requires that entities are unable to determine whether the same user caused certain specific operations in the system. [ISO99]: A pseudonym is simply a bit string which is unique as ID and is suitable to be used for end-point authentication. Unlinked Pseudonym: A pseudonym where the linking between the pseudonym and its holder is, at least initially, not known to anybody with the possible exception of the holder himself or a trusted server of the user. See [Pfi01] (there the term is called Initially Unlinked Pseudonym) The use of Unlinked Pseudonyms is necessary to obtain anonymity. But also it is necessary to change the used pseudonyms regularly, because identifying the user behind an unlinked pseudonym can be very simple. In order to remain anonymous, an entity may use private identifiers. Private identifiers convey less information than public identities, because they are meaningful to a smaller number of entities and in use for a shorter duration. Thus if A discloses a private identifier to B, B is less likely to associate this information with a known individual or entity than if a public identifier was disclosed. Short-lived Identifier [Not in Requirements Document]: An identifier that is used only for one or a limited number of "sessions". Using protocols should be able to handle LOs with identifiers, LOs without identifiers, and LOs with pseudonyms. The identity of the requester may be irrelevant in some cases, whereas the identity of the Target may be irrelevant in others. Entity-Identifier [Not in Requirements Document]: The names used by the Geopriv entities to identify, authenticate or authorize themselves to other entities. Rules also use entity-identifiers to express which Location Recipients may receive which transformed sighting information. 3.4.2. Authentication Cuellar, Morris, Kanai Geopriv Scenarios 11 Expires in six months Mar 2003 The word authentication is used in different meanings. Some assert that authentication associates an entity with a more or less well- known identity. This basically means that if A authenticates another entity B as being "id-B", then the label "id-B" is not a pseudonym, but a persistent or at least linkable identity of the entity. In this case, the label "id-B" is called a publicly known identifier, and the authentication is "explicit": Explicit Authentication: The act of verifying a claimed identity as the sole originator of a message (message authentication) or as the end-point of a channel (entity authentication). Moreover, this identity is easily linked back to the real identity of the entity in question, for instance being a pre-existing static label from a predefined name space (telephone number, name, etc.). 3.4.3. Authorization Authorization The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential. Depending on the type of credential, authorization may imply Explicit Authentication or not. 4. Three Frameworks to Classify Use Cases and Scenarios There are many different ways to conceptualize or classify the possible Geopriv scenarios. Among the possible approaches can be: A. How is the location information transaction being triggered: is it a "push" or a "pull" model, or a "query" to translate a location or find a location in a context? B. What are the relevant entities, devices, and roles, and how do they interrelate and (often) overlap? C. What entity first has control over the initial sighted data, and over the initial computation and distribution of the location information? These three classifications are discussed briefly in this section. A fourth approach to considering the full range of possible Geopriv scenarios is to analyze the use cases from the user's perspective, looking at what service is bring provided from the point of view of the user. A range of these use cases are described in Section 5, with references back to the three classification schemes discussed in this section. Cuellar, Morris, Kanai Geopriv Scenarios 12 Expires in six months Mar 2003 None of these classifications alone is fully sufficient to identify the full range of possible location services. Other ways to consider the possible uses and scenarios are discussed in Section 7. 4.1. Classifications "Push", "Pull", and "Translate/Query" One classification of scenarios is according to who is the Service Initiator and whether the service triggering is done on demand or on subscription mode, and if the Rule Maker is granted positioning consent or not. A Target, Rule Maker, Location Recipient, or another party may trigger the actions, depending on the service being provided. They may be triggered on demand or as a periodical subscription (periodical updates). Also it is possible for location services to support conditional positioning. Under these conditions, an application that is granted conditional positioning authorization must notify and obtain positioning authorization from the Rule Maker of the Target prior to performing the positioning process. The Rule Maker is able to accept or reject the positioning attempt. In Japan for instance, all major mobile carriers provide the following types of well-known commercial services: 1. "Here I am!" (Subscribers may send their location information to other subscribers or to Internet users via e-mail or other means.) 2. "Where is he/she?" (Carriers tell users where someone is located.) 3. "Where am I?" service (Carriers tell subscribers where they are located on a map.) Those three correspond roughly to 3 query modes described below: Push Model, Pull Model, and Translate/Query Model. Note than many scenarios will involve both Push and Translate, or both Pull and Translate. 4.1.1. Push Model In the Push Model, the Target typically acts as the Location Initiator (instead of responding to a request). For example, after locating himself, the Target may send his location to the Viewer or another Location Recipient. Similarly, the Target may ask a Location Generator to locate the Target and transmit the location to a Viewer or other Location Recipient. 4.1.2. Pull Model In the Pull Model, a Viewer or other Location Recipient wants to know where a given Target is, and thus is the Service Initiator. As one example of the Pull Model, a Location Server: Cuellar, Morris, Kanai Geopriv Scenarios 13 Expires in six months Mar 2003 1. receives Location Information from the Location Generator or from another Location Server, 2. receives, directly or through a repository or a trusted third party, the Privacy Rules associated with the Target, 3. accepts services requests from Location Recipients (including other Location Servers), 4. matches the location request to the Rules for the Target and processes the Location Information accordingly, and 5. returns Location Information (sometimes filtered) of the Target. 4.1.3. Translate/Query Model Those are services where some entity (such as a Target or other Location Recipient) provides Location Information and obtains a function of that information as response. For instance, he may want to translate a location from one format to another (say from coordinates to civil), or to see in a map where certain coordinates are, or given the distance from a point to 2 or more fixed locations, to find the possible locations of the point. This service may be invoked by a mobile Target that knows where he is, or where he plans to be this afternoon, but needs additional information about the location or needs the location in a different format. In one example, a Target knows his location (say, using a GPS chip), but not in the form that he needs it (say, as a street address). In this case, the Target asks an external Location Server to translate the information to a street address or position on a map. The Location Server obtains the location from the Location Generator (which is the Target itself), converts the Location Information to the requested form, and sends it back to the Location Recipient (also the Target). Cuellar, Morris, Kanai Geopriv Scenarios 14 Expires in six months Mar 2003 4.2. Overlap of Geopriv Roles (Classif. A-1 through A-9). In many Geopriv scenarios the different entities can overlap. Sometimes a Device is a proxy for a Target, and sometimes the Device is the Target. In some cases, the Rule Maker and the Target are the same individual or entity; in other cases, they are different. If the Target/Device knows his location (through GPS, for example), the Target/Device may also be the Location Generator. If the Target's Device has the capabilities and bandwidth, that Device may serve as the Location Server, or may rely on an external Location Server. The following is an admittedly incomplete breakdown of different overlaps among the Geopriv roles (where LS stands for Location Server, LG for Location Generator, and Sinitiator for Service Initiator): A-1: LS = RM = Target = LG / Viewer = SInitiator A-2: LS = RM = Target / LG / Viewer = Sinitiator A-3: LS / RM = Target = LG = Viewer = SInitiator A-4: LS / RM = Target = LG / Viewer = SInitiator A-5: LS / RM = Target / LG / Viewer = SInitiator A-6: LS / RM / Target / LG / Viewer / SInitiator A-7: LS / RM = Viewer = SInitiator / Target = LG A-8: LS = RM = Target = SInitiator / LG / Viewer A-9: LS = LG / RM = SInitiator / Target = Viewer For instance in group A-1 there are 2 physical entities (one entity is the Location Server, Rule Maker, Target and Location Generator, while the other entity has the roles of Viewer and Service Initiator). In A-5 there are 4 different physical entities (only the Rule Maker and the Target are the same). The A-6 group has different entities playing the 6 roles. Where possible in the use cases and scenarios in Sections 5 and 6 below, the classifications A-1 through A-9 will be given for each use case or scenario. 4.3. Initial Location Computation (Classif. B-1 through B-12) The location computation process contains two steps: 1) obtaining raw data about the Target's location, and 2) deriving or computing the Target's location using this raw data. One example of such a location computation process is signal triangulation. The raw data (Step 1) includes the direction a cell phone is from certain cell towers and where those cell towers are located. Given this information, one can compute the cell phone's location (Step 2). Thus two important questions raised by the initial location computation scenarios are (a) which entity has control over the raw data, and (b) the site of the location computation. On the first question (who has control over the raw data), there are two main Cuellar, Morris, Kanai Geopriv Scenarios 15 Expires in six months Mar 2003 likely answers: the Target's Device or the Target's (wired or wireless) Access Provider (AP). In this framework, if the Target cannot control the dissemination of the raw data (such as with a cell phone that transmits information from a GPS chip to the wireless carrier without regard to the user's preferences), then the correct value would be the AP. For the second question (the site of the initial location computation), there are three main likely answers: the Target's Device, the AP of the Target's Device, or a third party who is neither the Target nor the AP. In considering the use cases and scenarios set out later in this document, it is important to consider which entities have access to the raw data, to ensure that those entities comply with the relevant Privacy Rules. In addition to the two questions raised in this classification, there is value in noting a third question: whether the scenario involves a a Device (and Target) that are mobile or fixed. Although in many (perhaps most) the functioning of the Geopriv Location Object will not depend on whether a scenario if fixed or mobile, in considering the scenarios it is instructive to acknowledge the existence of the fixed scenarios. The three questions and their possible values yield a total of 12 basic scenarios, as illustrated below: mobility - mobility of the Device raw data - who controls or has access to raw location data computation - who performs the location computation AP - Access Provider for the Target's Device Target - the Target or the Target's Device > - direction of raw data flow >> - direction of processed location data flow Cuellar, Morris, Kanai Geopriv Scenarios 16 Expires in six months Mar 2003 [Class] [mobility] [raw data] [computation] B-1 fixed target -->-+-- target ------->> | B-2 fixed +-- AP ----------->> | B-3 fixed +-- third party -->> B-4 fixed AP ------>-+-- target ------->> | B-5 fixed +-- AP ----------->> | B-6 fixed +-- third party -->> B-7 mobile target -->-+-- target ------->> | B-8 mobile +-- AP ----------->> | B-9 mobile +-- third party -->> B-10 mobile AP ------>-+-- target ------->> | B-11 mobile +-- AP ----------->> | B-12 mobile +-- third party -->> In general, classifications B-1 through B-6 could apply in any use case or scenario involving a fixed location, and B-7 through B-12 could apply whenever a mobile location is involved. Thus, these classifications are not useful for distinguishing between different use cases and scenarions. Instead, these classifications are important to consider when assessing the security and privacy of the initial stages of any Geopriv transaction. In designing the Geopriv protocol, it is important that it be effective in all of these cases under this classification scheme. 5. Services From a User Point of View There is a huge diversity of possible location based services that may be offered. This section describes a sample of the possible location services, grouping them into rough and somewhat arbitrary categories. Many of the services listed below will be commercial services offered by network access providers or third parties. Where possible, the most appropriate classification designations from Section 4 above are offered for each use case. In some cases, the classifications offered are not the only possible classification for Cuellar, Morris, Kanai Geopriv Scenarios 17 Expires in six months Mar 2003 the service. <Note: This classification is significantly incomplete in this draft.> 5.1. Network Management and Computer Services Most wireless service providers (which act as the Access Providers in the Geopriv context) already use extensive location based services for internal operations, such as location assisted handover, traffic and coverage measurement, O&M related tasks, network planning, network QoS improvements, improved radio resource management, etc. Assuming that the information is entirely internal within a single network, privacy implications are likely governed by laws or contract, and many of the location services would be outside of the scope of Geopriv. 5.1.1. Location Based Charging or Billing This location based service can be used to charge users (for example, for wireless access) depending on the their location. Different rates may be applied at country clubs, golf courses, or shopping malls. This service may apply also for instance to business groups, which obtain preferential rates within corporate campuses. In many cases, subscribers should be notified of the zone or billing rate currently applicable, and be notified when the rate changes. Depending on implementation, this type of service may or may not come within the scope of Geopriv. This service could arise with either the Push or Pull Models, and most likely in classifications A-1, 2, 4, 5, or 8. 5.1.2. Enhanced Call Routing This service allows user calls to be routed to the closest service client based on the location of the originating and terminating point of the call. The user may for instance dial a feature or service code to invoke the service (*GAS for closest gas station, etc). ECR services may be offered, for example, through menu driven access that allows users to interactively select from a variety of services. If the implementation of the location based aspects of this service is entirely within a single wireless network provider, then this service may not utilize Geopriv. Even within one network, however, Geopriv may offer an effective way to implement this type of service. Similar forms of this service offered by third parties are discussed below. This service could arise with either the Push or Pull Models, and most likely in classification A-8. Cuellar, Morris, Kanai Geopriv Scenarios 18 Expires in six months Mar 2003 5.1.3. Ubiquitous computing applications The determination of access to bandwidth, devices and information sources and sinks can utilize location information. The location can provide information about the devices that are available to the user, which allows determination of what will be an effective means of communicating with him/her. This service could arise with either the Push or Pull Models, and most likely in classification A-8. 5.2. Emergency and Security Services 5.2.1. Emergency Call Services This location based service supplies location information to an emergency service provider to assist them in their response. This service is mandatory in some jurisdictions, for instance in the United States for mobile voice providers (E911 service). This service could arise with either the Push or Pull Models, and conceivably in almost any of the classifications A-1 through A-9. 5.2.2. Emergency Alert and other Public Safety Services Emergency Alert Services are used to notify subscribers within a specific geographic location of emergency alerts, including tornado or flooding warnings, evacuation instructions, police information broadcast, etc. This service could arise with either the Push or Pull Models, and conceivably in almost any of the classifications A-1 through A-9. 5.2.3. Evacuation navigation service In case of an emergency in a hotel, such as fire, the hotel initiates a navigation service to tell its customers about the evacuation routes. Each room has a mobile Device, similar to a PDA, with positioning functionality. A customer leaves his room along with the PDA. The system obtains customer's current location through the PDA and displays the safest evacuation route on it. The hotel is the Service Initiator, and both the Target and Viewer are the Device. This service could arise with either the Push or Pull Models, and most likely in classification A-9. 5.2.4. Location-based services to drivers Assistance for vehicle breakdown (Emergency Roadside Service) and personalized information on traffic conditions. This service may be Cuellar, Morris, Kanai Geopriv Scenarios 19 Expires in six months Mar 2003 used in complement to an enhanced call routing service, which calls the nearest Emergency Roadside Service of a certain type and delivers the location information of the Target to the Roadside Service. This could be used for the purpose of dispatching service agents. This service could arise with either the Push or Pull Models, and most likely in classification A-8. 5.2.5. Tracking services for Security The Rule Maker wants to protect his car with a location provider anti-theft device or to track the position of his children (or a pet). The network may provide the last known location and timestamp. If information is unavailable in real-time, a reason may be provided. This service could arise most likely under the Pull Model, but most probably under scenarios other than classifications A-1 through A-9. 5.3. Resource Management Services 5.3.1. Tracking services for Resource Management This service allows the tracking of location and status of specific service group users. One example is a supervisor in the role of Rule Maker and main Location Recipient who manages a delivery service and needs to know the location and status of employees. The supervisor may also be able to relay messages to the employees or other people involved in the service (for instance, customers). Another example is an enterprise tracking the location of vehicles (cars, trucks, etc.) and use location information to optimize services (Fleet Management). This service could arise most likely under the Pull Model, and most likely in classification A-6. 5.3.2. Package Tracking A delivery company (Rule Maker) launches a service to notify a customer 'C' (Viewer) about a package 'B' (Target) that it is now at the closest hub. The sighting might be triggered by an employee of the delivery company, or by the sender or the receiver of the package. This service could arise with either the Push or Pull Models, and most likely in classification A-6. 5.3.3. Taxi dispatch system - location of the customer Cuellar, Morris, Kanai Geopriv Scenarios 20 Expires in six months Mar 2003 A customer calls a taxi company for a taxi by his cellular. A dispatch operator initiates their taxi dispatch system to find the most appropriate taxi. First, the system obtains customer's current location from a Location Generator (maybe a cellular carrier). Then it searches the closest and available taxi based on location information that he has. When it finds one, it displays a map around the customer to the taxi driver. This service could arise most likely under the Pull Model, and most likely in classifications A-1, 2, 4, or 5. 5.3.4. Taxi dispatch system - location of the taxi After a customer calls a taxi company for a taxi and the dispatch operator already knows his location, it searches the closest and available taxi based on location information. This is an particular example of a Target Information Disclosure Service. This kind of service inputs Location Information and outputs a Target ID (or processed information). In our case the Location Server should have a functionality to obtain a Target ID (a taxi) by using the Location Information of the customer. When it finds a taxi, it displays a map around the customer to the taxi driver Note: the location of the customer is sent or the taxi, but the location of the taxi is sent (by LG) to the Operator, the taxi knows his own location. This service could arise most likely under the Pull Model, and most likely in classifications A-1, 2, 4, 5, or 7. 5.4. Geographic Based Content Services Location based information services allow subscribers to access information for which the information is filtered and tailored based on the location of the requesting user. Subscribers will likely initiate service requests on demand, but such services may be triggered automatically when certain user-set conditions are met. 5.4.1. Navigation The purpose of the navigation application is to provide directions to guide the target to his/her destination. Depending on the context this could be driving or walking directions, traffic update, public transport services, or others. The information may be in the form of plain text, SMS messages, symbols with text information (e.g. distances and turns), voice, or symbols on a map display. For example, a user is driving a car with a navigation Device which can access to the Internet. He initiates an online navigation service from the Device to get the fastest route to his destination. Cuellar, Morris, Kanai Geopriv Scenarios 21 Expires in six months Mar 2003 The online system obtains his location with the Device. Then searches traffic information around him and finds the fastest route. And it shows a direction on his Device. This service could arise most likely under the Translate/Query Model, and most likely in classification A-3. 5.4.2. City Sightseeing City Sightseeing would enable the delivery of location specific information to a tourist. Such information might describe historical sites, providing navigation directions between sites, facilitate finding the nearest museum, bank, airport, bus terminal, restroom facility, etc. This service could arise most likely under the Translate/Query Model, and most likely in classification A-3. 5.4.3. Mobile Yellow Pages Mobile Yellow Pages services provide the user with the address and phone number of the nearest location of a certain type or all locations within a chosen area (e.g. all Chinese restaurants within three kilometers). The information can be provided to the users in text format (e.g. name of the restaurant, address and telephone number) or in graphical format (map showing the location of the user and the restaurants). This service could arise most likely under the Translate/Query Model, and most likely in classification A-3. 5.4.4. Traffic Monitoring Mobiles in automobiles on freeways may be sampled to determine average velocity of vehicles. This service could arise most likely under the Pull Model, and most likely in classifications A-1, 2, 4, or 5. 5.4.5. Traffic jam information This is a particular case of an Area Information Disclosure Service. This service type, a variant of the Target Information Disclosure Services, comprehends services which input Area information, instead of Location, and output a Target ID (or processed information). A traffic information system inputs area information (e.g. location with range) to a Location Server. Then the Location Server returns number of targets which are within the area right now. This service could arise most likely under the Pull Model, but most probably under scenarios other than classifications A-1 through A-9. Cuellar, Morris, Kanai Geopriv Scenarios 22 Expires in six months Mar 2003 5.5. Content Provider-Initiated Information Services Another form of location based information services can transmit information to users based on their location, but at the request or initiation of entities other than the user. Users will likely need to subscribe or opt in to the services (and thus the services are in some ways user initiated). The delivery of such services may be triggered automatically when certain user-set conditions are met. 5.5.1. Location Dependent Content Broadcast The main characteristic of this service category is that the network automatically broadcasts information to terminals in a certain geographical area. The information may be broadcast to all terminals in a given area, or only to members of specific group (perhaps only to members of a specific organization). The user may disable the functionality totally from the terminal or select only the information categories that the user is interested in. An example of such a service may be localized advertising; merchants could broadcast coupons and advertisements to people passing by. This service could arise most likely under the Push Model, but most probably under scenarios other than classifications A-1 through A-9. 5.6. Entertainment and Community Services The services in this subsection could arise with either the Push, Pull, or Translate/Query Models, and conceivably in almost any of the classifications A-1 through A-9. 5.6.1. Mobile Communities or Locate a Person Find friends or share my position with my friends and interact 5.6.2. Gaming Play games based on playersÆ location. 5.6.3. Rendezvous service A user initiates a rendezvous service from his cellular. The system obtains his current location from a Location Generator, maybe a cellular carrier. The system sends his friend an e-mail to describe how to reach him. 6. Scenarios Cuellar, Morris, Kanai Geopriv Scenarios 23 Expires in six months Mar 2003 6.1. Scenario 1 Target Seeks Own Location with GPS Device with Computing Power In this very simple example, the Target wishes to know his/her location using GPS, and has a device that is capable of processing the raw data to determine a useful location. The location is derived as follows: the device receives transmissions from GPS satellites, and internally computes and displays the location. This is a wholly closed system. One Way GPS Satellites | V +---------------------------------------------+ | GPS Device with processing power: | | | | Rule Maker = Target = Location Recipient | | = Viewer | | | +---------------------------------------------+ In this closed system no external entity is granted access to location information. This minimizes the privacy concerns. But, because the device can be lost, stolen or accessed through legal process, questions about data retention and data security remain. What information is stored on the device? For how long? What security protects it? This scenario could arise most likely under the Translate/Query Model, but most probably under scenarios other than classifications A-1 through A-9. 6.2. Scenario 2 Target Seeks Own Location with GPS Device with No Computing Power In this example (an instance of B-8 or B-9), usable Location Information is computed by an outside entity based on GPS data. In this example, the outside entity is NOT the wireless carrier providing network access, but is instead a third party. The location is derived as follows: the Device receives GPS transmissions, and sends (using the wireless carriers network, which acts as a simple Data Transporter) the raw data to a third party Location Server. That server processes the data and sends it back to the Device. The third party Location Server may or may not store the Location Information for later use in accordance with the Privacy Rules set by the Rule Maker. Cuellar, Morris, Kanai Geopriv Scenarios 24 Expires in six months Mar 2003 One Way GPS Satellites | V +--------------------------+ +-----------+ | GPS Device: | 1. Raw GPS Data | Wireless | | | ---------------------> | Carrier: | | Rule Maker = Target = | | | | Location Recipient | | Data | | = Viewer | <--------------------- | Trans- | | | 4. Location Inform. | porter | +--------------------------+ +-----------+ 2. Raw | ^ 3. Data | | Loc. | | Inf. V | +-------------------------------+ | Third Party Service Provider: | | | | Location Server | | | +-------------------------------+ The same concerns raised in Scenario 6.1 (about the security of information contained in the Device) remain. A host of additional concerns are raised, including about the security of information as it passes through the Data Transporter. The most significant additional concerns are about the third party Location Server, including the length of data retention, the ability to reuse and disclose, and the security of any data storage. This scenario could arise most likely under the Translate/Query Model, but most probably under scenarios other than classifications A-1 through A-9. 6.3. Scenario 3 Fleet Owner Seeks Location of Rental Cars with GPS Device In this example (an instance of classification B-9), a rental car company wants to track its vehicles using GPS, solely for purposes of fleet management (and not as a service to the rental customer). The Target is the rental car and the Unintended Target is the driver. The location of the Target (and the Unintended Target as well) is derived as follows: the rental car receives GPS transmissions, and on a regular basis transmits the raw GPS data via a wireless network to a third party Location Server, which in turn determines the Location Information in a useful format and forwards that LI to the car rental company. Cuellar, Morris, Kanai Geopriv Scenarios 25 Expires in six months Mar 2003 One Way GPS Satellites | V +--------------------------+ +-----------+ | GPS Device: | 1. Raw GPS Data | Wireless | | | ---------------------> | Carrier: | | Rental Car = Target | | | | | | Data | | Driver = Unintended | | Trans- | | Target | | porter | +--------------------------+ +-----------+ 2. Raw | Data | | V +-----------------------+ +-----------------------+ | Rental Car Company | 3. Location | Third Party | | | Information | Service Provider: | | Rule Maker = Viewer |<--------------| | | | | Location Server | +-----------------------+ +-----------------------+ All of the same concerns raised in Scenario 6.2 are raised here, plus additional concerns (in particular concerning the threat to the privacy of the Unintended Target, the car rental customer driving the rental car). That threat is reduced (but far from eliminated) if the information transmitted to the third party Location Server does not carry any identifier related to the customer/driver. In general, the threats to the Unintended Target are outside the scope of Geopriv, but the risk to the Unintended Target nevertheless warrants note. This scenario could arise most likely under the Pull Model, and most likely in classification A-6. 6.4. Scenario 4 Target in Fixed Location Purchases Regionally Restricted Content In this example (an instance of classification B-5), the Target has in his or her home a desktop computer continuously connected to the Internet over a wire-line DSL connection. The Target seeks to purchase certain audio or video content from a World Wide Web based content provider. For contractual or legal reasons, the content provider will only sell the content to users located in a particular country or region. The content provider (as the Location Recipient) requests that the Target's Access Provider (the Target's DSL ISP) provide the Target's Location to the content provider. Cuellar, Morris, Kanai Geopriv Scenarios 26 Expires in six months Mar 2003 +------------------------+ +-----------+ | Home Computer: | 1. Content Request | DSL | | | ------------------>| Provider | | Rule Maker = Target | | | | | | Location | | | <----------------- | Server | | | 6. Content | | +------------------------+ +-----------+ | ^ | ^ | | | | | | | | +---------------------+ 2. Content Request | | | | | Content Provider: | <-----------------------/ | | | | | 3. Location Request | | | | Location Recipient | ---------------------------/ | | | Location | 4. Location Information | | | Recipient | <-----------------------------/ | | | 5. Content | | | ---------------------------------/ +---------------------+ This scenario could arise with either the Push or Pull Models, and most likely in classifications A-1, 2, 4, 5, or 8. 6.5. Scenario 5 Third Party Seeks Location of Target with Device with Computing Power and Location Awareness In this case, a mobile node (laptop or handheld) is at the same time is the Target, Rule Maker, Location Server, and Location Generator. The mobile node knows or discovers its own position using a GPS mechanism, a manual input from the user, or a co-located sensor that recognizes the relative position of some active badges or other reference points. An application running in the mobile node delivers its location to some Viewers. A Viewer that wants to know the position of the mobile node sends a Location Requests to the application running on the mobile node. After authenticating the Location Recipient, the application checks which Rule rule matches, translates the location information to the appropriate form and sends back this Filtered Location Information to the Viewer. Cuellar, Morris, Kanai Geopriv Scenarios 27 Expires in six months Mar 2003 +--------------------------+ +-----------+ | Smart Mobile Device: | 2. Location Request | Wireless | | | <--------------------- | Carrier: | | Rule Maker = Target = | | | | Location Generator = | | Data | | Location Server | ---------------------> | Trans- | | | 3. Location Inform. | porter | +--------------------------+ +-----------+ 4. Loc. | ^ 1. Inf. | | Loc. | | Req. V | +-------------------------------+ | Requesting entity: | | | | Location Recipient = | | Viewer | | | +-------------------------------+ Notice that in this case the Rules are only for internal use of the mobile node and as such do not have to be standardized. Only the interface to the Viewers has to be standardized. The Location Recipient, however, must obey the Rule Maker's Privacy Rules, which are either conveyed or referenced in the Location Object This scenario could arise most likely under the Pull Model, and most likely in classifications A-1 or 4. 6.6. Scenario 6 Third Party Seeks Location of Target with Device with Computing Power But No Location Awareness This scenario is very similar to the prior one, but instead of the mobile node discovering his position by himself, it requests its wireless carrier (its Access Provider) to determine the location of the mobile note (the Device), and send it back to the mobile node for service to the Viewer. Cuellar, Morris, Kanai Geopriv Scenarios 28 Expires in six months Mar 2003 +------------------+ +---------------------+ | Mobile Device: | 2. Location Request | Wireless Carrier | | | <--------------------- | | | | 3. Location Request | Data Transporter | | Rule Maker = | ---------------------> | for 1-2, 5-6 | | Target = | 4. Location Inform. | | | Location | <--------------------- | Location Gen. & | | Server | 5. Location Inform. | Server for 3-4 | | | ---------------------> | | +------------------+ +---------------------+ 6. Loc. | ^ 1. Inf. | | Loc. | | Req. V | +-------------------------------+ | Requesting entity: | | | | Location Recipient = | | Viewer | | | +-------------------------------+ Notice that in this scenario no Location Recipient exists, besides the Rule Maker and the Viewers served by the Rule Maker. Thus, the Rule Maker is in full control of its private information. There is a significant privacy concern raised by the uncertainty of how the Rule Maker makes sure that the Location Generator (here, the Access Provider) does not provide location information to other location recipients. Either the AP is aware of the full Rules of the owner, or a default (set by law, contract, or protocol design) prohibits disclosure. A precise requirement should be formulated to guarantee this privacy protection. Another concern is that, depending on the sensing infrastructure and its trusts relationships to the user, authenticating the supplied location information is difficult for the following reasons: o some sensor systems only detect active badges that can be removed from the mobile object they represent. o sensor systems are not equipped with proper keys or key distribution software. This scenario could arise most likely under the Pull Model, and most likely in classifications A-2 or 5. 6.7. Scenario 7 Target with Location Aware Device Using Third Party Location Server to Obtain Location Based Service From a Fourth Party Service Provider Cuellar, Morris, Kanai Geopriv Scenarios 29 Expires in six months Mar 2003 In this case, a mobile node (laptop or handheld) is at the same time is the Target, Rule Maker, Location Server, and Location Generator. The mobile node knows or discovers its own position using a GPS mechanism, a manual input from the user, etc., and periodically sends that location to a third party Location Server with which the Rule Maker has a prior contractual arrangement. The Target sends the Location Server its Privacy Rules in advance. When the Target then seeks a location service, it requests the service from the service provider. The service provider requests the Target's location from the Location Server, and then fills the Target's request for a service. +----------------------+ Periodically Sent +-----------------+ | Mobile Device: | b. Location Inform. | Wireless | | | ---------------------> | Carrier: | | Rule Maker = Target | | | | | 1. Service Request | Data | | | ---------------------> | Transporter | | | 6. Location Service | | | | <--------------------- | | +----------------------+ +-----------------+ | | | | | a. Privacy Rules | | | | (sent external to | | | | and in advance of | | | | location service | | | | transaction) Periodically | | | V Sent Location| | | +--------------------------+ c. Information | | | | Third Party Location | <---------------/ | | | Server: | | | | | | | | Location Server | | | | | | | +--------------------------+ | | ^ | | | 3. Location | | 4. Location | | Request | | Information | | | V | | +---------------------+ | | | Location Service | 2. Service Request | | | Provider | <-----------------------/ | | | | | Location Recipient | 5. Location Service | | = Viewer | ---------------------------/ +---------------------+ This scenario could arise most likely under the Pull Model, but most probably under scenarios other than classifications A-1 through A-9. Cuellar, Morris, Kanai Geopriv Scenarios 30 Expires in six months Mar 2003 6.8. Scenario 8 Target with Non-Aware Device Using Third Party Location Server to Obtain Location Based Service From a Fourth Party Service Provider This final scenario is the same as the prior scenario except that the Target's Device does NOT know its location and must instead have its Location Server ask for its location from the Target's Access Provider: +----------------------+ +-----------------+ | Mobile Device: | | Wireless | | | | Carrier: | | Rule Maker = Target | | Data Transport | | | 1. Service Request | for 1-2,7-8 | | | ---------------------> | Location Gen. | | | 8. Location Service | Server for 4-5 | | | <--------------------- | | +----------------------+ +-----------------+ | ^ | | ^ | a. Privacy Rules | | | | | (sent external to | | | | | and in advance of | | | | | location service | | | | | transaction) | | | | V | | | | +--------------------------+ 4. Loc. Request | | | | | Third Party Location | ----------------/ | | | | Server: | | | | | | 5. Location | | | | Location Server | Information | | | | | <------------------/ | | +--------------------------+ | | ^ | | | 3. Location | | 6. Location | | Request | | Information | | | V | | +---------------------+ | | | Location Service | 2. Service Request | | | Provider | <--------------------------/ | | | | | Location Recipient | 7. Location Service | | = Viewer | ------------------------------/ +---------------------+ Note that the Access Provider also acts as a Location Server to provide the initial Location Sighting to the third party Location Server, which then in turn fills the request for location. This scenario could arise most likely under the Pull Model, but most probably under scenarios other than classifications A-1 through A-9. Cuellar, Morris, Kanai Geopriv Scenarios 31 Expires in six months Mar 2003 7. Implications and Conclusions Critical privacy issues illustrated by the location computation scenarios are who controls the data and how, who computes or derives the location information, and who stores uses and discloses the data. All examples apart from the closed system represented by Scenario 1 present many privacy issues. The more entities involved, the more difficult it is to make sure the Privacy Rules of the Rule Maker are implemented. In cases where there is a pre-existing relationship, technology may not be necessary to transmit Privacy Rules. Instead, the Rule Maker and AP might reach a contractual agreement about privacy. But, the Rule Maker will not always have a contractual relationship with the AP or all involved entities. In some instances the Target will have no choice but to use a single AP. Sometimes "a chain" from the AP to other entities to enforce the Privacy Rules may work. Therefore, technologies that address these issues must be developed. Entities may be constrained by national or local laws regarding how they handle information. For example, in some relevant situations within some countries, "Customer Proprietary Network Information" (CPNI) rules require that telecommunications carriers obtain customer approval before using, disclosing, or permitting access to individually identifiable CPNI. 8. Security Considerations The purpose of the Geopriv Location Object is to allow a Rule- controlled disclosure of location information for location services. The information carried within the Location Object is secured in a way compliant with the privacy and security Rules of the Rule Maker, but other information, carried in other objects or headers are in general not secured in the same way. The scenarios included in this draft can serve to illustrate security concerns that must be addressed by Geopriv. 9. Acknowledgements Important elements of this draft were inspired by a prior scenarios draft by Kenji Takahashi and his colleagues. 10. References [ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/. [OECD] OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, http://www.oecd.org. Cuellar, Morris, Kanai Geopriv Scenarios 32 Expires in six months Mar 2003 [Pfi01] Pfitzmann, Andreas; K÷hntopp, Marit: Anonymity, Unobservability, and Pseudonymity - A Proposal for Terminology; in: H Federrath (Ed.): Designing Privacy Enhancing Technologies; Proc. Workshop on Design Issues in Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer versions available at http://www.koehntopp.de/marit/pub/anon [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 11. Author's Addresses Jorge R. Cuellar Siemens AG Otto-Hahn Ring 6 81730 Munich Email: jorge.cuellar@mchp.siemens.de Germany John B. Morris, Jr. Director, Internet Standards, Technology & Policy Project Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 Email: jmorris@cdt.org USA Tsuyoshi Go Kanai Fujitsu Laboratories, Ltd. 64 Nishiwaki, Okubo-cho, Akashi 674-8555 Email: kanai.go@jp.fujitsu.com Japan 12. Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Cuellar, Morris, Kanai Geopriv Scenarios 33 Expires in six months Mar 2003 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Cuellar, Morris, Kanai Geopriv Scenarios 34