Internet Draft                                                J.                                             Jorge Cuellar
Document: draft-ietf-geopriv-reqs-02.txt draft-ietf-geopriv-reqs-03.txt                      Siemens AG

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


                                                        Deirdre Mulligan
                    Samuelson Law, Technology, and Public Policy Privacy Clinic

                                                            Jon Peterson

                                                              James Polk

Expires in six months                                           Jan                                           Mar 2003

                          Geopriv requirements

Status of this Memo

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

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

   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
   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.


   Location-based services, navigation applications, emergency
   services, management of equipment in the field, and other location-
   dependent services need geographic location information about a

   Cuellar, Morris, Mulligan, Peterson, Polk                         1
                         Geopriv Requirements                 Mar 2003

   Target (such as a user, resource or other entity).  There is a need
   to securely gather and transfer location information for location
   services, while at the same time protecting the privacy of the
   individuals involved.

   Cuellar, Morris, Mulligan                                        1
                         Geopriv Requirements                 Jan 2003

   This document focuses on the authorization, integrity security and privacy
   requirements for such location-dependent services.  Specifically, it
   describes the requirements for the geopriv Geopriv Location Object (used to
   securely transfer location data and other privacy-enabling
   information) (LO) and
   for the protocols that use this Location Object.  This LO is
   envisioned to be the main object defined by the Geopriv WG, used in
   all Geopriv exchanges and in particular used to securely transfer
   location data.

Table of Contents

    1. Overview........................................................3 Overview.......................................................3
    2. Conventions used in this document...............................4 document..............................4
    3. Terminology.....................................................4
      3.1. Foundational Definitions...................................4
         3.1.1. Glossary.......................................................4
    4. Primary Geopriv Entities.......................................6
    5. Further Geopriv Terminology....................................7
       5.1. Location Information (LI) and Sighting................4
         3.1.2. Sighting.........................7
       5.2. The Location Object...................................6
         3.1.3. Location Object vs. and Using Protocol....................6
         3.1.4. Protocol....................8
       5.3. Trusted vs. Non-trusted Data Flows....................6
      3.2. Geopriv Entities and Functions.............................7
         3.2.1. Primary Geopriv Entities..............................7
         3.2.2. Secondary Geopriv Entities............................8
         3.2.3. Flows........................9
       5.4. Further Geopriv Data Storage Functions........................9
      3.3. Principals...............................10
       5.5. Privacy Policies and Rules.................................9
      3.4. Rules............................................12
       5.6. Identifiers, Authentication and Authorization.............10
   4. Authorization............12
    6. Scenarios and Explanatory Discussion...........................11
      4.1. Scenarios of Data Flow....................................11
   5. Requirements...................................................14
      5.1. Discussion..........................13
    7. Requirements..................................................17
       7.1. Location Object...........................................15
      5.2. Object..........................................17
       7.2. The Using Protocol........................................16
      5.3. Policy Protocol.......................................19
       7.3. Rule based Location Data Transfer.......................17
      5.4. Transfer........................20
       7.4. Location Object Privacy and Security......................18
      5.5. Security.....................21
          7.4.1. Identity Protection.......................................18
      5.6. Protection.................................21
          7.4.2. Authentication Requirements...............................18
      5.7. Requirements.........................21
          7.4.3. Actions to be secured.....................................18
      5.8. Non-Requirements..........................................19
   6. secured...............................21
       7.5. Non-Requirements.........................................22
    8. Security Considerations........................................19
      6.1. Considerations.......................................22
       8.1. Traffic Analysis..........................................19
      6.2. Analysis.........................................22
       8.2. Securing the Privacy Policies.............................19
      6.3. Rules...............................22
       8.3. Emergency Case............................................20
      6.4. Case...........................................23
       8.4. Identities and Anonymity..................................20
      6.5. Anonymity.................................23
       8.5. Unintended Target.........................................21
   7. Acknowledgements...............................................21
   8. References.....................................................21 Target........................................24
    9. Protocol and LO Issues for later Consideration.................22 Consideration................24
       9.1. Multiple Locations in one LO..............................22 LO.............................24
       9.2. Translation Fields........................................22 Fields.......................................24
       9.3. Specifying Desired Accuracy in a Request..................22
      9.4. Truth Flag................................................22 Flag...............................................25
       9.4. Timing Information Format................................25

   Cuellar, Morris, Mulligan Mulligan, Peterson, Polk                         2
                         Geopriv Requirements                 Jan                 Mar 2003

       9.5. Timing Information Format.................................22
      9.6. The Name Space of Identifiers.............................22 Identifiers............................25
    10. Author's Addresses............................................23 Acknowledgements.............................................25
    11. References...................................................25
    12. Author's Addresses...........................................26
    13. Full Copyright Statement......................................23 Statement.....................................27

1. Overview

   Location-based services (applications that require geographic
   location information as input) are becoming increasingly common.
   The collection and transfer of location information about a
   particular Device and/or Target can have important privacy implications.  A key
   goal of the protocols protocol described in this document is to facilitate the
   protection of privacy pursuant to
   privacy policies Privacy Rules set by the "user"
   "user/owner of the Target" (or, more precisely in the terminology of
   this document defined given in Section 3 and 5.4 below, the "Rule Maker").

   The ability to derive or compute gather and generate a Device's Target's location, and access
   to the derived or computed location, are key elements of the location-
   location-based services privacy equation.  Central to a Target's
   privacy are (a) the identity of entities that have access to raw
   location data, derive or compute location, and/or have access to
   derived or computed location information, and (b) whether those
   entities can be trusted to know and follow the privacy policy Privacy Rules of the

   The main principles guiding the requirements described in this
   document are:

   1) Security of the transmission of Location Object is essential to
      guarantee the integrity and confidentiality of the location
      information.  This includes authenticating the sender and
      receiver of the Location Object, and securing the Location Object

   2) A critical role is played by user-controlled policies, Privacy Rules, which
      describe the restrictions imposed or permissions given by the
      "user" (or, as defined below, the "Rule Maker").  The policies Privacy
      Rules specify the necessary conditions that allow a Location
      Server to forward Location Information to a Location Recipient,
      and the conditions under which and purposes for which the
      Location Information 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
                         Geopriv Requirements                 Mar 2003

   4) The Location Object should be able to carry a limited but core
      set of privacy policies. Privacy Rules. The exact form or expressiveness of
      policies those
      Rules in the core set or in the full set is not further discussed
      in this paper, document, but is will be discussed more extensively in a
      separate document.

      future documents produced by this working group.

   5) Whenever appropriate, the location information should not be
      linked to the real identity of the user or a static identifier
      easily linked back to the real identity of the user (e.g., the (i.e.,
      Personally Identifiable Information such as a name, mailing
      address, phone number). number, social security number, or email address
      or username).  Rather, the user should be able to specify which

   Cuellar, Morris, Mulligan                                        3
                         Geopriv Requirements                 Jan 2003
      local identifier, unlinked pseudonym, or private identifier is to
      be bound to the location information.


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

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

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in [RFC2119].

   Note that the requirements discussed here are requirements on the
   generic Location Object and on the using protocols for location
   services.  Thus  Thus, for the most part, the requirements discussed in
   this document mostly refer to the capabilities that are mandatory-to-implement.
   For example, requiring that implementations support integrity is not
   the same thing as requiring that all protocol traffic be
   authenticated. In other cases, the contrast, an example of a mandatory-to-use (not
   just mandatory-to-implement) requirement may might be one that states
   that the user always obtains receives a notice when his location data was
   not authenticated. This practice is mandatory-to-use, not just to

3. Glossary

   For easy reference and readability, below are basic terms that will
   be defined more formally and fully later in this document.

      Location Generator (LG): The entity that initially determines or
         gathers the location of the Target and creates Location
         Objects describing the location of the Target.

   Cuellar, Morris, Mulligan, Peterson, Polk                         4
                         Geopriv Requirements                 Mar 2003

      Location Object (LO): An object conveying location information
         (and possibly privacy rules) to which Geopriv security
         mechanisms and privacy rules are to be applied.

      Location Recipient (LR): The entity that receives location
         information. It may have asked for this location explicitly
         (by sending a query to a location server), or it may receive
         this location asynchronously.

      Location Server (LS): The entity to which a LG publishes location
         objects, the recipient of queries from location receivers, and
         the entity that applies rules designed by the rule maker.

      Precision: The number of significant digits to which a value has
         been reliably measured.

      Principal: The holder/subject of the credentials, e.g. a
         workstation user or a network server.

      Resolution: The fineness of detail that can be distinguished in
         measured area. Applied to Geopriv this means the fineness of
         area within provided, and closed, borders (ex. Latitude and
         Longitude boundaries).

      Rule Holder: The entity that provides the rules associated with a
         particular target for the distribution of location
         information. It may either ępushĘ rules to a location server,
         or a location server may ępullĘ rules from the Rule Holder.

      Rule Maker: The authority that creates rules governing access to
         location information for a target (typically, this it the
         target themselves).

      Rule, or Privacy Rule: A directive that regulates an entity's
         activities with respect to location information, including the
         collection, use, disclosure, and retention of location

      Target: A person or other entity whose location is communicated
         by a Geopriv Location Object.

      Using Protocol: A protocol that carries a Location Object.

      Viewer: A Principal that consumes location information that is
         communicated by a Geopriv Location Object, but does not pass
         this information further.

   Resolution and Precision are very close terms.  Either quality can
   be 'reduced' to coarsen location information: 'resolution' by
   defining a off-center perimeter around a user's location or

   Cuellar, Morris, Mulligan, Peterson, Polk                         5
                         Geopriv Requirements                 Mar 2003

   otherwise enlarging the area in consideration (from state to
   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

   The following picture shows the primary Geopriv entities in a simple
   and basic architecture, without claim of completeness nor any
   suggestion that the entities identified must in all cases be
   physically separate entities.

                                |  Rule    |
                                | Holder   |
                                |          |
     +----------+               +----------+               +----------+
     |Location  |  publication  | Location |  notification |Location  |
     |Generator +-------------->| Server   +-------------->|Recipient |
     |          |  interface    |          |  interface    |          |
     +----------+               +----------+               +----------+

   The four primary Entities are described as follows:

      Location Generator (LG):  The entity that initially determines or
         gathers the location of the Target and creates Location
         Objects describing that location.  LGs publish Location
         Objects to Location Servers.  The manner in which the Location
         Generator learns of Location Information is outside the scope
         of the Geopriv Protocol..

      Location Server (LS): The LS is an element that receives
         publications of Location Objects from Location Generators and
         may receive subscriptions from Location Recipients. The LS
         applies the rules (which it learns from the Rule Holder) to
         LOs it receives from LGs, and then notifies LRs of resulting
         LOs as necessary.

      Location Recipient (LR): The LR is an element that receives
         notifications of Location Objects from Location Servers. The
         LR may render these LOs to a user or automaton in some

   Cuellar, Morris, Mulligan, Peterson, Polk                         6
                         Geopriv Requirements                 Mar 2003

      Rule Holder (RH): The RH is an element that houses Privacy Rules
         for receiving, filtering and distributing Location Objects for
         specific Targets. A LS may query an RH for a set of rules, or
         rules may be pushed from the RH to an LS. The rules in the
         Rule Holder are populated by the Rule Maker.

   Thus Location Generation is the process of gathering Location
   Information, perhaps from multiple sources, at an IP-based Geopriv
   Entity, the LG, which communicates with other Geopriv Entities.

   Rules MUST be authenticated and protected. How this is done and in
   particular how to distribute the keys to the RM and other
   authorities is outside of the scope of this document. See also
   Section 8.2 "Securing the Privacy Rules".

   The interfaces between the Geopriv entities are not necessarily
   protocol interfaces; they could be internal interfaces within a
   single composed device. In some architectures, the Location
   Generator, Rule Holder, and Location Server might all be implemented
   in the same device. There may be several Rule Holders that enforce
   the Privacy Rules at a particular Location Server.

5. Further Geopriv Terminology

   The terminology and definitions detailed below include both (1) terms
   that, besides the primary Geopriv entities, (1) are used in the
   requirements section of this document, and (2)
   terms that provide additional
   detail about the usage model envisioned for the geopriv Geopriv Location
   Object.  These latter terms will be utilized in a separate scenarios document.

3.1. Foundational Definitions

   document and elsewhere.

5.1. Location Information (LI) and Sighting

   The focus of the geopriv Geopriv working group is on information about a
   Target's location that is NOT based on generally or publicly
   available sources, but instead on private information provided or
   created by a Target, a Target's Device, or a Target's network or
   service provider: provider.   Notwithstanding this focus on private location
   information, the Geopriv Location Information (LI): Object could certainly be used to
   convey location information from publicly available sources.

      Location Information: A relatively specific way of describing
         where a Device is
         located and that is located.

   This Location Information may have determined in many different
   ways, including:
   (a) derived or computed from information generally not available to
   the general public (such as

   Cuellar, Morris, Mulligan                                        4
                         Geopriv Requirements                 Jan 2003 information mainly available to a
   network or service provider), (b) determined by a Device that may be
   not generally publicly addressable or accessible, or (c) input or
   otherwise provided by a Target.

   Cuellar, Morris, Mulligan, Peterson, Polk                         7
                         Geopriv Requirements                 Mar 2003

   As examples, LI the Location Information could include (a) information
   calculated by triangulating on a wireless signal with respect to
   cell phone towers, (b) longitude and latitude information determined
   by a Device with GPS (global positioning satellite) capabilities, or
   (c) information manually entered into a cell phone or laptop by a
   Target in response to a query. query, or (d) automatically delivered by
   some other IP protocol, such as at device configuration via DHCP.

   Excluded from this definition is the determination of location
   information wholly without the knowledge or consent of the Target
   (or the Target's network or access service provider), based on
   generally available information such as an IP or e-mail address.  In
   some cases information like IP address can enable someone to
   estimate (at least roughly) a location.  Commercial services exist
   that offer to provide rough location information based on IP
   address.  Currently, this type of location information is typically
   less accurate and has a coarser granularity precise than the type of location information addressed in this
   document.  Although this type of location computation still raises
   significant potential privacy and public policy privacy concerns, such
   scenarios are generally outside the scope of this document.

   Within any given location-based transaction, the INITIAL
   determination of location (and thus the initial creation of Location
   Information) is termed a Sighting:

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

   Some variant of the sighting information is included in the Location
   Object.  Abstractly, it consists of two separate data fields:

              (Identifier, Location)

   where Identifier is the identifier assigned to a Target being
   sighted, and Location is the current position of that Target being
   sighted.  Not all entities may have access to exactly the same piece
   of sighting information.  A sighting may be transformed to a new
   sighting pair:

              (Identifier-1, Location-1)

   before it is provided by a Location Sighter Generator or Location Server to
   another Location Recipient (for instance, another
   Location Server).

   Cuellar, Morris, Mulligan                                        5
                         Geopriv Requirements                 Jan 2003 Recipient.  In this case, Identifier-1 may be Pseudonym,
   and Location-1 may have less accuracy precision or granularity resolution than the
   original value.


5.2. The Location Object and Using Protocol

   Cuellar, Morris, Mulligan, Peterson, Polk                         8
                         Geopriv Requirements                 Mar 2003

   A main goal of the geopriv Geopriv working group is to define a Location
   Object (LO), to be used to convey both Location Information and
   basic privacy-protecting instructions:

      Location Object (LO): This data contains the Location Information
         of the Target, and other fields including an identity or
         pseudonym of the Target, time information, core privacy
         policies, Privacy Rules,
         authenticators, etc.  Most of the fields are optional,
         including the Location Information itself.

   Nothing is said about the semantics of a missing field.  For
   instance, a partially filled object MAY be understood implicitly as
   the request to complete it.  Or, if no time information is included,
   this MAY implicitly mean "at the current time" or "at a very recent
   time", but it could be interpreted in a different way, depending on
   the context.

3.1.3. Location Object vs. Using Protocol

   The "using protocol" is the protocol that uses (creates, reads (reads or modifies)
   the Location Object.  A protocol that just transports the LO as a
   string of bits, without looking at them (like an IP storage protocol
   could do), is not a using protocol, but only a transport protocol.
   Nevertheless, the entity or protocol that caused the transport
   protocol to move the LO is responsible of for the correct appropriate
   distribution, protection, usage, retention, and storage of the LO
   based on the rules that apply to that LO.

   The security and privacy enhancing mechanisms used to protect the LO
   are of two types:  First, the Location Object definition MUST
   include (optional) the fields or mechanisms used to secure the LO as such.  The
   LO MAY be secured, for example, using cryptographic checksums or
   encryption as part of the LO itself.  Second, the using protocol may
   also provide security mechanisms to securely transport the Location


   When defining the LO, the design should observe that the security
   mechanisms of the Location Object itself are to be preferred.

3.1.4.   Thus
   the definition of the LO MUST include some minimal crypto
   functionality (Req. 14 and 15).  Moreover, if the RM specifies the
   use of a particular LO security mechanism, it MUST be used (Req. 4).

5.3. Trusted vs. Non-trusted Data Flows

   Location information can be used in very different environments.  In
   some cases the participants will have longstanding relationships,
   while in others the participants may have discrete interactions with
   no prior contractual or other contact.

   The different relationships raise different concerns for the
   implementation of privacy rules, including the need to communicate

   Cuellar, Morris, Mulligan                                        6
                         Geopriv Requirements                 Jan 2003

   privacy policies.
   Privacy Rules.  A public Rule Repository, Holder, for example, may be
   unnecessary in a trusted environment where more efficient methods of

   Cuellar, Morris, Mulligan, Peterson, Polk                         9
                         Geopriv Requirements                 Mar 2003

   addressing privacy issues exist.  The following terms distinguish
   between the two basic types of data flows:

      Trusted Data Flow:
         A data flow that is governed by a pre-existing contractual
         relationship that addresses location privacy.

      Non-trusted Data Flow:
         The data flow is not governed by a pre-existing contractual
         relationship that addresses location privacy.

3.2. Geopriv Entities and Functions

   The entities of a geopriv application or transaction may be given
   explicit roles:

3.2.1. Primary

5.4. Further Geopriv Entities

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

         The entity whose location is desired by the Location Seeker.
         Recipient.  In many cases the Target will be the human "user"
         of a Device or an object such as a vehicle or shipping
         container to which the Device is attached.  In some instances
         the Target will be the Device itself.

         The technical device the location of which is tracked as a
         proxy for the location of a Target.

   A Device might, for example, be a cell phone, a Global Positioning
   Satellite (GPS) receiver, a laptop equipped with a wireless access
   Device, or a transmitter that emits a signal that can be tracked or
   located.  In some situations, such as when a Target manually inputs
   location information (perhaps with a web browser), the Target is
   effectively performing the function of a Device.

      Rule Maker: Maker (RM):
         The individual or entity that has the authorization to set the
         applicable privacy policies and rules. Privacy Rules for a potential Geopriv Target.  In
         many cases this will be the owner of the Device, and in other
         cases this may be the user who is in possession of the Device.
         For example, parents may control what happens to the location
         information derived from a child's cell phone. A company, in
         contrast, may own and provide a cell phone to an employee but
         permit the employee to set the privacy rules.

         There are four scenarios in which some form of constraint or
         override might be placed on the Privacy Rules of the Rule

         1. In the case of emergency services (such as E911 within the
         United States), local or national laws may require that
         accurate location information be transmitted in certain
         defined emergency call situations.  The Geopriv Working Group
         MUST facilitate this situation.

   Cuellar, Morris, Mulligan                                        7 Mulligan, Peterson, Polk                        10
                         Geopriv Requirements                 Jan 2003

      Location Seeker (LSeek):
         An individual or entity who seeks to receive location data
         about a Target.

   A Location Seeker Requirements                 Mar 2003

         2. In the case of legal interception, the RM may act in one or more not be aware
         of an override directive imposed by a legal authority.  It is
         not the following more
   specialized roles: as expectation of the Location Sighter, a Location Server, or as Working Group that particular
         accommodation will be made to facilitate this situation.

         3. In the context of an Ultimate Location Recipient:

      Location Sighter (LoSi), employment relationship or Location Data-Source
         The original source of other
         contractual relationship, the sighting owner of a Target in particular location
         (such as a given

      Location Server (LServ), or Intermediate Location Recipient:
         A Device or entity that provides access to Location
         Information (possibly after processing or altering it) in
         accordance with corporate campus) may impose constraints on the privacy policies use
         of the Privacy Rules by a Rule Maker.  Some
         location tracking scenarios may involve  It is not the expectation
         of the Working Group that particular accommodation will be
         made to facilitate this situation.

         4. It is conceivable that a Target, Device, or
         Device user performing governmental authority may seek to
         impose constraints  on the function use of Privacy Rules by a Location Server.

      Ultimate Location Recipient (ULR): Rule
         Maker in non-emergency situations.  It is not the expectation
         of the Working Group that particular accommodation will be
         made to facilitate this situation.

         An individual or entity who receives location data about a
         Target and does not transmit the location information or
         information based on the Target's location (such as driving
         directions to or from the Target) to any party OTHER than the
         Target or the Rule Maker.

3.2.2. Secondary Geopriv Entities

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

      Data Transporter:
         An entity or network that receives and forwards data without
         processing or altering it.  A Data Transporter could
         theoretically be involved in almost any transmission between a
         Device and a Location Server, a Location Server and a second
         Location Server, or a Location Server and an Ultimate Location
         Recipient. Viewer.  Some
         location tracking scenarios may not involve a Data


      Access Provider (IAP): (AP):
         The entity domain that provides the initial network access or other
         data communications services essential for the operation of
         communications functions of the Device or computer equipment
         in which the Device operates.  Often, the IAP AP -- which will be
         a wireless carrier, an Internet Service Provider, or an
         internal corporate network -- will be identical to contains the LoSi.
         In other cases LG.  Sometimes the IAP
         AP has a "dumb" LoSi, LG, one that transmits
         geopriv data Geopriv LOs but does
         not implement or use any part of the
         geopriv Location Object.  Other cases may involve no IAP at
         all or the IAP is only a Data Transporter.

   Cuellar, Morris, Mulligan                                        8
                         Geopriv Requirements                 Jan 2003

3.2.3. Geopriv Data Storage Functions

   Within the geopriv framework, certain data may be stored in various
   functional entities:

      Rule (or Policy) Storage
         A storage used to store privacy-protecting policies, and
         perhaps identifiers, credentials or keys.  A Private Rule
         Storage could be operated by a Device, a Location Server, or a
         third party service provider.

   How policies are authenticated and otherwise protected is outside part of the scope of this document, but see Geopriv Location Object.  Other cases
         may not involve any AP, or the remarks in Section 6
   (Privacy Considerations). AP may only act as a Data

      Location Storage:
         A Device or entity that stores raw or processed Location
         Information, such as a database, for any period of time longer
         than the duration necessary to complete an immediate
         transaction regarding the
         LI. Location Information.

   Cuellar, Morris, Mulligan, Peterson, Polk                        11
                         Geopriv Requirements                 Mar 2003

   The existence and data storage practices of Location Storage is
   crucial to privacy considerations, because this may influence what
   Location Information could eventually be revealed (through later
   distribution, technical breach, or legal processes).


5.5. Privacy Policies and Rules

   Privacy Policies Rules are rules that regulate an entity's activities with
   respect to location and other information, including, but not
   limited to, the collection, use, disclosure, and retention of
   location information.  Such rules are generally based on fair
   information practices, as detailed in (for example) the OECD
   Guidelines on the Protection of Privacy and Transporter Flows of
   Personal Data [OECD].

      Privacy Policy or Privacy Rule:
         A rule or set of rules that regulate an entity's activities
         with respect to location information, including the
         collection, use, disclosure, and retention of location
         information.  In particular, the policy Rule describes how location
         information may be used by an entity and which transformed
         location information may be released to which entities under
         which conditions.  Policies  Rules must be obeyed; they are not

   A full set of Privacy Rules will likely include both rules that have
   only one possible technical meaning, and rules that will be affected
   by a locality's prevailing laws and customs.  For example, a
   distribution rule of the form "my location can only be disclosed to
   the owner of such credentials and in such accuracy" precision or resolution"
   has clear-cut implications for the protocol that uses the LO. But
   other rules,

   Cuellar, Morris, Mulligan                                        9
                         Geopriv Requirements                 Jan 2003 like retention or usage policies, Rules, may have unclear
   technical consequences for the protocol or for the involved
   entities.  For example, the precise scope of a retention rule
   stating "you may not store my location for more than 2 days" may in
   part turn on local laws or customs.


5.6. Identifiers, Authentication and Authorization

   Anonymity is the property of being not identifiable (within a set of
   subjects).  Anonymity serves as the base case for privacy: without
   the ability to remain anonymous, individuals cannot may be unable to
   control their own privacy.  Unlinkability ensures that a user may
   make multiple uses of resources or services without others being
   able to link these uses together. to each other.  Unlinkability requires that
   entities are unable to determine whether the same user caused
   certain specific operations in the system. [ISO99]  A pseudonym is
   simply a bit string which is unique as ID and is suitable to be used
   for end-
   point end-point authentication.

   Cuellar, Morris, Mulligan, Peterson, Polk                        12
                         Geopriv Requirements                 Mar 2003

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

   The word authentication is used in different meanings.  Some require
   that authentication associates an entity with a more or less well-
   known identity.  This basically means that if A authenticates
   another entity B as being "id-B", then the label "id-B" is a well-
   known, or at least a linkable identity of the entity.  In this case,
   the label "id-B" is called a publicly known identifier, and the
   authentication is "explicit":

      Explicit Authentication:
         The act of verifying a claimed identity as the sole originator
         of a message (message authentication) or as the end-point of a
         channel (entity authentication). Moreover, this identity is
         easily linked back to the real identity of the entity in
         question, for instance being a pre-existing static label from
         a predefined name space (telephone number, name, etc.).


         The act of determining if a particular right, such as access
         to some resource, can be granted to the presenter of a
         particular credential.

   Depending on the type of credential, authorization may imply
   Explicit Authentication or not.

   Cuellar, Morris, Mulligan                                       10
                         Geopriv Requirements                 Jan 2003


6. Scenarios and Explanatory Discussion

4.1. Scenarios of Data Flow

   In this subsection we introduce short scenarios to illustrate how
   these terms and attributes describe location information
   transactions.  Additional illustrative scenarios are discussed in a
   separate Document.

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

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

   Cuellar, Morris, Mulligan, Peterson, Polk                        13
                         Geopriv Requirements                 Mar 2003

        GPS Satellite
                | Sighting (not a Geopriv Interface)
                V             GPS Device
        /                                                  \
        |  Data  Location     -----  Location  -----  Location   |
        |  Transporter  Generator            Server            Storage  |
        \                                           |      /
                                                    | Notification
                                                    | Interface
                                       /            V      \
                                      / Target    Location  \
                                      |           Seeker          Recipient   |
                                      |                      |
                                      \    Rule Maker       /
                                       \                   /

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

   SCENARIO 2:  Cell Phone Roaming

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

   Cuellar, Morris, Mulligan                                       11
                         Geopriv Requirements                 Jan 2003
   outsourced the accounting of cell phone usage. The cell phone is not
   GPS-enabled.  Location is derived by the cell phone network in which
   the Target and Device are roaming.  When the Target wishes to use
   the cell phone, cell phone Corp 1 (IAP) (AP) provides the roaming service
   for the Target, which sends the raw data about usage (e.g., duration
   of call, location ” roaming network, etc.) to cell phone Corp 2, the
   home service provider.  Cell phone Corp 2 submits the raw data to
   the accounting company, which processes the raw data for the
   accounting statements.  Finally, the raw data is sent to a data
   warehouse where the raw data is stored in a Location Server (e.g.,
   computer server).

   Cuellar, Morris, Mulligan, Peterson, Polk                        14
                         Geopriv Requirements                 Mar 2003

                   Cell Phone Corp 1                Cell Phone Corp 2
                   -----------------               -----------------
         Sighting /                 \  Sighting  Publish    /                 \
    Device ----- | Data Transporter | ---------  | Data Transporter |
    Target        \                 / Interface   \                 /
                   -----------------              / -----------------
                                                 /       |
                                                /  sighting|        | Notification
                                               /         | Interface
                                    -----------          |
                                   /                     V
                 ------------     /                  ----------
                /            \   /                  /          \
               /   Location   \ /                  |  Location  |
               |   Storage     |   Location Info   |  Storage   |
               |               |<----------------- |            |
               |   Location    |                   |  Location  |
               |   Seeker  Recipient    |                   |  Seeker Recipient  |
                \             /                     \          /
                 -------------                       ----------

   Here cell phone corp Corp 1 is the IAP AP and the LoSi. LG. In this scenario, Cell
   phone corp 1
   could Corp 2 is likely to be Non-trusted (the Rule Maker does not have a contract
   protecting location information with corp 1 and there is no
   contractual relationship with privacy provisions between corp 1 and
   corp 2) or  Trusted (contract with privacy protections between entity, but cell phone corp 2 and corp 1).  Cell phone corp 2 is Trusted. Corp
   1 may be Non-trusted.

   SCENARIO 3:  Mobile Communities and Location-Based Services

   The figure below shows a common scenario, where a user wants to find
   his friends or colleagues or wants to share his position with them
   or with a Location-Based Service Provider.  Some of the messages use
   a Location Object to carry carry, for instance: instance, identities or pseudonyms,
   credentials and proof-of-possession of them, Policies Rules and Location Data
   Information, including Data Types and Accuracy.  They are shown
   in the figure by normal arrows ("--->"). Other messages Precision or Resolution.
   Messages that do not use

   Cuellar, Morris, Mulligan                                       12
                         Geopriv Requirements                 Jan 2003 the Location Object and are outside of the
   scope of the geopriv Geopriv WG, but should be mentioned for understandability.  They
   understandability, are shown in the figure as starred arrows

   Cuellar, Morris, Mulligan, Peterson, Polk                        15
                         Geopriv Requirements                 Mar 2003

        +---------+                      +------------+
        | Location|                      | Public         |                      |  Data   |<**            | Policy
        | Location|<**                   | Source   Public   |
        |Generator|    *                 | Repository | Rule Holder|
        |  + IAP         |      *               +------------+               |            |
        +---------+\       *            *       *
            ^             +------------+
                      \       *5     3a*         *       *3     1a*        *
                        \       *    *          *
                          \       **            *
                           \    *  *            *3a
         5a *            *1a
                             \*      *          *
                            *               *  \       *        *
                          *             *      \       *      *
                        *          \4      *          \6    *
      +----------+    *              \       *  V
      | Target   |
                    *                  \->+-----------+
        +----------+           3           1          | Location  |
        |   Rule   |--------------------->| Server +  |
        |   Maker  |                      | Private   |
        +----------+<********************>| Repository|
             ^                  1
        +----------+                      |Rule Holder|
                                               ^  |
             |                                4|  |7
                                              3|  |5
                                               |  V
                                           |                             | Ultimate |
             +---------------------------->| Location |
                               2           | Recipient|

                   Figure 1: The Entities and Data Flows

      1: Registration:
                                           | Recipient|

   Assume that the Rule Maker registers himself and the Target are registered with the
   Location Server. This registration process is outside of the
         scope of our discussion, but probably the Rule Maker The RM has somehow proven to
         prove the LS that he indeed
   is the owner of the privacy rights of the Target (the Target is
   usually a Device owned by the Rule Maker).  The Rule Maker and the
   Location Server agree, as part
         of have agreed on the Registration Process, which set of keys or credentials and
         proof-of-possession of the corresponding secrets
   cryptographic material that they will use to authenticate each
   other, and in particular, to authenticate or sign the policies, or how they will agree on them or renew
         those keys or credentials.

   Cuellar, Morris, Mulligan                                       13
                         Geopriv Requirements                 Jan 2003

      2: End-to-End Negotiation:
         The Rule Maker and the Location Seeker exchange information
         about the service (if any) and negotiate it.  They also
         negotiate the pseudonyms that they will use later on and the
         credentials or keys that the Ultimate Location Recipient will
         use to prove his authorization to Rules.  How
   this has been done is outside of the Location Server.  This
         End-to-End Negotiation may contain several messages and may
         use or not scope of the Location Object.

      3: Policy document.

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

      3a:Signed Policy:

      1a:Signed Rule:
         As an alternative to the Policy Transfer, alternative, the Rule Maker may write a policy Rule and place
         it in the Open Repository. a Public Rule Holder.  The entities access the
         repository to read the signed policies.

      4: Rules.

      2: Location Information Request:
         The Location Seeker Recipient requests location information for a

   Cuellar, Morris, Mulligan, Peterson, Polk                        16
                         Geopriv Requirements                 Mar 2003

         Target.  In this request, the Location Seeker Recipient may select
         which location information data type it prefers.  One way of
         requesting Location Information MAY be sending a partially
         filled Location Object, including only the identities of the
         Target and Location Recipient and the desired Data Type and
         precision or resolution, and providing proof of possession of
         the required credentials.  But whether the using protocol
         understands this partially filled object as a request, this
         MAY depend on the using protocol or on the context.  The
         Location Seeker Recipient could also specify the need for periodic
         location information updates, but this is probably out of the
         scope of geopriv.

      5: Geopriv.

      3: Locate:
         When a Location Server receives an Location Information
         Request for a Target for which has no current location
         information, the server may send ask the Location Sighter Generator to
         locate the Target.


      4: Location Information:
         The Location Sighter Generator sends the "full" location information
         to the Location Server.  This Location Information may be
         embedded in a Location Object or not.


      5: Filtered Location Information:
         Then the Location Server sends Location Server sends the location information to the
         Location Recipient.  The information may be filtered in the
         sense that in general a less precise or a computed version of
         the information is being delivered.

7. Requirements

7.1. Location Object

   Recall that this document is primarily specifying requirements on
   how the definition of the LO.  Some Requirements read like this:
   "The LO definition MUST contain Field 'A' as an optional field."
   This requirement just states that

   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
     LO MAY contain the field 'A' or not).

   Some Requirements read like this: "The LO definition MUST contain
   Field 'A', which MAY be an optional field."  This requirement states

   o the document that defines the location information to LO MUST define the
         Location Recipient.  The information may be filtered in LO field 'A',
   o the
         sense that in general a less precise field 'A' MAY be defined as optional or a computed version not to use.  If it is
     defined as optional to use, any instance of a LO MAY contain the information
     field 'A' or not; if it is being delivered.

5. Requirements not optional, all instances of LOs MUST
     contain the field 'A'.

   Cuellar, Morris, Mulligan                                       14 Mulligan, Peterson, Polk                        17
                         Geopriv Requirements                 Jan                 Mar 2003

5.1. Location Object

   Req. 1.  (Location Object generalities)

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

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

      1.3) Some fields of the Location Object MAY be defined as
      "extensions".  This means that the syntax or semantics of these
      fields is not fully defined in the basic Location Object
      definition, but their use may be private to one or more using

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

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

      1.6) The object MUST permit (but not require) the policy Privacy Rules
      to be enforced by a third party.

      1.7) The object MUST be usable in a variety of protocols, such as
      HTTP and SIP, as well as local APIs.

      1.8) The object MUST be usable in a secure manner even by
      applications on constrained devices.

   Req. 2.  (Location Object fields) The Location Object definition
      MUST support contain the following Fields (but not all LOs must use all
      fields) Fields, which MAY be optional to use:

      2.1) Target Identifier

      2.2) Location Recipient Identity

      This identity may be a multicast or group identity, used to
      include the Location Object in multicast-based using protocols.

      2.3) Location Recipient Credential

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

      2.5) Location Field.

         2.5.1) Motion and direction vectors.  This field MUST be

   Cuellar, Morris, Mulligan                                       15 Mulligan, Peterson, Polk                        18
                         Geopriv Requirements                 Jan                 Mar 2003

      Each Location Field may contain one or more Location
      Representations, which can be also in different formats.

      2.6) Location Data Type

      When transmitting the Location Object, the sender and the
      receiver must agree on the data type of the location information.
      The using protocol may specify that the data type information is
      part of the Location Object or that sender and receiver have
      agreed on it before the actual data transfer.

      2.7) Motion and direction vectors

      2.8) Timing information:
      (a) When was the LI Location Information accurate? (sighting time)
      (b) Until when considered current? TTL (Time-to-live) (This is
      different than a privacy rule setting a limit on data retention)

      2.9) Policy

      2.8) Rule Field: this field MAY be a referral to an applicable
      Rule (for instance, an URI to a full policy), Rule), or it MAY contain a
      Limited Policy Rule (see Req. 9), 11), or both.


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

      2.11) 14 and 15).

      2.10) Version number

   Req. 3.  (Location Data Types)

      3.1) The Location Object MUST define at least one Location Data
      Type to be supported by all geopriv Geopriv receivers (entities that
      receive LOs).

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

      3.3) The latitude / longitude / altitude Data Type SHOULD also
      support a delta format in addition to an absolute one, used for
      the purpose of reducing the size of the packages or the security
      and confidentiality needs.

      3.4) The Location Object definition SHOULD agree on further
      Location Data Types supported by some geopriv Geopriv entities and
      defined by other organizations.


7.2. The Using Protocol

   Req. 4.  The using protocol has to obey the privacy and security
      instructions coded in the Location Object and in the

   Cuellar, Morris, Mulligan                                       16
                         Geopriv Requirements                 Jan 2003
      corresponding Policy Rules regarding the transmission and storage of the

   Req. 5.  The using protocol will typically facilitate that the keys
      associated with the credentials are transported to the respective

   Cuellar, Morris, Mulligan, Peterson, Polk                        19
                         Geopriv Requirements                 Mar 2003

      parties, that is, key agreement is responsibility of the using

   Req. 6.  (Single Message Transfer)  In particular for tracking of
      small target devices, the design should allow a single
      message/packet transmission of location as a complete

   Other requirements on the using protocol are out of the scope of
   this document. document, but might be the subject of future efforts from this
   working group.  See also Section 9 (Protocol and LO Issues for later

5.3. Policy

7.3. Rule based Location Data Transfer

   Req. 7.  (LServ Policies)  (LS Rules) The decision of a Location Server to provide a
      Location Seeker Recipient access to Location Information MUST be based
      on Rule Maker-defined Privacy Policies. Rules.

   It is outside of our scope how Privacy Policies Rules are managed, managed and how a
   Location Server has access to the Privacy Policies, and if he is or
   not aware of the full set of rules desired by the Rule-Maker. Rules.  Note that it might
   be that some rules contain private information not intended for
   untrusted parties.

   Req. 8.  (LoSi Policies)  (LG Rules) Even if a Location Sighter Generator is unaware of and
      lacks access to the full Privacy Policies Rules defined by the Rule Maker,
      the Location Sighter Generator MUST transmit Location Information in
      compliance with instructions set by the Rule Maker.  Such
      compliance MAY be accomplished by the Location Sighter Generator
      transmitting LI the LO only to a URI designated by the Rule Maker.

   Req. 9.  (ULR Policies)  (Viewer Rules) An Ultimate Location Recipient Viewer does not need to be aware of the
      full policies Rules defined by the Rule Maker (because an ULR Viewer SHOULD
      NOT retransmit Location Information), and thus an ULR Viewer SHOULD
      receive only the subset of Privacy Policies Rules necessary for the ULR Viewer
      to handle the LI LO in compliance with the full Privacy Policies Rules (such
      as, for example, an instruction on the time period for which then LI
      the LO can be retained).

   Req. 10.  (Full Policy Rule language) Geopriv MAY specify a policy Rule language
      capable of expressing a wide range of privacy rules concerning
      location information.  This policy Rule language MAY be an existing one,
      an adaptation of an existing one or a new policy Rule language, and it
      SHOULD be as simple as possible.

   Req. 11.  (Limited Policy Rule language) Geopriv MUST specify a limited
      Rule language capable of expressing a limited set of privacy

   Cuellar, Morris, Mulligan                                       17
                         Geopriv Requirements                 Jan 2003
      rules concerning location information.  This policy Rule language MAY be
      an existing one, an adaptation of an existing one or a new
      policy Rule
      language.  The Location Object MUST include sufficient fields and
      data to express the limited set of privacy rules.


   Cuellar, Morris, Mulligan, Peterson, Polk                        20
                         Geopriv Requirements                 Mar 2003

7.4. Location Object Privacy and Security


7.4.1. Identity Protection

   Req. 12.  (Identity Protection) The Location Object MUST support use
      of Unlinked Pseudonyms in the corresponding identification fields
      of Rule Maker, Target, Device, and Location Recipient.  Since
      Unlinked Pseudonyms are simply bit strings that are not linked
      initially to a well-known identity, this requirement boils down
      to saying that the name space for Identifiers used in the LO has
      to be large enough to contain many unused strings.


7.4.2. Authentication Requirements

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


7.4.3. Actions to be secured

   Req. 14.  (Security Features) The Location Object MUST support
      fields suitable for protecting the Object to provide the
      following security features:

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

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

      14.3)     Data object confidentiality: the LO is secured from
      eavesdropping (unauthorized reading) during transmission and
      during storage, and

      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
      perhaps during a small window of time that is configurable or
      accepted by the Rule Maker).

   Req. 15.  (Minimal Crypto)

      15.1)     Geopriv MUST specify a minimum mandatory to implement
      Location Object security including mandatory to implement crypto

   Cuellar, Morris, Mulligan                                       18
                         Geopriv Requirements                 Jan 2003
      algorithms, for digital signature algorithms and encryption

      15.2)     It MAY also define further mandatory to implement
      Location Object security mechanisms for message authentication
      codes (MACs) or other purposes.

   Cuellar, Morris, Mulligan, Peterson, Polk                        21
                         Geopriv Requirements                 Mar 2003

      15.3)     The protocol SHOULD allow a bypass if authentication
      fails in an emergency call.

   The issue addressed in the last point is that an emergency call in
   some very unfavorable situations my may not be completed if the minimal
   authentication fails.  This is probably not what the user would like
   to see. happen.  The user may prefer an unauthenticated call to an
   unauthenticated emergency server than over no call completion at all,
   even at the risk that he is talking to an attacker or that his
   information is not secured.


7.5. Non-Requirements

   Non-Req. 1. (Bridging to non-IP networks) The geopriv Geopriv specification
      SHOULD NOT specify the bridging to non-IP networks (PSTN, etc).


8. Security Considerations

   The purpose of the geopriv Geopriv Location Object and the requirements on
   the using protocol are to allow a policy-controlled Privacy Rule-controlled disclosure
   of location information for location services.


8.1. Traffic Analysis

   The information carried within the Location Object is secured in a
   way compliant with the privacy and security policies Rules of the Rule Maker,
   but other information, carried in other objects or headers are in
   general not secured in the same way.  This means that geopriv
   does Geopriv may
   not as a general matter secure the Target against general traffic
   analysis attacks or other forms of privacy violations.


8.2. Securing the Privacy Policies Rules

   The Privacy Policies Rules of the Rule Maker regarding the location of the
   Target may be accessible to a Location Server in a Private Storage public or in a Public Repository, non-
   public Rule Holder, or they may be carried by the Location Object,
   or they may be presented by the Location Seeker Recipient as capabilities
   or tokens. Each of this types of policy Rule has to be secured itĘs it's own
   particular way.

   The rules in a Private Storage non-public Rule Holder are typically authenticated
   using a MAC (Message Authentication Code) or a signature, depending
   on the type of keys used. The rules in a Public Repository public Rule Holder (one
   that in

   Cuellar, Morris, Mulligan                                       19
                         Geopriv Requirements                 Jan 2003 principle may be accessed directly by several entities, for
   instance several Location Servers) are typically digitally signed.  A Policy
   Rule Fields in a LO is are secured as part of the LO itself. A Geopriv
   Token (a token or ticket issued by the Rule Maker to a Location Seeker,
   Recipient, expressing the explicit consent of the Rule Maker to
   access his location information) is authenticated or signed.


   Cuellar, Morris, Mulligan, Peterson, Polk                        22
                         Geopriv Requirements                 Mar 2003

8.3. Emergency Case


   Let us consider the situation where the authentication fails in an
   emergency call because the authentication center fails to
   authenticate itself.  In this case, one way of implementing the
   authentication bypass for emergency calls, mentioned in Req 14.3) 15.3) is
   to let the user have the choice of writing a policy Rule that says:
   -  "If the emergency server does not authenticate itself,
      nevertheless send the location",
      location information anyway", or
   -  "If the emergency server does not authenticate itself, let the
   call fail".


   Second, in the case where the authentication of the emergency call
   fails because the user may not authenticate itself, the question
   arises: whose policy Rule to use? It is reasonable to use a default one:
   this location information can only be sent to an emergency center.


   The third situation, which should be studied in more detail detail, is:
   what to do if not only the user fails to authenticate itself, but
   also the emergency center is not authenticable? It is reasonable to
   send the Location Information anyway, but are there in this case any
   security threats that must be considered?


8.4. Identities and Anonymity

   The use of Unlinked Pseudonyms is necessary to obtain anonymity.

   The purpose of the use of Unlinked Pseudonyms is the following: the
   using protocol should be able to hide the real identity of the Rule
   Maker, the Target, and the Device, the and to Location Servers or Location Recipients.
   Recipients, if required by the RM.  Also, the using protocol SHOULD
   be able to hide the real identity of the Location Recipient to the
   Location Server.

   In this last case, the Target is not concerned about the Server
   identifying him and knowing his location, but identifying his
   business partners, and therefore his habits, etc.  Reasons for
   hiding the real identities of the Location Recipients include (a)
   that this knowledge may be used to infer the identity of the Target,
   (b) that knowledge of the identity of the Location Recipient may
   embarrass the Target or breach confidential information, and  (c)
   that the dossier telling who has obtained a Target's location
   information over a long period of time can give information on
   habits, movements, etc.  Even if the location service providers
   agree to respect the privacy of the user, are compelled by laws or
   regulations to protect the privacy of the user, and misbehavior or

   Cuellar, Morris, Mulligan                                       20
                         Geopriv Requirements                 Jan 2003
   negligence of the Location Server can be ruled out, there is still
   risk that personal data may become available to unauthorized persons
   through attacks from outsiders, unauthorized access from insiders,
   technical or human errors, or legal processes.

   Cuellar, Morris, Mulligan, Peterson, Polk                        23
                         Geopriv Requirements                 Mar 2003

   In some occasions a Location Server has to know who is supplying
   policies the
   Privacy Rules for a particular Target, but in other situations it
   could be enough to know that the supplier of the policies Rules is authorized
   to do so.  Those considerations are outside of our scope.


8.5. Unintended Target

   An Unintended Target is a person or object tracked by proximity to
   the Target. This special case most frequently occurs if the Target
   is not a person.  For example, the Target may be a rental car
   equipped with a GPS Device, used to track car inventory.  The rental
   company may not care about the driver's location, but the driver's
   privacy is implicitly affected.

   Geopriv may or may not protect or affect the privacy of Unintended
   Targets, but the impact on Unintended Targets should be

7. Acknowledgements

   We wish to thank the members of the IETF geopriv WG for their
   comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison
   Mankin, Randall Gellens, Jon Peterson, and the participants of the
   geopriv meetings in San Diego and Yokohama provided detailed
   comments or text.

8. References

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

   [Cha85] Chaum, David: Security without Identification, Card
           Computers to make Big Brother Obsolete. Original Verion
           appeared in: Communications of the ACM, vol. 28 no. 10,
           October 1985 pp. 1030-1044. Revised version available at

   [ISO99] ISO99: ISO IS 15408, 1999,

   [OECD] OECD Guidelines on rental
   company may not care about the Protection of Privacy and Transborder
           Flows of Personal Data,

   [Pfi01] Pfitzmann, Andreas; K÷hntopp, Marit: Anonymity,
           Unobservability, and Pseudonymity - A Proposal for
           Terminology; in: H Federrath (Ed.): Designing Privacy

   Cuellar, Morris, Mulligan                                       21 driver's location, but the driver's
   privacy is implicitly affected.

   Geopriv Requirements                 Jan 2003

           Enhancing Technologies; Proc. Workshop may or may not protect or affect the privacy of Unintended
   Targets, but the impact on Design Issues in
           Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer
           versions available at

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997. Unintended Targets should be

9. Protocol and LO Issues for later Consideration

   It seems important to mention some

   This section briefly discusses issues on relating to the Location
   Object or
   on the protocol, which protocol that have emerged during the discussion of
   earlier versions of this document.

9.1. Multiple Locations in one LO

   A location Field is intended to represent one point or one region in
   space (either 1, 2, or 3 dimensionally). The possibility of
   inclusion of multiple locations is discussed in another draft, draft-morris-geopriv-location-object-issues-00.txt.

   An instance of a document.
   The current rough consensus is the following: the LO definition MAY
   allow the Location Object could contain zero, one, Field to be optional, to appear exactly one time
   or to occur several times.  Each Location Fields, perhaps in Field may contain one or
   more "Location Representations", each of which is intended to
   represent a different formats.  Several measurement or a different formatting of the
   same position.  But there are other possibilities for using multiple
   Location Fields and multiple representations: maybe several Location
   Fields would be used to report the same sighting in different
   formats, or multiple sightings at different times, or multiple
   sensor locations for the same device, or other purposes. purposes, which could
   also depend on the using protocol.  This all is for further

9.2. Translation Fields

   It is possible to include fields to indicate that one of the
   locations is a translation of another.  If this is done, it is also
   possible to have a field to identify the translator, as identity and

9.3. Specifying Desired Accuracy in a Request

   If the LO is used to request location information (leaving some
   fields empty), it is not clear how to specify the requested
   accuracy.  Are the data types "country/state/city" and
   "country/state" different data types or the same data type with
   different "accuracy" or "granularity"?

9.4. and

   Cuellar, Morris, Mulligan, Peterson, Polk                        24
                         Geopriv Requirements                 Mar 2003

9.3. Truth Flag

   Geopriv should 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
   attribute in object saying "I'm not "I am (or am not) telling you the whole


9.4. Timing Information Format

   The format of timing information is out of the scope of this


9.5. The Name Space of Identifiers

   Cuellar, Morris, Mulligan                                       22
                         Geopriv Requirements                 Jan 2003

   Who defines the Identities: may the using protocol define the
   Identifiers or must the using protocol use and authenticate
   Pseudonyms proposed by the policies, Rules, chosen independently of the using
   protocol?  Of course, if the using protocol has an appropriate
   namespace, containing many unused names that may be used as
   pseudonyms and may be replaced by new ones regularly, then the
   Location Object may be able to use the name space. For this purpose,
   the user would probably have to write his policies Rules using this name
   space.  Note that it is necessary to change the used pseudonyms
   regularly, because identifying the user behind an unlinked pseudonym
   can be very simple.

   There are several advantages of letting the using protocol to define
   the name space:
   o the embedded authentication would be easier, as the using protocol
     has often already the credentials for the authentication identity
     in place and the "embedded" authentication would be independent on
     the form of Identifiers,
   o the size of the names would be fixed.

   On the other hand, the benefits of the policy Rule choosing the identifiers
   o the user has a control of his anonymity, and
   o the interworking of multiple systems with Location object across
     protocol boundaries is facilitated.

10. Acknowledgements

   We wish to thank the members of the IETF Geopriv WG for their
   comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison
   Mankin, Randall Gellens, and the participants of the Geopriv
   meetings in San Diego and Yokohama provided detailed comments or

11. References

   Cuellar, Morris, Mulligan, Peterson, Polk                        25
                         Geopriv Requirements                 Mar 2003

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

   [Cha85] Chaum, David: Security without Identification, Card
           Computers to make Big Brother Obsolete. Original Version
           appeared in: Communications of the ACM, vol. 28 no. 10,
           October 1985 pp. 1030-1044. Revised version available at

   [ISO99] ISO99: ISO IS 15408, 1999,

   [OECD] OECD Guidelines on the Protection of Privacy and Transborder
           Flows of Personal Data,

   [Pfi01] Pfitzmann, Andreas; K÷hntopp, Marit: Anonymity,
           Unobservability, and Pseudonymity - A Proposal for
           Terminology; in: H Federrath (Ed.): Designing Privacy
           Enhancing Technologies; Proc. Workshop on Design Issues in
           Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer
           versions available at

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

12. Author's Addresses

   Jorge R Cuellar
   Siemens AG
   Corporate Technology
   CT IC 3
   81730 Munich                   Email:

   John B. Morris, Jr.
   Director, Internet Standards, Technology & Policy Privacy Project
   Center for Democracy and Technology
   1634 I Street NW, Suite 1100
   Washington, DC 20006                         Email:

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


   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 5707                          Email:

   Cuellar, Morris, Mulligan, Peterson, Polk                        26
                         Geopriv Requirements                 Mar 2003

   Concord, CA  94520                 

   James M. Polk
   Cisco Systems
   2200 East President George Bush Turnpike
   Richardson, Texas 75082 USA7                Email:

13. Full Copyright Statement

   Copyright (C) The Internet Society (date).  All Rights Reserved.

   Cuellar, Morris, Mulligan                                       23
                         Geopriv Requirements                 Jan 2003

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

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

   This document and the information contained herein is provided on an

   Cuellar, Morris, Mulligan                                       24 Mulligan, Peterson, Polk                        27