draft-ietf-geopriv-reqs-00.txt   draft-ietf-geopriv-reqs-01.txt 
Internet Draft J. Cuellar Internet Draft J. Cuellar
Document: draft-ietf-geopriv-reqs-00.txt Siemens AG Document: draft-ietf-geopriv-reqs-01.txt Siemens AG
John B. Morris, Jr. John B. Morris, Jr.
Center for Democracy and Technology Center for Democracy and Technology
D. Mulligan D. Mulligan
Samuelson Law, Technology, and Public Policy Clinic Samuelson Law, Technology, and Public Policy Clinic
Expires: Dec. 2002 June 2002 Expires in six months November 2002
Geopriv requirements Geopriv requirements
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
Location-based services, navigation applications, emergency services, Location-based services, navigation applications, emergency
management of equipment in the field, and other location-dependent services, management of equipment in the field, and other location-
services need geographic location information about a target (user, dependent services need geographic location information about a
resource or other entity). There is a need to securely gather and Target (such as a user, resource or other entity). There is a need
transfer location information for location services, protecting the to securely gather and transfer location information for location
privacy of the individuals involved. services, while at the same time protecting the privacy of the
individuals involved.
This document describes the requirements for the geopriv Location
Object (used to transfer location data and perhaps some other
Cuellar, Morris, Mulligan Expires Dec 2002 1 Cuellar, Morris, Mulligan 1
Geopriv Requirements June 2002 Geopriv Requirements Nov 2002
information) and for further IETF protocols that use this Location This document focuses on the authorization, integrity and privacy
Object as an embedded protocol. We focus on authorization, integrity requirements for such location-dependent services. Specifically, it
and privacy requirements. describes the requirements for the geopriv Location Object (used to
securely transfer location data and other privacy-enabling
information) and for the protocols that use this Location Object.
Table of Contents Table of Contents
1. Overview.......................................................2 1. Overview........................................................3
2. Conventions used in this document..............................4 2. Conventions used in this document...............................4
3. Usage Model....................................................4 3. Terminology.....................................................4
3.1. Roles and attributes......................................4 3.1. Foundational Definitions...................................4
3.2. Data......................................................8 3.1.1. Location Information (LI) and Sighting................4
3.3. Identification, Authentication, and Authorization.........9 3.1.2. The Location Object...................................6
3.3.1. Identifiers..........................................9 3.1.3. Location Object vs. Using Protocol....................6
3.3.2. Authentication......................................10 3.1.4. Trusted vs. Non-trusted Data Flows....................6
3.3.3. Authorization.......................................10 3.2. Geopriv Entities and Functions.............................7
3.4. Data Flows...............................................10 3.2.1. Primary Geopriv Entities..............................7
3.4.1. Relationship framework..............................12 3.2.2. Secondary Geopriv Entities............................8
3.4.2. Scenarios of Data Flow..............................12 3.2.3. Geopriv Data Storage Functions........................9
3.5. Further explanations.....................................14 3.3. Privacy Policies and Rules.................................9
3.5.1. Location Data Types.................................14 3.4. Identifiers, Authentication and Authorization.............10
3.5.2. Public Global Identities............................15 4. Scenarios and Explanatory Discussion...........................11
3.5.3. Authorization without Explicit Authentication.......15 4.1. Scenarios of Data Flow....................................11
4. Requirements..................................................17 5. Requirements...................................................14
4.1. Protocols................................................17 5.1. Location Object...........................................15
4.2. Policy based Location Data transfer......................17 5.2. The Using Protocol........................................16
4.3. Location Object, Location Field..........................18 5.3. Policy based Location Data transfer.......................17
4.4. Requests.................................................19 5.4. Location Object Privacy and Security......................17
4.5. Identity Protection......................................19 5.5. Identity Protection.......................................18
4.6. Authentication Requirements..............................20 5.6. Authentication Requirements...............................18
4.7. Actions to be secured....................................21 5.7. Actions to be secured.....................................18
4.8. Non-Requirements.........................................21 5.8. Non-Requirements..........................................19
5. Security Considerations.......................................21 6. Security Considerations........................................19
6. Acknowledgements..............................................21 6.1. Traffic Analysis..........................................19
7. References....................................................22 6.2. Securing the Privacy Policies.............................19
8. Author's Addresses............................................22 6.3. Emergency Case............................................20
9. Full Copyright Statement......................................22 6.4. Identities and Anonymity..................................20
6.5. Unintended Target.........................................21
7. Acknowledgements...............................................21
8. References.....................................................21
9. Protocol and LO Issues for later Consideration.................22
9.1. Single Message Transfer...................................22
9.2. Multiple Locations in one LO..............................22
9.3. Translation Fields........................................22
9.4. Specifying Desired Accuracy in a Request..................22
Cuellar, Morris, Mulligan 2
Geopriv Requirements Nov 2002
9.5. Truth Flag................................................22
9.6. Timing Information Format.................................22
9.7. The Name Space of Identifiers.............................22
10. Author's Addresses............................................23
11. Full Copyright Statement......................................23
1. Overview 1. Overview
Location-based services (applications that require geographic Location-based services (applications that require geographic
location information as input) are becoming increasingly common. The location information as input) are becoming increasingly common.
collection and transfer of location information about a particular The collection and transfer of location information about a
device and/or target can have privacy implications. particular Device and/or Target can have important privacy
implications. A key goal of the protocols described in this
document is to facilitate the protection of privacy pursuant to
privacy policies set by the "user" (or, more precisely in the
terminology of this document defined in Section 3 below, the "Rule
Maker").
The ability to derive or compute a device's location, and access to The ability to derive or compute a Device's location, and access to
the derived or computed location, are key elements of the location- the derived or computed location, are key elements of the location-
based services privacy equation. Central to a target's privacy are based services privacy equation. Central to a Target's privacy are
(a) the identity of entities that have access to raw location data, (a) the identity of entities that have access to raw location data,
derive or compute location, and/or have access to derived or
computed location information, and (b) whether those entities can be
trusted to know and follow the privacy policy of the user.
Cuellar, Morris, Mulligan Expires Dec 2002 2 The main principles guiding the requirements described in this
Geopriv Requirements June 2002 document are:
derive or compute location, and/or have access to derived or computed
location information, and (b) whether those entities can be trusted
to know and follow the target's (or better Rule Maker's) policy.
In this paper we assume that "location information" is a relatively
specific way of describing where a device is located and that the
location information is either (a) derived or computed from
information generally not available to the general public, or (b)
determined by a device that is not generally publicly addressable or
accessible. For example, location information could include
information calculated by triangulating on a wireless signal with
respect to cell phone towers, or longitude and latitude information
determined by a device with GPS (global positioning satellite)
capabilities.
Excluded from the discussion below 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. It is
important to note that information like IP address can enable someone
to roughly or in some instances precisely estimate a location.
Commercial services exist, for example, that offer to provide rough
location information based on IP address. Currently, this type of
location information is typically less accurate and has a coarser
granularity than the type of location information addressed in this
document. This less accurate type of location computation still
raises significant potential privacy and public policy concerns, but
such scenarios are generally outside the scope of this document.
For the purposes of this document, "policies" or "privacy rules" are
rules that regulate an entity's activities with respect to location
information, including, but not limited to, the collection, use,
disclosure, and retention of location information. These rules must
generally comply with fair information practices. For instance, see
the OECD Guidelines on the Protection of Privacy and Transporter
Flows of Personal Data at http://www.oecd.org.
The main principles guiding the requirements exposed in this paper
are:
1) Security of the protocol is of essential to guarantee the 1) Security of the transmission of Location Object is essential to
correctness (integrity) and the confidentiality of the location guarantee the integrity and confidentiality of the location
information. This includes authenticating the main entities of information. This includes authenticating the sender and
the protocol and securing the exchanged messages. receiver of the Location Object, and securing the Location Object
itself.
2) A critical role is played by user-controlled policies, which 2) A critical role is played by user-controlled policies, which
describe the permissions (or consent) given by the user. (In describe the restrictions imposed or permissions given by the
this introductory section we use the word "user" informally; to "user" (or, as defined below, the "Rule Maker"). The policies
be more precise, instead of "user", we should say "Rule Maker" specify the necessary conditions that allow a Location Server to
but this term has not been introduced yet.) The policies specify forward Location Information to a Location Recipient, and the
the necessary conditions that allow a Location Server to forward conditions under which and purposes for which the Location
(transformed or filtered) location information to a Location Information can be used.
Recipient and the conditions under which and purposes for which
Cuellar, Morris, Mulligan Expires Dec 2002 3 3) The Location Object should be able to carry a limited but core
Geopriv Requirements June 2002 set of privacy policies. This core set is defined below and
discussed more extensively in a separate document. Beyond the
core set of privacy policies, the user or Rule Maker should be
able to define a more robust and complex set of policies. The
exact form or expressiveness of policies beyond the core set is
not further discussed in this paper.
location information can be used. That is, using policies, the Cuellar, Morris, Mulligan 3
user is able to specify which component or derived measure of the Geopriv Requirements Nov 2002
information is to be released to whom and in which granularity or
accuracy. The exact form or expressiveness of policies is not
further discussed in this paper.
3) Whenever possible, the location information should not be linked 4) Whenever appropriate, the location information should not be
to the real identity of the user or a static identifier easily linked to the real identity of the user or a static identifier
linked back to the real identity of the user (e.g., the phone easily linked back to the real identity of the user (e.g., the
number). Rather, the user is able to specify which local phone number). Rather, the user should be able to specify which
identifier, pseudonym, or private identifier is to be linked to local identifier, unlinked pseudonym, or private identifier is to
the location information. be bound to the location information.
4) The user may want to hide the real identities of himself and his 5) The user may want to hide the real identities of himself and his
partners not only to eavesdroppers but also to other entities partners not only to eavesdroppers but also to other entities
participating in the protocol. participating in the protocol.
Although complete anonymity may not be appropriate because of legal Although complete anonymity may not be appropriate for some
constraints or because some location services may in fact need applications because of legal constraints or because some location
explicit identifications, in most cases the location services only services may in fact need explicit identifications, in most cases
need some type of authorization information and/or perhaps anonymous the location services only need some type of authorization
identifiers of the entities in question. information and/or perhaps anonymous identifiers of the entities in
question.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [1]. this document are to be interpreted as described in [RFC2119].
Note that the requirements discussed here are requirements on privacy
protocols for location services. Thus the requirements sometimes
refer only to the capabilities of these protocols. For example,
requiring that the protocol support integrity is not the same thing
as requiring that all protocol traffic be authenticated. In other
cases, the requirement may be that the user always obtains a notice
when his location data was not authenticated. This is clearly not
just a capability of the protocol.
3. Usage Model
The following usage model will be discussed more extensively in
another framework and scenarios document. We present here a summary
of the terminology of the usage model for convenience.
3.1. Roles and attributes
The entities of a geopriv application or scenario may be given
explicit roles:
Target:
The entity whose location is desired by the Location Seeker.
Cuellar, Morris, Mulligan Expires Dec 2002 4 Note that the requirements discussed here are requirements on the
Geopriv Requirements June 2002 generic Location Object and on the using protocols for location
services. Thus the requirements discussed in this document mostly
refer to the capabilities that are mandatory-to-implement. For
example, requiring that implementations support integrity is not the
same thing as requiring that all protocol traffic be authenticated.
In other cases, the requirement may be that the user always obtains
a notice when his location data was not authenticated. This practice
is mandatory-to-use, not just to implement.
In many cases the Target will be the human "user" of a Device 3. Terminology
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 terminology and definitions detailed below include both (1)
The technical device the location of which is tracked as a terms used in the requirements section of this document, and (2)
proxy for the location of a Target. A Device might, for terms that provide additional detail about the usage model
example, be a Global Positioning Satellite (GPS) receiver, a envisioned for the geopriv Location Object. These latter terms will
laptop equipped with a wireless access device, or a be utilized in a separate scenarios document.
transmitter that emits a signal that can be tracked or
located. In some situations there may be no Device, in the
sense of this definition, but for instance a user is entering
the location information manually.
Rule Maker: 3.1. Foundational Definitions
The individual or entity who has the authorization to set the
applicable privacy rules, collectively known also as the
policy. In some cases this is the user who is in possession
of the Device, but is some cases it is not. For example,
parents may control what happens to the location information
derived from their children's cell phones. The Rule Maker is
often, but not always, the "owner" of the Device used to track
location. For example, a company may own and provide a cell
phone to an employee but permit him/her to set the privacy
rules. Other proposed names are "Owner (of the privacy
rights)" or "policy maker"
Unintended Target: 3.1.1. Location Information (LI) and Sighting
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. Working group
protocols may or may not protect or affect the privacy of
Unintended Targets, but the impact on Unintended Targets
should be acknowledged.
Data Transporter ("DT"): The focus of the geopriv working group is on information about a
An entity or sub-network that receives and forwards data Target's location that is NOT based on generally or publicly
without processing or altering it. A Data Transporter could available sources, but instead on private information provided or
theoretically be involved in almost any transmission between a created by a Target, a Target's Device, or a Target's network or
Device and a Location Processor, a Location Processor and a service provider:
second Location Processor, or a Location Processor and a
Location Seeker. Some location tracking scenarios may not
involve a Data Transporter.
Location Seeker ("LS") Cuellar, Morris, Mulligan 4
An individual or entity who seeks to receive location data Geopriv Requirements Nov 2002
about a Target.
Cuellar, Morris, Mulligan Expires Dec 2002 5 Location Information (LI):
Geopriv Requirements June 2002 A relatively specific way of describing where a Device is
located and that 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.
Computational Location Server ("CLServ") As examples, LI could include (a) information calculated by
A Device or entity that computes or processes raw data to triangulating on a wireless signal with respect to cell phone
compute or derive location data, or processes location data to towers, (b) longitude and latitude information determined by a
transform or refine the data into new location data. The Device with GPS (global positioning satellite) capabilities, or (c)
actual computation of location information is beyond geopriv's information manually entered into a cell phone or laptop by a Target
scope, the distribution of location information is not. in response to a query.
Location Storage ("LStor") Excluded from this definition is the determination of location
(. Location Server: Think of pure storage devices as disks. information wholly without the knowledge or consent of the Target
They matter for privacy purposes!) (or the Target's network or access service provider), based on
A Device or entity that stores raw or location data. The data generally available information such as an IP or e-mail address. In
storage policy of LStor is crucial to privacy considerations, some cases information like IP address can enable someone to
because this policy may influence what location information estimate (at least roughly) a location. Commercial services exist
the Rule Maker will reveal. The different actors in a location that offer to provide rough location information based on IP
information request create intertwined privacy concerns. If address. Currently, this type of location information is typically
data about a requester is stored and correlated with data less accurate and has a coarser granularity than the type of
about a Target, it may be possible to infer more information location information addressed in this document. Although this type
from the aggregate than one or both entity's rules would of location computation still raises significant potential privacy
allow. Unlinkable identifiers provide the ideal solution to and public policy concerns, such scenarios are generally outside the
this problem, but may be impossible in practice. Stored scope of this document.
identifiers SHOULD use the closest possible approximation to
unlinkable identifiers. LStor devices SHOULD follow the Rule
Maker's policies regarding permissible duration of data
storage, etc.
<Although it is clear that aggregation in particular and data
storage policies in general pose serious privacy questions, it
is open how much of this concern falls within geopriv scope.>
Rule Repository ("RR") Within any given location-based transaction, the INITIAL
A repository that contains private (authenticated, but not determination of location (and thus the initial creation of Location
signed) or public (signed) policies, identifiers, and perhaps Information) is termed a Sighting:
also stores requests.
Roles of Location Information Requesters 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.
An entity that seeks to access the location data is a Location Seeker Some variant of the sighting information is included in the Location
and may act in one or more of the following roles: as the Location Object. Abstractly, it consists of two separate data fields:
Sighter (Location Data Source), as a Location Server, or as an
Ultimate Location Recipient.
Location Sighter (LoSi), or Location Data Source (Identifier, Location)
The original source of the sighting of a target in a given
transaction.
Location Server (LS), or Intermediate Location Recipient: where Identifier is the identifier assigned to a Target being
A Device or entity that provides access to raw data or sighted, and Location is the current position of that Target being
location data after processing or altering it or not. Some sighted. Not all entities may have access to exactly the same piece
location tracking scenarios may not involve a Location Server. of sighting information. A sighting may be transformed to a new
sighting pair:
Cuellar, Morris, Mulligan Expires Dec 2002 6 (Identifier-1, Location-1)
Geopriv Requirements June 2002
Ultimate Location Recipient (ULR): Cuellar, Morris, Mulligan 5
An individual or entity who receives location data about a Geopriv Requirements Nov 2002
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 another party distinct
from the target or the Rule Maker.
A data transporter may be an before it is provided by a Location Sighter 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.
Initial Access Provider ("IAP"): 3.1.2. The Location Object
A data transporter 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 IAP --
which will be a wireless carrier, an Internet Service
Provider, or an internal corporate network -- will be
identical to the LoSi. Other cases may involve no IAP at all.
But in other instances the IAP's infrastructure may be
controlled by another party. In these cases the IAP could be
seen as a "dumb" LoSi, one that transmits geopriv data but
does not implement any part of the geopriv protocol.
The rules of the Target may be accessible to a Location Server in the A main goal of the geopriv working group is to define a Location
form of Private or Public Rules Repositories: Object (LO), to be used to convey both Location Information and
basic privacy-protecting instructions:
Public Policy Repository: Location Object (LO): This data contains the Location Information
A repository where signed policies, identifiers, and perhaps of the Target, and other fields including an identity or
also requests are stored. pseudonym of the Target, time information, core privacy
policies, authenticators, etc. Most of the fields are
optional, including the Location Information itself.
Private Policy Repository: Nothing is said about the semantics of a missing field. For
A repository of authenticated policies, identifiers, and instance, a partially filled object MAY be understood implicitly as
perhaps also requests are stored, for the private use of one the request to complete it. Or, if no time information is included,
Location Server. 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.
The following table shows the possible roles of the geopriv entities. 3.1.3. Location Object vs. Using Protocol
Cuellar, Morris, Mulligan Expires Dec 2002 7 The "using protocol" is the protocol that uses (creates, reads or
Geopriv Requirements June 2002 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 correct
distribution, protection, usage, retention, and storage of the LO.
+------------------+-----+------+--------+---------+----------+ The security and privacy enhancing mechanisms used to protect the LO
| role| IAP | ULR | Public | Private | Location | are of two types: First, the Location Object definition MUST
|entity | | | RR | RR | Sighter | include (optional) fields or mechanisms used to secure the LO as
+------------------+-----+------+--------+---------+----------+ such. The LO MAY be secured, for example, using cryptographic
|Target | | | | | x | checksums or encryption as part of the LO itself. Second, the using
+------------------+-----+------+--------+---------+----------+ protocol may also provide security mechanisms to securely transport
|Device | | | | | x | the Location Object.
+------------------+-----+------+--------+---------+----------+
|Rule Maker | x | | | | x |
+------------------+-----+------+--------+---------+----------+
|Unintended Target | | | | | |
+------------------+-----+------+--------+---------+----------+
|Data Transporter | x | | | | x |
+------------------+-----+------+--------+---------+----------+
|Location Seeker | x | x | | | |
+------------------+-----+------+--------+---------+----------+
|Location Server | x | | | | x |
+------------------+-----+------+--------+---------+----------+
|Rule Repository | | | x | x | |
+------------------+-----+------+--------+---------+----------+
3.2. Data The security mechanisms of the Location Object itself are to be
preferred.
The main data used by the protocol is the Location Object (LO). It 3.1.4. Trusted vs. Non-trusted Data Flows
contains the sighting information (the identity/location pair) and
some other information to be determined, e.g., time information, some
types of policies, authenticators, etc. If no time information is
included, this implicitly means "at the current time" or "at a very
recent time".
Sighting: the location information for a target. This is the Location information can be used in very different environments. In
main private data accessed by Location Servers and/or Ultimate some cases the participants will have longstanding relationships,
Location Recipients. Some variant of the sighting information while in others participants may have discrete interactions with no
is included in the Location Object. Abstractly, it consists prior contractual or other contact.
of two separate data fields:
(Sighting-Identifier, Location) Cuellar, Morris, Mulligan 6
Geopriv Requirements Nov 2002
Sighting-Identifier is the identifier assigned to a target or The different relationships raise different concerns for the
device being sighted, and Location is the current position of implementation of privacy rules, including the need to communicate
that target or device being sighted. privacy policies. A public Rule Repository, 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:
Not all entities have access to exactly the same piece of Trusted Data Flow:
sighting information. The sighting may be transformed to a A data flow that is governed by a pre-existing contractual
new sighting pair: relationship that addresses location privacy.
(Sighting-Identifier-1, Location-1) Non-trusted Data Flow:
The data flow is not governed by a pre-existing contractual
relationship that addresses location privacy.
before it is provided by the Location Data Source or the 3.2. Geopriv Entities and Functions
Location Server to another Location Recipient.
Cuellar, Morris, Mulligan Expires Dec 2002 8 The entities of a geopriv application or transaction may be given
Geopriv Requirements June 2002 explicit roles:
Policy: 3.2.1. Primary Geopriv Entities
A 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 policy describes how location information may
be used by an entity and which transformed location
information may be released to which entities under which
conditions. Policies contain "rules" or "assertions".
Policies must be obeyed; they are not advisory. To make this
more explicit, the term "rules" is also used instead of
"policy".
Data attributes: Certain entities and roles are involved in most (and in some cases
Filtered: all) geopriv transactions:
Location information that has been computationally modified.
3.3. Identification, Authentication, and Authorization Target:
The entity whose location is desired by the Location Seeker.
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.
This subsection introduces some terms to be used later in the Device:
Requirements Section. 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.
3.3.1. Identifiers Rule Maker:
The individual or entity that has the authorization to set the
applicable privacy policies and rules. 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.
The LO has a filed for identification of the target. Geopriv- Cuellar, Morris, Mulligan 7
compliant systems MUST implement a means of asserting identities and Geopriv Requirements Nov 2002
inserting and using the identifiers in the LO, but the LO needs not
use identifiers under all circumstances.
<Need to define pseudonym here.> Location Seeker (LSeek):
An individual or entity who seeks to receive location data
about a Target.
Using protocols should be able to handle LOs with identifiers, LOs A Location Seeker may act in one or more of the following more
without identifiers, and LOs with pseudonyms. The identity of the specialized roles: as the Location Sighter, a Location Server, or as
requester may be irrelevant in some cases, whereas the identity of an Ultimate Location Recipient:
the Target may be irrelevant in others. In particular, geopriv does
not suggest that a LO with no identifier provides anonymity.
Entity-Identifier: The names used by the entities of the protocol Location Sighter (LoSi), or Location Data-Source
to identify, authenticate or authorize themselves to other The original source of the sighting of a Target in a given
entities. Policies also use entity-identifiers to express transaction.
which Location Seekers may receive which transformed sighting
information.
The next type of identifier may not be used as an Entity-Identifier, Location Server (LServ), or Intermediate Location Recipient:
since it can be shared by several, perhaps many, different entities: A Device or entity that provides access to Location
Information (possibly after processing or altering it) in
accordance with the privacy policies of the Rule Maker. Some
location tracking scenarios may involve a Target, Device, or
Device user performing the function of a Location Server.
Role identifier Ultimate Location Recipient (ULR):
("administrator", "member-of-club-A", etc.) The meaning of the An individual or entity who receives location data about a
role may be context dependent. Target and does not transmit the location information or
Geopriv will probably does not support role identifiers in any information based on the Target's location (such as driving
particular way. directions to or from the Target) to any party OTHER than the
Target or the Rule Maker.
Cuellar, Morris, Mulligan Expires Dec 2002 9 3.2.2. Secondary Geopriv Entities
Geopriv Requirements June 2002
3.3.2. Authentication Certain entities and functions are present or involved in only a
subset of geopriv transactions:
People use the word authentication with different meanings. Some Data Transporter:
people insist that authentication associates an entity with a more or An entity or network that receives and forwards data without
less well-known identity. This basically means that if A processing or altering it. A Data Transporter could
authenticates another entity as being "B", then the label "B" has theoretically be involved in almost any transmission between a
also a meaning for many entities different from A. In this case, the Device and a Location Server, a Location Server and a second
label "B" is called a publicly known identifier, and the Location Server, or a Location Server and an Ultimate Location
authentication is "explicit": Recipient. Some location tracking scenarios may not involve a
Data Transporter.
Explicit Authentication Initial Access Provider (IAP):
The act of verifying a claimed static identity easily linked The entity that provides the initial network access or other
back to the real identity of the user, in the form of a pre- data communications services essential for the operation of
existing label from a predefined name space, as the sole communications functions of the Device or computer equipment
originator of a message (message authentication) or as the in which the Device operates. Often, the IAP -- which will be
end-point of a channel (entity authentication). a wireless carrier, an Internet Service Provider, or an
internal corporate network -- will be identical to the LoSi.
In other cases the IAP has a "dumb" LoSi, one that transmits
geopriv data but does not implement or use any part of the
geopriv Location Object. Other cases may involve no IAP at
all or the IAP is only a Data Transporter.
3.3.3. Authorization Cuellar, Morris, Mulligan 8
Geopriv Requirements Nov 2002
Authorization 3.2.3. Geopriv Data Storage Functions
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 Within the geopriv framework, certain data may be stored in various
Explicit Authentication or not. functional entities:
3.4. Data Flows Rule (or Policy) Storage
A storage used to store privacy-protecting policies, and
perhaps identifiers, credentials or keys. A Private Rule
Storage could be operated by a Device, a Location Server, or a
third party service provider.
Figure 1 presents the entities of a "typical" protocol setting, using How policies are authenticated and otherwise protected is outside of
the Location Object and the data flows between those entities. Not the scope of this document, but see the remarks in Section 6
all steps discussed here necessarily occur in every scenario. The (Privacy Considerations).
data flows may be one-step message exchanges, or multi-step sub-
protocols and the actual transport of the Location Object may be done
via some other transport entities not included in the diagram. The
data flows to be considered by the geopriv WG, in the sense that WG
will assess their authentication, authorization and privacy
requirements, are the following. They are shown in Figure 1 by
normal arrows ("--->")
LI (Location Information): Location Storage:
the location data source sends the "full" location information A Device or entity that stores raw or processed Location
to the location server. Then the location server sends the Information for any period of time longer than the duration
full or filtered location information to the Location necessary to complete an immediate transaction regarding the
Recipient. The information may be filtered in the sense that LI.
in general a less precise or a computed version of the
information is being delivered.
Pol (Policy): The existence and data storage practices of Location Storage is
The Rule Maker(or in particular, the target itself) sends a crucial to privacy considerations, because this may influence what
Policy to the location server. Location Information could eventually be revealed (through later
distribution, technical breach, or legal processes).
Cuellar, Morris, Mulligan Expires Dec 2002 10 3.3. Privacy Policies and Rules
Geopriv Requirements June 2002
PolInfo (Policy Information): Privacy Policies are rules that regulate an entity's activities with
the server informs the Location Seeker which data type(s) of respect to location and other information, including, but not
filtered location information are available to him for a given limited to, the collection, use, disclosure, and retention of
target. This mechanism must be able to be invoked by the location information. Such rules are generally based on fair
Location Seeker before he sends an LRequest. information practices, as detailed in (for example) the OECD
Guidelines on the Protection of Privacy and Transporter Flows of
Personal Data [OECD].
LRequest (Location Information Request): Privacy Policy or Privacy Rule:
the Location Seeker requests location information for a A rule or set of rules that regulate an entity's activities
target, a given class of targets, or for targets with a with respect to location information, including the
particular set of attributes. In this request, the Location collection, use, disclosure, and retention of location
Seeker may select which location information data type it information. In particular, the policy describes how location
prefers. The Location Seeker can also specify the need for information may be used by an entity and which transformed
periodic location information updates. location information may be released to which entities under
which conditions. Policies must be obeyed; they are not
advisory.
+---------+ Locate +-----------+ A full set of Privacy Rules will likely include both rules that have
| Location|<************| Location | SPol +------------+ only one possible technical meaning, and rules that will be affected
| Data | LI | Server + |<*************| Public | by a locality's prevailing laws and customs. For example, a
| Source |------------>| Private | * | Policy | distribution rule of the form "my location can only be disclosed to
| + IAP | | Repository|<---\ * | Repository | the owner of such credentials and in such accuracy" has clear-cut
+---------+ +-----------+ | * +------------+
^ | | | * ^
LRequest| |LI |PolInfo | * * SPol
| V V | * *
+----------+ +-----------+ | * *
| Target | | Location |<**+****/ +----------+
| or |<***********>| Server + | | | |
|Rule Maker| Service | Private | | <-----------|Rule Maker|
+----------+ | Repository|<--/ Pol | |
^ +-----------+ +----------+
* ^ | |
* LRequest| |LI |PolInfo
* | V V
* +----------+
* | Ultimate |
******************>| Location |
Service | Recipient|
+----------+
Figure 1: The Entities and Data Flows Cuellar, Morris, Mulligan 9
Geopriv Requirements Nov 2002
The following Data Flows MAY be outside of the scope of the geopriv implications for the protocol that uses the LO. But other rules,
WG, but should be mentioned for understandability. They are shown in like retention or usage policies, may have unclear technical
Figure 1 as while starred arrows ("***>"). 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.
Service: (Service Information, Negotiation and Delivery): 3.4. Identifiers, Authentication and Authorization
The target (or the Rule Maker) and the client exchange
information about the service and negotiate it. The client
provides service delivery to the target and accounting or
billing data, as necessary.
Cuellar, Morris, Mulligan Expires Dec 2002 11 Anonymity is the property of being not identifiable (within a set of
Geopriv Requirements June 2002 subjects). Anonymity serves as the base case for privacy: without
the ability to remain anonymous, individuals cannot 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.
SPol (Signed Policy): Unlinked Pseudonym:
As an alternative to Pol, the Rule Maker may write a policy A pseudonym where the linking between the pseudonym and its
and place it in the Open Repository. The entities access the holder is, at least initially, not known to anybody with the
repository via SPol. possible exception of the holder himself or a trusted server
of the user. See [Pfi01] (there the term is called Initially
Unlinked Pseudonym)
Locate: The word authentication is used in different meanings. Some require
Request to locate the target. When a Location Server receives that authentication associates an entity with a more or less well-
an LRequest for a target for which has no current location known identity. This basically means that if A authenticates
information, the server may send this "Locate" request to the another entity B as being "id-B", then the label "id-B" is a well-
Location Data Source. 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":
3.4.1. Relationship framework 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.).
Location information can be used in very different environments. In Authorization
some cases the participants will have longstanding relationships The act of determining if a particular right, such as access
while in others participants may have discrete interactions. to some resource, can be granted to the presenter of a
particular credential.
The different relationships raise different concerns for the Depending on the type of credential, authorization may imply
implementation of privacy rules, including the need to communicate Explicit Authentication or not.
privacy instructions. A public rule repository for example seems to
be superfluous in a trusted environment where more efficient methods
of addressing privacy issues likely exist. We propose the following
attributes as modifiers to a given data flow:
Trusted: Cuellar, Morris, Mulligan 10
The data flow is governed by a contract that protects location Geopriv Requirements Nov 2002
privacy.
Non-trusted: 4. Scenarios and Explanatory Discussion
The data flow is not governed by a contract that protects
location privacy.
3.4.2. Scenarios of Data Flow 4.1. Scenarios of Data Flow
In this subsection we introduce two short scenarios to illustrate how In this subsection we introduce short scenarios to illustrate how
these terms and attributes describe location information these terms and attributes describe location information
transactions. transactions.
SCENARIO 1: GPS Device with Internal Computing Power: Closed System SCENARIO 1: GPS Device with Internal Computing Power: Closed System
In this example, the target wishes to know his/her location using In this example, the Target wishes to know his/her location using
Global Positioning System (GPS) and the device is capable of Global Positioning System (GPS) and the Device is capable of
independently processing the raw data to determine its location. The independently processing the raw data to determine its location.
location is derived as follows: the device receives transmissions The location is derived as follows: the Device receives
from the GPS satellites, internally computes and displays location. transmissions from the GPS satellites, internally computes and
This is a closed system. For the purpose of this and subsequent displays location. This is a closed system. For the purpose of this
examples, it is assumed that the GPS satellite broadcasts some and subsequent examples, it is assumed that the GPS satellite
signal, and has no information about the identity or whereabouts of broadcasts some signal, and has no information about the identity or
devices using the signal. whereabouts of Devices using the signal.
Cuellar, Morris, Mulligan Expires Dec 2002 12
Geopriv Requirements June 2002
GPS Satellite GPS Satellite
| |
| |
| |
| |
V GPS Device V GPS Device
-------------------------------------------------- --------------------------------------------------
/ \ / \
| Data ----- Location ----- Location | | Data ----- Location ----- Location |
skipping to change at line 655 skipping to change at line 583
| |
------------|------ ------------|------
/ V \ / V \
/ Target Location \ / Target Location \
| Seeker | | Seeker |
| | | |
\ Rule Maker / \ Rule Maker /
\ / \ /
------------------- -------------------
In this scenario the GPS device is both the IAP and the LoSi. The In this scenario the GPS Device is both the IAP and the LoSi. The
interaction occurs in a Trusted environment because it occurs in the interaction occurs in a Trusted environment because it occurs in the
Rule Maker’s device. Rule MakerÆs Device.
SCENARIO 2: Cell Phone Roaming SCENARIO 2: Cell Phone Roaming
In this example, a cell phone is used outside its home service area In this example, a cell phone is used outside its home service area
(roaming). Also, the cell phone service provider (cell phone Corp 2) (roaming). Also, the cell phone service provider (cell phone Corp 2)
Cuellar, Morris, Mulligan 11
Geopriv Requirements Nov 2002
outsourced the accounting of cell phone usage. The cell phone is not outsourced the accounting of cell phone usage. The cell phone is not
GPS-enabled. Location is derived by the cell phone network in which 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 the Target and Device are roaming. When the Target wishes to use
cell phone, cell phone Corp 1 (IAP) provides the roaming service for the cell phone, cell phone Corp 1 (IAP) provides the roaming service
the target, which sends the raw data about usage (e.g., duration of for the Target, which sends the raw data about usage (e.g., duration
call, location ­ roaming network, etc.) to cell phone Corp 2, the of call, location ¡ roaming network, etc.) to cell phone Corp 2, the
home service provider. Cell phone Corp 2 submits the raw data to the home service provider. Cell phone Corp 2 submits the raw data to
accounting company which processes the raw data for the accounting the accounting company, which processes the raw data for the
statements. Finally, the raw data is sent to a data warehouse where accounting statements. Finally, the raw data is sent to a data
the raw data is stored in a location server (e.g., computer server). warehouse where the raw data is stored in a Location Server (e.g.,
computer server).
Cuellar, Morris, Mulligan Expires Dec 2002 13
Geopriv Requirements June 2002
Cell Phone Corp 1 Cell Phone Corp 2 Cell Phone Corp 1 Cell Phone Corp 2
----------------- ----------------- ----------------- -----------------
Sighting / \ Sighting / \ Sighting / \ Sighting / \
Device --- | Data Transporter| --------- | Data Transporter | Device ----- | Data Transporter | --------- | Data Transporter |
\ / \ / Target \ / \ /
----------------- / ----------------- ----------------- / -----------------
Target / | / |
/ sighting| / sighting|
/ | / |
----------- | ----------- |
/ V / V
------------ / ---------- ------------ / ----------
/ \ / / \ / \ / / \
/ Location \ / | Location | / Location \ / | Location |
| Storage | Location Info | Storage | | Storage | Location Info | Storage |
| |<----------------- | | | |<----------------- | |
| Location | | Location | | Location | | Location |
skipping to change at line 705 skipping to change at line 635
\ / \ / \ / \ /
------------- ---------- ------------- ----------
Here cell phone corp 1 is the IAP and the LoSi. Cell phone corp 1 Here cell phone corp 1 is the IAP and the LoSi. Cell phone corp 1
could be Non-trusted (the Rule Maker does not have a contract could be Non-trusted (the Rule Maker does not have a contract
protecting location information with corp 1 and there is no protecting location information with corp 1 and there is no
contractual relationship with privacy provisions between corp 1 and contractual relationship with privacy provisions between corp 1 and
corp 2) or Trusted (contract with privacy protections between cell corp 2) or Trusted (contract with privacy protections between cell
phone corp 2 and corp 1). Cell phone corp 2 is Trusted. phone corp 2 and corp 1). Cell phone corp 2 is Trusted.
3.5. Further explanations SCENARIO 3: Mobile Communities and Location-Based Services
<Note: Although this section is relevant to the requirements, it The figure below shows a common scenario, where a user wants to find
could probably be condensed.> 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, Policies and Location
Data Information, including Data Types and Accuracy. They are shown
in the figure by normal arrows ("--->"). Other messages do not use
3.5.1. Location Data Types Cuellar, Morris, Mulligan 12
Geopriv Requirements Nov 2002
Two apparently different data types may contain the same information the Location Object and are outside of the scope of the geopriv WG,
if it is possible to transform one data type into the other and vice- but should be mentioned for understandability. They are shown in
versa without information loss. the figure as starred arrows ("***>").
One location data type DT1 may contain more location information than +---------+ +------------+
another DT2 in at least two different senses: | Location| | Public |
| Data |<** | Policy |
| Source | * | Repository |
| + IAP | * +------------+
+---------+\ * * *
^ \ *5 3a* *
* \ * * *
* \ ** *
* \ * * *3a
5a * \* * *
* * \ * *
* * \ * *
* * \6 * *
+----------+ * \ * V
| Target | * \->+-----------+
| +----------+ 3 | Location |
+-| Rule |--------------------->| Server + |
| Maker | | Private |
+----------+<********************>| Repository|
^ 1 +-----------+
| ^ |
| 4| |7
| | V
| +----------+
| | Ultimate |
+---------------------------->| Location |
2 | Recipient|
+----------+
- DT1 may have the same dimensions as DT2 has, plus some extra Figure 1: The Entities and Data Flows
ones. (For instance, DT1 contains velocity, while DT2 does
not).
- DT1 may be more accurate than DT2. 1: Registration:
The Rule Maker registers himself and the Target with the
Location Server. This registration process is outside of the
scope of our discussion, but probably the Rule Maker has to
prove 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 agree, as part
of the Registration Process, which keys or credentials and
proof-of-possession of the corresponding secrets they will use
to authenticate each other, and in particular, to authenticate
or sign the policies, or how they will agree on them or renew
those keys or credentials.
Cuellar, Morris, Mulligan Expires Dec 2002 14 Cuellar, Morris, Mulligan 13
Geopriv Requirements June 2002 Geopriv Requirements Nov 2002
In general, if DT1 has more information than DT2, then there is one a 2: End-to-End Negotiation:
function that "translates correctly" from DT1 to DT2. There are The Rule Maker and the Location Seeker exchange information
other types of transformations that introduce errors (obfuscation: about the service (if any) and negotiate it. They also
intentionally make the location values less accurate by adding negotiate the pseudonyms that they will use later on and the
randomness). During a transformation, information can be lost, but credentials or keys that the Ultimate Location Recipient will
not gained. Of course, a transformation that merges information from use to prove his authorization to the Location Server. This
several sources clearly increases the information of each one. Thus End-to-End Negotiation may contain several messages and may
a transformation is a filtering of information. For instance there use or not the Location Object.
are transformation functions from both data types "(latitude,
longitude, altitude)" and "(country, state, province, city)" to the
data types "(country, state)" and "time zone", but not vice-versa.
Notice that if the space regions determined by different location 3: Policy Transfer:
values of DT2 do not overlap, then there is at most one The Rule Maker sends a Policy to the Location Server. This
transformation from DT1 to DT2. If the space regions of DT2 overlap, Policy may be a field in a Location Object or not.
then usually there is some choice, which can be given by a (pseudo-)
random function.
If DT1 does not have more information than DT2, then there is no 3a:Signed Policy:
function that "translates correctly" from DT1 to DT2. In other As an alternative to the Policy Transfer, the Rule Maker may
words: there are many functions that translate from DT1 to DT2, but write a policy and place it in the Open Repository. The
all introduce some degree of error. We believe that this kind of entities access the repository to read the signed policies.
functions should be avoided.
3.5.2. Public Global Identities 4: Location Information Request:
The Location Seeker requests location information for a
Target. In this request, the Location Seeker 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
accuracy, and providing proof of possession of the required
credentials. But whether the using protocol understands this
partially filled object as a request, this MAY depend on the
using protocol or on the context. The Location Seeker could
also specify the need for periodic location information
updates, but this is probably out of the scope of geopriv.
If A has some information about a public global identifier "ID" and A 5: Locate:
discloses this information to B, then B may associate this When a Location Server receives an Location Information
information with the same entity as A did. In this way, B may Request for a Target for which has no current location
accumulate information about the entity labeled by "ID". information, the server may send ask the Location Sighter to
locate the Target.
A public identity is a well-known label that identifies an entity for 6: Location Information:
a (rather large) group of entities. The Location Sighter sends the "full" location information to
the Location Server. This Location Information may be
embedded in a Location Object or not.
A public identity may be the subscription identity at the home domain 7: Filtered Location Information:
(if applicable), a well-known identity (name, address or Tel Number), Then the Location Server sends the location information to the
etc. Location Recipient. The information may be filtered in the
sense that in general a less precise or a computed version of
the information is being delivered.
An entity may regard the disclosure of his public identity (in 5. Requirements
connection with some activity of him, his location or other
attribute) as a violation of his privacy right.
3.5.3. Authorization without Explicit Authentication Cuellar, Morris, Mulligan 14
Geopriv Requirements Nov 2002
In order to remain anonymous, an entity may use private identifiers. 5.1. Location Object
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.
Cuellar, Morris, Mulligan Expires Dec 2002 15 Req. 1. (Location Object generalities)
Geopriv Requirements June 2002
Short-lived identifier 1.1) Geopriv MUST define one Location Object (LO) -- both in
an identifier that is used only for one or a limited number of syntax and semantics -- that must be supported by all geopriv
"sessions". entities.
Short-lived identifiers may be used to anonymously authenticate 1.2) Some fields of the Location Object MAY be optional. This
entities in some settings. means that an instance of a Location Object MAY contain the
fields or not.
In many situations, including pre-paid services, token-based or role- 1.3) Some fields of the Location Object MAY be defined as
based authorizations, unauthenticated key agreement, and purpose- "extensions". This means that the syntax or semantics of these
based identifiers, there is no need for explicit authentication. fields is not fully defined in the basic Location Object
definition, but their use may be private to one or more using
protocols.
Using weaker forms of authentication, the communication partner may 1.4) The Location Object MUST be extensible, allowing the
still want to make sure that he is communicating to the same entity definition of new attributes or fields.
during the whole session, or that he is communicating with an
authorized entity. Thus message authentication codes are used, based
on "unauthenticated keys".
Authorization credentials may be used in the same way as 1.5) The object MUST be suitable for requesting and receiving a
authentication credentials to secure a key agreement in the following location.
sense: one party is assured that no other party aside from the owner
of the authorization credentials (and possibly additional identified
trusted parties) may gain access to the agreed secret key. The
resulting keys are called authorized keys. Those keys may be used
for message authentication, without implying an explicit
authentication.
In real life this corresponds for instance to the following 1.6) The object MUST permit (but not require) the policy to be
situation: at a cloakroom a person deposits his coat and receives a enforced by a third party.
credential that he may use later to obtain back the coat.
One possible goal of the Rule Maker is to hide the identity of the 1.7) The object MUST be usable in a variety of protocols, such as
Location Recipient to the Location Server. Nevertheless, the HTTP and SIP, as well as local APIs.
Location Server has to be sure that the Rule Maker has authorized the
Recipient to access the location. This is a case of authorization
without explicit authentication: the Location Server has to be sure
that the Location Recipient is a particular (i.e., authorized)
communication partner of the Rule Maker.
This may be done for instance as follows: consider a Location Seeker 1.8) The object MUST be usable in a secure manner even by
that obtains a set of "traveller's cheques" from the Rule Maker. The applications on constrained devices.
cheques will be used to "buy" location information from a Location
Service. Initially, the Location Seeker signs for a first time the
cheques with any "signature" that he wants to use. The Rule Maker,
through his own signature, authorizes the signature of the Location
Seeker. When presented to the Location Server, the cheques may be
countersigned so that the server is sure that the signer is the same
as the one who was authorized by the Rule Maker. This
countersignature does not only authenticate the Location Seeker to
the verifier, but also indirectly to the Rule Maker, when the cheque
is later presented to him. Incidentally, the Rule Maker may achieve
full information about who has accessed to his location information.
Cuellar, Morris, Mulligan Expires Dec 2002 16 Req. 2. (Location Object fields) The Location Object MUST support
Geopriv Requirements June 2002 the following (eventually optional) Fields
To hide the real identity of the Rule Maker to the Location Server, 2.1) Target Identifier.
the following dual solution can be used. The Rule Maker buys (say,
using e-cash) a service from a Location Seeker (e.g., a navigation
service). During this transaction, the Location Seeker and the Rule
Maker agree on one or several pseudonyms and a set of "traveller's
cheques" that the target may use later to authenticate himself to the
server and thus indirectly also to the Location Seeker.
Since e-cash protocols may be also anonymous, this may be used to
hide simultaneously,
o the identity of the target from the Location Server, 2.2) Location Recipient Identity
o the identity of the Location Seeker from the Location
Server,
o the identity of the target from the Location Seeker.
But notice that the Location Data Source is in general not able to This identity may be a multicast or group identity, used to
localize the target based on some short-lived identifier. In this include the Location Object in multicast-based using protocols.
scenario, the Location Data Source should be a Location Server, a
different one from the one from whom the identity of the target is to
be hidden.
4. Requirements 2.3) Location Recipient Credential
4.1. Protocols 2.4) Location Recipient Proof-of-Possession of the Credential
Req. 1. The geopriv protocol MUST be an embedded protocol: it 2.5) Location Field.
defines a Location Object (LO), together with the security
mechanisms used to secure it. The security mechanisms are
of two types: on one hand the Location Object as such is
secured, using cryptographic checksums or encryption as
part of the Location Object itself, and on the other hand
security mechanisms may be provided by the embedding using
<or usage?> protocol that uses the Location Object. If
possible, security mechanisms on the Location Object itself
are to be preferred.
We refer to the embedded protocol also as the geopriv protocol and to Each Location Field may contain one or more Location
the combination of both the embedded protocol and the using <usage?> Representations, which can be also in different formats.
protocol as the combined protocol.
4.2. Policy based Location Data transfer Cuellar, Morris, Mulligan 15
Geopriv Requirements Nov 2002
Req. 2. The decision of a Location Server to provide a Location 2.6) Location Data Type
Seeker access to location information is based on Rule
Maker-defined privacy policies.
Req. 3. The Location Data Source may be unaware of the full When transmitting the Location Object, the sender and the
policies defined by the Rule Maker, but in that case it receiver must agree on the data type of the location information.
will have to obey another set of "generic" policies, The using protocol may specify that the data type information is
consented to by the Rule Maker, to transfer Location Data part of the Location Object or that sender and receiver have
(raw or not) to another entity. agreed on it before the actual data transfer.
Cuellar, Morris, Mulligan Expires Dec 2002 17 2.7) Motion and direction vectors
Geopriv Requirements June 2002
Req. 4. An Ultimate Location Recipient does not need to be aware 2.8) Timing information:
of the full policies defined by the Rule Maker, but it will (a) When was the LI accurate? (sighting time)
obey a set of policies regarding the use and retention of (b) Until when considered current? TTL (Time-to-live) (This is
the location information. different than a privacy rule setting a limit on data retention)
Req. 5. The "generic" policies (as opposed to the policies 2.9) Policy Field: this field MAY be a referral to an applicable
created by the Rule Maker) used by the Location Data policy (for instance, an URI to a full policy) or it MAY contain
Source, by the Ultimate Location Recipients and by the a Limited Policy (see Req. 9).
Location Server of some special scenarios MUST be made
explicit.
Req. 6. The combined protocol MAY specify a policy language. 2.10) Security-headers and -trailers (for instance encryption
This policy language MAY be an existing one, an adaptation information, hashes, or signatures) (see Req. 13).
of an existing one or a new policy language.
If specified, the policy language MUST be strong enough to 2.11) Version number
express policies of the form: a group G of clients are
allowed to know a certain transformation A of the location
L of a target together with a given identifier I of the
target for a given purpose, for a given period of time.
If specified, the policy language MUST be strong enough to Req. 3. (Location Data Types)
express conditions on G and A as follows:
G, the group of clients SHOULD be characterized by the
possession of (identifiers, credentials) with a certain
syntactic property.
A, the transformation function MAY be specified by data
type of the expected filtered location information.
Within those constraints, the policy language SHOULD be as 3.1) The Location Object MUST define at least one Location Data
simple as possible, or it SHOULD be an existing policy Type to be supported by all geopriv receivers (entities that
language. receive LOs).
4.3. Location Object, Location Field 3.2) The Location Object SHOULD define two Location Data Types:
one for latitude / longitude / altitude coordinates and one for
civil locations (City, Street, Number) supported by all geopriv
receivers (entities that receive LOs).
The Location Object has at least the following optional fields 3.3) The latitude / longitude / altitude Data Type SHOULD also
(attributes): Identifier, Location, Location Data Type, Policy, support a delta format in addition to an absolute one, used for
Request, and Version. The definition of the Location Object should the purpose of reducing the size of the packages or the security
be flexible enough to accommodate new application-specific fields. and confidentiality needs.
Req. 7. The embedded protocol MUST define one Location Object 3.4) The Location Object definition SHOULD agree on further
(LO) -- both in syntax and semantics -- that must be Location Data Types supported by some geopriv entities and
supported by all geopriv entities. defined by other organizations.
Some fields of the Location Object MAY be optional. This 5.2. The Using Protocol
means that an instance of a Location Object MAY contain the
fields or not.
Some fields of the Location Object MAY be opaque to the Req. 4. The using protocol has to obey the privacy and security
embedded protocol. This means that the syntax and instructions coded in the Location Object and in the
semantics of these fields is not defined in the embedded corresponding Policy Rules regarding the transmission and storage
of the LO.
Cuellar, Morris, Mulligan Expires Dec 2002 18 Cuellar, Morris, Mulligan 16
Geopriv Requirements June 2002 Geopriv Requirements Nov 2002
protocol, but rather it is only clear in the using Req. 5. The using protocol will typically facilitate that the keys
protocol. Nevertheless the embedded protocol MUST know how associated with the credentials are transported to the respective
large the fields are. parties, that is, key agreement is responsibility of the using
protocol.
Req. 8. The Location Object MUST contain one optional Identifier Other requirements on the using protocol are out of the scope of
Field. this document. See also Section 9 (Protocol and LO Issues for later
Consideration)
Req. 9. The embedded protocol MUST define of at least one 5.3. Policy based Location Data Transfer
Location Data Type supported by all geopriv implementations
and entities.
Req. 10. The Location Object MUST contain one optional Location Req. 6. (LServ Policies) The decision of a Location Server to
Field. An instance of a Location Object MAY contain zero, provide a Location Seeker access to Location Information MUST be
one, or several Location Fields. (We also say in this case based on Rule Maker-defined Privacy Policies.
that the LO contains several Locations.) Each Location
Field may contain one or more Location Representations.
<Locations (= Location Fields), and Location Representations are It is outside of our scope how Privacy Policies are managed, how a
discussed further in another draft, draft-morris-geopriv-location- Location Server has access to the Privacy Policies, and if he is or
object-issues-00.txt.> not aware of the full set of rules desired by the Rule-Maker. Note
that it might be that some rules contain private information not
intended for untrusted parties.
When transmitting location information, (LI in Figure 1), the sender Req. 7. (LoSi Policies) Even if a Location Sighter is unaware of
and the receiver must agree on the data type of the location and lacks access to the full Privacy Policies defined by the Rule
information. The combined protocol may specify that the data type Maker, the Location Sighter MUST transmit Location Information in
information is part of the Location Object or that sender and compliance with instructions set by the Rule Maker. Such
receiver have agreed on it before the actual data transfer. compliance MAY be accomplished by the Location Sighter
transmitting LI only to a URI designated by the Rule Maker.
Req. 11. The Location Object MUST contain one optional Location Req. 8. (ULR Policies) An Ultimate Location Recipient does not need
Data Type Field. The Location Data Type Field may be used to be aware of the full policies defined by the Rule Maker
to specify the type of a Location Field or Location (because an ULR SHOULD NOT retransmit Location Information), and
Representation, or to request a Location Field of this thus an ULR SHOULD receive only the subset of Privacy Policies
particular type. necessary for the ULR to handle the LI in compliance with the
full Privacy Policies (such as, for example, an instruction on
the time period for which then LI can be retained).
Req. 12. The Location Object MUST contain one optional Policy Req. 9. (Full Policy language) Geopriv MAY specify a policy
Field. language capable of expressing a wide range of privacy rules
concerning location information. This policy language MAY be an
existing one, an adaptation of an existing one or a new policy
language, and it SHOULD be as simple as possible.
Req. 13. The Location Object MUST contain a version number. Req. 10. (Limited Policy language) Geopriv MUST specify a limited
policy language capable of expressing a limited set of privacy
rules concerning location information. This policy language MAY
be an existing one, an adaptation of an existing one or a new
policy language. The Location Object MUST include sufficient
fields and data to express the limited set of privacy rules.
Req. 14. The protocol MUST be extensible, allowing the 5.4. Location Object Privacy and Security
definition of new attributes in the Location Object.
4.4. Requests Cuellar, Morris, Mulligan 17
Geopriv Requirements Nov 2002
Req. 15. The Location Object MUST contain one optional Request 5.5. Identity Protection
Field, encoding the type of remote request. Examples of
remote requests are: "send me the location information in a
given format", "send me a pseudonym to be used later",
"send me a pseudonym to be used later", "confirm the
purpose built key", etc.
4.5. Identity Protection Req. 11. (Identity Protection) The Location Object MUST support use
of Unlinked Pseudonyms in the corresponding identification fields
of Rule Maker, Target, Device, and Location Recipient. Since
Unlinked Pseudonyms are simply bit strings that are not linked
initially to a well-known identity, this requirement boils down
to saying that the name space for Identifiers used in the LO has
to be large enough to contain many unused strings.
Cuellar, Morris, Mulligan Expires Dec 2002 19 5.6. Authentication Requirements
Geopriv Requirements June 2002
Req. 16. The combined protocol MUST be able to hide the real Req. 12. (Credential Requirements) The using protocol and the
identity or linkable identifiers associated with the real Location Object SHOULD allow the use of different credentials
identity of the Rule Maker, the target, and the device from types, including privacy-enhancing credentials (like for instance
the Ultimate Location Recipient. the ones described in [Bra00] or [Cha85]).
This may be easily done using short-lived identifiers. 5.7. Actions to be secured
Req. 17. The combined protocol MUST be able to hide the real Req. 13. (Security Features) The Location Object MUST support
identity of the Rule Maker to a Location Seeker, including fields suitable for protecting the Object to provide the
a Location Server. following security features:
Req. 18. The combined protocol MUST be able to hide the real 13.1) Mutual end-point authentication: the using protocol is
identity of the Location Recipient to the Location Server. able to authenticate both parties in a Location Object
transmission,
Thus here the target is not concerned about the Server identifying 13.2) Data object integrity: the LO is secured from
him and knowing his location, but identifying his business partners, modification by unauthorized entities during transmission and
and therefore his habits, etc. One reason for hiding the real during storage,
identities of the Location Recipients may be that this knowledge may
be used to infer the identity of the target. Or perhaps I have just
asked a certain organization (say, a political party or a night club)
to send me driving directions, but it could be embarrassing for me if
certain people find out that I have some relationship to that
organization. I do not want to let the Location Server know about
this. Even if my Server is trustworthy, it would be better if this
explicit information was never disclosed to anybody. Another reason
for not wanting the Server to know the real identity of the location
recipients is that the dossier telling who has obtained my location
information over a long period of time gives quite a lot of
information on my habits, movements, etc. Even if the location
service providers agree to respect the privacy of the user, are
compelled by laws or regulations to protect the privacy of the user,
and misbehavior or negligence of the Location Server can be ruled
out, there is still a chance that personal data may become available
to unauthorized persons through attacks from outsiders, unauthorized
access from insiders, or technical or human errors.
Req. 19. When a Location Server accepts a policy from the Rule 13.3) Data object confidentiality: the LO is secured from
Maker, the target MUST prove to the combined protocol that eavesdropping (unauthorized reading) during transmission and
he owns the claimed group or role identifier that should be during storage, and
passed to the Location Recipient.
For instance, if a Target wants the role identifier "medical doctor" 13.4) Replay protection: an old LO may not be replayed by an
to be passed to a Location Recipient, the Target must prove the adversary or by the same entity that used the LO itself (except
claims to be a medical doctor. <But probably group or role perhaps during a small window of time that is configurable or
identifiers will be discouraged in geopriv.> accepted by the Rule Maker).
4.6. Authentication Requirements Req. 14. (Minimal Crypto)
Req. 20. The combined protocol MUST allow different 14.1) Geopriv MUST specify a minimum mandatory to implement
authentication schemes. The combined protocol MUST Location Object security including mandatory to implement crypto
guarantee that appropriate keys (shared or asymmetric) are algorithms, for digital signature algorithms and encryption
algorithms.
Cuellar, Morris, Mulligan Expires Dec 2002 20 14.2) It MAY also define further mandatory to implement
Geopriv Requirements June 2002 Location Object security mechanisms for message authentication
codes (MACs) or other purposes.
generated and available to secure the Location Object Cuellar, Morris, Mulligan 18
within the embedded protocol. Geopriv Requirements Nov 2002
Req. 21. The combined protocol MUST allow authorization without 14.3) The protocol SHOULD allow a bypass if authentication
explicit authentication. fails in an emergency call.
4.7. Actions to be secured The issue addressed in the last point is that an emergency call in
some very unfavorable situations my not be completed if the minimal
authentication fails. This is probably not what the user would like
to see. The user may prefer an unauthenticated call to an
unauthenticated emergency server than no call completion at all,
even at the risk that he is talking to an attacker or that his
information is not secured.
Req. 22. The embedded protocol MUST be able to secure the 5.8. Non-Requirements
Location Object for the following message flows (mutual
end-point authentication, data object integrity, data
object confidentiality, replay protection, in the absence
of a time parameter): LI, Pol, LIF, LRequest, and PolInfo.
Req. 23. The embedded protocol MUST specify a minimum mandatory Non-Req. 1. (Bridging to non-IP networks) The geopriv specification
to implement Location Object security including mandatory SHOULD NOT specify the bridging to non-IP networks (PSTN, etc).
to implement crypto transforms.
Req. 24. The embedding protocol MAY provide extra security for 6. Security Considerations
these flows (hop-by-hop or end-to-end).
In full details, these requirements have many consequences: the The purpose of the geopriv Location Object and the requirements on
communicating parties MUST have security relationships between them, the using protocol are to allow a policy-controlled disclosure of
allowing them to construct secure channels between them. This may location information for location services.
imply that some scenarios should not be permitted in general. The
Rule Maker MAY choose to use the security provided by the embedded or
by the embedding protocol, or none.
4.8. Non-Requirements 6.1. Traffic Analysis
Req. 25. The geopriv specification SHOULD NOT specify the The information carried within the Location Object is secured in a
bridging to non-IP networks (PSTN, etc). way compliant with the privacy and security policies of the Rule
Maker, but other information, carried in other objects or headers
are in general not secured in the same way. This means that geopriv
does not as a general matter secure the Target against general
traffic analysis attacks or other forms of privacy violations.
5. Security Considerations 6.2. Securing the Privacy Policies
The purpose of the geopriv protocol is to allow a policy-controlled The Privacy Policies of the Rule Maker regarding the location of the
disclosure of location information for location services. Only the Target may be accessible to a Location Server in a Private Storage
information carried within the Location Object is secured in a way or in a Public Repository, or they may be carried by the Location
compliant with the privacy and security policies of the target. This Object, or they may be presented by the Location Seeker as
does not mean that geopriv secures the target against general traffic capabilities or tokens. Each of this types of policy has to be
analysis attacks or other forms of privacy violations. secured itÆs own particular way.
The Location Server is assumed to be trustworthy. The rules in a Private Storage are typically authenticated using a
MAC (Message Authentication Code) or a signature, depending on the
type of keys used. The rules in a Public Repository (one that in
principle may be accessed directly by several entities, for instance
several Location Servers) are typically digitally signed. A Policy
Field in a LO is secured as part of the LO itself. A Geopriv Token
(a token or ticket issued by the Rule Maker to a Location Seeker,
expressing the explicit consent of the Rule Maker to access his
location information) is authenticated or signed.
6. Acknowledgements Cuellar, Morris, Mulligan 19
Geopriv Requirements Nov 2002
6.3. Emergency Case
One way of implementing the authentication bypass for emergency
calls, mentioned in Req 14.3) is to let the user have the choice of
writing a policy that says:
- "If the emergency server does not authenticate itself,
nevertheless send the location", or
- "If the emergency server does not authenticate itself, let the
call fail".
In the case where the authentication of the emergency call fails
because the user may not authenticate itself, the question arises:
whose policy to use? It is reasonable to use a default one: this
location information can only be sent to an emergency center.
Another situation, which should be studied in more detail is: what
to do if not only the user fails to authenticate itself, but also
the emergency center is not authenticable? It is reasonable to send
the Location Information anyway, but are there in this case any
security threats that must be considered?
6.4. Identities and Anonymity
The use of Unlinked Pseudonyms is necessary to obtain anonymity.
The purpose of the use of Unlinked Pseudonyms is the following: the
using protocol should be able to hide the real identity of the Rule
Maker, the Target, and the Device, the and to Location Servers or
Location Recipients. Also, the using protocol SHOULD be able to
hide the real identity of the Location Recipient to the Location
Server.
In this last case, the Target is not concerned about the Server
identifying him and knowing his location, but identifying his
business partners, and therefore his habits, etc. Reasons for
hiding the real identities of the Location Recipients include (a)
that this knowledge may be used to infer the identity of the Target,
(b) that knowledge of the identity of the Location Recipient may
embarrass the Target or breach confidential information, and (c)
that the dossier telling who has obtained a Target's location
information over a long period of time can give information on
habits, movements, etc. Even if the location service providers
agree to respect the privacy of the user, are compelled by laws or
regulations to protect the privacy of the user, and misbehavior or
negligence of the Location Server can be ruled out, there is still
risk that personal data may become available to unauthorized persons
through attacks from outsiders, unauthorized access from insiders,
technical or human errors, or legal processes.
In some occasions a Location Server has to know who is supplying
policies for a particular Target, but in other situations it could
Cuellar, Morris, Mulligan 20
Geopriv Requirements Nov 2002
be enough to know that the supplier of the policies is authorized to
do so. Those considerations are outside of our scope.
6.5. Unintended Target
An Unintended Target is 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.
7. Acknowledgements
We wish to thank the members of the IETF geopriv WG for their We wish to thank the members of the IETF geopriv WG for their
comments and suggestions. Detailed comments or text were provided by comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison
Aaron Burstein, Mehmet Ersue, Allison Mankin, Randall Gellens, and Mankin, Randall Gellens, Jon Peterson, and the participants of the
the participants of the geopriv interim meeting in San Diego. geopriv meetings in San Diego and Yokohama provided detailed
comments or text.
Cuellar, Morris, Mulligan Expires Dec 2002 21 8. References
Geopriv Requirements June 2002
7. References [Bra00] Stefan A.: Rethinking Public Key Infrastructures and Digital
Certificates : Building in Privacy, MIT Press; ISBN:
0262024918; 1st edition, August, 2000
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [Cha85] Chaum, David: Security without Identification, Card
Levels", BCP 14, RFC 2119, March 1997. Computers to make Big Brother Obsolete. Original Verion
appeared in: Communications of the ACM, vol. 28 no. 10,
October 1985 pp. 1030-1044. Revised version available at
http://www.chaum.com/articles/
8. Author's Addresses [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.
[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.
Cuellar, Morris, Mulligan 21
Geopriv Requirements Nov 2002
9. Protocol and LO Issues for later Consideration
It seems important to mention some issues on the Location Object or
on the protocol, which have emerged during the discussion of earlier
versions of this document.
9.1. Single Message Transfer
For several purposes, and in particular for the tracking of small
target devices, the design should not preclude a single
message/packet transmission of location as a complete transaction.
9.2. Multiple Locations in one LO
The possibility of inclusion of multiple locations is discussed in
another draft, draft-morris-geopriv-location-object-issues-00.txt.
An instance of a Location Object could contain zero, one, or several
Location Fields, perhaps in different formats. Several Location
Fields would be used to report the same sighting in different
formats, or multiple sightings at different times, or multiple
sensor locations for the same device, or other purposes.
9.3. Translation Fields
It is possible to include fields to indicate that one of the
locations is a translation of another. If this is done, it is also
possible to have a field to identify the translator, as identity and
method.
9.4. Specifying Desired Accuracy in a Request
If the LO is used to request location information (leaving some
fields empty), it is not clear how to specify the requested
accuracy. Are the data types "country/state/city" and
"country/state" different data types or the same data type with
different "accuracy" or "granularity"?
9.5. Truth Flag
Geopriv should not provide an attribute in object saying "I'm not
telling you the whole truth."
9.6. Timing Information Format
The format of timing information is out of the scope of this
document.
9.7. The Name Space of Identifiers
Cuellar, Morris, Mulligan 22
Geopriv Requirements Nov 2002
Who defines the Identities: may the using protocol define the
Identifiers or must the using protocol use and authenticate
Pseudonyms proposed by the policies, chosen independently of the
using protocol? Of course, if the using protocol has an appropriate
namespace, containing many unused names that may be used as
pseudonyms and may be replaced by new ones regularly, then the
Location Object may be able to use the name space. For this purpose,
the user would probably have to write his policies using this name
space. Note that it is necessary to change the used pseudonyms
regularly, because identifying the user behind an unlinked pseudonym
can be very simple.
There are several advantages of letting the using protocol to define
the name space:
o the embedded authentication would be easier, as the using protocol
has often already the credentials for the authentication identity
in place and the "embedded" authentication would be independent on
the form of Identifiers,
o the size of the names would be fixed.
On the other hand, the benefits of the policy choosing the
identifiers are:
o the user has a control of his anonymity, and
o the interworking of multiple systems with Location object across
protocol boundaries is facilitated.
10. Author's Addresses
Jorge R Cuellar Jorge R Cuellar
Siemens AG Siemens AG
Corporate Technology Corporate Technology
CT IC 3 CT IC 3
81730 Munich Email: Jorge.Cuellar@mchp.siemens.de 81730 Munich Email: Jorge.Cuellar@mchp.siemens.de
Germany Germany
John B. Morris, Jr. John B. Morris, Jr.
Director, Internet Standards, Technology & Policy Project Director, Internet Standards, Technology & Policy Project
skipping to change at line 1138 skipping to change at line 1234
1634 I Street NW, Suite 1100 1634 I Street NW, Suite 1100
Washington, DC 20006 Email: jmorris@cdt.org Washington, DC 20006 Email: jmorris@cdt.org
USA http://www.cdt.org USA http://www.cdt.org
Deirdre K. Mulligan Deirdre K. Mulligan
Samuelson Law, Technology and Public Policy Clinic Samuelson Law, Technology and Public Policy Clinic
Boalt Hall School of Law Boalt Hall School of Law
University of California University of California
Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu
9. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (date). All Rights Reserved.
Cuellar, Morris, Mulligan 23
Geopriv Requirements Nov 2002
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
Cuellar, Morris, Mulligan Expires Dec 2002 22
Geopriv Requirements June 2002
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Cuellar, Morris, Mulligan Expires Dec 2002 23 Cuellar, Morris, Mulligan 24
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/