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

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

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

Expires: Dec. 2002                                             June

Expires in six months                                      November 2002

                          Geopriv requirements

Status of this Memo

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

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

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

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

Copyright Notice

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

Abstract

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

   Cuellar, Morris, Mulligan                                        1
                         Geopriv Requirements                 Nov 2002

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

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

Table of Contents

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

   Cuellar, Morris, Mulligan                                        2
                         Geopriv Requirements                 Nov 2002

      9.5. Truth Flag................................................22
      9.6. Timing Information Format.................................22
      9.7. The Name Space of Identifiers.............................22
   10. Author's Addresses............................................23
   11. Full Copyright Statement......................................22 Statement......................................23

1. Overview

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

   The ability to derive or compute a device's Device's location, and access to
   the derived or computed location, are key elements of the location-
   based services privacy equation.  Central to a target's Target's privacy are
   (a) the identity of entities that have access to raw location data,

   Cuellar, Morris, Mulligan      Expires Dec 2002                  2
                         Geopriv Requirements                June 2002
   derive or compute location, and/or have access to derived or
   computed location information, and (b) whether those entities can be
   trusted to know and follow the target's (or better Rule Maker's) policy.

   In privacy policy of the user.

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

   1) Security of describing where a device the transmission of Location Object is located essential to
      guarantee the integrity and that confidentiality of the location information is either (a) derived or computed from
   information generally not available to
      information.  This includes authenticating the general public, or (b)
   determined by a device that is not generally publicly addressable or
   accessible.  For example, location information could include
   information calculated by triangulating on a wireless signal with
   respect to cell phone towers, or longitude sender and latitude information
   determined by a device with GPS (global positioning satellite)
   capabilities.

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

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

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

   For privacy policies, the purposes of this document, "policies" user or "privacy rules" are
   rules that regulate an entity's activities with respect to location
   information, including, but not limited to, the collection, use,
   disclosure, and retention of location information.  These rules must
   generally comply with fair information practices.  For instance, see
   the OECD Guidelines on the Protection of Privacy and Transporter
   Flows of Personal Data at http://www.oecd.org.

   The main principles guiding the requirements exposed in this paper
   are:

   1) Security of the protocol is of essential to guarantee the
      correctness (integrity) and the confidentiality of the location
      information.  This includes authenticating the main entities of
      the protocol and securing the exchanged messages.

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                  3
                         Geopriv Requirements                June 2002

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

   3)

   Cuellar, Morris, Mulligan                                        3
                         Geopriv Requirements                 Nov 2002

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

   4)

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

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

2. Conventions used in this document

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

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

3. Usage Model Terminology

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

3.1. Roles Foundational Definitions

3.1.1. Location Information (LI) and attributes Sighting

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

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                                        4
                         Geopriv Requirements                June                 Nov 2002

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

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

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

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

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

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

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

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

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

              (Identifier, Location)

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

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

              (Identifier-1, Location-1)

   Cuellar, Morris, Mulligan                                        5
                         Geopriv Requirements                 Nov 2002

   before it is provided by proximity a Location Sighter or Location Server to
   another Location Recipient (for instance, another Location Server).
   In this case, Identifier-1 may be Pseudonym, and Location-1 may have
   less accuracy or granularity than the Target. This
         special case most frequently occurs if original value.

3.1.2. The Location Object

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

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

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

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

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

   The "using protocol" is the protocol that uses (creates, reads or a
   modifies) the Location Processor and a
         Location Seeker.  Some location tracking scenarios may Object.  A protocol that just transports the
   LO as a string of bits, without looking at them (like an IP storage
   protocol could do), is not
         involve a Data Transporter.

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                  5
                         Geopriv Requirements                June 2002

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

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

   The different actors in a location
         information request create intertwined privacy concerns. If
         data about a requester is stored security and correlated with data
         about a Target, it may be possible privacy enhancing mechanisms used to infer more information
         from protect the aggregate than one or both entity's rules would
         allow. Unlinkable identifiers provide LO
   are of two types:  First, the ideal solution Location Object definition MUST
   include (optional) fields or mechanisms used to
         this problem, but may secure the LO as
   such.  The LO MAY be impossible in practice. Stored
         identifiers SHOULD use secured, for example, using cryptographic
   checksums or encryption as part of the closest possible approximation LO itself.  Second, the using
   protocol may also provide security mechanisms to
         unlinkable identifiers. LStor devices SHOULD follow securely transport
   the Rule
         Maker's policies regarding permissible duration of data
         storage, etc.
         <Although it is clear that aggregation in particular and data
         storage policies in general pose serious privacy questions, it
         is open how much of this concern falls within geopriv scope.>

      Rule Repository ("RR")
         A repository that contains private (authenticated, but not
         signed) or public (signed) policies, identifiers, and perhaps
         also stores requests.

   Roles of Location Information Requesters

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

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

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

      Location Sighter (LoSi), or Flows

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

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                                        6
                         Geopriv Requirements                June                 Nov 2002

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

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

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

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

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

3.2. Geopriv Entities and Functions

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

3.2.1. Primary Geopriv Entities

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

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

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

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

      Rule Maker:
         The individual or Public Rules Repositories:

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

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

   The following table shows the possible roles Device, and in other cases this may
         be the user who is in possession of the geopriv entities. Device.  For example,
         parents may control what happens to the location information
         derived from a child's cell phone. A company, in contrast, may
         own and provide a cell phone to an employee but permit the
         employee to set the privacy rules.

   Cuellar, Morris, Mulligan      Expires Dec 2002                                        7
                         Geopriv Requirements                June                 Nov 2002

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

      Location |
     |entity            |     |      |   RR   |   RR    |  Sighter |
     +------------------+-----+------+--------+---------+----------+
     |Target            |     |      |        |         |    x     |
     +------------------+-----+------+--------+---------+----------+
     |Device            |     |      |        |         |    x     |
     +------------------+-----+------+--------+---------+----------+
     |Rule Maker        |  x  |      |        |         |    x     |
     +------------------+-----+------+--------+---------+----------+
     |Unintended Target |     |      |        |         |          |
     +------------------+-----+------+--------+---------+----------+
     |Data Transporter  |  x  |      |        |         |    x     |
     +------------------+-----+------+--------+---------+----------+
     |Location Seeker   |  x  |  x   |        |         |          |
     +------------------+-----+------+--------+---------+----------+
     |Location Server   |  x  |      |        |         |    x     |
     +------------------+-----+------+--------+---------+----------+
     |Rule Repository   |     |      |    x   |    x    |          |
     +------------------+-----+------+--------+---------+----------+

3.2. Data

   The main (LSeek):
         An individual or entity who seeks to receive location data used by
         about a Target.

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

      Location Sighter (LoSi), or Location Data-Source
         The original source of the sighting information (the identity/location pair) and
   some other information to be determined, e.g., time information, some
   types of policies, authenticators, etc.  If no time information is
   included, this implicitly means "at the current time" or "at a very
   recent time".

      Sighting: the location information for a target.  This is the
         main private data accessed by Location Servers and/or Ultimate
         Location Recipients.  Some variant of the sighting information
         is included Target in the Location Object.  Abstractly, it consists
         of two separate data fields:

              (Sighting-Identifier, Location)

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

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

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

              (Sighting-Identifier-1, Location-1)

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

      Ultimate Location Recipient.

   Cuellar, Morris, Mulligan      Expires Dec 2002                  8
                         Geopriv Requirements                June 2002

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

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

3.3. Identification, Authentication, and Authorization

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

3.3.1. Identifiers

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

3.2.2. Secondary Geopriv Entities

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

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

      <Need to define pseudonym here.>

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

      Entity-Identifier:
         Data Transporter.

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

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

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

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

   Cuellar, Morris, Mulligan                                        8
                         Geopriv Requirements                June                 Nov 2002

3.3.2. Authentication

   People use

3.2.3. Geopriv Data Storage Functions

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

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

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

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

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

3.3.3. Authorization

      Authorization
         LI.

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

3.3. Privacy Policies and Rules

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

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

3.4. Data Flows

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

      Privacy Policy or multi-step sub-
   protocols and the actual transport Privacy Rule:
         A rule or set of the Location Object may be done
   via some other transport entities not included in the diagram.  The
   data flows to be considered by the geopriv WG, in the sense rules that WG
   will assess their authentication, authorization and privacy
   requirements, are the following.  They are shown in Figure 1 by
   normal arrows ("--->")

      LI (Location Information):
         the location data source sends the "full" location information regulate an entity's activities
         with respect to the location server. Then information, including the
         collection, use, disclosure, and retention of location server sends
         information.  In particular, the
         full or filtered policy describes how location
         information to the Location
         Recipient.  The may be used by an entity and which transformed
         location information may be filtered in the sense released to which entities under
         which conditions.  Policies must be obeyed; they are not
         advisory.

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

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 10                                        9
                         Geopriv Requirements                June                 Nov 2002

      PolInfo (Policy Information):

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

3.4. Identifiers, Authentication and Authorization

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

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

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

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

  +---------+   Locate    +-----------+
  | Location|<************| Location  |         SPol +------------+
  |  Data   |     LI      | Server +  |<*************| Public     |
  | Source  |------------>| Private   |         *    | Policy     |
  |  + IAP  |             | Repository|<---\    *    | Repository |
  +---------+             +-----------+    |    *    +------------+
                           ^ |    |        |    *            ^
                   LRequest| |LI  |PolInfo |    *            * SPol
                           | V    V        |    *            *
  +----------+             +-----------+   |    *            *
  | Target   |             | Location  |<**+****/        +----------+
  |   or     |<***********>| Server +  |   |             |          |
  |Rule Maker|   Service   | Private   |   | <-----------|Rule Maker|
  +----------+             | Repository|<--/     Pol     |          |
       ^                   +-----------+                 +----------+
       *                   ^ |    |
       *           LRequest| |LI  |PolInfo
       *                   | V    V
       *                  +----------+
       *                  | Ultimate |
       ******************>| Location |
              Service     | Recipient|
                          +----------+

                   Figure 1: The Entities and Data Flows
   authentication is "explicit":

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

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

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

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 11                                       10
                         Geopriv Requirements                June                 Nov 2002

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

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

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

3.4.1. Relationship framework

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

   The different relationships raise different concerns for the
   implementation of privacy rules, including the need to communicate
   privacy instructions. A public rule repository for example seems to
   be superfluous in a trusted environment where more efficient methods
   of addressing privacy issues likely exist. We propose the following
   attributes as modifiers to a given data flow:

      Trusted:
         The data flow is governed by a contract that protects location
         privacy.

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

3.4.2. Explanatory Discussion

4.1. Scenarios of Data Flow

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

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

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 12
                         Geopriv Requirements                June 2002

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

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

   SCENARIO 2:  Cell Phone Roaming

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

   Cuellar, Morris, Mulligan                                       11
                         Geopriv Requirements                 Nov 2002

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 13
                         Geopriv Requirements                June 2002

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

   Here cell phone corp 1 is the IAP and the LoSi. Cell phone corp 1
   could be Non-trusted (the Rule Maker does not have a contract
   protecting location information with corp 1 and there is no
   contractual relationship with privacy provisions between corp 1 and
   corp 2) or Trusted (contract with privacy protections between cell
   phone corp 2 and corp 1).  Cell phone corp 2 is Trusted.

3.5. Further explanations

   <Note: Although this section is relevant

   SCENARIO 3:  Mobile Communities and Location-Based Services

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

3.5.1. messages use
   a Location Object to carry for instance: identities or pseudonyms,
   credentials and proof-of-possession of them, Policies and Location
   Data Information, including Data Types

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

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

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

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 14                                       12
                         Geopriv Requirements                June                 Nov 2002

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

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

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

                   Figure 1: The Entities and Data Flows

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

   Notice that if the space regions determined by different location
   values of DT2 do not overlap, then there is at most one
   transformation from DT1 to DT2.  If Target with the space regions of DT2 overlap,
   then usually there is some choice, which can be given by a (pseudo-)
   random function.

   If DT1 does not have more information than DT2, then there
         Location Server. This registration process is no
   function that "translates correctly" from DT1 to DT2.  In other
   words: there are many functions that translate from DT1 to DT2, but
   all introduce some degree outside of error.  We believe that this kind the
         scope of
   functions should be avoided.

3.5.2. Public Global Identities

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

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

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

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

3.5.3. Authorization without Explicit Authentication

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 15                                       13
                         Geopriv Requirements                June                 Nov 2002

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

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

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

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

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

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

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

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

      4: Location Information Request:
         The
   resulting keys are called authorized keys.  Those keys may be used Location Seeker requests location information for message authentication, without implying an explicit
   authentication. a
         Target.  In real life this corresponds request, the Location Seeker may select which
         location information data type it prefers.  One way of
         requesting Location Information MAY be sending a partially
         filled Location Object, including only the identities of the
         Target and Location Recipient and the desired Data Type and
         accuracy, and providing proof of possession of the required
         credentials.  But whether the using protocol understands this
         partially filled object as a request, this MAY depend on the
         using protocol or on the context.  The Location Seeker could
         also specify the need for instance to periodic location information
         updates, but this is probably out of the following
   situation: at a cloakroom scope of geopriv.

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

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

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

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

5. Requirements

   Cuellar, Morris, Mulligan                                       14
                         Geopriv Requirements                 Nov 2002

5.1. Location Object

   Req. 1.  (Location Object generalities)

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

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

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

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

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

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

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

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

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

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

      2.1) Target Identifier.

      2.2) Location Seeker signs for Recipient Identity

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

      2.3) Location Recipient Credential

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

      2.5) Location
   Seeker.  When presented to the Field.

      Each Location Server, the cheques Field may be
   countersigned so that the server is sure that the signer is the same
   as the contain one who was authorized by the Rule Maker.  This
   countersignature does not only authenticate the or more Location Seeker to
   the verifier, but
      Representations, which can be also indirectly to the Rule Maker, when the cheque
   is later presented to him.  Incidentally, the Rule Maker may achieve
   full information about who has accessed to his location information. in different formats.

   Cuellar, Morris, Mulligan      Expires Dec 2002                 16                                       15
                         Geopriv Requirements                June                 Nov 2002

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

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

      When transmitting the Location Seeker and the Rule
   Maker agree on one or several pseudonyms and a set of "traveller's
   cheques" that the target may use later to authenticate himself to Object, the
   server sender and thus indirectly also to the Location Seeker.
   Since e-cash protocols may be also anonymous, this may be used to
   hide simultaneously,

          o the identity of the target from the Location Server,
          o
      receiver must agree on the identity data type of the Location Seeker from the Location
             Server,
          o location information.
      The using protocol may specify that the identity data type information is
      part of the target from the Location Seeker.

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

      2.7) Motion and direction vectors

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

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

4. Requirements

4.1. Protocols

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

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

      2.11)     Version number

   Req. 3.  (Location Data Types)

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

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

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

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

5.2. The Using Protocol

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

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

   Cuellar, Morris, Mulligan                                       16
                         Geopriv Requirements                 Nov 2002

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

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

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

5.3. Policy based Location Data transfer Transfer

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

      Req. 3.  The Privacy Policies.

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

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 17
                         Geopriv Requirements                June 2002 a URI designated by the Rule Maker.

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

      Req. 5.  The "generic" policies (as opposed to the policies
            created by the Rule Maker) used by the Location Data
            Source, the full policies defined by the Ultimate Rule Maker
      (because an ULR SHOULD NOT retransmit Location Recipients Information), and by
      thus an ULR SHOULD receive only the
            Location Server subset of some special scenarios MUST Privacy Policies
      necessary for the ULR to handle the LI in compliance with the
      full Privacy Policies (such as, for example, an instruction on
      the time period for which then LI can be made
            explicit. retained).

   Req. 6.  The combined protocol 9.  (Full Policy language) Geopriv MAY specify a policy language.
      language capable of expressing a wide range of privacy rules
      concerning location information.  This policy language MAY be an
      existing one, an adaptation of an existing one or a new policy language.

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

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

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

5.4. Location Object Privacy and Security

   Cuellar, Morris, Mulligan                                       17
                         Geopriv Requirements                 Nov 2002

5.5. Identity Protection

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

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

5.6. Authentication Requirements

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

5.7. Actions to be an existing policy
            language.

4.3. Location Object, Location Field secured

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

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

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

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

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

   Req. 14.  (Minimal Crypto)

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

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

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

   Cuellar, Morris, Mulligan                                       18
                         Geopriv Requirements                 Nov 2002

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

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

5.8. Non-Requirements

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

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

6. Security Considerations

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

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

6.1. Traffic Analysis

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 18
                         Geopriv Requirements                June 2002

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

6.2. Securing the fields are.

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

      Req. 9. Privacy Policies

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

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

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

   <Locations (= Location Fields), and be accessed directly by several entities, for instance
   several Location Representations Servers) are
   discussed further in another draft, draft-morris-geopriv-location-
   object-issues-00.txt.>

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

   Cuellar, Morris, Mulligan                                       19
                         Geopriv Requirements                 Nov 2002

6.3. Emergency Case

   One way of implementing the actual data transfer.

      Req. 11.  The Location Object MUST contain one optional Location
            Data Type Field.  The Location Data Type Field may be used authentication bypass for emergency
   calls, mentioned in Req 14.3) is to specify let the type user have the choice of
   writing a Location Field or Location
            Representation, policy that says:
   -  "If the emergency server does not authenticate itself,
      nevertheless send the location", or
   -  "If the emergency server does not authenticate itself, let the
   call fail".

   In the case where the authentication of the emergency call fails
   because the user may not authenticate itself, the question arises:
   whose policy to request use? It is reasonable to use a Location Field of default one: this
            particular type.

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

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

      Req. 14.  The protocol MUST
   location information can only be extensible, allowing sent to an emergency center.

   Another situation, which should be studied in more detail is: what
   to do if not only the user fails to authenticate itself, but also
   the
            definition of new attributes in emergency center is not authenticable? It is reasonable to send
   the Location Object.

4.4. Requests

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

6.4. Identities and Anonymity

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

   The purpose of
            remote requests are: "send me the location information in a
            given format", "send me a pseudonym to be used later",
            "send me a pseudonym to be used later", "confirm use of Unlinked Pseudonyms is the
            purpose built key", etc.

4.5. Identity Protection

   Cuellar, Morris, Mulligan      Expires Dec 2002                 19
                         Geopriv Requirements                June 2002

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

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

      Req. 17.  The combined protocol MUST SHOULD be able to
   hide the real identity of the Rule Maker Location Recipient to the Location
   Server.

   In this last case, the Target is not concerned about the Server
   identifying him and knowing his location, but identifying his
   business partners, and therefore his habits, etc.  Reasons for
   hiding the real identities of the Location Recipients include (a)
   that this knowledge may be used to infer the identity of the Target,
   (b) that knowledge of the identity of the Location Recipient may
   embarrass the Target or breach confidential information, and  (c)
   that the dossier telling who has obtained a Target's location
   information over a long period of time can give information on
   habits, movements, etc.  Even if the location service providers
   agree to respect the privacy of the user, are compelled by laws or
   regulations to protect the privacy of the user, and misbehavior or
   negligence of the Location Server can be ruled out, there is still
   risk that personal data may become available to unauthorized persons
   through attacks from outsiders, unauthorized access from insiders,
   technical or human errors, or legal processes.

   In some occasions a Location Seeker, including Server has to know who is supplying
   policies for a Location Server.

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

   Cuellar, Morris, Mulligan                                       20
                         Geopriv Requirements                 Nov 2002

   be able enough to hide know that the real
            identity supplier of the Location Recipient policies is authorized to
   do so.  Those considerations are outside of our scope.

6.5. Unintended Target

   An Unintended Target is a person or object tracked by proximity to
   the Location Server.

   Thus here Target. This special case most frequently occurs if the target Target
   is not concerned a person.  For example, the Target may be a rental car
   equipped with a GPS Device, used to track car inventory.  The rental
   company may not care about the Server identifying
   him and knowing his driver's location, but identifying his business partners,
   and therefore his habits, etc.  One reason for hiding the real
   identities of the Location Recipients driver's
   privacy is implicitly affected.

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

7. Acknowledgements

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

8. References

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

   [Cha85] Chaum, David: Security without Identification, Card
           Computers to send me driving directions, but it could be embarrassing make Big Brother Obsolete. Original Verion
           appeared in: Communications of the ACM, vol. 28 no. 10,
           October 1985 pp. 1030-1044. Revised version available at
           http://www.chaum.com/articles/

   [ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/.

   [OECD] OECD Guidelines on the Protection of Privacy and Transborder
           Flows of Personal Data, http://www.oecd.org.

   [Pfi01] Pfitzmann, Andreas; K÷hntopp, Marit: Anonymity,
           Unobservability, and Pseudonymity - A Proposal for me if
   certain people find out that I have some relationship
           Terminology; in: H Federrath (Ed.): Designing Privacy
           Enhancing Technologies; Proc. Workshop on Design Issues in
           Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer
           versions available at http://www.koehntopp.de/marit/pub/anon

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

   Cuellar, Morris, Mulligan                                       21
                         Geopriv Requirements                 Nov 2002

9. Protocol and LO Issues for later Consideration

   It seems important to let mention some issues on the Location Server know about
   this. Even if my Server is trustworthy, it would be better if this
   explicit information was never disclosed to anybody.  Another reason
   for not wanting Object or
   on the Server to know protocol, which have emerged during the real identity discussion of earlier
   versions of this document.

9.1. Single Message Transfer

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

9.2. Multiple Locations in one LO

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

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

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

9.3. Translation Fields

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

   For instance, if translator, as identity and
   method.

9.4. Specifying Desired Accuracy in a Target wants Request

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

9.5. Truth Flag

   Geopriv should not provide an attribute in geopriv.>

4.6. Authentication Requirements

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

9.6. Timing Information Format

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

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 20                                       22
                         Geopriv Requirements                June                 Nov 2002

            generated and available to secure

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

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

4.7. Actions to be secured

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

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

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

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

4.8. Non-Requirements

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

5. Security Considerations

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

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

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

6. Acknowledgements

   We wish to thank fixed.

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 21
                         Geopriv Requirements                June 2002

7. References

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

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

10. Author's Addresses

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

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

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

9.

11. Full Copyright Statement

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

   Cuellar, Morris, Mulligan                                       23
                         Geopriv Requirements                 Nov 2002

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

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

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

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

   Cuellar, Morris, Mulligan      Expires Dec 2002                 23                                       24