draft-ietf-geopriv-reqs-04.txt   rfc3693.txt 
Internet Draft Jorge Cuellar Network Working Group J. Cuellar
Document: draft-ietf-geopriv-reqs-04.txt Siemens AG Request for Comments: 3693 Siemens AG
Category: Informational J. Morris
John B. Morris, Jr. Center for Democracy & Technology
Center for Democracy and Technology D. Mulligan
Samuelson Law, Technology & Public Policy Clinic
Deirdre Mulligan J. Peterson
Samuelson Law, Technology, and Public Privacy Clinic
Jon Peterson
NeuStar NeuStar
J. Polk
James Polk
Cisco Cisco
February 2004
Expires in six months Oct 2003 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 memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Location-based services, navigation applications, emergency Location-based services, navigation applications, emergency services,
services, management of equipment in the field, and other location- management of equipment in the field, and other location-dependent
dependent services need geographic location information about a services need geographic location information about a Target (such as
a user, resource or other entity). There is a need to securely
Cuellar, Morris, Mulligan, Peterson, Polk 1 gather and transfer location information for location services, while
Geopriv Requirements Oct 2003 at the same time protect the privacy of the individuals involved.
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.
This document focuses on the authorization, security and privacy This document focuses on the authorization, security and privacy
requirements for such location-dependent services. Specifically, it requirements for such location-dependent services. Specifically, it
describes the requirements for the Geopriv Location Object (LO) and describes the requirements for the Geopriv Location Object (LO) and
for the protocols that use this Location Object. This LO is for the protocols that use this Location Object. This LO is
envisioned to be the main object defined by the Geopriv WG, used in envisioned to be the primary data structure used in all Geopriv
all Geopriv exchanges and in particular used to securely transfer protocol exchanges to securely transfer location data.
location data.
Table of Contents Table of Contents
1. Overview.......................................................3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document..............................4 2. Conventions Used in this Document. . . . . . . . . . . . . . . 4
3. Glossary.......................................................4 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Primary Geopriv Entities.......................................6 4. Primary Geopriv Entities . . . . . . . . . . . . . . . . . . . 6
5. Further Geopriv Terminology....................................7 5. Further Geopriv Terminology. . . . . . . . . . . . . . . . . . 7
5.1. Location Information and Sighting.........................7 5.1. Location Information and Sighting. . . . . . . . . . . . 7
5.2. The Location Object and Using Protocol....................8 5.2. The Location Object and Using Protocol . . . . . . . . . 9
5.3. Trusted vs. Non-trusted Data Flows........................9 5.3. Trusted vs. Non-trusted Data Flows . . . . . . . . . . . 10
5.4. Further Geopriv Principals...............................10 5.4. Further Geopriv Principals . . . . . . . . . . . . . . . 10
5.5. Privacy Rules............................................12 5.5. Privacy Rules. . . . . . . . . . . . . . . . . . . . . . 12
5.6. Identifiers, Authentication and Authorization............12 5.6. Identifiers, Authentication and Authorization. . . . . . 13
6. Scenarios and Explanatory Discussion..........................13 6. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 15
7. Requirements..................................................17 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Location Object..........................................17 7.1. Location Object. . . . . . . . . . . . . . . . . . . . . 19
7.2. The Using Protocol.......................................19 7.2. The Using Protocol . . . . . . . . . . . . . . . . . . . 21
7.3. Rule based Location Data Transfer........................20 7.3. Rule based Location Data Transfer. . . . . . . . . . . . 21
7.4. Location Object Privacy and Security.....................21 7.4. Location Object Privacy and Security . . . . . . . . . . 22
7.4.1. Identity Protection.................................21 7.4.1. Identity Protection. . . . . . . . . . . . . . . 22
7.4.2. Authentication Requirements.........................21 7.4.2. Authentication Requirements. . . . . . . . . . . 23
7.4.3. Actions to be secured...............................21 7.4.3. Actions to be secured. . . . . . . . . . . . . . 23
7.5. Non-Requirements.........................................22 7.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations.......................................22 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
8.1. Traffic Analysis.........................................22 8.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 24
8.2. Securing the Privacy Rules...............................22 8.2. Securing the Privacy Rules . . . . . . . . . . . . . . . 24
8.3. Emergency Case...........................................23 8.3. Emergency Case . . . . . . . . . . . . . . . . . . . . . 24
8.4. Identities and Anonymity.................................23 8.4. Identities and Anonymity . . . . . . . . . . . . . . . . 25
8.5. Unintended Target........................................24 8.5. Unintended Target. . . . . . . . . . . . . . . . . . . . 26
9. Protocol and LO Issues for later Consideration................24 9. Protocol and LO Issues for later Consideration . . . . . . . . 26
9.1. Multiple Locations in one LO.............................24 9.1. Multiple Locations in one LO . . . . . . . . . . . . . . 26
9.2. Translation Fields.......................................24 9.2. Translation Fields . . . . . . . . . . . . . . . . . . . 26
9.3. Truth Flag...............................................25 9.3. Truth Flag . . . . . . . . . . . . . . . . . . . . . . . 27
9.4. Timing Information Format................................25 9.4. Timing Information Format. . . . . . . . . . . . . . . . 27
9.5. The Name Space of Identifiers. . . . . . . . . . . . . . 27
Cuellar, Morris, Mulligan, Peterson, Polk 2 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
Geopriv Requirements Oct 2003 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative Reference . . . . . . . . . . . . . . . . . . 28
9.5. The Name Space of Identifiers............................25 11.2. Informative References . . . . . . . . . . . . . . . . . 28
10. Acknowledgements.............................................25 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
11. References...................................................25 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
12. Author's Addresses...........................................26
13. Full Copyright Statement.....................................27
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. location information as input) are becoming increasingly common. The
The collection and transfer of location information about a collection and transfer of location information about a particular
particular Target can have important privacy implications. A key Target can have important privacy implications. A key goal of the
goal of the protocol described in this document is to facilitate the protocol described in this document is to facilitate the protection
protection of privacy pursuant to Privacy Rules set by the of privacy pursuant to Privacy Rules set by the "user/owner of the
"user/owner of the Target" (or, more precisely in the terminology of Target" (or, more precisely in the terminology of this document given
this document given in Section 3 and 5.4 below, the "Rule Maker"). in Section 3 and 5.4 below, the "Rule Maker").
The ability to gather and generate a Target's location, and access The ability to gather and generate a Target's location, and access to
to the derived or computed location, are key elements of the the derived or computed location, are key elements of the location-
location-based services privacy equation. Central to a Target's based services privacy equation. Central to a Target's privacy are
privacy are (a) the identity of entities that have access to raw (a) the identity of entities that have access to raw location data,
location data, derive or compute location, and/or have access to derive or compute location, and/or have access to derived or computed
derived or computed location information, and (b) whether those location information, and (b) whether those entities can be trusted
entities can be trusted to know and follow the Privacy Rules of the to know and follow the Privacy Rules of the user.
user.
The main principles guiding the requirements described in this The main principles guiding the requirements described in this
document are: document are:
1) Security of the transmission of Location Object is essential to 1) Security of the transmission of Location Object is essential to
guarantee the integrity and confidentiality of the location guarantee the integrity and confidentiality of the location
information. This includes authenticating the sender and information. This includes authenticating the sender and receiver
receiver of the Location Object, and securing the Location Object of the Location Object, and securing the Location Object itself.
itself.
2) A critical role is played by user-controlled Privacy Rules, which 2) A critical role is played by user-controlled Privacy Rules, which
describe the restrictions imposed or permissions given by the describe the restrictions imposed or permissions given by the
"user" (or, as defined below, the "Rule Maker"). The Privacy "user" (or, as defined below, the "Rule Maker"). The Privacy
Rules specify the necessary conditions that allow a Location Rules specify the necessary conditions that allow a Location
Server to forward Location Information to a Location Recipient, Server to forward Location Information to a Location Recipient,
and the conditions under which and purposes for which the and the conditions and purposes for which the Location Information
Location Information can be used. can be used.
3) One type of Privacy Rules specify in particular how location
information should be filtered, depending on who the recipient
is. Filtering is the process of reducing the precision or
resolution of the data. A typical rule may be of the form: "my
location can only be disclosed to the owner of such credentials
in such precision or resolution" (e.g., "my co-workers can be
told the city I am currently in").
Cuellar, Morris, Mulligan, Peterson, Polk 3 3) One type of Privacy Rules specify how location information should
Geopriv Requirements Oct 2003 be filtered, depending on who the recipient is. Filtering is the
process of reducing the precision or resolution of the data. A
typical rule may be of the form: "my location can only be
disclosed to the owner of such credentials in such precision or
resolution" (e.g., "my co-workers can be told the city I am
currently in").
4) The Location Object should be able to carry a limited but core 4) The Location Object should be able to carry a limited but core set
set of Privacy Rules. The exact form or expressiveness of those of Privacy Rules. The exact form or expressiveness of those Rules
Rules in the core set or in the full set is not further discussed in the core set or in the full set is not further discussed in
in this document, but will be discussed more extensively in this document, but will be discussed more extensively in future
future documents produced by this working group. documents produced by this working group.
5) Whenever appropriate, the location information should not be 5) Whenever appropriate, the location information should not be
linked to the real identity of the user or a static identifier linked to the real identity of the user or a static identifier
easily linked back to the real identity of the user (i.e., easily linked back to the real identity of the user (i.e.,
Personally Identifiable Information such as a name, mailing Personally Identifiable Information such as a name, mailing
address, phone number, social security number, or email address address, phone number, social security number, or email address or
or username). Rather, the user should be able to specify which username). Rather, the user should be able to specify which local
local identifier, unlinked pseudonym, or private identifier is to identifier, unlinked pseudonym, or private identifier is to be
be bound to the location information. bound to the location information.
6) The user may want to hide the real identities of himself and his 6) 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 for some Although complete anonymity may not be appropriate for some
applications because of legal constraints or because some location applications because of legal constraints or because some location
services may in fact need explicit identifications, in most cases services may in fact need explicit identifications, most often the
the location services only need some type of authorization location services only need some type of authorization information
information and/or perhaps anonymous identifiers of the entities in and/or perhaps anonymous identifiers of the entities in question.
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Note that the requirements discussed here are requirements on the Note that the requirements discussed here are requirements on the
generic Location Object and on the using protocols for location generic Location Object and on using protocols for location services.
services. Thus, for the most part, the requirements discussed in Thus, for the most part, the requirements discussed in this document
this document refer to capabilities that are mandatory-to-implement. refer to capabilities that are mandatory-to-implement. For example,
For example, requiring that implementations support integrity is not requiring that implementations support integrity is not the same
the same thing as requiring that all protocol traffic be thing as requiring that all protocol traffic be authenticated. In
authenticated. In contrast, an example of a mandatory-to-use (not contrast, an example of a mandatory-to-use (not just mandatory-to-
just mandatory-to-implement) requirement might be one that states implement) requirement might be one that states that the user always
that the user always receives a notice when his location data was receives a notice when his location data was not authenticated. This
not authenticated. This practice is mandatory-to-use, not just to practice is mandatory-to-use, not just to implement.
implement.
3. Glossary 3. Glossary
For easy reference and readability, below are basic terms that will For easy reference and readability, below are basic terms that will
be defined more formally and fully later in this document. be defined more formally and fully later in this document.
Location Generator (LG): The entity that initially determines or Location Generator (LG): The entity that initially determines or
gathers the location of the Target and creates Location gathers the location of the Target and creates Location Objects
Objects describing the location of the Target. describing the location of the Target.
Cuellar, Morris, Mulligan, Peterson, Polk 4
Geopriv Requirements Oct 2003
Location Object (LO): An object conveying location information Location Object (LO): An object conveying location information
(and possibly privacy rules) to which Geopriv security (and possibly privacy rules) to which Geopriv security
mechanisms and privacy rules are to be applied. mechanisms and privacy rules are to be applied.
Location Recipient (LR): The entity that receives location Location Recipient (LR): The entity that receives location
information. It may have asked for this location explicitly information. It may have asked for this location explicitly
(by sending a query to a location server), or it may receive (by sending a query to a location server), or it may receive
this location asynchronously. this location asynchronously.
Location Server (LS): The entity to which a LG publishes location Location Server (LS): The entity to which a LG publishes location
objects, the recipient of queries from location receivers, and objects, the recipient of queries from location receivers, and
the entity that applies rules designed by the rule maker. the entity that applies rules designed by the rule maker.
Precision: The number of significant digits to which a value has Precision: The number of significant digits to which a value has
been reliably measured. been reliably measured.
Principal: The holder/subject of the credentials, e.g. a Principal: The holder/subject of the credentials, e.g., a
workstation user or a network server. workstation user or a network server.
Resolution: The fineness of detail that can be distinguished in Resolution: The fineness of detail that can be distinguished in a
measured area. Applied to Geopriv this means the fineness of measured area. Applied to Geopriv this means the finite area
area within provided, and closed, borders (ex. Latitude and within provided and closed borders (ex. Latitude and Longitude
Longitude boundaries). boundaries).
Rule Holder: The entity that provides the rules associated with a Rule Holder: The entity that provides the rules associated with a
particular target for the distribution of location particular target for the distribution of location information.
information. It may either push rules to a location server, It may either 'push' rules to a location server, or a location
or a location server may pull rules from the Rule Holder. server may 'pull' rules from the Rule Holder.
Rule Maker: The authority that creates rules governing access to Rule Maker: The authority that creates rules governing access to
location information for a target (typically, this it the location information for a target (typically, this it the
target themselves). target themselves).
Rule, or Privacy Rule: A directive that regulates an entity's Rule, or Privacy Rule: A directive that regulates an entity's
activities with respect to location information, including the activities with respect to location information, including the
collection, use, disclosure, and retention of location collection, use, disclosure, and retention of location
information. information.
Target: A person or other entity whose location is communicated Target: A person or other entity whose location is communicated by
by a Geopriv Location Object. a Geopriv Location Object.
Using Protocol: A protocol that carries a Location Object. Using Protocol: A protocol that carries a Location Object.
Viewer: A Principal that consumes location information that is Viewer: A Principal that consumes location information that is
communicated by a Geopriv Location Object, but does not pass communicated by a Geopriv Location Object, but does not pass
this information further. this information further.
Resolution and Precision are very close terms. Either quality can Resolution and Precision are very close terms. Either quality can be
be 'reduced' to coarsen location information: 'resolution' by 'reduced' to coarsen location information: 'resolution' by defining a
defining a off-center perimeter around a user's location or off-center perimeter around a user's location or otherwise enlarging
the area in consideration (from state to country, say) and
Cuellar, Morris, Mulligan, Peterson, Polk 5 'precision' by discarding significant digits of positioning
Geopriv Requirements Oct 2003 information (rounding off longitude and latitude from seconds to
minutes, say). Another WG document discusses this topic in much more
otherwise enlarging the area in consideration (from state to detail.
country, say) and 'precision' by discarding significant digits of
positioning information (rounding off longitude and latitude from
seconds to minutes, say). Another WG document treats this topic in
much more detail.
4. Primary Geopriv Entities 4. Primary Geopriv Entities
The following picture shows the primary Geopriv entities in a simple The following picture shows the primary Geopriv entities in a simple
and basic architecture, without claim of completeness nor any and basic architecture, without claim of completeness or any
suggestion that the entities identified must in all cases be suggestion that the entities identified must in all cases be
physically separate entities. physically separate entities.
+----------+ +----------+
| Rule | | Rule |
| Holder | | Holder |
| | | |
+----+-----+ +----+-----+
| |
rule|interface rule|interface
V V
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
|Location | publication | Location | notification |Location | |Location | publication | Location | notification |Location |
|Generator +-------------->| Server +-------------->|Recipient | |Generator +-------------->| Server +-------------->|Recipient |
| | interface | | interface | | | | interface | | interface | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
The four primary Entities are described as follows: The four primary Entities are described as follows:
Location Generator (LG): The entity that initially determines or Location Generator (LG): The entity that initially determines or
gathers the location of the Target and creates Location gathers the location of the Target and creates Location Objects
Objects describing that location. LGs publish Location describing that location. LGs publish Location Objects to
Objects to Location Servers. The manner in which the Location Location Servers. The manner in which the Location Generator
Generator learns of Location Information is outside the scope learns of Location Information is outside the scope of the
of the Geopriv Protocol.. Geopriv Protocol.
Location Server (LS): The LS is an element that receives Location Server (LS): The LS is an element that receives
publications of Location Objects from Location Generators and publications of Location Objects from Location Generators and
may receive subscriptions from Location Recipients. The LS may receive subscriptions from Location Recipients. The LS
applies the rules (which it learns from the Rule Holder) to applies the rules (which it learns from the Rule Holder) to LOs
LOs it receives from LGs, and then notifies LRs of resulting it receives from LGs, and then notifies LRs of resulting LOs as
LOs as necessary. necessary.
Location Recipient (LR): The LR is an element that receives Location Recipient (LR): The LR is an element that receives
notifications of Location Objects from Location Servers. The notifications of Location Objects from Location Servers. The
LR may render these LOs to a user or automaton in some LR may render these LOs to a user or automaton in some fashion.
fashion.
Cuellar, Morris, Mulligan, Peterson, Polk 6
Geopriv Requirements Oct 2003
Rule Holder (RH): The RH is an element that houses Privacy Rules Rule Holder (RH): The RH is an element that houses Privacy Rules
for receiving, filtering and distributing Location Objects for for receiving, filtering and distributing Location Objects for
specific Targets. A LS may query an RH for a set of rules, or specific Targets. An LS may query an RH for a set of rules, or
rules may be pushed from the RH to an LS. The rules in the rules may be pushed from the RH to an LS. The rules in the
Rule Holder are populated by the Rule Maker. Rule Holder are populated by the Rule Maker.
Thus Location Generation is the process of gathering Location Thus Location Generation is the process of gathering Location
Information, perhaps from multiple sources, at an IP-based Geopriv Information, perhaps from multiple sources, at an IP-based Geopriv
Entity, the LG, which communicates with other Geopriv Entities. Entity, the LG, which communicates with other Geopriv Entities.
Rules MUST be authenticated and protected. How this is done and in Rules MUST be authenticated and protected. How this is done and in
particular how to distribute the keys to the RM and other particular how to distribute the keys to the RM and other authorities
authorities is outside of the scope of this document. See also is outside of the scope of this document. See also Section 8.2,
Section 8.2 "Securing the Privacy Rules". "Securing the Privacy Rules".
The interfaces between the Geopriv entities are not necessarily The interfaces between the Geopriv entities are not necessarily
protocol interfaces; they could be internal interfaces within a protocol interfaces; they could be internal interfaces within a
single composed device. In some architectures, the Location single composed device. In some architectures, the Location
Generator, Rule Holder, and Location Server might all be implemented Generator, Rule Holder, and Location Server might all be implemented
in the same device. There may be several Rule Holders that enforce in the same device. There may be several Rule Holders that enforce
the Privacy Rules at a particular Location Server. the Privacy Rules at a particular Location Server.
5. Further Geopriv Terminology 5. Further Geopriv Terminology
skipping to change at line 364 skipping to change at page 8, line 5
Target's location that is NOT based on generally or publicly Target's location that is NOT based on generally or publicly
available sources, but instead on private information provided or available sources, but instead on private information provided or
created by a Target, a Target's Device, or a Target's network or created by a Target, a Target's Device, or a Target's network or
service provider. Notwithstanding this focus on private location service provider. Notwithstanding this focus on private location
information, the Geopriv Location Object could certainly be used to information, the Geopriv Location Object could certainly be used to
convey location information from publicly available sources. convey location information from publicly available sources.
Location Information: A relatively specific way of describing Location Information: A relatively specific way of describing
where a Device is located. where a Device is located.
This Location Information may have determined in many different This Location Information may have been determined in many different
ways, including: ways, including:
(a) derived or computed from information generally not available to (a) derived or computed from information generally not available to
the general public (such as information mainly available to a the general public (such as information mainly available to a network
network or service provider), (b) determined by a Device that may be or service provider), (b) determined by a Device that may not be
not generally publicly addressable or accessible, or (c) input or generally publicly addressable or accessible, or (c) input or
otherwise provided by a Target. otherwise provided by a Target.
Cuellar, Morris, Mulligan, Peterson, Polk 7
Geopriv Requirements Oct 2003
As examples, the Location Information could include (a) information As examples, the Location Information could include (a) information
calculated by triangulating on a wireless signal with respect to calculated by triangulating on a wireless signal with respect to cell
cell phone towers, (b) longitude and latitude information determined phone towers, (b) longitude and latitude information determined by a
by a Device with GPS (global positioning satellite) capabilities, Device with GPS (global positioning satellite) capabilities, (c)
(c) information manually entered into a cell phone or laptop by a information manually entered into a cell phone or laptop by a Target
Target in response to a query, or (d) automatically delivered by in response to a query, or (d) automatically delivered by some other
some other IP protocol, such as at device configuration via DHCP. IP protocol, such as at device configuration via DHCP.
Excluded from this definition is the determination of location Excluded from this definition is the determination of location
information wholly without the knowledge or consent of the Target information wholly without the knowledge or consent of the Target (or
(or the Target's network or access service provider), based on the Target's network or access service provider), based on generally
generally available information such as an IP or e-mail address. In available information such as an IP or e-mail address. In some
some cases information like IP address can enable someone to cases, information like IP address can enable someone to estimate (at
estimate (at least roughly) a location. Commercial services exist least roughly) a location. Commercial services exist that provide
that offer to provide rough location information based on IP rough location information based on IP addresses. Currently, this
address. Currently, this type of location information is typically type of location information is typically less precise than the type
less precise than the type of location information addressed in this of location information addressed in this document. Although this
document. Although this type of location computation still raises type of location computation still raises significant potential
significant potential privacy and public privacy concerns, such privacy and public privacy concerns, such scenarios are generally
scenarios are generally outside the scope of this document. outside the scope of this document.
Within any given location-based transaction, the INITIAL Within any given location-based transaction, the INITIAL
determination of location (and thus the initial creation of Location determination of location (and thus the initial creation of Location
Information) is termed a Sighting: Information) is termed a Sighting:
Sighting: Sighting:
The initial determination of location based on non-public The initial determination of location based on non-public
information (as discussed in the definition of Location information (as discussed in the definition of Location
Information), and the initial creation of Location Information), and the initial creation of Location Information.
Information.
Some variant of the sighting information is included in the Location Some variant of the sighting information is included in the Location
Object. Abstractly, it consists of two separate data fields: Object. Abstractly, it consists of two separate data fields:
(Identifier, Location) (Identifier, Location)
where Identifier is the identifier assigned to a Target being where Identifier is the identifier assigned to a Target being
sighted, and Location is the current position of that Target being sighted, and Location is the current position of that Target being
sighted. Not all entities may have access to exactly the same piece sighted. Not all entities may have access to exactly the same piece
of sighting information. A sighting may be transformed to a new of sighting information. A sighting may be transformed to a new
sighting pair: sighting pair:
(Identifier-1, Location-1) (Identifier-1, Location-1)
before it is provided by a Location Generator or Location Server to before it is provided by a Location Generator or Location Server to
Location Recipient. In this case, Identifier-1 may be Pseudonym, Location Recipient. In this case, Identifier-1 may be a Pseudonym,
and Location-1 may have less precision or resolution than the and Location-1 may have less precision or resolution than the
original value. original value.
5.2. The Location Object and Using Protocol 5.2. The Location Object and Using Protocol
Cuellar, Morris, Mulligan, Peterson, Polk 8
Geopriv Requirements Oct 2003
A main goal of the Geopriv working group is to define a Location A main goal of the Geopriv working group is to define a Location
Object (LO), to be used to convey both Location Information and Object (LO), to be used to convey both Location Information and basic
basic privacy-protecting instructions: privacy-protecting instructions:
Location Object (LO): This data contains the Location Information Location Object (LO): This data contains the Location Information
of the Target, and other fields including an identity or of the Target, and other fields including an identity or
pseudonym of the Target, time information, core Privacy Rules, pseudonym of the Target, time information, core Privacy Rules,
authenticators, etc. Most of the fields are optional, authenticators, etc. Most of the fields are optional,
including the Location Information itself. including the Location Information itself.
Nothing is said about the semantics of a missing field. For Nothing is said about the semantics of a missing field. For
instance, a partially filled object MAY be understood implicitly as instance, a partially filled object MAY be understood implicitly as a
the request to complete it. Or, if no time information is included, request to complete it. Or, if no time information is included, this
this MAY implicitly mean "at the current time" or "at a very recent MAY implicitly mean "at the current time" or "at a very recent time",
time", but it could be interpreted in a different way, depending on but it could be interpreted in a different way, depending on the
the context. context.
The "using protocol" is the protocol that uses (reads or modifies) The "using protocol" is the protocol that uses (reads or modifies)
the Location Object. A protocol that just transports the LO as a the Location Object. A protocol that just transports the LO as a
string of bits, without looking at them (like an IP storage protocol string of bits, without looking at them (like an IP storage protocol
could do), is not a using protocol, but only a transport protocol. could do), is not a using protocol, but only a transport protocol.
Nevertheless, the entity or protocol that caused the transport Nevertheless, the entity or protocol that caused the transport
protocol to move the LO is responsible for the appropriate protocol to move the LO is responsible for the appropriate
distribution, protection, usage, retention, and storage of the LO distribution, protection, usage, retention, and storage of the LO
based on the rules that apply to that LO. based on the rules that apply to that LO.
The security and privacy enhancing mechanisms used to protect the LO The security and privacy enhancing mechanisms used to protect the LO
are of two types: First, the Location Object definition MUST are of two types: First, the Location Object definition MUST include
include the fields or mechanisms used to secure the LO as such. The the fields or mechanisms used to secure the LO as such. The LO MAY
LO MAY be secured, for example, using cryptographic checksums or be secured, for example, using cryptographic checksums or encryption
encryption as part of the LO itself. Second, the using protocol may as part of the LO itself. Second, the using protocol may also
also provide security mechanisms to securely transport the Location provide security mechanisms to securely transport the Location
Object. Object.
When defining the LO, the design should observe that the security When defining the LO, the design should observe that the security
mechanisms of the Location Object itself are to be preferred. Thus mechanisms of the Location Object itself are to be preferred. Thus
the definition of the LO MUST include some minimal crypto the definition of the LO MUST include some minimal crypto
functionality (Req. 14 and 15). Moreover, if the RM specifies the functionality (Req. 14 and 15). Moreover, if the RM specifies the
use of a particular LO security mechanism, it MUST be used (Req. 4). use of a particular LO security mechanism, it MUST be used (Req. 4).
5.3. Trusted vs. Non-trusted Data Flows 5.3. Trusted vs. Non-trusted Data Flows
Location information can be used in very different environments. In Location information can be used in very different environments. In
some cases the participants will have longstanding relationships, some cases, the participants will have longstanding relationships,
while in others the participants may have discrete interactions with while in others the participants may have discrete interactions with
no prior contractual or other contact. no prior contractual or other contact.
The different relationships raise different concerns for the The different relationships raise different concerns for the
implementation of privacy rules, including the need to communicate implementation of privacy rules, including the need to communicate
Privacy Rules. A public Rule Holder, for example, may be Privacy Rules. A public Rule Holder, for example, may be unnecessary
unnecessary in a trusted environment where more efficient methods of in a trusted environment where more efficient methods of addressing
privacy issues exist. The following terms distinguish between the
Cuellar, Morris, Mulligan, Peterson, Polk 9 two basic types of data flows:
Geopriv Requirements Oct 2003
addressing privacy issues exist. The following terms distinguish
between the two basic types of data flows:
Trusted Data Flow: Trusted Data Flow:
A data flow that is governed by a pre-existing contractual A data flow that is governed by a pre-existing contractual
relationship that addresses location privacy. relationship that addresses location privacy.
Non-trusted Data Flow: Non-trusted Data Flow:
The data flow is not governed by a pre-existing contractual The data flow is not governed by a pre-existing contractual
relationship that addresses location privacy. relationship that addresses location privacy.
5.4. Further Geopriv Principals 5.4. Further Geopriv Principals
Target: Target:
The entity whose location is desired by the Location The entity whose location is desired by the Location Recipient.
Recipient. In many cases the Target will be the human "user" In many cases the Target will be the human "user" of a Device
of a Device or an object such as a vehicle or shipping or an object such as a vehicle or shipping container to which
container to which the Device is attached. In some instances the Device is attached. In some instances the Target will be
the Target will be the Device itself. the Device itself.
Device: Device:
The technical device the location of which is tracked as a The technical device whereby the location is tracked as a proxy
proxy for the location of a Target. for the location of a Target.
A Device might, for example, be a cell phone, a Global Positioning A Device might, for example, be a cell phone, a Global Positioning
Satellite (GPS) receiver, a laptop equipped with a wireless access Satellite (GPS) receiver, a laptop equipped with a wireless access
Device, or a transmitter that emits a signal that can be tracked or Device, or a transmitter that emits a signal that can be tracked or
located. In some situations, such as when a Target manually inputs located. In some situations, such as when a Target manually inputs
location information (perhaps with a web browser), the Target is location information (perhaps with a web browser), the Target is
effectively performing the function of a Device. effectively performing the function of a Device.
Rule Maker (RM): Rule Maker (RM):
The individual or entity that has the authorization to set the The individual or entity that has the authorization to set the
skipping to change at line 532 skipping to change at page 11, line 22
contrast, may own and provide a cell phone to an employee but contrast, may own and provide a cell phone to an employee but
permit the employee to set the privacy rules. permit the employee to set the privacy rules.
There are four scenarios in which some form of constraint or There are four scenarios in which some form of constraint or
override might be placed on the Privacy Rules of the Rule override might be placed on the Privacy Rules of the Rule
Maker: Maker:
1. In the case of emergency services (such as E911 within the 1. In the case of emergency services (such as E911 within the
United States), local or national laws may require that United States), local or national laws may require that
accurate location information be transmitted in certain accurate location information be transmitted in certain
defined emergency call situations. The Geopriv Working Group defined emergency call situations. The Geopriv Working
MUST facilitate this situation. Group MUST facilitate this situation.
Cuellar, Morris, Mulligan, Peterson, Polk 10
Geopriv Requirements Oct 2003
2. In the case of legal interception, the RM may not be aware 2. In the case of legal interception, the RM may not be aware
of an override directive imposed by a legal authority. It is of an override directive imposed by a legal authority. It
not the expectation of the Working Group that particular is not the expectation of the Working Group that a
accommodation will be made to facilitate this situation. particular accommodation will be made to facilitate this
situation.
3. In the context of an employment relationship or other 3. In the context of an employment relationship or other
contractual relationship, the owner of a particular location contractual relationship, the owner of a particular location
(such as a corporate campus) may impose constraints on the use (such as a corporate campus) may impose constraints on the
of Privacy Rules by a Rule Maker. It is not the expectation use of Privacy Rules by a Rule Maker. It is not the
of the Working Group that particular accommodation will be expectation of the Working Group that a particular
made to facilitate this situation. accommodation will be made to facilitate this situation.
4. It is conceivable that a governmental authority may seek to 4. It is conceivable that a governmental authority may seek to
impose constraints on the use of Privacy Rules by a Rule impose constraints on the use of Privacy Rules by a Rule
Maker in non-emergency situations. It is not the expectation Maker in non-emergency situations. It is not the
of the Working Group that particular accommodation will be expectation of the Working Group that a particular
made to facilitate this situation. accommodation will be made to facilitate this situation.
Viewer: Viewer:
An individual or entity who receives location data about a An individual or entity who receives location data about a
Target and does not transmit the location information or Target and does not transmit the location information or
information based on the Target's location (such as driving information based on the Target's location (such as driving
directions to or from the Target) to any party OTHER than the directions to or from the Target) to any party OTHER than the
Target or the Rule Maker. Target or the Rule Maker.
Data Transporter: Data Transporter:
An entity or network that receives and forwards data without An entity or network that receives and forwards data without
processing or altering it. A Data Transporter could processing or altering it. A Data Transporter could
theoretically be involved in almost any transmission between a theoretically be involved in almost any transmission between a
Device and a Location Server, a Location Server and a second Device and a Location Server, a Location Server and a second
Location Server, or a Location Server and an Viewer. Some Location Server, or a Location Server and a Viewer. Some
location tracking scenarios may not involve a Data location tracking scenarios may not involve a Data Transporter.
Transporter.
Access Provider (AP): Access Provider (AP):
The domain that provides the initial network access or other The domain that provides the initial network access or other
data communications services essential for the operation of data communications services essential for the operation of
communications functions of the Device or computer equipment communications functions of the Device or computer equipment in
in which the Device operates. Often, the AP -- which will be which the Device operates. Often, the AP -- which will be a
a wireless carrier, an Internet Service Provider, or an wireless carrier, an Internet Service Provider, or an internal
internal corporate network -- contains the LG. Sometimes the corporate network -- contains the LG. Sometimes the AP has a
AP has a "dumb" LG, one that transmits Geopriv LOs but does "dumb" LG, one that transmits Geopriv LOs but does not use any
not use any part of the Geopriv Location Object. Other cases part of the Geopriv Location Object. Other cases may not
may not involve any AP, or the AP may only act as a Data involve any AP, or the AP may only act as a Data Transporter.
Transporter.
Location Storage: Location Storage:
A Device or entity that stores raw or processed Location A Device or entity that stores raw or processed Location
Information, such as a database, for any period of time longer Information, such as a database, for any period of time longer
than the duration necessary to complete an immediate than the duration necessary to complete an immediate
transaction regarding the Location Information. transaction regarding the Location Information.
Cuellar, Morris, Mulligan, Peterson, Polk 11
Geopriv Requirements Oct 2003
The existence and data storage practices of Location Storage is The existence and data storage practices of Location Storage is
crucial to privacy considerations, because this may influence what crucial to privacy considerations, because this may influence what
Location Information could eventually be revealed (through later Location Information could eventually be revealed (through later
distribution, technical breach, or legal processes). distribution, technical breach, or legal processes).
5.5. Privacy Rules 5.5. Privacy Rules
Privacy Rules are rules that regulate an entity's activities with Privacy Rules are rules that regulate an entity's activities with
respect to location and other information, including, but not respect to location and other information, including, but not limited
limited to, the collection, use, disclosure, and retention of to, the collection, use, disclosure, and retention of location
location information. Such rules are generally based on fair information. Such rules are generally based on fair information
information practices, as detailed in (for example) the OECD practices, as detailed in (for example) the OECD Guidelines on the
Guidelines on the Protection of Privacy and Transporter Flows of Protection of Privacy and Transporter Flows of Personal Data [OECD].
Personal Data [OECD].
Privacy Rule: Privacy Rule:
A rule or set of rules that regulate an entity's activities A rule or set of rules that regulate an entity's activities
with respect to location information, including the with respect to location information, including the collection,
collection, use, disclosure, and retention of location use, disclosure, and retention of location information. In
information. In particular, the Rule describes how location particular, the Rule describes how location information may be
information may be used by an entity and which transformed used by an entity and which transformed location information
location information may be released to which entities under may be released to which entities under which conditions.
which conditions. Rules must be obeyed; they are not Rules must be obeyed; they are not advisory.
advisory.
A full set of Privacy Rules will likely include both rules that have A full set of Privacy Rules will likely include both rules that have
only one possible technical meaning, and rules that will be affected only one possible technical meaning, and rules that will be affected
by a locality's prevailing laws and customs. For example, a by a locality's prevailing laws and customs. For example, a
distribution rule of the form "my location can only be disclosed to distribution rule of the form "my location can only be disclosed to
the owner of such credentials and in such precision or resolution" the owner of such credentials and in such precision or resolution"
has clear-cut implications for the protocol that uses the LO. But has clear-cut implications for the protocol that uses the LO. But
other rules, like retention or usage Rules, may have unclear other rules, like retention or usage Rules, may have unclear
technical consequences for the protocol or for the involved technical consequences for the protocol or for the involved entities.
entities. For example, the precise scope of a retention rule For example, the precise scope of a retention rule stating "you may
stating "you may not store my location for more than 2 days" may in not store my location for more than 2 days" may in part turn on local
part turn on local laws or customs. laws or customs.
5.6. Identifiers, Authentication and Authorization 5.6. Identifiers, Authentication and Authorization
Anonymity is the property of being not identifiable (within a set of Anonymity is the property of being not identifiable (within a set of
subjects). Anonymity serves as the base case for privacy: without subjects). Anonymity serves as the base case for privacy: without
the ability to remain anonymous, individuals may be unable to the ability to remain anonymous, individuals may be unable to control
control their own privacy. Unlinkability ensures that a user may their own privacy. Unlinkability ensures that a user may make
make multiple uses of resources or services without others being multiple uses of resources or services without others being able to
able to link these uses to each other. Unlinkability requires that link these uses to each other. Unlinkability requires that entities
entities are unable to determine whether the same user caused be unable to determine whether the same user caused certain specific
certain specific operations in the system. [ISO99] A pseudonym is operations in the system. [ISO99] A pseudonym is simply a bit string
simply a bit string which is unique as ID and is suitable to be used which is unique as an ID and is suitable to be used for end-point
for end-point authentication. authentication.
Cuellar, Morris, Mulligan, Peterson, Polk 12
Geopriv Requirements Oct 2003
Unlinked Pseudonym: Unlinked Pseudonym:
A pseudonym where the linking between the pseudonym and its A pseudonym where the linking between the pseudonym and its
holder is, at least initially, not known to anybody with the holder is, at least initially, not known to anybody with the
possible exception of the holder himself or a trusted server possible exception of the holder himself or a trusted server of
of the user. See [Pfi01] (there the term is called Initially the user. See [Pfi01] (there the term is called Initially
Unlinked Pseudonym) Unlinked Pseudonym).
The word authentication is used in different meanings. Some require The word authentication is used in different manners. Some require
that authentication associates an entity with a more or less well- that authentication associates an entity with a more or less well-
known identity. This basically means that if A authenticates known identity. This basically means that if A authenticates another
another entity B as being "id-B", then the label "id-B" is a well- entity B as being "id-B", then the label "id-B" is a well-known, or
known, or at least a linkable identity of the entity. In this case, at least a linkable identity of the entity. In this case, the label
the label "id-B" is called a publicly known identifier, and the "id-B" is called a publicly known identifier, and the authentication
authentication is "explicit": is "explicit":
Explicit Authentication: Explicit Authentication:
The act of verifying a claimed identity as the sole originator The act of verifying a claimed identity as the sole originator
of a message (message authentication) or as the end-point of a of a message (message authentication) or as the end-point of a
channel (entity authentication). Moreover, this identity is channel (entity authentication). Moreover, this identity is
easily linked back to the real identity of the entity in easily linked back to the real identity of the entity in
question, for instance being a pre-existing static label from question, for instance being a pre-existing static label from a
a predefined name space (telephone number, name, etc.). predefined name space (telephone number, name, etc.)
Authorization: Authorization:
The act of determining if a particular right, such as access The act of determining if a particular right, such as access to
to some resource, can be granted to the presenter of a some resource, can be granted to the presenter of a particular
particular credential. credential.
Depending on the type of credential, authorization may imply Depending on the type of credential, authorization may or may not
Explicit Authentication or not. imply Explicit Authentication.
6. Scenarios and Explanatory Discussion 6. Scenarios and Explanatory Discussion
In this subsection we introduce 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. Additional illustrative scenarios are discussed in a transactions. Additional illustrative scenarios are discussed in a
separate Document. separate document.
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 the
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. independently processing the raw data to determine its location. The
The location is derived as follows: the Device receives location is derived as follows: the Device receives transmissions
transmissions from the GPS satellites, internally computes and from the GPS satellites, internally computes and displays location.
displays location. This is a closed system. For the purpose of this This is a closed system. For the purpose of this and subsequent
and subsequent examples, it is assumed that the GPS satellite examples, it is assumed that the GPS satellite broadcasts some
broadcasts some signal, and has no information about the identity or signal, and has no information about the identity or whereabouts of
whereabouts of Devices using the signal. Devices using the signal.
Cuellar, Morris, Mulligan, Peterson, Polk 13
Geopriv Requirements Oct 2003
GPS Satellite GPS Satellite
| |
| Sighting (not a Geopriv Interface) | Sighting (not a Geopriv Interface)
| |
| |
| |
V GPS Device V GPS Device
-------------------------------------------------- --------------------------------------------------
/ \ / \
skipping to change at line 727 skipping to change at page 15, line 52
/ V \ / V \
/ Target Location \ / Target Location \
| Recipient | | Recipient |
| | | |
\ Rule Maker / \ Rule Maker /
\ / \ /
------------------- -------------------
In this scenario the GPS Device is both the AP and the LG. The In this scenario the GPS Device is both the AP and the LG. The
interaction occurs in a Trusted environment because it occurs in the interaction occurs in a Trusted environment because it occurs in the
Rule Makers 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)
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 Target and Device are roaming. When the Target wishes to use the
the cell phone, cell phone Corp 1 (AP) provides the roaming service cell phone, cell phone Corp 1 (AP) provides the roaming service for
for the Target, which sends the raw data about usage (e.g., duration the Target, which sends the raw data about usage (e.g., duration of
of call, location roaming network, etc.) to cell phone Corp 2, the call, location in the roaming network, etc.) to cell phone Corp 2,
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
the accounting company, which processes the raw data for the the accounting company, which processes the raw data for the
accounting statements. Finally, the raw data is sent to a data accounting statements. Finally, the raw data is sent to a data
warehouse where the raw data is stored in a Location Server (e.g., warehouse where the raw data is stored in a Location Server (e.g.,
computer server). computer server).
Cuellar, Morris, Mulligan, Peterson, Polk 14
Geopriv Requirements Oct 2003
Cell Phone Corp 1 Cell Phone Corp 2 Cell Phone Corp 1 Cell Phone Corp 2
----------------- ----------------- ----------------- -----------------
Sighting / \ Publish / \ Sighting / \ Publish / \
Device ----- | Data Transporter | --------- | Data Transporter | Device ----- | Data Transporter | --------- | Data Transporter |
Target \ / Interface \ / Target \ / Interface \ /
----------------- / ----------------- ----------------- / -----------------
/ | / |
/ | Notification / | Notification
/ | Interface / | Interface
----------- | ----------- |
skipping to change at line 769 skipping to change at page 16, line 42
------------ / ---------- ------------ / ----------
/ \ / / \ / \ / / \
/ Location \ / | Location | / Location \ / | Location |
| Storage | Location Info | Storage | | Storage | Location Info | Storage |
| |<----------------- | | | |<----------------- | |
| Location | | Location | | Location | | Location |
| Recipient | | Recipient | | Recipient | | Recipient |
\ / \ / \ / \ /
------------- ---------- ------------- ----------
Here cell phone Corp 1 is the AP and the LG. In this scenario, Cell Here, cell phone Corp 1 is the AP and the LG. In this scenario, Cell
phone Corp 2 is likely to be a Trusted entity, but cell phone Corp phone Corp 2 is likely to be a Trusted entity, but cell phone Corp 1
1 may be Non-trusted. may be Non-trusted.
SCENARIO 3: Mobile Communities and Location-Based Services SCENARIO 3: Mobile Communities and Location-Based Services
The figure below shows a common scenario, where a user wants to find 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 his friends or colleagues or wants to share his position with them or
or with a Location-Based Service Provider. Some of the messages use with a Location-Based Service Provider. Some of the messages use a
a Location Object to carry, for instance, identities or pseudonyms, Location Object to carry, for instance, identities or pseudonyms,
credentials and proof-of-possession of them, Rules and Location Data credentials and proof-of-possession of them, Rules and Location Data
Information, including Data Types and Precision or Resolution. Information, including Data Types and Precision or Resolution.
Messages that do not use the Location Object and are outside of the Messages that do not use the Location Object and are outside of the
scope of the Geopriv WG, but should be mentioned for scope of the Geopriv WG, but should be mentioned for
understandability, are shown in the figure as starred arrows understandability, are shown in the figure as starred arrows
("***>"). ("***>").
Cuellar, Morris, Mulligan, Peterson, Polk 15
Geopriv Requirements Oct 2003
+---------+ +------------+ +---------+ +------------+
| | | | | | | |
| Location|<** | Public | | Location|<** | Public |
|Generator| * | Rule Holder| |Generator| * | Rule Holder|
| | * | | | | * | |
+---------+\ * +------------+ +---------+\ * +------------+
\ *3 1a* * \ *3 1a* *
\ * * * \ * * *
\ ** * \ ** *
\ * * *1a \ * * *1a
skipping to change at line 823 skipping to change at page 17, line 52
+----------+ +----------+
| Location | | Location |
| Recipient| | Recipient|
+----------+ +----------+
Assume that the Rule Maker and the Target are registered with the Assume that the Rule Maker and the Target are registered with the
Location Server. The RM has somehow proven to the LS that he indeed Location Server. The RM has somehow proven to the LS that he indeed
is the owner of the privacy rights of the Target (the Target is 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 usually a Device owned by the Rule Maker). The Rule Maker and the
Location Server have agreed on the set of keys or credentials and Location Server have agreed on the set of keys or credentials and
cryptographic material that they will use to authenticate each cryptographic material that they will use to authenticate each other,
other, and in particular, to authenticate or sign the Rules. How and in particular, to authenticate or sign the Rules. How this has
this has been done is outside of the scope of the document. been done is outside of the scope of the document.
1: Rule Transfer: 1: Rule Transfer:
The Rule Maker sends a Rule to the Location Server. This Rule The Rule Maker sends a Rule to the Location Server. This Rule
may be a field in a Location Object or not. may or may not be a field in a Location Object.
1a:Signed Rule: 1a:Signed Rule:
As an alternative, the Rule Maker may write a Rule and place As an alternative, the Rule Maker may write a Rule and place it
it in a Public Rule Holder. The entities access the in a Public Rule Holder. The entities access the repository to
repository to read the signed Rules. read the signed Rules.
2: Location Information Request: 2: Location Information Request:
The Location Recipient requests location information for a The Location Recipient requests location information for a
Cuellar, Morris, Mulligan, Peterson, Polk 16
Geopriv Requirements Oct 2003
Target. In this request, the Location Recipient may select Target. In this request, the Location Recipient may select
which location information data type it prefers. One way of which location information data type it prefers. One way of
requesting Location Information MAY be sending a partially requesting Location Information MAY be sending a partially
filled Location Object, including only the identities of the filled Location Object, including only the identities of the
Target and Location Recipient and the desired Data Type and Target and Location Recipient and the desired Data Type and
precision or resolution, and providing proof of possession of precision or resolution, and providing proof of possession of
the required credentials. But whether the using protocol the required credentials. But whether or not the using
understands this partially filled object as a request, this protocol understands this partially filled object as a request
MAY depend on the using protocol or on the context. The MAY depend on the using protocol or on the context. The
Location Recipient could also specify the need for periodic Location Recipient could also specify the need for periodic
location information updates, but this is probably out of the location information updates, but this is probably out of the
scope of Geopriv. scope of Geopriv.
3: Locate: 3: Locate:
When a Location Server receives an Location Information When a Location Server receives a Location Information Request
Request for a Target for which has no current location for a Target which has no current location information, the
information, the server may send ask the Location Generator to server may ask the Location Generator to locate the Target.
locate the Target.
4: Location Information: 4: Location Information:
The Location Generator sends the "full" location information The Location Generator sends the "full" location information to
to the Location Server. This Location Information may be the Location Server. This Location Information may or may not
embedded in a Location Object or not. be embedded in a Location Object.
5: Filtered Location Information: 5: Filtered Location Information:
Then the Location Server sends the location information to the The Location Server sends the location information to the
Location Recipient. The information may be filtered in the Location Recipient. The information may be filtered in the
sense that in general a less precise or a computed version of sense that in general a less precise or a computed version of
the information is being delivered. the information is being delivered.
7. Requirements 7. Requirements
7.1. Location Object 7.1. Location Object
Recall that this document is primarily specifying requirements on Remember that this document is primarily specifying requirements on
how the definition of the LO. Some Requirements read like this: the definition of the LO. Some Requirements read like this: "The LO
"The LO definition MUST contain Field 'A' as an optional field." definition MUST contain Field 'A' as an optional field." This
This requirement just states that requirement states that
o the document that defines the LO MUST define the LO field 'A', o the document that defines the LO MUST define the LO field 'A',
o the field 'A' MUST be defined as optional to use (an instance of a o the field 'A' MUST be defined as optional to use (an instance of a
LO MAY contain the field 'A' or not). LO MAY or may not contain the field 'A').
Some Requirements read like this: "The LO definition MUST contain Some Requirements read like this: "The LO definition MUST contain
Field 'A', which MAY be an optional field." This requirement states Field 'A', which MAY be an optional field." This requirement states
that that
o the document that defines the LO MUST define the LO field 'A', o the document that defines the LO MUST define the LO field 'A',
o the field 'A' MAY be defined as optional or not to use. If it is
defined as optional to use, any instance of a LO MAY contain the
field 'A' or not; if it is not optional, all instances of LOs MUST
contain the field 'A'.
Cuellar, Morris, Mulligan, Peterson, Polk 17 o the field 'A' MAY be defined as optional or not to use. If it is
Geopriv Requirements Oct 2003 defined as optional to use, any instance of an LO MAY or may not
contain the field 'A'; if it is not optional, all instances of LOs
MUST contain the field 'A'.
Req. 1. (Location Object generalities) Req. 1. (Location Object generalities)
1.1) Geopriv MUST define one Location Object (LO) -- both in 1.1) Geopriv MUST define one Location Object (LO) -- both in
syntax and semantics -- that must be supported by all Geopriv syntax and semantics -- that must be supported by all Geopriv
entities. entities.
1.2) Some fields of the Location Object MAY be optional. This 1.2) Some fields of the Location Object MAY be optional. This
means that an instance of a Location Object MAY contain the means that an instance of a Location Object MAY or may not contain
fields or not. the fields.
1.3) Some fields of the Location Object MAY be defined as 1.3) Some fields of the Location Object MAY be defined as
"extensions". This means that the syntax or semantics of these "extensions". This means that the syntax or semantics of these
fields is not fully defined in the basic Location Object fields is not fully defined in the basic Location Object
definition, but their use may be private to one or more using definition, but their use may be private to one or more of the
protocols. using protocols.
1.4) The Location Object MUST be extensible, allowing the 1.4) The Location Object MUST be extensible, allowing the
definition of new attributes or fields. definition of new attributes or fields.
1.5) The object MUST be suitable for requesting and receiving a 1.5) The object MUST be suitable for requesting and receiving a
location. location.
1.6) The object MUST permit (but not require) the Privacy Rules 1.6) The object MUST permit (but not require) the Privacy Rules to
to be enforced by a third party. be enforced by a third party.
1.7) The object MUST be usable in a variety of protocols, such as 1.7) The object MUST be usable in a variety of protocols, such as
HTTP and SIP, as well as local APIs. HTTP and SIP, as well as local APIs.
1.8) The object MUST be usable in a secure manner even by 1.8) The object MUST be usable in a secure manner even by
applications on constrained devices. applications on constrained devices.
Req. 2. (Location Object fields) The Location Object definition Req. 2. (Location Object fields) The Location Object definition MUST
MUST contain the following Fields, which MAY be optional to use: contain the following Fields, which MAY be optional to use:
2.1) Target Identifier 2.1) Target Identifier
2.2) Location Recipient Identity 2.2) Location Recipient Identity
This identity may be a multicast or group identity, used to This identity may be a multicast or group identity, used to
include the Location Object in multicast-based using protocols. include the Location Object in multicast-based using protocols.
2.3) Location Recipient Credential 2.3) Location Recipient Credential
2.4) Location Recipient Proof-of-Possession of the Credential 2.4) Location Recipient Proof-of-Possession of the Credential
2.5) Location Field. 2.5) Location Field
2.5.1) Motion and direction vectors. This field MUST be
optional.
Cuellar, Morris, Mulligan, Peterson, Polk 18 2.5.1) Motion and direction vectors. This field MUST be optional.
Geopriv Requirements Oct 2003
2.6) Location Data Type 2.6) Location Data Type
When transmitting the Location Object, the sender and the When transmitting the Location Object, the sender and the receiver
receiver must agree on the data type of the location information. must agree on the data type of the location information. The
The using protocol may specify that the data type information is using protocol may specify that the data type information is part
part of the Location Object or that sender and receiver have of the Location Object or that the sender and receiver have agreed
agreed on it before the actual data transfer. on it before the actual data transfer.
2.7) Timing information: 2.7) Timing information:
(a) When was the Location Information accurate? (sighting time) (a) When was the Location Information accurate? (sighting time)
(b) Until when considered current? TTL (Time-to-live) (This is (b) Until when considered current? TTL (Time-to-live) (This is
different than a privacy rule setting a limit on data retention) different than a privacy rule setting a limit on data retention)
2.8) Rule Field: this field MAY be a referral to an applicable 2.8) Rule Field: this field MAY be a referral to an applicable
Rule (for instance, an URI to a full Rule), or it MAY contain a Rule (for instance, a URI to a full Rule), or it MAY contain a
Limited Rule (see Req. 11), or both. Limited Rule (see Req. 11), or both.
2.9) Security-headers and -trailers (for instance encryption 2.9) Security-headers and -trailers (for instance encryption
information, hashes, or signatures) (see Req. 14 and 15). information, hashes, or signatures) (see Req. 14 and 15).
2.10) Version number 2.10) Version number
Req. 3. (Location Data Types) Req. 3. (Location Data Types)
3.1) The Location Object MUST define at least one Location Data 3.1) The Location Object MUST define at least one Location Data
Type to be supported by all Geopriv receivers (entities that Type to be supported by all Geopriv receivers (entities that
receive LOs). receive LOs).
3.2) The Location Object SHOULD define two Location Data Types: 3.2) The Location Object SHOULD define two Location Data Types:
one for latitude / longitude / altitude coordinates and one for one for latitude / longitude / altitude coordinates and one for
civil locations (City, Street, Number) supported by all Geopriv civil locations (City, Street, Number) supported by all Geopriv
receivers (entities that receive LOs). receivers (entities that receive LOs).
skipping to change at line 990 skipping to change at page 21, line 21
one for latitude / longitude / altitude coordinates and one for one for latitude / longitude / altitude coordinates and one for
civil locations (City, Street, Number) supported by all Geopriv civil locations (City, Street, Number) supported by all Geopriv
receivers (entities that receive LOs). receivers (entities that receive LOs).
3.3) The latitude / longitude / altitude Data Type SHOULD also 3.3) The latitude / longitude / altitude Data Type SHOULD also
support a delta format in addition to an absolute one, used for support a delta format in addition to an absolute one, used for
the purpose of reducing the size of the packages or the security the purpose of reducing the size of the packages or the security
and confidentiality needs. and confidentiality needs.
3.4) The Location Object definition SHOULD agree on further 3.4) The Location Object definition SHOULD agree on further
Location Data Types supported by some Geopriv entities and Location Data Types supported by some Geopriv entities and defined
defined by other organizations. by other organizations.
7.2. The Using Protocol 7.2. The Using Protocol
Req. 4. The using protocol has to obey the privacy and security Req. 4. The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the instructions coded in the Location Object and in the corresponding
corresponding Rules regarding the transmission and storage of the Rules regarding the transmission and storage of the LO.
LO.
Req. 5. The using protocol will typically facilitate that the keys Req. 5. The using protocol will typically facilitate that the keys
associated with the credentials are transported to the respective associated with the credentials are transported to the respective
parties, that is, key establishment is the responsibility of the
using protocol.
Cuellar, Morris, Mulligan, Peterson, Polk 19 Req. 6. (Single Message Transfer) In particular, for tracking of
Geopriv Requirements Oct 2003
parties, that is, key agreement is responsibility of the using
protocol.
Req. 6. (Single Message Transfer) In particular for tracking of
small target devices, the design should allow a single small target devices, the design should allow a single
message/packet transmission of location as a complete message/packet transmission of location as a complete transaction.
transaction.
Other requirements on the using protocol are out of the scope of Other requirements on the using protocol are out of the scope of this
this document, but might be the subject of future efforts from this document, but might be the subject of future efforts from this
working group. See also Section 9 (Protocol and LO Issues for later working group. See also Section 9 (Protocol and LO Issues for later
Consideration) Consideration).
7.3. Rule based Location Data Transfer 7.3. Rule based Location Data Transfer
Req. 7. (LS Rules) The decision of a Location Server to provide a Req. 7. (LS Rules) The decision of a Location Server to provide a
Location Recipient access to Location Information MUST be based Location Recipient access to Location Information MUST be based on
on Rule Maker-defined Privacy Rules. Rule Maker-defined Privacy Rules.
It is outside of our scope how Privacy Rules are managed and how a It is outside of our scope how Privacy Rules are managed and how a
Location Server has access to the Privacy Rules. Note that it might Location Server has access to the Privacy Rules. Note that it might
be that some rules contain private information not intended for be that some rules contain private information not intended for
untrusted parties. untrusted parties.
Req. 8. (LG Rules) Even if a Location Generator is unaware of and Req. 8. (LG Rules) Even if a Location Generator is unaware of and
lacks access to the full Privacy Rules defined by the Rule Maker, lacks access to the full Privacy Rules defined by the Rule Maker,
the Location Generator MUST transmit Location Information in the Location Generator MUST transmit Location Information in
compliance with instructions set by the Rule Maker. Such compliance with instructions set by the Rule Maker. Such
compliance MAY be accomplished by the Location Generator compliance MAY be accomplished by the Location Generator
transmitting the LO only to a URI designated by the Rule Maker. transmitting the LO only to a URI designated by the Rule Maker.
Req. 9. (Viewer Rules) An Viewer does not need to be aware of the Req. 9. (Viewer Rules) A Viewer does not need to be aware of the
full Rules defined by the Rule Maker (because an Viewer SHOULD full Rules defined by the Rule Maker (because a Viewer SHOULD NOT
NOT retransmit Location Information), and thus an Viewer SHOULD retransmit Location Information), and thus a Viewer SHOULD receive
receive only the subset of Privacy Rules necessary for the Viewer only the subset of Privacy Rules necessary for the Viewer to
to handle the LO in compliance with the full Privacy Rules (such handle the LO in compliance with the full Privacy Rules (such as,
as, for example, an instruction on the time period for which then instruction on the time period for which the LO can be retained).
the LO can be retained).
Req. 10. (Full Rule language) Geopriv MAY specify a Rule language Req. 10. (Full Rule language) Geopriv MAY specify a Rule language
capable of expressing a wide range of privacy rules concerning capable of expressing a wide range of privacy rules concerning
location information. This Rule language MAY be an existing one, location information. This Rule language MAY be an existing one,
an adaptation of an existing one or a new Rule language, and it an adaptation of an existing one or a new Rule language, and it
SHOULD be as simple as possible. SHOULD be as simple as possible.
Req. 11. (Limited Rule language) Geopriv MUST specify a limited Req. 11. (Limited Rule language) Geopriv MUST specify a limited Rule
Rule language capable of expressing a limited set of privacy language capable of expressing a limited set of privacy rules
rules concerning location information. This Rule language MAY be concerning location information. This Rule language MAY be an
an existing one, an adaptation of an existing one or a new Rule existing one, an adaptation of an existing one or a new Rule
language. The Location Object MUST include sufficient fields and language. The Location Object MUST include sufficient fields and
data to express the limited set of privacy rules. data to express the limited set of privacy rules.
Cuellar, Morris, Mulligan, Peterson, Polk 20
Geopriv Requirements Oct 2003
7.4. Location Object Privacy and Security 7.4. Location Object Privacy and Security
7.4.1. Identity Protection 7.4.1. Identity Protection
Req. 12. (Identity Protection) The Location Object MUST support use Req. 12. (Identity Protection) The Location Object MUST support use
of Unlinked Pseudonyms in the corresponding identification fields of Unlinked Pseudonyms in the corresponding identification fields
of Rule Maker, Target, Device, and Location Recipient. Since of Rule Maker, Target, Device, and Location Recipient. Since
Unlinked Pseudonyms are simply bit strings that are not linked Unlinked Pseudonyms are simply bit strings that are not linked
initially to a well-known identity, this requirement boils down initially to a well-known identity, this requirement boils down to
to saying that the name space for Identifiers used in the LO has saying that the name space for Identifiers used in the LO has to
to be large enough to contain many unused strings. be large enough to contain many unused strings.
7.4.2. Authentication Requirements 7.4.2. Authentication Requirements
Req. 13. (Credential Requirements) The using protocol and the Req. 13. (Credential Requirements) The using protocol and the
Location Object SHOULD allow the use of different credentials Location Object SHOULD allow the use of different credential
types, including privacy-enhancing credentials (like for instance types, including privacy-enhancing credentials (for instance those
the ones described in [Bra00] or [Cha85]). described in [Bra00] or [Cha85]).
7.4.3. Actions to be secured 7.4.3. Actions to be secured
Req. 14. (Security Features) The Location Object MUST support Req. 14. (Security Features) The Location Object MUST support fields
fields suitable for protecting the Object to provide the suitable for protecting the Object to provide the following
following security features: security features:
14.1) Mutual end-point authentication: the using protocol is 14.1) Mutual end-point authentication: the using protocol is
able to authenticate both parties in a Location Object able to authenticate both parties in a Location Object
transmission, transmission,
14.2) Data object integrity: the LO is secured from 14.2) Data object integrity: the LO is secured from
modification by unauthorized entities during transmission and modification by unauthorized entities during transmission and
during storage, storage,
14.3) Data object confidentiality: the LO is secured from 14.3) Data object confidentiality: the LO is secured from
eavesdropping (unauthorized reading) during transmission and eavesdropping (unauthorized reading) during transmission and
during storage, and storage, and
14.4) Replay protection: an old LO may not be replayed by an 14.4) Replay protection: an old LO may not be replayed by an
adversary or by the same entity that used the LO itself (except adversary or by the same entity that used the LO itself (except
perhaps during a small window of time that is configurable or perhaps during a small window of time that is configurable or
accepted by the Rule Maker). accepted by the Rule Maker).
Req. 15. (Minimal Crypto) Req. 15. (Minimal Crypto)
15.1) Geopriv MUST specify a minimum mandatory to implement 15.1) Geopriv MUST specify a minimum mandatory to implement
Location Object security including mandatory to implement crypto Location Object security, including mandatory to implement crypto
algorithms, for digital signature algorithms and encryption algorithms for digital signature algorithms and encryption
algorithms. algorithms.
15.2) It MAY also define further mandatory to implement 15.2) It MAY also define further mandatory to implement
Location Object security mechanisms for message authentication Location Object security mechanisms for message authentication
codes (MACs) or other purposes. codes (MACs) or other purposes.
Cuellar, Morris, Mulligan, Peterson, Polk 21
Geopriv Requirements Oct 2003
15.3) The protocol SHOULD allow a bypass if authentication 15.3) The protocol SHOULD allow a bypass if authentication
fails in an emergency call. fails in an emergency call.
The issue addressed in the last point is that an emergency call in The issue addressed in the last point is that an emergency call in
some unfavorable situations may not be completed if the minimal some unfavorable situations may not be completed if the minimal
authentication fails. This is probably not what the user would like authentication fails. This is probably not what the user would like
to happen. The user may prefer an unauthenticated call to an to happen. The user may prefer an unauthenticated call to an
unauthenticated emergency server over no call completion at all, unauthenticated emergency server over no call completion at all, even
even at the risk that he is talking to an attacker or that his at the risk that he is talking to an attacker or that his information
information is not secured. is not secured.
7.5. Non-Requirements 7.5. Non-Requirements
Non-Req. 1. (Bridging to non-IP networks) The Geopriv specification Non-Req. 1. (Bridging to non-IP networks) The Geopriv specification
SHOULD NOT specify the bridging to non-IP networks (PSTN, etc). SHOULD NOT specify the bridging to non-IP networks (PSTN, etc).
8. Security Considerations 8. Security Considerations
The purpose of the Geopriv Location Object and the requirements on The purpose of the Geopriv Location Object and the requirements on
the using protocol are to allow a Privacy Rule-controlled disclosure the using protocol are to allow a Privacy Rule-controlled disclosure
of location information for location services. of location information for location services.
8.1. Traffic Analysis 8.1. Traffic Analysis
The information carried within the Location Object is secured in a The information carried within the Location Object is secured in a
way compliant with the privacy and security Rules of the Rule Maker, way compliant with the privacy and security Rules of the Rule Maker,
but other information, carried in other objects or headers are in but other information, carried in other objects or headers are in
general not secured in the same way. This means that Geopriv may general not secured in the same way. This means that Geopriv may not
not as a general matter secure the Target against general traffic as a general matter, secure the Target against general traffic
analysis attacks or other forms of privacy violations. analysis attacks or other forms of privacy violations.
8.2. Securing the Privacy Rules 8.2. Securing the Privacy Rules
The Privacy Rules of the Rule Maker regarding the location of the The Privacy Rules of the Rule Maker regarding the location of the
Target may be accessible to a Location Server in a public or non- Target may be accessible to a Location Server in a public or non-
public Rule Holder, or they may be carried by the Location Object, public Rule Holder, or they may be carried by the Location Object, or
or they may be presented by the Location Recipient as capabilities they may be presented by the Location Recipient as capabilities or
or tokens. Each of this types of Rule has to be secured it's own tokens. Each type of Rule has to be secured its own particular way.
particular way.
The rules in a non-public Rule Holder are typically authenticated The rules in a non-public Rule Holder are typically authenticated
using a MAC (Message Authentication Code) or a signature, depending using a MAC (Message Authentication Code) or a signature, depending
on the type of keys used. The rules in a public Rule Holder (one on the type of keys used. The rules in a public Rule Holder (one
that in principle may be accessed directly by several entities, for that in principle may be accessed directly by several entities, for
instance several Location Servers) are typically digitally signed. instance several Location Servers) are typically digitally signed.
Rule Fields in a LO are secured as part of the LO itself. A Geopriv Rule Fields in an LO are secured as part of the LO itself. A Geopriv
Token (a token or ticket issued by the Rule Maker to a Location Token (a token or ticket issued by the Rule Maker to a Location
Recipient, expressing the explicit consent of the Rule Maker to Recipient, expressing the explicit consent of the Rule Maker to
access his location information) is authenticated or signed. access his location information) is authenticated or signed.
Cuellar, Morris, Mulligan, Peterson, Polk 22
Geopriv Requirements Oct 2003
8.3. Emergency Case 8.3. Emergency Case
Let us consider the situation where the authentication fails in an Let us consider the situation where the authentication fails in an
emergency call because the authentication center fails to emergency call because the authentication center fails to
authenticate itself. In this case, one way of implementing the authenticate itself. In this case, one way of implementing the
authentication bypass for emergency calls, mentioned in Req 15.3) is authentication bypass for emergency calls (mentioned in Req 15.3) is
to let the user have the choice of writing a Rule that says: to let the user have the choice of writing a Rule that says:
- "If the emergency server does not authenticate itself, send the - "If the emergency server does not authenticate itself, send the
location information anyway", or location information anyway", or
- "If the emergency server does not authenticate itself, let the - "If the emergency server does not authenticate itself, let the
call fail". call fail".
Second, in the case where the authentication of the emergency call Second, in the case where the authentication of the emergency call
fails because the user may not authenticate itself, the question fails because the user may not authenticate itself, the question
arises: whose Rule to use? It is reasonable to use a default one: arises: whose Rule to use? It is reasonable to use a default one:
this location information can only be sent to an emergency center. this location information can only be sent to an emergency center.
The third situation, which should be studied in more detail, is: The third situation, which should be studied in more detail, is:
what to do if not only the user fails to authenticate itself, but what to do if not only the user fails to authenticate itself, but
skipping to change at line 1190 skipping to change at page 25, line 21
call fail". call fail".
Second, in the case where the authentication of the emergency call Second, in the case where the authentication of the emergency call
fails because the user may not authenticate itself, the question fails because the user may not authenticate itself, the question
arises: whose Rule to use? It is reasonable to use a default one: arises: whose Rule to use? It is reasonable to use a default one:
this location information can only be sent to an emergency center. this location information can only be sent to an emergency center.
The third situation, which should be studied in more detail, is: The third situation, which should be studied in more detail, is:
what to do if not only the user fails to authenticate itself, but what to do if not only the user fails to authenticate itself, but
also the emergency center is not authenticable? It is reasonable to also the emergency center is not authenticable? It is reasonable to
send the Location Information anyway, but are there in this case any send the Location Information anyway, but are there any security
security threats that must be considered? threats that must be considered?
8.4. Identities and Anonymity 8.4. Identities and Anonymity
The use of Unlinked Pseudonyms is necessary to obtain anonymity. The use of Unlinked Pseudonyms is necessary to obtain anonymity.
The purpose of the use of Unlinked Pseudonyms is the following: the 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 using protocol should be able to hide the real identity of the Rule
Maker, the Target, and the Device, to Location Servers or Location Maker, the Target, and the Device, from Location Servers or Location
Recipients, if required by the RM. Also, the using protocol SHOULD Recipients, if required by the RM. Also, the using protocol SHOULD
be able to hide the real identity of the Location Recipient to the be able to hide the real identity of the Location Recipient from the
Location Server. Location Server.
In this last case, the Target is not concerned about the Server In this last case, the Target is not concerned about the Server
identifying him and knowing his location, but identifying his identifying him and knowing his location, but identifying his
business partners, and therefore his habits, etc. Reasons for business partners, and therefore his habits, etc. Reasons for hiding
hiding the real identities of the Location Recipients include (a) the real identities of the Location Recipients include (a) that this
that this knowledge may be used to infer the identity of the Target, knowledge may be used to infer the identity of the Target, (b) that
(b) that knowledge of the identity of the Location Recipient may knowledge of the identity of the Location Recipient may embarrass the
embarrass the Target or breach confidential information, and (c) Target or breach confidential information, and (c) that the dossier
that the dossier telling who has obtained a Target's location telling who has obtained a Target's location information over a long
information over a long period of time can give information on period of time can give information on habits, movements, etc. Even
habits, movements, etc. Even if the location service providers if the location service providers agree to respect the privacy of the
agree to respect the privacy of the user, are compelled by laws or user, are compelled by laws or regulations to protect the privacy of
regulations to protect the privacy of the user, and misbehavior or the user, and misbehavior or negligence of the Location Server can be
negligence of the Location Server can be ruled out, there is still ruled out, there is still risk that personal data may become
risk that personal data may become available to unauthorized persons available to unauthorized persons through attacks from outsiders,
through attacks from outsiders, unauthorized access from insiders, unauthorized access from insiders, technical or human errors, or
technical or human errors, or legal processes. legal processes.
Cuellar, Morris, Mulligan, Peterson, Polk 23
Geopriv Requirements Oct 2003
In some occasions a Location Server has to know who is supplying the On some occasions, a Location Server has to know who is supplying the
Privacy Rules for a particular Target, but in other situations it Privacy Rules for a particular Target, while in other situations it
could be enough to know that the supplier of the Rules is authorized could be enough to know that the supplier of the Rules is authorized
to do so. to do so.
8.5. Unintended Target 8.5. Unintended Target
An Unintended Target is a person or object tracked by proximity to An Unintended Target is a person or object tracked by proximity to
the Target. This special case most frequently occurs if the Target the Target. This special case most frequently occurs if the Target
is not a person. For example, the Target may be a rental car 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 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 company may not care about the driver's location, but the driver's
privacy is implicitly affected. privacy is implicitly affected.
Geopriv may or may not protect or affect the privacy of Unintended Geopriv may or may not protect or affect the privacy of Unintended
Targets, but the impact on Unintended Targets should be Targets, but the impact on Unintended Targets should be acknowledged.
acknowledged.
9. Protocol and LO Issues for later Consideration 9. Protocol and LO Issues for later Consideration
This section briefly discusses issues relating to the Location This section briefly discusses issues relating to the Location Object
Object or the protocol that have emerged during the discussion of or the protocol that have emerged during the discussion of earlier
earlier versions of this document. versions of this document.
9.1. Multiple Locations in one LO 9.1. Multiple Locations in one LO
A location Field is intended to represent one point or one region in A location Field is intended to represent one point or one region in
space (either 1, 2, or 3 dimensionally). The possibility of space (either 1, 2, or 3 dimensionally). The possibility of
inclusion of multiple locations is discussed in another document. inclusion of multiple locations is discussed in another document.
The current rough consensus is the following: the LO definition MAY The current rough consensus is the following: the LO definition MAY
allow the Location Field to be optional, to appear exactly one time allow the Location Field to be optional, to appear exactly one time
or to occur several times. Each Location Field may contain one or or to occur several times. Each Location Field may contain one or
more "Location Representations", each of which is intended to more "Location Representations", each of which is intended to
represent a different measurement or a different formatting of the represent a different measurement or a different formatting of the
same position. But there are other possibilities for using multiple same position. But there are other possibilities for using multiple
Location Fields and multiple representations: maybe several Location Location Fields and multiple representations: maybe several Location
Fields would be used to report the same sighting in different Fields would be used to report the same sighting in different
formats, or multiple sightings at different times, or multiple formats, or multiple sightings at different times, or multiple sensor
sensor locations for the same device, or other purposes, which could locations for the same device, or other purposes, which could also
also depend on the using protocol. This all is for further depend on the using protocol. This is all for further discussion.
discussion.
9.2. Translation Fields 9.2. Translation Fields
It is possible to include fields to indicate that one of the 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 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 possible to have a field to identify the translator, as identity and
method. method.
Cuellar, Morris, Mulligan, Peterson, Polk 24
Geopriv Requirements Oct 2003
9.3. Truth Flag 9.3. Truth Flag
Geopriv MUST be silent on the truth or lack-of-truth of the location Geopriv MUST be silent on the truth or lack-of-truth of the location
information contained in the LO. Thus, the LO MUST NOT provide an information contained in the LO. Thus, the LO MUST NOT provide an
attribute in object saying "I am (or am not) telling you the whole attribute in object saying "I am (or am not) telling you the whole
truth." truth."
9.4. Timing Information Format 9.4. Timing Information Format
The format of timing information is out of the scope of this The format of timing information is out of the scope of this
document. document.
9.5. The Name Space of Identifiers 9.5. The Name Space of Identifiers
Who defines the Identities: may the using protocol define the Who defines the Identities: can the using protocol define the
Identifiers or must the using protocol use and authenticate Identifiers or must the using protocol use and authenticate
Pseudonyms proposed by the Rules, chosen independently of the using Pseudonyms proposed by the Rules, chosen independently of the using
protocol? Of course, if the using protocol has an appropriate protocol? Of course, if the using protocol has an appropriate
namespace, containing many unused names that may be used as namespace, containing many unused names that may be used as
pseudonyms and may be replaced by new ones regularly, then the pseudonyms and may be replaced by new ones regularly, then the
Location Object may be able to use the name space. For this purpose, Location Object may be able to use the name space. For this purpose,
the user would probably have to write his Rules using this name the user would probably have to write his Rules using this name
space. Note that it is necessary to change the used pseudonyms space. Note that it is necessary to change the used pseudonyms
regularly, because identifying the user behind an unlinked pseudonym regularly, because identifying the user behind an unlinked pseudonym
can be very simple. can be very simple.
There are several advantages of letting the using protocol to define There are several advantages in letting the using protocol define the
the name space: name space:
o the embedded authentication would be easier, as the using protocol o the embedded authentication would be easier, as the using protocol
has often already the credentials for the authentication identity often already has the credentials for the authentication identity
in place and the "embedded" authentication would be independent on in place and the "embedded" authentication would be independent on
the form of Identifiers, the form of Identifiers,
o the size of the names would be fixed. o the size of the names would be fixed.
On the other hand, the benefits of the Rule choosing the identifiers On the other hand, the benefits of the Rule choosing the identifiers
are: are:
o the user has a control of his anonymity, and o the user has a control of his anonymity, and
o the interworking of multiple systems with Location object across o the interworking of multiple systems with Location object across
protocol boundaries is facilitated. protocol boundaries is facilitated.
10. Acknowledgements 10. 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. Aaron Burstein, Mehmet Ersue, Allison comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison
Mankin, Randall Gellens, and the participants of the Geopriv Mankin, Randall Gellens, and the participants of the Geopriv meetings
meetings in San Diego and Yokohama provided detailed comments or in San Diego and Yokohama provided detailed comments or text.
text.
11. References 11. References
Cuellar, Morris, Mulligan, Peterson, Polk 25 11.1. Normative Reference
Geopriv Requirements Oct 2003
[Bra00] Stefan A.: Rethinking Public Key Infrastructures and Digital [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Certificates : Building in Privacy, MIT Press; ISBN: Requirement Levels", BCP 14, RFC 2119, March 1997.
0262024918; 1st edition, August, 2000
11.2. Informative 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 [Cha85] Chaum, David: Security without Identification, Card
Computers to make Big Brother Obsolete. Original Version Computers to make Big Brother Obsolete. Original Version
appeared in: Communications of the ACM, vol. 28 no. 10, appeared in: Communications of the ACM, vol. 28 no. 10,
October 1985 pp. 1030-1044. Revised version available at October 1985 pp. 1030-1044. Revised version available at
http://www.chaum.com/articles/ http://www.chaum.com/articles/
[ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/. [ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/.
[OECD] OECD Guidelines on the Protection of Privacy and Transborder [OECD] OECD Guidelines on the Protection of Privacy and
Flows of Personal Data, http://www.oecd.org. Transborder Flows of Personal Data, http://www.oecd.org.
[Pfi01] Pfitzmann, Andreas; Khntopp, Marit: Anonymity, [Pfi01] Pfitzmann, Andreas; Koehntopp, Marit: Anonymity,
Unobservability, and Pseudonymity - A Proposal for Unobservability, and Pseudonymity - A Proposal for
Terminology; in: H Federrath (Ed.): Designing Privacy Terminology; in: H Federrath (Ed.): Designing Privacy
Enhancing Technologies; Proc. Workshop on Design Issues in Enhancing Technologies; Proc. Workshop on Design Issues in
Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer
versions available at http://www.koehntopp.de/marit/pub/anon 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.
12. Author's Addresses 12. Authors' 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, Germany
Germany
EMail: Jorge.Cuellar@siemens.com
John B. Morris, Jr. John B. Morris, Jr.
Director, Internet Standards, Technology & Privacy Project Director, Internet Standards, Technology & Privacy Project
Center for Democracy and Technology Center for Democracy & Technology
1634 I Street NW, Suite 1100 1634 I Street NW, Suite 1100
Washington, DC 20006 Email: jmorris@cdt.org Washington, D.C. 20006 USA
USA http://www.cdt.org
EMail: jmorris@cdt.org
URI: http://www.cdt.org
Deirdre K. Mulligan Deirdre K. Mulligan
Samuelson Law, Technology and Public Privacy Clinic Samuelson Law, Technology & 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 USA
USA
EMail: dmulligan@law.berkeley.edu
URI: http://www.law.berkeley.edu/cenpro/samuelson/
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St 1800 Sutter St
Suite 5707 Email: jon.peterson@neustar.biz Suite 5707
Concord, CA 94520 USA
Cuellar, Morris, Mulligan, Peterson, Polk 26
Geopriv Requirements Oct 2003
Concord, CA 94520 http://www.neustar.biz/ EMail: jon.peterson@neustar.biz
USA URI: http://www.neustar.biz/
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, Texas 75082 USA7 Email: jmpolk@cisco.com Richardson, Texas 75082 USA
EMail: jmpolk@cisco.com
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
or assist in its implementation may be prepared, copied, published REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
and distributed, in whole or in part, without restriction of any INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
kind, provided that the above copyright notice and this paragraph IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
are included on all such copies and derivative works. However, this THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 Intellectual Property
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an The IETF takes no position regarding the validity or scope of any
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Intellectual Property Rights or other rights that might be claimed
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING to pertain to the implementation or use of the technology
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION described in this document or the extent to which any license
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF under such rights might or might not be available; nor does it
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Cuellar, Morris, Mulligan, Peterson, Polk 27 Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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