WDIFF

draft-ietf-geopriv-reqs-00.txt --> draft-ietf-geopriv-reqs-01.txt

view Side-By-Side changes

Internet Draft J. Cuellar
Document: draft-ietf-geopriv-reqs-00.txt draft-ietf-geopriv-reqs-01.txt Siemens AG

John B. Morris, Jr.
Center for Democracy and Technology

D. Mulligan
Samuelson Law, Technology, and Public Policy Clinic

Expires: Dec. 2002 June

Expires in six months November 2002

Geopriv requirements

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

Location-based services, navigation applications, emergency
services, management of equipment in the field, and other location-dependent location-
dependent services need geographic location information about a target (user,
Target (such as a user, resource or other entity). There is a need
to securely gather and transfer location information for location
services, while at the same time protecting the privacy of the
individuals involved.

Cuellar, Morris, Mulligan 1

Geopriv Requirements Nov 2002

This document focuses on the authorization, integrity and privacy
requirements for such location-dependent services. Specifically, it
describes the requirements for the geopriv Location Object (used to
securely transfer location data and perhaps some other

Cuellar, Morris, Mulligan Expires Dec 2002 1

Geopriv Requirements June 2002 privacy-enabling
information) and for further IETF the protocols that use this Location
Object as an embedded protocol. We focus on authorization, integrity
and privacy requirements. Object.

Table of Contents

1. Overview.......................................................2 Overview........................................................3
2. Conventions used in this document..............................4 document...............................4
3. Usage Model....................................................4 Terminology.....................................................4
3.1. Roles Foundational Definitions...................................4
3.1.1. Location Information (LI) and attributes......................................4 Sighting................4
3.1.2. The Location Object...................................6
3.1.3. Location Object vs. Using Protocol....................6
3.1.4. Trusted vs. Non-trusted Data Flows....................6
3.2. Data......................................................8 Geopriv Entities and Functions.............................7
3.2.1. Primary Geopriv Entities..............................7
3.2.2. Secondary Geopriv Entities............................8
3.2.3. Geopriv Data Storage Functions........................9
3.3. Identification, Authentication, Privacy Policies and Authorization.........9
3.3.1. Identifiers..........................................9
3.3.2. Authentication......................................10
3.3.3. Authorization.......................................10 Rules.................................9
3.4. Data Flows...............................................10
3.4.1. Relationship framework..............................12
3.4.2. Identifiers, Authentication and Authorization.............10
4. Scenarios and Explanatory Discussion...........................11
4.1. Scenarios of Data Flow..............................12
3.5. Further explanations.....................................14
3.5.1. Flow....................................11
5. Requirements...................................................14
5.1. Location Data Types.................................14
3.5.2. Public Global Identities............................15
3.5.3. Authorization without Explicit Authentication.......15
4. Requirements..................................................17
4.1. Protocols................................................17
4.2. Object...........................................15
5.2. The Using Protocol........................................16
5.3. Policy based Location Data transfer......................17
4.3. transfer.......................17
5.4. Location Object, Location Field..........................18
4.4. Requests.................................................19
4.5. Object Privacy and Security......................17
5.5. Identity Protection......................................19
4.6. Protection.......................................18
5.6. Authentication Requirements..............................20
4.7. Requirements...............................18
5.7. Actions to be secured....................................21
4.8. Non-Requirements.........................................21
5. Security Considerations.......................................21 secured.....................................18
5.8. Non-Requirements..........................................19
6. Acknowledgements..............................................21 Security Considerations........................................19
6.1. Traffic Analysis..........................................19
6.2. Securing the Privacy Policies.............................19
6.3. Emergency Case............................................20
6.4. Identities and Anonymity..................................20
6.5. Unintended Target.........................................21
7. References....................................................22 Acknowledgements...............................................21
8. Author's Addresses............................................22 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......................................22 Statement......................................23

1. Overview

Location-based services (applications that require geographic
location information as input) are becoming increasingly common.
The collection and transfer of location information about a
particular
device Device and/or target 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 Device's location, and access to
the derived or computed location, are key elements of the location-
based services privacy equation. Central to a target's Target's privacy are
(a) the identity of entities that have access to raw location data,

Cuellar, Morris, Mulligan Expires Dec 2002 2

Geopriv Requirements June 2002
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 privacy policy of the user.

The main principles guiding the requirements described in this paper we assume that "location information" is a relatively
specific way
document are:

1) Security of describing where a device the transmission of Location Object is located essential to
guarantee the integrity and that confidentiality of the location information is either (a) derived or computed from
information generally not available to
information. This includes authenticating 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 sender and latitude information
determined by a device with GPS (global positioning satellite)
capabilities.

Excluded from the discussion below is the determination
receiver of location
information wholly without the knowledge or consent of Location Object, and securing the target (or Location Object
itself.

2) A critical role is played by user-controlled policies, which
describe the target's network restrictions imposed or access service provider), based on generally
available information such permissions given by the
"user" (or, as an IP or e-mail address. It is
important to note defined below, the "Rule Maker"). The policies
specify the necessary conditions that information like IP address can enable someone allow a Location Server to
forward Location Information to roughly or in some instances precisely estimate a location.
Commercial services exist, Location Recipient, and the
conditions under which and purposes for example, that offer which the Location
Information can be used.

3) The Location Object should be able to provide rough
location information based on IP address. Currently, this type carry a limited but core
set of
location information privacy policies. This core set is typically less accurate defined below and has a coarser
granularity than the type of location information addressed
discussed more extensively in this a separate document. This less accurate type of location computation still
raises significant potential privacy and public policy concerns, but
such scenarios are generally outside Beyond the scope
core set of this document.

For privacy policies, the purposes of this document, "policies" user 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
correctness (integrity) and the confidentiality of the location
information. This includes authenticating the main entities of
the protocol and securing the exchanged messages.

2) A critical role is played by user-controlled policies, which
describe the permissions (or consent) given by the user. (In
this introductory section we use the word "user" informally; to
be more precise, instead of "user", we should say "Rule Maker"
but this term has not been introduced yet.) The policies specify
the necessary conditions that allow a Location Server to forward
(transformed or filtered) location information Rule Maker should be
able to define a Location
Recipient and the conditions under which more robust and purposes for which

Cuellar, Morris, Mulligan Expires Dec 2002 3

Geopriv Requirements June 2002

location information can be used. That is, using policies, the
user is able to specify which component or derived measure complex set of the
information is to be released to whom and in which granularity or
accuracy. policies. The
exact form or expressiveness of policies beyond the core set is
not further discussed in this paper.

Cuellar, Morris, Mulligan 3

Geopriv Requirements Nov 2002

4) Whenever possible, appropriate, the location information should not be
linked to the real identity of the user or a static identifier
easily linked back to the real identity of the user (e.g., the
phone number). Rather, the user is should be able to specify which
local identifier, unlinked pseudonym, or private identifier is to
be linked bound to the location information.

5) The user may want to hide the real identities of himself and his
partners not only to eavesdroppers but also to other entities
participating in the protocol.

Although complete anonymity may not be appropriate for some
applications because of legal constraints or because some location
services may in fact need explicit identifications, in most cases
the location services only need some type of authorization
information and/or perhaps anonymous identifiers of the entities in
question.

2. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [1]. [RFC2119].

Note that the requirements discussed here are requirements on privacy the
generic Location Object and on the using protocols for location
services. Thus the requirements sometimes discussed in this document mostly
refer only to the capabilities of these protocols. that are mandatory-to-implement. For
example, requiring that the protocol 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 clearly mandatory-to-use, not just a capability of the protocol. to implement.

3. Usage Model Terminology

The following usage model will be discussed more extensively in
another framework terminology and scenarios document. We present here a summary
of definitions detailed below include both (1)
terms used in the terminology requirements section of this document, and (2)
terms that provide additional detail about the usage model
envisioned for convenience. the geopriv Location Object. These latter terms will
be utilized in a separate scenarios document.

3.1. Roles Foundational Definitions

3.1.1. Location Information (LI) and attributes Sighting

The entities focus of a the geopriv application or scenario may be given
explicit roles:

Target:
The entity whose working group is on information about a
Target's location that is desired NOT based on generally or publicly
available sources, but instead on private information provided or
created by the Location Seeker. a Target, a Target's Device, or a Target's network or
service provider:

Cuellar, Morris, Mulligan Expires Dec 2002 4

Geopriv Requirements June Nov 2002

In many cases the Target will be the human "user"

Location Information (LI):
A relatively specific way of describing where a Device is
located and that is (a) derived or an object such as a vehicle or shipping container computed from information
generally not available to which
the device is attached. In some instances the target will be
the device itself.

Device:
The technical device the location of which is tracked general public (such as
information mainly available to a
proxy for the location of network or service
provider), (b) determined by a Target. A Device might, for
example, that may be not
generally publicly addressable or accessible, or (c) input or
otherwise provided by a Global Positioning Satellite (GPS) receiver, Target.

As examples, LI could include (a) information calculated by
triangulating on a
laptop equipped wireless signal with respect to cell phone
towers, (b) longitude and latitude information determined by a wireless access device,
Device with GPS (global positioning satellite) capabilities, or (c)
information manually entered into a
transmitter that emits a signal that can be tracked cell phone or
located. In some situations there may be no Device, laptop by a Target
in the
sense of this definition, but for instance response to a user query.

Excluded from this definition is entering the determination of location
information manually.

Rule Maker:
The individual wholly without the knowledge or entity who has consent of the authorization to set Target
(or the
applicable privacy rules, collectively known also Target's network or access service provider), based on
generally available information such as the
policy. an IP or e-mail address. In
some cases information like IP address can enable someone to
estimate (at least roughly) a location. Commercial services exist
that offer to provide rough location information based on IP
address. Currently, this type of location information is typically
less accurate and has a coarser granularity than the user who is type of
location information addressed in possession this document. Although this type
of location computation still raises significant potential privacy
and public policy concerns, such scenarios are generally outside the Device, but is some cases it is not. For example,
parents may control what happens to
scope of this document.

Within any given location-based transaction, the INITIAL
determination of location information
derived from their children's cell phones. (and thus the initial creation of Location
Information) is termed a Sighting:

Sighting:
The Rule Maker initial determination of location based on non-public
information (as discussed in the definition of Location
Information), and the initial creation of Location
Information.

Some variant of the sighting information is
often, but not always, included in the "owner" Location
Object. Abstractly, it consists of two separate data fields:

(Identifier, Location)

where Identifier is the Device used identifier assigned to track
location. For example, a company may own Target being
sighted, and provide a cell
phone to an employee but permit him/her to set Location is the privacy
rules. Other proposed names are "Owner (of current position of that Target being
sighted. Not all entities may have access to exactly the privacy
rights)" or "policy maker"

Unintended Target: same piece
of sighting information. A person or object tracked sighting may be transformed to a new
sighting pair:

(Identifier-1, Location-1)

Cuellar, Morris, Mulligan 5

Geopriv Requirements Nov 2002

before it is provided by proximity 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 Target. This
special case most frequently occurs if original value.

3.1.2. The Location Object

A main goal of the target geopriv working group is not to define a
person. For example, the Target may Location
Object (LO), to be a rental car equipped
with a GPS device, used to track car inventory. The rental
company may not care about convey both Location Information and
basic privacy-protecting instructions:

Location Object (LO): This data contains the driver's location, but Location Information
of the
driver's privacy is implicitly affected. Working group
protocols may or may not protect Target, and other fields including an identity or affect
pseudonym of the Target, time information, core privacy
policies, authenticators, etc. Most of
Unintended Targets, but the impact on Unintended Targets
should fields are
optional, including the Location Information itself.

Nothing is said about the semantics of a missing field. For
instance, a partially filled object MAY be acknowledged.

Data Transporter ("DT"):
An entity or sub-network that receives and forwards data
without processing or altering understood implicitly as
the request to complete it. A Data Transporter Or, if no time information is included,
this MAY implicitly mean "at the current time" or "at a very recent
time", but it could
theoretically be involved interpreted in almost any transmission between a
Device and a Location Processor, a different way, depending on
the context.

3.1.3. Location Processor and a
second Location Processor, Object vs. Using Protocol

The "using protocol" is the protocol that uses (creates, reads or a
modifies) the Location Processor and a
Location Seeker. Some location tracking scenarios may 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
involve a Data Transporter.

Location Seeker ("LS")
An individual or entity who seeks to receive location data
about using protocol, but only a Target.

Cuellar, Morris, Mulligan Expires Dec 2002 5

Geopriv Requirements June 2002

Computational Location Server ("CLServ")
A Device or transport
protocol. Nevertheless, the entity that computes or processes raw data to
compute or derive location data, or processes location data to
transform or refine protocol that caused the data into new location data. The
actual computation of location information is beyond geopriv's
scope,
transport protocol to move the distribution of location information LO is not.

Location Storage ("LStor")
(. Location Server: Think responsible of pure storage devices as disks.
They matter for privacy purposes!)
A Device or entity that stores raw or location data. The data the correct
distribution, protection, usage, retention, and storage policy of LStor is crucial to privacy considerations,
because this policy may influence what location information the Rule Maker will reveal. LO.

The different actors in a location
information request create intertwined privacy concerns. If
data about a requester is stored security and correlated with data
about a Target, it may be possible privacy enhancing mechanisms used to infer more information
from protect the aggregate than one or both entity's rules would
allow. Unlinkable identifiers provide LO
are of two types: First, the ideal solution Location Object definition MUST
include (optional) fields or mechanisms used to
this problem, but may secure the LO as
such. The LO MAY be impossible in practice. Stored
identifiers SHOULD use secured, for example, using cryptographic
checksums or encryption as part of the closest possible approximation LO itself. Second, the using
protocol may also provide security mechanisms to
unlinkable identifiers. LStor devices SHOULD follow securely transport
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")
A repository that contains private (authenticated, but not
signed) or public (signed) policies, identifiers, and perhaps
also stores requests.

Roles of Location Information Requesters

An entity that seeks to access the location data is a Location Seeker
and may act in one or more Location Object.

The security mechanisms of the following roles: as the Location
Sighter (Location Object itself are to be
preferred.

3.1.4. Trusted vs. Non-trusted Data Source), as a Location Server, or as an
Ultimate Location Recipient.

Location Sighter (LoSi), or Flows

Location Data Source
The original source of information can be used in very different environments. In
some cases the sighting of a target participants will have longstanding relationships,
while in a given
transaction.

Location Server (LS), or Intermediate Location Recipient:
A Device or entity that provides access to raw data or
location data after processing or altering it or not. Some
location tracking scenarios others participants may not involve a Location Server. have discrete interactions with no
prior contractual or other contact.

Cuellar, Morris, Mulligan Expires Dec 2002 6

Geopriv Requirements June Nov 2002

Ultimate Location Recipient (ULR):
An individual or entity who receives location data about a
Target and does not transmit the location information or
information based on

The different relationships raise different concerns for the Target's location (such as driving
directions to or from
implementation of privacy rules, including the target) need to another party distinct
from the target or the Rule Maker. communicate
privacy policies. A data transporter public Rule Repository, for example, may be an

Initial Access Provider ("IAP"):
unnecessary in a trusted environment where more efficient methods of
addressing privacy issues exist. The following terms distinguish
between the two basic types of data flows:

Trusted Data Flow:
A data transporter flow that provides the initial network access or
other is governed by a pre-existing contractual
relationship that addresses location privacy.

Non-trusted Data Flow:
The data communications services essential for the operation
of communications functions flow is not governed by a pre-existing contractual
relationship that addresses location privacy.

3.2. Geopriv Entities and Functions

The entities of the Device a geopriv application or computer
equipment transaction may be given
explicit roles:

3.2.1. Primary Geopriv Entities

Certain entities and roles are involved in which most (and in some cases
all) geopriv transactions:

Target:
The entity whose location is desired by the Device operates. Often, Location Seeker.
In many cases the IAP --
which Target will be the human "user" of a wireless carrier, an Internet Service
Provider, Device
or an internal corporate network -- will be
identical object such as a vehicle or shipping container to which
the LoSi. Other cases may involve no IAP at all.
But in other Device is attached. In some instances the IAP's infrastructure may Target will be
controlled by another party. In these cases
the IAP could be
seen Device itself.

Device:
The technical device the location of which is tracked as a "dumb" LoSi, one that transmits geopriv data but
does not implement any part of
proxy for the geopriv protocol.

The rules location of the Target may a Target. A Device might, for
example, be accessible to a Location Server in 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
form
Target is effectively performing the function of Private a Device.

Rule Maker:
The individual or Public Rules Repositories:

Public Policy Repository:
A repository where signed policies, identifiers, and perhaps
also requests are stored.

Private Policy Repository:
A repository of authenticated policies, identifiers, entity that has the authorization to set the
applicable privacy policies and
perhaps also requests are stored, for rules. In many cases this
will be the private use owner of one
Location Server.

The following table shows the possible roles Device, and in other cases this may
be the user who is in possession of the geopriv entities. 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.

Cuellar, Morris, Mulligan Expires Dec 2002 7

Geopriv Requirements June Nov 2002

+------------------+-----+------+--------+---------+----------+
| role| IAP | ULR | Public | Private |

Location |
|entity | | | RR | RR | Sighter |
+------------------+-----+------+--------+---------+----------+
|Target | | | | | x |
+------------------+-----+------+--------+---------+----------+
|Device | | | | | x |
+------------------+-----+------+--------+---------+----------+
|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 main (LSeek):
An individual or entity who seeks to receive location data used by
about a Target.

A Location Seeker may act in one or more of the protocol is following more
specialized roles: as the Location Object (LO). It
contains Sighter, a Location Server, or as
an Ultimate Location Recipient:

Location Sighter (LoSi), or Location Data-Source
The original source of 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
main private data accessed by Location Servers and/or Ultimate
Location Recipients. Some variant of the sighting information
is included Target in the Location Object. Abstractly, it consists
of two separate data fields:

(Sighting-Identifier, Location)

Sighting-Identifier is the identifier assigned to a target given
transaction.

Location Server (LServ), or
device being sighted, and Intermediate Location is the current position of
that target Recipient:
A Device or device being sighted.

Not all entities have entity that provides access to exactly Location
Information (possibly after processing or altering it) in
accordance with the same piece privacy policies of
sighting information. The sighting the Rule Maker. Some
location tracking scenarios may be transformed to involve a
new sighting pair:

(Sighting-Identifier-1, Location-1)

before it is provided by the Location Data Source Target, Device, or
Device user performing the function of a Location Server to another Server.

Ultimate Location Recipient.

Cuellar, Morris, Mulligan Expires Dec 2002 8

Geopriv Requirements June 2002

Policy:
A set of rules that regulate an entity's activities with
respect to Recipient (ULR):
An individual or entity who receives location information, including the collection,
use, disclosure, data about a
Target and retention of location information. In
particular, does not transmit the policy describes how location information may
be used by an entity and which transformed location or
information may be released based on the Target's location (such as driving
directions to which entities under which
conditions. Policies contain "rules" or "assertions".
Policies must be obeyed; they are not advisory. To make this
more explicit, from the term "rules" is also used instead of
"policy".

Data attributes:
Filtered:
Location information that has been computationally modified.

3.3. Identification, Authentication, and Authorization

This subsection introduces some terms Target) to be used later in any party OTHER than the
Requirements Section.

3.3.1. Identifiers

The LO has a filed for identification of
Target or the target. Geopriv-
compliant systems MUST implement Rule Maker.

3.2.2. Secondary Geopriv Entities

Certain entities and functions are present or involved in only a means
subset of asserting identities and
inserting geopriv transactions:

Data Transporter:
An entity or network that receives and using the identifiers in the LO, but the LO needs not
use identifiers under all circumstances.

Using protocols should be able to handle LOs with identifiers, LOs forwards data without identifiers, and LOs with pseudonyms. The identity of the
requester may
processing or altering it. A Data Transporter could
theoretically be irrelevant involved in some cases, whereas the identity of
the Target almost any transmission between a
Device and a Location Server, a Location Server and a second
Location Server, or a Location Server and an Ultimate Location
Recipient. Some location tracking scenarios may be irrelevant in others. In particular, geopriv does not suggest that involve a LO with no identifier provides anonymity.

Entity-Identifier:
Data Transporter.

Initial Access Provider (IAP):
The names used by entity that provides the entities initial network access or other
data communications services essential for the operation of
communications functions of the protocol
to identify, authenticate Device or authorize themselves to other
entities. Policies also use entity-identifiers to express computer equipment
in which Location Seekers may receive the Device operates. Often, the IAP -- which transformed sighting
information.

The next type of identifier may not will be used as
a wireless carrier, an Entity-Identifier,
since it can Internet Service Provider, or an
internal corporate network -- will be shared by several, perhaps many, different entities:

Role identifier
("administrator", "member-of-club-A", etc.) The meaning of identical to the
role may be context dependent.
Geopriv will probably LoSi.
In other cases the IAP has a "dumb" LoSi, one that transmits
geopriv data but does not support role identifiers in implement or use any
particular way.

Cuellar, Morris, Mulligan Expires Dec 2002 9 part of the
geopriv Location Object. Other cases may involve no IAP at
all or the IAP is only a Data Transporter.

Cuellar, Morris, Mulligan 8

Geopriv Requirements June Nov 2002

3.3.2. Authentication

People use

3.2.3. Geopriv Data Storage Functions

Within the word authentication with different meanings. Some
people insist that authentication associates an entity with a more geopriv framework, certain data may be stored in various
functional entities:

Rule (or Policy) Storage
A storage used to store privacy-protecting policies, and
perhaps identifiers, credentials or
less well-known identity. This basically means that if keys. A
authenticates another entity as being "B", then the label "B" has
also Private Rule
Storage could be operated by a meaning for many entities different from A. In this case, the
label "B" is called Device, a publicly known identifier, Location Server, or a
third party service provider.

How policies are authenticated and the
authentication otherwise protected is "explicit":

Explicit Authentication
The act outside of verifying a claimed static identity easily linked
back to
the real identity scope of this document, but see the user, remarks in the form Section 6
(Privacy Considerations).

Location Storage:
A Device or entity that stores raw or processed Location
Information for any period of a pre-
existing label from a predefined name space, as time longer than the sole
originator of a message (message authentication) or as duration
necessary to complete an immediate transaction regarding the
end-point of a channel (entity authentication).

3.3.3. Authorization

Authorization
LI.

The act existence and data storage practices of determining if a particular right, such as access Location Storage is
crucial to some resource, can privacy considerations, because this may influence what
Location Information could eventually be granted revealed (through later
distribution, technical breach, or legal processes).

3.3. Privacy Policies and Rules

Privacy Policies are rules that regulate an entity's activities with
respect to location and other information, including, but not
limited to, the presenter of a
particular credential.

Depending collection, use, disclosure, and retention of
location information. Such rules are generally based on fair
information practices, as detailed in (for example) the type of credential, authorization may imply
Explicit Authentication or not.

3.4. Data Flows

Figure 1 presents OECD
Guidelines on the entities Protection of a "typical" protocol setting, using
the Location Object Privacy and the data flows between those entities. Not
all steps discussed here necessarily occur in every scenario. The
data flows may be one-step message exchanges, Transporter Flows of
Personal Data [OECD].

Privacy Policy or multi-step sub-
protocols and the actual transport Privacy Rule:
A rule or set 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 rules 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):
the location data source sends the "full" location information regulate an entity's activities
with respect to the location server. Then information, including the
collection, use, disclosure, and retention of location server sends
information. In particular, the
full or filtered policy describes how location
information to the Location
Recipient. The may be used by an entity and which transformed
location information may be filtered in the sense released to which entities under
which conditions. Policies must be obeyed; they are not
advisory.

A full set of Privacy Rules will likely include both rules that
in general have
only one possible technical meaning, and rules that will be affected
by a less precise or locality's prevailing laws and customs. For example, a computed version
distribution rule of the
information is being delivered.

Pol (Policy):
The Rule Maker(or in particular, the target itself) sends a
Policy form "my location can only be disclosed to
the location server. owner of such credentials and in such accuracy" has clear-cut

Cuellar, Morris, Mulligan Expires Dec 2002 10 9

Geopriv Requirements June Nov 2002

PolInfo (Policy Information):

implications for the server informs protocol that uses the Location Seeker which data type(s) LO. But other rules,
like retention or usage policies, may have unclear technical
consequences for the protocol or for the involved entities. For
example, the precise scope of
filtered a retention rule stating "you may not
store my location information are available to him for more than 2 days" may in part turn on local
laws or customs.

3.4. Identifiers, Authentication and Authorization

Anonymity is the property of being not identifiable (within a set of
subjects). Anonymity serves as the base case for privacy: without
the ability to remain anonymous, individuals cannot control their
own privacy. Unlinkability ensures that a given
target. This mechanism must be user may make multiple
uses of resources or services without others being able to be invoked by link
these uses together. Unlinkability requires that entities are
unable to determine whether the
Location Seeker before he sends an LRequest.

LRequest (Location Information Request): same user caused certain specific
operations in the Location Seeker requests location information for a
target, system. [ISO99] A pseudonym is simply a given class bit
string which is unique as ID and is suitable to be used for end-
point authentication.

Unlinked Pseudonym:
A pseudonym where the linking between the pseudonym and its
holder is, at least initially, not known to anybody with the
possible exception of targets, the holder himself or for targets a trusted server
of the user. See [Pfi01] (there the term is called Initially
Unlinked Pseudonym)

The word authentication is used in different meanings. Some require
that authentication associates an entity with a
particular set more or less well-
known identity. This basically means that if A authenticates
another entity B as being "id-B", then the label "id-B" is a well-
known, or at least a linkable identity of attributes. the entity. In this request, case,
the Location
Seeker may select which location information data type it
prefers. The Location Seeker can also specify label "id-B" is called a publicly known identifier, and the need for
periodic location information updates.

+---------+ Locate +-----------+
| Location|<************| Location | SPol +------------+
| Data | LI | Server + |<*************| Public |
| Source |------------>| Private | * | Policy |
| + IAP | | Repository|<---\ * | Repository |
+---------+ +-----------+ | * +------------+
^ | | | * ^
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
authentication is "explicit":

Explicit Authentication:
The following Data Flows MAY be outside act of verifying a claimed identity as the scope sole originator
of the geopriv
WG, but should be mentioned for understandability. They are shown in
Figure 1 a message (message authentication) or as while starred arrows ("***>").

Service: (Service Information, Negotiation and Delivery):
The target (or the Rule Maker) and end-point of a
channel (entity authentication). Moreover, this identity is
easily linked back to the client exchange
information about real identity of the service and negotiate it. entity in
question, for instance being a pre-existing static label from
a predefined name space (telephone number, name, etc.).

Authorization
The client
provides service delivery act of determining if a particular right, such as access
to some resource, can be granted to the target and accounting presenter of a
particular credential.

Depending on the type of credential, authorization may imply
Explicit Authentication or
billing data, as necessary. not.

Cuellar, Morris, Mulligan Expires Dec 2002 11 10

Geopriv Requirements June Nov 2002

SPol (Signed Policy):
As an alternative to Pol, the Rule Maker may write a policy

4. Scenarios and place it in the Open Repository. The entities access the
repository via SPol.

Locate:
Request to locate the target. When a Location Server receives
an LRequest for a target for which has no current location
information, the server may send this "Locate" request to the
Location Data Source.

3.4.1. Relationship framework

Location information can be used in very different environments. In
some cases the participants will have longstanding relationships
while in others participants may have discrete interactions.

The different relationships raise different concerns for the
implementation of privacy rules, including the need to communicate
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:
The data flow is governed by a contract that protects location
privacy.

Non-trusted:
The data flow is not governed by a contract that protects
location privacy.

3.4.2. Explanatory Discussion

4.1. Scenarios of Data Flow

In this subsection we introduce two short scenarios to illustrate how
these terms and attributes describe location information
transactions.

SCENARIO 1: GPS Device with Internal Computing Power: Closed System

In this example, the target Target wishes to know his/her location using
Global Positioning System (GPS) and the device Device is capable of
independently processing the raw data to determine its location.
The location is derived as follows: the device Device receives
transmissions from the GPS satellites, internally computes and
displays location. This is a closed system. For the purpose of this
and subsequent examples, it is assumed that the GPS satellite
broadcasts some signal, and has no information about the identity or
whereabouts of
devices Devices using the signal.

Cuellar, Morris, Mulligan Expires Dec 2002 12

Geopriv Requirements June 2002

GPS Satellite
|
|
|
|
V GPS Device
--------------------------------------------------
/ \
| Data ----- Location ----- Location |
| Transporter Server Storage |
\ | /
-------------------------------------------|------
|
------------|------
/ V \
/ Target Location \
| Seeker |
| |
\ Rule Maker /
\ /
-------------------

In this scenario the GPS device Device is both the IAP and the LoSi. The
interaction occurs in a Trusted environment because it occurs in the
Rule Maker�s device. Maker�s Device.

SCENARIO 2: Cell Phone Roaming

In this example, a cell phone is used outside its home service area
(roaming). Also, the cell phone service provider (cell phone Corp 2)

Cuellar, Morris, Mulligan 11

Geopriv Requirements Nov 2002

outsourced the accounting of cell phone usage. The cell phone is not
GPS-enabled. Location is derived by the cell phone network in which
the target Target and device Device are roaming. When the target Target wishes to use
the cell phone, cell phone Corp 1 (IAP) provides the roaming service
for the target, Target, which sends the raw data about usage (e.g., duration
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 accounting company company, which processes the raw data for the
accounting statements. Finally, the raw data is sent to a data
warehouse where the raw data is stored in a location server 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
----------------- -----------------
Sighting / \ Sighting / \
Device --- ----- | Data Transporter| Transporter | --------- | Data Transporter |
Target \ / \ /
----------------- / -----------------
Target
/ |
/ sighting|
/ |
----------- |
/ V
------------ / ----------
/ \ / / \
/ Location \ / | Location |
| Storage | Location Info | Storage |
| |<----------------- | |
| Location | | Location |
| Seeker | | Seeker |
\ / \ /
------------- ----------

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
protecting location information with corp 1 and there is no
contractual relationship with privacy provisions between corp 1 and
corp 2) or Trusted (contract with privacy protections between cell
phone corp 2 and corp 1). Cell phone corp 2 is Trusted.

3.5. Further explanations

<Note: Although this section is relevant

SCENARIO 3: Mobile Communities and Location-Based Services

The figure below shows a common scenario, where a user wants to find
his friends or colleagues or wants to share his position with them
or with a Location-Based Service Provider. Some of the requirements, it
could probably be condensed.>

3.5.1. 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

Two apparently different data types may contain and Accuracy. They are shown
in the same information
if it is possible to transform one data type into the other and vice-
versa without information loss.

One location data type DT1 may contain more location information than
another DT2 in at least two different senses:

- DT1 may have the same dimensions as DT2 has, plus some extra
ones. (For instance, DT1 contains velocity, while DT2 does
not).

- DT1 may be more accurate than DT2. figure by normal arrows ("--->"). Other messages do not use

Cuellar, Morris, Mulligan Expires Dec 2002 14 12

Geopriv Requirements June Nov 2002

In general, if DT1 has more information than DT2, then there is one a
function that "translates correctly" from DT1 to DT2. There

the Location Object and are
other types outside of transformations that introduce errors (obfuscation:
intentionally make the location values less accurate by adding
randomness). During a transformation, information can be lost, but
not gained. Of course, a transformation that merges information from
several sources clearly increases the information of each one. Thus
a transformation is a filtering scope of information. For instance there the geopriv WG,
but should be mentioned for understandability. They are transformation functions from both data types "(latitude,
longitude, altitude)" and "(country, state, province, city)" to shown in
the
data types "(country, state)" figure as starred arrows ("***>").

+---------+ +------------+
| 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|
+----------+

Figure 1: The Entities and Data Flows

1: Registration:
The Rule Maker registers himself and "time zone", but not vice-versa.

Notice that if the space regions determined by different location
values of DT2 do not overlap, then there is at most one
transformation from DT1 to DT2. If Target with the space regions of DT2 overlap,
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
Location Server. This registration process is no
function that "translates correctly" from DT1 to DT2. In other
words: there are many functions that translate from DT1 to DT2, but
all introduce some degree outside of error. We believe that this kind the
scope of
functions should be avoided.

3.5.2. Public Global Identities

If A our discussion, but probably the Rule Maker has some information about a public global identifier "ID" and A
discloses this information to B, then B may associate this
information with the same entity as A did. In this way, B may
accumulate information about the entity labeled by "ID".

A public identity is a well-known label
prove that identifies an entity for
a (rather large) group he indeed is the owner of entities.

A public identity may be the subscription identity at privacy rights of the home domain
(if applicable),
Target (the Target is usually a well-known identity (name, address or Tel Number),
etc.

An entity may regard Device owned by the disclosure of his public identity (in
connection with some activity Rule
Maker). The Rule Maker and the Location Server agree, as part
of him, his location the Registration Process, which keys or other
attribute) as a violation credentials and
proof-of-possession of his privacy right.

3.5.3. Authorization without Explicit Authentication

In order to remain anonymous, an entity may use private identifiers.
Private identifiers convey less information than public identities,
because the corresponding secrets they are meaningful will use
to a smaller number of entities authenticate each other, and in
use for a shorter duration. Thus if A discloses a private identifier
to B, B is less likely particular, to associate this information with a known
individual authenticate
or entity than if a public identifier was disclosed. sign the policies, or how they will agree on them or renew
those keys or credentials.

Cuellar, Morris, Mulligan Expires Dec 2002 15 13

Geopriv Requirements June Nov 2002

Short-lived identifier
an identifier that is used only for one or a limited number of
"sessions".

Short-lived identifiers may be used to anonymously authenticate
entities in some settings.

In many situations, including pre-paid services, token-based or role-
based authorizations, unauthenticated key agreement,

2: End-to-End Negotiation:
The Rule Maker and purpose-
based identifiers, there is no need for explicit authentication.

Using weaker forms of authentication, the communication partner may
still want to make sure that he is communicating to Location Seeker exchange information
about the same entity
during service (if any) and negotiate it. They also
negotiate the whole session, or pseudonyms that he is communicating with an
authorized entity. Thus message authentication codes are used, based they will use later on "unauthenticated keys".

Authorization and the
credentials or keys that the Ultimate Location Recipient will
use to prove his authorization to the Location Server. This
End-to-End Negotiation may be used in contain several messages and may
use or not the same way as
authentication credentials Location Object.

3: Policy Transfer:
The Rule Maker sends a Policy to secure the Location Server. This
Policy may be a key agreement field in a Location Object or not.

3a:Signed Policy:
As an alternative to the following
sense: one party is assured that no other party aside from the owner
of Policy Transfer, the authorization credentials (and possibly additional identified
trusted parties) Rule Maker may gain
write a policy and place it in the Open Repository. The
entities access the repository to read the agreed secret key. signed policies.

4: Location Information Request:
The
resulting keys are called authorized keys. Those keys may be used Location Seeker requests location information for message authentication, without implying an explicit
authentication. a
Target. In real life this corresponds 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 instance to periodic location information
updates, but this is probably out of the following
situation: at a cloakroom scope of geopriv.

5: Locate:
When a person deposits his coat and Location Server receives an Location Information
Request for a
credential that he may use later to obtain back Target for which has no current location
information, the coat.

One possible goal of server may send ask the Rule Maker is Location Sighter to hide the identity of
locate the Target.

6: Location Recipient Information:
The Location Sighter sends the "full" location information to
the Location Server. Nevertheless, This Location Information may be
embedded in a Location Object or not.

7: Filtered Location Information:
Then the Location Server has sends the location information to the
Location Recipient. The information may be sure that filtered in the Rule Maker has authorized
sense that in general a less precise or a computed version of
the
Recipient to access information is being delivered.

5. Requirements

Cuellar, Morris, Mulligan 14

Geopriv Requirements Nov 2002

5.1. Location Object

Req. 1. (Location Object generalities)

1.1) Geopriv MUST define one Location Object (LO) -- both in
syntax and semantics -- that must be supported by all geopriv
entities.

1.2) Some fields of the location. Location Object MAY be optional. This is
means that an instance of a case Location Object MAY contain the
fields or not.

1.3) Some fields of authorization
without explicit authentication: the Location Server has to Object MAY be sure defined as
"extensions". This means that the Location Recipient is a particular (i.e., authorized)
communication partner syntax or semantics of these
fields is not fully defined in the Rule Maker.

This basic Location Object
definition, but their use may be done for instance as follows: consider private to one or more using
protocols.

1.4) The Location Object MUST be extensible, allowing the
definition of new attributes or fields.

1.5) The object MUST be suitable for requesting and receiving a
location.

1.6) The object MUST permit (but not require) the policy to be
enforced by a Location Seeker
that obtains third party.

1.7) The object MUST be usable in a set variety of "traveller's cheques" from the Rule Maker. protocols, such as
HTTP and SIP, as well as local APIs.

1.8) The
cheques will object MUST be used to "buy" location information from usable in a secure manner even by
applications on constrained devices.

Req. 2. (Location Object fields) The Location
Service. Initially, Object MUST support
the following (eventually optional) Fields

2.1) Target Identifier.

2.2) Location Seeker signs for Recipient Identity

This identity may be a first time the
cheques with any "signature" that he wants multicast or group identity, used to use. The Rule Maker,
through his own signature, authorizes
include the signature Location Object in multicast-based using protocols.

2.3) Location Recipient Credential

2.4) Location Recipient Proof-of-Possession of the Credential

2.5) Location
Seeker. When presented to the Field.

Each Location Server, the cheques Field may be
countersigned so that the server is sure that the signer is the same
as the contain one who was authorized by the Rule Maker. This
countersignature does not only authenticate the or more Location Seeker to
the verifier, but
Representations, which can be 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. in different formats.

Cuellar, Morris, Mulligan Expires Dec 2002 16 15

Geopriv Requirements June Nov 2002

To hide the real identity of the Rule Maker to the Location Server,
the following dual solution can be used. The Rule Maker buys (say,
using e-cash) a service from a

2.6) Location Seeker (e.g., a navigation
service). During this transaction, Data Type

When transmitting 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 Object, the
server sender 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,
o
receiver must agree on the identity data type of the Location Seeker from the Location
Server,
o location information.
The using protocol may specify that the identity data type information is
part of the target from the Location Seeker.

But notice Object or that sender and receiver have
agreed on it before the Location Data Source is in general not able to
localize actual data transfer.

2.7) Motion and direction vectors

2.8) Timing information:
(a) When was the target based LI accurate? (sighting time)
(b) Until when considered current? TTL (Time-to-live) (This is
different than a privacy rule setting a limit on some short-lived identifier. In data retention)

2.9) Policy Field: this
scenario, the Location Data Source should field MAY be a Location Server, a
different one from the one from whom the identity of the target is referral to
be hidden.

4. Requirements

4.1. Protocols

Req. 1. The geopriv protocol MUST be an embedded protocol: applicable
policy (for instance, an URI to a full policy) or it
defines MAY contain
a Limited Policy (see Req. 9).

2.10) Security-headers and -trailers (for instance encryption
information, hashes, or signatures) (see Req. 13).

2.11) Version number

Req. 3. (Location Data Types)

3.1) The Location Object (LO), together with the security
mechanisms used MUST define at least one Location Data
Type to secure it. be supported by all geopriv receivers (entities that
receive LOs).

3.2) The security mechanisms are
of Location Object SHOULD define two types: on Location Data Types:
one for latitude / longitude / altitude coordinates and one hand for
civil locations (City, Street, Number) supported by all geopriv
receivers (entities that receive LOs).

3.3) The latitude / longitude / altitude Data Type SHOULD also
support a delta format in addition to an absolute one, used for
the Location Object as such is
secured, using cryptographic checksums or encryption as
part purpose of reducing the size of the packages or the security
and confidentiality needs.

3.4) The Location Object itself, and definition SHOULD agree on the other hand
security mechanisms may be provided further
Location Data Types supported by the embedding some geopriv entities and
defined by other organizations.

5.2. The Using Protocol

Req. 4. The using
<or usage?> protocol that uses has to obey the Location Object. If
possible, privacy and security mechanisms on
instructions coded in the Location Object itself
are to be preferred.

We refer to and in the embedded protocol also as
corresponding Policy Rules regarding the geopriv protocol transmission and storage
of the LO.

Cuellar, Morris, Mulligan 16

Geopriv Requirements Nov 2002

Req. 5. The using protocol will typically facilitate that the keys
associated with the credentials are transported to the combination respective
parties, that is, key agreement is responsibility of both the embedded protocol and using
protocol.

Other requirements on the using <usage?> protocol as are out of the combined protocol.

4.2. scope of
this document. See also Section 9 (Protocol and LO Issues for later
Consideration)

5.3. Policy based Location Data transfer Transfer

Req. 2. 6. (LServ Policies) The decision of a Location Server to
provide a Location Seeker access to location information is Location Information MUST be
based on Rule Maker-defined privacy policies.

Req. 3. The Privacy Policies.

It is outside of our scope how Privacy Policies are managed, how a
Location Data Source may Server has access to the Privacy Policies, and if he is or
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.

Req. 7. (LoSi Policies) Even if a Location Sighter is unaware of
and lacks access to the full
policies Privacy Policies defined by the Rule
Maker, but the Location Sighter MUST transmit Location Information in that case it
will have to obey another
compliance with instructions set of "generic" policies,
consented to by the Rule Maker, to transfer Maker. Such
compliance MAY be accomplished by the Location Data
(raw or not) Sighter
transmitting LI only to another entity.

Cuellar, Morris, Mulligan Expires Dec 2002 17

Geopriv Requirements June 2002 a URI designated by the Rule Maker.

Req. 4. 8. (ULR Policies) An Ultimate Location Recipient does not need
to be aware of the full policies defined by the Rule Maker, but it will
obey a set of policies regarding the use and retention of
the location information.

Req. 5. The "generic" policies (as opposed to the policies
created by the Rule Maker) used by the Location Data
Source, the full policies defined by the Ultimate Rule Maker
(because an ULR SHOULD NOT retransmit Location Recipients Information), and by
thus an ULR SHOULD receive only the
Location Server subset of some special scenarios MUST Privacy Policies
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 made
explicit. retained).

Req. 6. The combined protocol 9. (Full Policy language) Geopriv MAY specify a policy language.
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.

If specified, the policy language MUST
language, and it SHOULD be strong enough to
express policies of the form: as simple as possible.

Req. 10. (Limited Policy language) Geopriv MUST specify a group G limited
policy language capable of clients are
allowed to know expressing a certain transformation A limited set of the privacy
rules concerning location
L of a target together with a given identifier I information. This policy language MAY
be an existing one, an adaptation of the
target for a given purpose, for an existing one or a given period of time.

If specified, the new
policy language language. The Location Object MUST be strong enough include sufficient
fields and data to express conditions on G and A as follows:
G, the group limited set of clients SHOULD be characterized by privacy rules.

5.4. Location Object Privacy and Security

Cuellar, Morris, Mulligan 17

Geopriv Requirements Nov 2002

5.5. Identity Protection

Req. 11. (Identity Protection) The Location Object MUST support use
of Unlinked Pseudonyms in the
possession corresponding identification fields
of (identifiers, credentials) with Rule Maker, Target, Device, and Location Recipient. Since
Unlinked Pseudonyms are simply bit strings that are not linked
initially to a certain
syntactic property.
A, well-known identity, this requirement boils down
to saying that the transformation function MAY be specified by data
type of name space for Identifiers used in the expected filtered location information.

Within those constraints, LO has
to be large enough to contain many unused strings.

5.6. Authentication Requirements

Req. 12. (Credential Requirements) The using protocol and the policy language
Location Object SHOULD be as
simple as possible, allow the use of different credentials
types, including privacy-enhancing credentials (like for instance
the ones described in [Bra00] or it SHOULD [Cha85]).

5.7. Actions to be an existing policy
language.

4.3. Location Object, Location Field secured

Req. 13. (Security Features) The Location Object has at least MUST support
fields suitable for protecting the Object to provide the
following optional fields
(attributes): Identifier, Location, security features:

13.1) Mutual end-point authentication: the using protocol is
able to authenticate both parties in a Location Object
transmission,

13.2) Data object integrity: the LO is secured from
modification by unauthorized entities during transmission and
during storage,

13.3) Data Type, Policy,
Request, object confidentiality: the LO is secured from
eavesdropping (unauthorized reading) during transmission and Version. The definition
during storage, and

13.4) Replay protection: an old LO may not be replayed by an
adversary or by the same entity that used the LO itself (except
perhaps during a small window of time that is configurable or
accepted by the Rule Maker).

Req. 14. (Minimal Crypto)

14.1) Geopriv MUST specify a minimum mandatory to implement
Location Object should
be flexible enough security including mandatory to accommodate new application-specific fields.

Req. 7. The embedded protocol MUST implement crypto
algorithms, for digital signature algorithms and encryption
algorithms.

14.2) It MAY also define one further mandatory to implement
Location Object
(LO) -- both security mechanisms for message authentication
codes (MACs) or other purposes.

Cuellar, Morris, Mulligan 18

Geopriv Requirements Nov 2002

14.3) The protocol SHOULD allow a bypass if authentication
fails in syntax and semantics -- an emergency call.

The issue addressed in the last point is that must an emergency call in
some very unfavorable situations my not be
supported by all 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.

5.8. Non-Requirements

Non-Req. 1. (Bridging to non-IP networks) The geopriv entities.

Some fields specification
SHOULD NOT specify the bridging to non-IP networks (PSTN, etc).

6. Security Considerations

The purpose of the geopriv Location Object MAY be optional. This
means that an instance of a Location Object MAY contain and the
fields or not.

Some fields requirements on
the using protocol are to allow a policy-controlled disclosure of
location information for location services.

6.1. Traffic Analysis

The information carried within the Location Object MAY be opaque to the
embedded protocol. This means that is secured in a
way compliant with the syntax privacy and
semantics security policies of these fields is not defined in the embedded

Cuellar, Morris, Mulligan Expires Dec 2002 18

Geopriv Requirements June 2002

protocol, Rule
Maker, but rather it is only clear other information, carried in other objects or headers
are in general not secured in the using
protocol. Nevertheless same way. This means that geopriv
does not as a general matter secure the embedded protocol MUST know how
large Target against general
traffic analysis attacks or other forms of privacy violations.

6.2. Securing the fields are.

Req. 8. The Location Object MUST contain one optional Identifier
Field.

Req. 9. Privacy Policies

The embedded protocol MUST define Privacy Policies of at least one the Rule Maker regarding the location of the
Target may be accessible to a Location Data Type supported Server in a Private Storage
or in a Public Repository, or they may be carried by all geopriv implementations
and entities.

Req. 10. The the Location Object MUST contain one optional
Object, or they may be presented by the Location
Field. An instance Seeker as
capabilities or tokens. Each of this types of policy has to be
secured it�s own particular way.

The rules in a Location Object MAY contain zero,
one, Private Storage are typically authenticated using a
MAC (Message Authentication Code) or several Location Fields. (We also say a signature, depending on the
type of keys used. The rules in this case a Public Repository (one that the LO contains several Locations.) Each Location
Field in
principle may contain one or more Location Representations.

When transmitting location information, (LI typically digitally signed. A Policy
Field in Figure 1), a LO is secured as part of the sender
and LO itself. A Geopriv Token
(a token or ticket issued by the receiver must agree on Rule Maker to a Location Seeker,
expressing the data type explicit consent of the Rule Maker to access his
location
information. The combined protocol may specify that the data type
information information) is part of the Location Object authenticated or that sender and
receiver have agreed on it before signed.

Cuellar, Morris, Mulligan 19

Geopriv Requirements Nov 2002

6.3. Emergency Case

One way of implementing the actual data transfer.

Req. 11. The Location Object MUST contain one optional Location
Data Type Field. The Location Data Type Field may be used authentication bypass for emergency
calls, mentioned in Req 14.3) is to specify let the type user have the choice of
writing a Location Field or Location
Representation, 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 request use? It is reasonable to use a Location Field of default one: this
particular type.

Req. 12. The Location Object MUST contain one optional Policy
Field.

Req. 13. The Location Object MUST contain a version number.

Req. 14. The protocol MUST
location information can only be extensible, allowing 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
definition of new attributes in emergency center is not authenticable? It is reasonable to send
the Location Object.

4.4. Requests

Req. 15. Information anyway, but are there in this case any
security threats that must be considered?

6.4. Identities and Anonymity

The Location Object MUST contain one optional Request
Field, encoding the type use of remote request. Examples Unlinked Pseudonyms is necessary to obtain anonymity.

The purpose 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 use of Unlinked Pseudonyms is the
purpose built key", etc.

4.5. Identity Protection

Cuellar, Morris, Mulligan Expires Dec 2002 19

Geopriv Requirements June 2002

Req. 16. The combined following: the
using protocol MUST should be able to hide the real identity or linkable identifiers associated with the real
identity of the Rule
Maker, the target, Target, and the device from Device, the Ultimate and to Location Recipient.

This may be easily done Servers or
Location Recipients. Also, the using short-lived identifiers.

Req. 17. The combined protocol MUST SHOULD be able to
hide the real identity of the Rule Maker 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 Seeker, including Server has to know who is supplying
policies for a Location Server.

Req. 18. The combined protocol MUST particular Target, but in other situations it could

Cuellar, Morris, Mulligan 20

Geopriv Requirements Nov 2002

be able enough to hide know that the real
identity supplier of the Location Recipient 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 Location Server.

Thus here Target. This special case most frequently occurs if the target Target
is not concerned 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 Server identifying
him and knowing his driver's location, but identifying his business partners,
and therefore his habits, etc. One reason for hiding the real
identities of the Location Recipients driver's
privacy is implicitly affected.

Geopriv may be that this knowledge or may not protect or affect the privacy of Unintended
Targets, but the impact on Unintended Targets should be used
acknowledged.

7. Acknowledgements

We wish to infer thank the identity members of the target. Or perhaps I have just
asked a certain organization (say, a political party IETF geopriv WG for their
comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison
Mankin, Randall Gellens, Jon Peterson, and the participants of the
geopriv meetings in San Diego and Yokohama provided detailed
comments or a night club) text.

8. References

[Bra00] Stefan A.: Rethinking Public Key Infrastructures and Digital
Certificates : Building in Privacy, MIT Press; ISBN:
0262024918; 1st edition, August, 2000

[Cha85] Chaum, David: Security without Identification, Card
Computers to send me driving directions, but it could be embarrassing 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/

[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 me if
certain people find out that I have some relationship
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 that
organization. I do not want 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 let mention some issues on 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 Object or
on the Server to know protocol, which have emerged during the real identity discussion of earlier
versions of this document.

9.1. Single Message Transfer

For several purposes, and in particular for the location
recipients is that tracking of small
target devices, the dossier telling who has obtained my location
information over design should not preclude a long period single
message/packet transmission of time gives quite location as a lot complete transaction.

9.2. Multiple Locations in one LO

The possibility of
information on my habits, movements, etc. Even if the location
service providers agree to respect the privacy inclusion of the user, are
compelled by laws or regulations to protect the privacy multiple locations is discussed in
another draft, draft-morris-geopriv-location-object-issues-00.txt.

An instance of the user,
and misbehavior a Location Object could contain zero, one, or negligence of the several
Location Server can Fields, perhaps in different formats. Several Location
Fields would be ruled
out, there is still a chance that personal data may become available used to unauthorized persons through attacks from outsiders, unauthorized
access from insiders, report the same sighting in different
formats, or technical multiple sightings at different times, or human errors.

Req. 19. When a Location Server accepts a policy from multiple
sensor locations for the Rule
Maker, same device, or other purposes.

9.3. Translation Fields

It is possible to include fields to indicate that one of the target MUST prove
locations is a translation of another. If this is done, it is also
possible to the combined protocol that
he owns the claimed group or role identifier that should be
passed have a field to identify the Location Recipient.

For instance, if translator, as identity and
method.

9.4. Specifying Desired Accuracy in a Target wants Request

If the role identifier "medical doctor" LO is used to be passed request location information (leaving some
fields empty), it is not clear how to a Location Recipient, specify the Target must prove requested
accuracy. Are the
claims to be a medical doctor. <But probably group data types "country/state/city" and
"country/state" different data types or role
identifiers will be discouraged the same data type with
different "accuracy" or "granularity"?

9.5. Truth Flag

Geopriv should not provide an attribute in geopriv.>

4.6. Authentication Requirements

Req. 20. object saying "I'm not
telling you the whole truth."

9.6. Timing Information Format

The combined protocol MUST allow different
authentication schemes. format of timing information is out of the scope of this
document.

9.7. The combined protocol MUST
guarantee that appropriate keys (shared or asymmetric) are Name Space of Identifiers

Cuellar, Morris, Mulligan Expires Dec 2002 20 22

Geopriv Requirements June Nov 2002

generated and available to secure

Who defines the Location Object
within Identities: may the embedded protocol.

Req. 21. The combined protocol MUST allow authorization without
explicit authentication.

4.7. Actions to be secured

Req. 22. The embedded using protocol MUST be able to secure define the
Location Object for
Identifiers or must the following message flows (mutual
end-point authentication, data object integrity, data
object confidentiality, replay protection, in using protocol use and authenticate
Pseudonyms proposed by the absence policies, chosen independently of a time parameter): LI, Pol, LIF, LRequest, and PolInfo.

Req. 23. The embedded protocol MUST specify a minimum mandatory
to implement Location Object security including mandatory
to implement crypto transforms.

Req. 24. The embedding the
using protocol? Of course, if the using protocol MAY provide extra security for
these flows (hop-by-hop or end-to-end).

In full details, these requirements have has an appropriate
namespace, containing many consequences: the
communicating parties MUST have security relationships between them,
allowing them to construct secure channels between them. This may
imply unused names that some scenarios should not may be used as
pseudonyms and may be replaced by new ones regularly, then the
Location Object may be permitted in general. The
Rule Maker MAY choose able to use the security provided by name space. For this purpose,
the embedded or
by user would probably have to write his policies using this name
space. Note that it is necessary to change the embedding protocol, or none.

4.8. Non-Requirements

Req. 25. The geopriv specification SHOULD NOT specify used pseudonyms
regularly, because identifying the
bridging to non-IP networks (PSTN, etc).

5. Security Considerations

The purpose user behind an unlinked pseudonym
can be very simple.

There are several advantages of letting the geopriv using protocol is to allow a policy-controlled
disclosure of location information for location services. Only define
the
information carried within name space:
o the Location Object is secured in a way
compliant with embedded authentication would be easier, as the privacy using protocol
has often already the credentials for the authentication identity
in place and security policies of the target. This
does not mean that geopriv secures "embedded" authentication would be independent on
the target against general traffic
analysis attacks or other forms form of privacy violations.

The Location Server is assumed to Identifiers,
o the size of the names would be trustworthy.

6. Acknowledgements

We wish to thank fixed.

On the members other hand, the benefits of the IETF geopriv WG for their
comments and suggestions. Detailed comments or text were provided by
Aaron Burstein, Mehmet Ersue, Allison Mankin, Randall Gellens, and policy choosing the participants
identifiers are:
o the user has a control of his anonymity, and
o the geopriv interim meeting in San Diego.

Cuellar, Morris, Mulligan Expires Dec 2002 21

Geopriv Requirements June 2002

7. References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

8. interworking of multiple systems with Location object across
protocol boundaries is facilitated.

10. Author's Addresses

Jorge R Cuellar
Siemens AG
Corporate Technology
CT IC 3
81730 Munich Email: Jorge.Cuellar@mchp.siemens.de
Germany

John B. Morris, Jr.
Director, Internet Standards, Technology & Policy Project
Center for Democracy and Technology
1634 I Street NW, Suite 1100
Washington, DC 20006 Email: jmorris@cdt.org
USA http://www.cdt.org

Deirdre K. Mulligan
Samuelson Law, Technology and Public Policy Clinic
Boalt Hall School of Law
University of California
Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu

11. Full Copyright Statement

Cuellar, Morris, Mulligan 23

Geopriv Requirements Nov 2002

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

Cuellar, Morris, Mulligan Expires Dec 2002 22

Geopriv Requirements June 2002
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Cuellar, Morris, Mulligan Expires Dec 2002 23 24
----