Location information can be used in very different environments. In
some cases, the participants will have longstanding relationships,
while in others the 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:
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.
5.4. Further Geopriv Principals
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 whereby the location 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.
There are four scenarios in which some form of constraint or
override might be placed on the Privacy Rules of the Rule
Maker:
1. In the case of emergency services (such as E911 within the
United States), local or national laws may require that
accurate location information be transmitted in certain
defined emergency call situations. The Geopriv Working
Group MUST facilitate this situation.
2. In the case of legal interception, the RM may not be aware
of an override directive imposed by a legal authority. It
is not the expectation of the Working Group that a
particular accommodation will be made to facilitate this
situation.
3. In the context of an employment relationship or other
contractual relationship, the owner of a particular location
(such as a corporate campus) may impose constraints on the
use of Privacy Rules by a Rule Maker. It is not the
expectation of the Working Group that a particular
accommodation will be made to facilitate this situation.
4. It is conceivable that a governmental authority may seek to
impose constraints on the use of Privacy Rules by a Rule
Maker in non-emergency situations. It is not the
expectation of the Working Group that a particular
accommodation will be made to facilitate this situation.
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.
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
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.
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 Location Information.
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).
5.5. Privacy Rules
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 precision or resolution"
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.
5.6. Identifiers, Authentication and Authorization
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 to each other. Unlinkability requires that entities
be 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 an 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 word authentication is used in different manners. Some require
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 a well-known, or
at least a 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.)
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 or may not
imply Explicit Authentication.
6. Scenarios and Explanatory Discussion
In this subsection we introduce short scenarios to illustrate how
these terms and attributes describe location information
transactions. Additional illustrative scenarios are discussed in a
separate document.
SCENARIO 1: GPS Device with Internal Computing Power: Closed System
In this example, the Target wishes to know his/her location using the
Global Positioning System (GPS) and the Device is capable of
independently processing the raw data to determine its location. The
location is derived as follows: the Device receives transmissions
from the GPS satellites, internally computes and displays location.
This is a closed system. For the purpose of this and subsequent
examples, it is assumed that the GPS satellite broadcasts some
signal, and has no information about the identity or whereabouts of
Devices using the signal.
GPS Satellite
|
| Sighting (not a Geopriv Interface)
|
|
|
V GPS Device
--------------------------------------------------
/ \
| Location ----- Location ----- Location |
| Generator Server Storage |
\ | /
-------------------------------------------|------
|
| Notification
| Interface
|
------------|------
/ V \
/ Target Location \
| Recipient |
| |
\ Rule Maker /
\ /
-------------------
In this scenario the GPS Device is both the AP and the LG. The
interaction occurs in a Trusted environment because it occurs in the
Rule Maker’s Device.
SCENARIO 2: Cell Phone Roaming
In this example, a cell phone is used outside its home service area
(roaming). Also, the cell phone service provider (cell phone Corp 2)
outsourced the accounting of cell phone usage. The cell phone is not
GPS-enabled. Location is derived by the cell phone network in which
the Target and Device are roaming. When the Target wishes to use the
cell phone, cell phone Corp 1 (AP) provides the roaming service for
the Target, which sends the raw data about usage (e.g., duration of
call, location in the roaming network, etc.) to cell phone Corp 2,
the home service provider. Cell phone Corp 2 submits the raw data to
the accounting company, which processes the raw data for the
accounting statements. Finally, the raw data is sent to a data
warehouse where the raw data is stored in a Location Server (e.g.,
computer server).
Cell Phone Corp 1 Cell Phone Corp 2
----------------- -----------------
Sighting / \ Publish / \
Device ----- | Data Transporter | --------- | Data Transporter |
Target \ / Interface \ /
----------------- / -----------------
/ |
/ | Notification
/ | Interface
----------- |
/ V
------------ / ----------
/ \ / / \
/ Location \ / | Location |
| Storage | Location Info | Storage |
| |<----------------- | |
| Location | | Location |
| Recipient | | Recipient |
\ / \ /
------------- ----------
Here, cell phone Corp 1 is the AP and the LG. In this scenario, Cell
phone Corp 2 is likely to be a Trusted entity, but cell phone Corp 1
may be Non-trusted.
SCENARIO 3: Mobile Communities and Location-Based Services
The figure below shows a common scenario, where a user wants to find
his friends or colleagues or wants to share his position with them or
with a Location-Based Service Provider. Some of the messages use a
Location Object to carry, for instance, identities or pseudonyms,
credentials and proof-of-possession of them, Rules and Location Data
Information, including Data Types and Precision or Resolution.
Messages that do not use the Location Object and are outside of the
scope of the Geopriv WG, but should be mentioned for
understandability, are shown in the figure as starred arrows
("***>").
+---------+ +------------+
| | | |
| Location|<** | Public |
|Generator| * | Rule Holder|
| | * | |
+---------+\ * +------------+
\ *3 1a* *
\ * * *
\ ** *
\ * * *1a
\* * *
* \ * *
* \ * *
* \4 * *
* \ * V
* \->+-----------+
+----------+ 1 | Location |
| Rule |--------------------->| Server + |
| Maker | | Private |
+----------+ |Rule Holder|
+-----------+
^ |
3| |5
| V
+----------+
| Location |
| Recipient|
+----------+
Assume that the Rule Maker and the Target are registered with the
Location Server. The RM has somehow proven to the LS that he indeed
is the owner of the privacy rights of the Target (the Target is
usually a Device owned by the Rule Maker). The Rule Maker and the
Location Server have agreed on the set of keys or credentials and
cryptographic material that they will use to authenticate each other,
and in particular, to authenticate or sign the Rules. How this has
been done is outside of the scope of the document.
1: Rule Transfer:
The Rule Maker sends a Rule to the Location Server. This Rule
may or may not be a field in a Location Object.
1a:Signed Rule:
As an alternative, the Rule Maker may write a Rule and place it
in a Public Rule Holder. The entities access the repository to
read the signed Rules.
2: Location Information Request:
The Location Recipient requests location information for a
Target. In this request, the Location Recipient may select
which location information data type it prefers. One way of
requesting Location Information MAY be sending a partially
filled Location Object, including only the identities of the
Target and Location Recipient and the desired Data Type and
precision or resolution, and providing proof of possession of
the required credentials. But whether or not the using
protocol understands this partially filled object as a request