doc: Add RFC documents

1 files changed, 2299 insertions, 0 deletions

diff --git a/doc/rfc/rfc6280.txt b/doc/rfc/rfc6280.txt
new file mode 100644
index 0000000..67328fc
--- /dev/null
+++ b/doc/rfc/rfc6280.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         R. Barnes
+Request for Comments: 6280                                   M. Lepinski
+BCP: 160                                                BBN Technologies
+Updates: 3693, 3694                                            A. Cooper
+Category: Best Current Practice                                J. Morris
+ISSN: 2070-1721                        Center for Democracy & Technology
+                                                           H. Tschofenig
+                                                  Nokia Siemens Networks
+                                                          H. Schulzrinne
+                                                     Columbia University
+                                                               July 2011
+
+
+           An Architecture for Location and Location Privacy
+                        in Internet Applications
+
+Abstract
+
+   Location-based services (such as navigation applications, emergency
+   services, and management of equipment in the field) need geographic
+   location information about Internet hosts, their users, and other
+   related entities.  These applications need to securely gather and
+   transfer location information for location services, and at the same
+   time protect the privacy of the individuals involved.  This document
+   describes an architecture for privacy-preserving location-based
+   services in the Internet, focusing on authorization, security, and
+   privacy requirements for the data formats and protocols used by these
+   services.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6280.
+
+
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                 [Page 1]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                 [Page 2]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Binding Rules to Data ......................................4
+      1.2. Location-Specific Privacy Risks ............................5
+      1.3. Privacy Paradigms ..........................................6
+   2. Terminology Conventions .........................................7
+   3. Overview of the Architecture ....................................7
+      3.1. Basic Geopriv Scenario .....................................8
+      3.2. Roles and Data Formats ....................................10
+   4. The Location Life Cycle ........................................12
+      4.1. Positioning ...............................................13
+           4.1.1. Determination Mechanisms and Protocols .............14
+           4.1.2. Privacy Considerations for Positioning .............16
+           4.1.3. Security Considerations for Positioning ............16
+      4.2. Location Distribution .....................................17
+           4.2.1. Privacy Rules ......................................17
+           4.2.2. Location Configuration .............................19
+           4.2.3. Location References ................................20
+           4.2.4. Privacy Considerations for Distribution ............21
+           4.2.5. Security Considerations for Distribution ...........23
+      4.3. Location Use ..............................................24
+           4.3.1. Privacy Considerations for Use .....................25
+           4.3.2. Security Considerations for Use ....................25
+   5. Security Considerations ........................................25
+   6. Example Scenarios ..............................................28
+      6.1. Minimal Scenario ..........................................28
+      6.2. Location-Based Web Services ...............................29
+      6.3. Emergency Calling .........................................31
+      6.4. Combination of Services ...................................32
+   7. Glossary .......................................................35
+   8. Acknowledgements ...............................................38
+   9. References .....................................................38
+      9.1. Normative References ......................................38
+      9.2. Informative References ....................................38
+
+1.  Introduction
+
+   Location-based services (applications that require information about
+   the geographic location of an individual or device) are becoming
+   increasingly common on the Internet.  Navigation and direction
+   services, emergency services, friend finders, management of equipment
+   in the field, and many other applications require geographic location
+   information about Internet hosts, their users, and other related
+   entities.  As the accuracy of location information improves and the
+   expense of calculating and obtaining it declines, the distribution
+   and use of location information in Internet-based services will
+   likely become increasingly pervasive.  Ensuring that location
+
+
+
+Barnes, et al.            Best Current Practice                 [Page 3]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   information is transmitted and accessed in a secure and privacy-
+   protective way is essential to the future success of these services,
+   as well as the minimization of the privacy harms that could flow from
+   their wide deployment and use.
+
+   Standards for communicating location information over the Internet
+   have an important role to play in providing a technical basis for
+   privacy and security protection.  This document describes a
+   standardized privacy- and security-focused architecture for location-
+   based services in the Internet: the Geopriv architecture.  The
+   central component of the Geopriv architecture is the location object,
+   which is used to convey both location information about an individual
+   or device and user-specified privacy rules governing that location
+   information.  As location information moves through its life cycle --
+   positioning, distribution, and use by its ultimate recipient(s) --
+   Geopriv provides mechanisms to secure the integrity and
+   confidentiality of location objects and to ensure that location
+   information is only transmitted in compliance with the user's privacy
+   rules.
+
+   The goals of this document are two-fold: First, the architecture
+   described revises and expands on the basic Geopriv Requirements [2]
+   [3], in order to clarify how these privacy concerns and the Geopriv
+   architecture apply to use cases that have arisen since the
+   publication of those documents.  Second, this document provides a
+   general introduction to Geopriv and Internet location-based services,
+   and is useful as a good first document for readers new to Geopriv.
+
+1.1.  Binding Rules to Data
+
+   A central feature of the Geopriv architecture is that location
+   information is always bound to privacy rules to ensure that entities
+   that receive location information are informed of how they may use
+   it.  These rules can convey simple directives ("do not share my
+   location with others"), or more robust preferences ("allow my spouse
+   to know my exact location all of the time, but only allow my boss to
+   know it during work hours").  By creating a structure to convey the
+   user's preferences along with location information, the likelihood
+   that those preferences will be honored necessarily increases.  In
+   particular, no recipient of the location information can disavow
+   knowledge of users' preferences for how their location may be used.
+   The binding of privacy rules to location information can convey
+   users' desire for and expectations of privacy, which in turn helps to
+   bolster social and legal systems' protection of those expectations.
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                 [Page 4]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   Binding of usage rules to sensitive information is a common way of
+   protecting information.  Several emerging schemes for expressing
+   copyright information provide for rules to be transmitted together
+   with copyrighted works.  The Creative Commons [28] model is the most
+   prominent example, allowing an owner of a work to set four types of
+   rules ("Attribution", "Noncommercial", "No Derivative Works", and
+   "ShareAlike") governing the subsequent use of the work.  After the
+   author sets these rules, the rules are conveyed together with the
+   work itself, so that every recipient is aware of the copyright terms.
+
+   Classification systems for controlling sensitive documents within an
+   organization are another example.  In these systems, when a document
+   is created, it is marked with a classification such as "SECRET" or
+   "PROPRIETARY".  Each recipient of the document knows from this
+   marking that the document should only be shared with other people who
+   are authorized to access documents with that marking.  Classification
+   markings can also convey other sorts of rules, such as a
+   specification for how long the marking is valid (a declassification
+   date).  The United States Department of Defense guidelines for
+   classification [4] provide one example.
+
+1.2.  Location-Specific Privacy Risks
+
+   While location-based services raise some privacy concerns that are
+   common to all forms of personal information, many of them are
+   heightened, and others are uniquely applicable in the context of
+   location information.
+
+   Location information is frequently generated on or by mobile devices.
+   Because individuals often carry their mobile devices with them,
+   location data may be collected everywhere and at any time, often
+   without user interaction, and it may potentially describe both what a
+   person is doing and where he or she is doing it.  For example,
+   location data can reveal the fact that an individual was at a
+   particular medical clinic at a particular time.  The ubiquity of
+   location information may also increase the risks of stalking and
+   domestic violence if perpetrators are able to use (or abuse)
+   location-based services to gain access to location information about
+   their victims.
+
+   Location information is also of particular interest to governments
+   and law enforcers around the world.  The existence of detailed
+   records of individuals' movements should not automatically facilitate
+   the ability for governments to track their citizens, but in some
+   jurisdictions, laws dictating what government agents must do to
+   obtain location data are either non-existent or out of date.
+
+
+
+
+
+Barnes, et al.            Best Current Practice                 [Page 5]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+1.3.  Privacy Paradigms
+
+   Traditionally, the extent to which data about individuals enjoys
+   privacy protections on the Internet has largely been decided by the
+   recipients of the data.  Internet users may or may not be aware of
+   the privacy practices of the entities with whom they share data.
+   Even if they are aware, they have generally been limited to making a
+   binary choice between sharing data with a particular entity or not
+   sharing it.  Internet users have not historically been granted the
+   opportunity to express their own privacy preferences to the
+   recipients of their data and to have those preferences honored.
+
+   This paradigm is problematic because the interests of data recipients
+   are often not aligned with the interests of data subjects.  While
+   both parties may agree that data should be collected, used,
+   disclosed, and retained as necessary to deliver a particular service
+   to the data subject, they may not agree about how the data should
+   otherwise be used.  For example, an Internet user may gladly provide
+   his email address on a Web site to receive a newsletter, but he may
+   not want the Web site to share his email address with marketers,
+   whereas the Web site may profit from such sharing.  Neither providing
+   the address for both purposes nor deciding not to provide it is an
+   optimal option from the Internet user's perspective.
+
+   The Geopriv model departs from this paradigm for privacy protection.
+   As explained above, location information can be uniquely sensitive.
+   And as location-based services emerge and proliferate, they
+   increasingly require standardized protocols for communicating
+   location information between services and entities.  Recognizing both
+   of these dynamics, Geopriv gives data subjects the ability to express
+   their choices with respect to their own location information, rather
+   than allowing the recipients of the information to define how it will
+   be used.  The combination of heightened privacy risk and the need for
+   standardization compelled the Geopriv designers to shift away from
+   the prevailing Internet privacy model, instead empowering users to
+   express their privacy preferences about the use of their location
+   information.
+
+   Geopriv does not, by itself, provide technical means through which it
+   can be guaranteed that users' location privacy rules will be honored
+   by recipients.  The privacy protections in the Geopriv architecture
+   are largely provided by virtue of the fact that recipients of
+   location information are informed of relevant privacy rules, and are
+   expected to only use location information in accordance with those
+   rules.  The distributed nature of the architecture inherently limits
+   the degree to which compliance can be guaranteed and verified by
+   technical means.  Section 5 describes how some security mechanisms
+   can address this to a limited extent.
+
+
+
+Barnes, et al.            Best Current Practice                 [Page 6]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   By binding privacy rules to location information, however, Geopriv
+   provides valuable information about users' privacy preferences, so
+   that non-technical forces such as legal contracts, governmental
+   consumer protection authorities, and marketplace feedback can better
+   enforce those privacy preferences.  If a commercial recipient of
+   location information, for example, violates the location rules bound
+   to the information, the recipient can in a growing number of
+   countries be charged with violating consumer or data protection laws.
+   In the absence of a binding of rules with location information,
+   consumer protection authorities would be less able to protect
+   individuals whose location information has been abused.
+
+2.  Terminology Conventions
+
+   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 RFC 2119 [1].
+
+   Throughout the remainder of this document, capitalized terms defined
+   in Section 7 refer to Geopriv-specific roles and formats; the same
+   terms used in all lowercase refer generically to those terms.
+
+3.  Overview of the Architecture
+
+   This section provides an overview of the Geopriv architecture for the
+   secure and private distribution of location information on the
+   Internet.  We describe the three phases of the "location life cycle"
+   -- positioning, distribution, and use -- and discuss how the
+   components of the architecture fit within each phase.  The next
+   section provides additional detail about how each phase can be
+   achieved in a private and secure manner.
+
+   The risks discussed in the previous section all arise from
+   unauthorized disclosure or usage of location information.  Thus, the
+   Geopriv architecture has two fundamental privacy goals:
+
+   1.  Ensure that location information is distributed only to
+       authorized entities, and
+
+   2.  Provide information to those entities about how they are
+       authorized to use the location information.
+
+   If these two goals are met, all parties that receive location
+   information will also receive directives about how they can use that
+   information.  Privacy-preserving entities will only engage in
+   authorized uses, and entities that violate privacy will do so
+   knowingly, since they have been informed of what is authorized (and
+   thus, implicitly, of what is not).
+
+
+
+Barnes, et al.            Best Current Practice                 [Page 7]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   Privacy rules and their distribution are thus the central technical
+   components of the privacy system, since they inform location
+   recipients about how they are authorized to use that information.
+   The two goals in the preceding paragraph are enabled by two classes
+   of rules:
+
+   1.  Access control rules: Rules that describe which entities may
+       receive location information and in what form
+
+   2.  Usage rules: Rules that describe what uses of location
+       information are authorized
+
+   Within this framework for privacy, security mechanisms provide
+   support for the application of privacy rules.  For example,
+   authentication mechanisms validate the identities of entities
+   requesting a location (so that authorization and access-control
+   policies can be applied), and confidentiality mechanisms protect
+   location information en route between privacy-preserving entities.
+   Security mechanisms can also provide assurances that are outside the
+   purview of privacy by, for example, assuring location recipients that
+   location information has been faithfully transmitted to them by its
+   creator.
+
+3.1.  Basic Geopriv Scenario
+
+   As location information is transmitted among Internet hosts, it goes
+   through a "location life cycle": first, the location is computed
+   based on some external information (positioning), and then it is
+   transmitted from one host to another (distribution) until finally it
+   is used by a recipient (use).
+
+   For example, suppose Alice is using a mobile device, she learns of
+   her location from a wireless location service, and she wishes to
+   share her location privately with her friends by way of a presence
+   service.  Alice clearly needs to provide the presence server with her
+   location and rules about which friends can be provided with her
+   location.  To enable Alice's friends to preserve her privacy, they
+   need to be provided with privacy rules.  Alice may tell some of her
+   friends the rules directly, or she can have the presence server
+   provide the rules to her friends when it provides them with her
+   location.  In this way, every friend who receives Alice's location is
+   authorized by Alice to receive it, and every friend who receives it
+   knows the rules.  Good friends will obey the rules.  If a bad friend
+   breaks them and Alice finds out, the bad friend cannot claim that he
+   was unaware of the rules.
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                 [Page 8]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   Some of Alice's friends will be interested in using Alice's location
+   only for their own purposes, for example, to meet up with her or plot
+   her location over time.  The usage rules that they receive direct
+   them as to what they can or cannot do (for example, Alice might not
+   want them keeping her location for more than, say, two weeks).
+
+   Consider one friend, Bob, who wants to send Alice's location to some
+   of his friends.  To operate in a privacy-protective way, Bob needs
+   not only usage rules for himself, but also access control rules that
+   describe who he can send information to and rules to give to the
+   recipients.  If the rules he received from the presence server
+   authorize him to give Alice's location to others, he may do so;
+   otherwise, he will require additional rules from Alice before he is
+   authorized to distribute her location.  If recipients who receive
+   Alice's location from Bob want to distribute the location information
+   further, they must go through the same process as Bob.
+
+   The whole example is illustrated in the following figure:
+
+   +----------+
+   | Wireless |
+   | Location |
+   | Service  |                          Retrieve
+   +----------+                      Access Control Rules
+       |                      +--------------------------------+
+       |                      | +--------------------------+   |
+    Location                  | |        Access            |   |
+       |                      | |     Control Rules        v   |
+       |                      | |                         +-----+
+       |                      | |                         | Bob |
+       |                      | |                         |+---+|--> ...
+       |                      | |                  +----->||PC ||
+   ...........                v |                  |      ++---++
+   | +------+|            +----------+             |
+   | |Mobile|+--Location->| Presence |--Location-->|     +----------+
+   | |Phone ||            | Server   |             |---->| Friend-1 |
+   | +------++---Rules--->|          |---Rules---->|     +----------+
+   |  Alice  |            +----------+             |
+   |   O     |                                     |
+   |  /|\    |                                     |     +----------+
+   |  / \    |                                     +---->| Friend-2 |
+   `---------'                                           +----------+
+
+                     Figure 1: Basic Geopriv Scenario
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                 [Page 9]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+3.2.  Roles and Data Formats
+
+   The above example illustrates the six basic roles in the Geopriv
+   architecture:
+
+   Target:   An individual or other entity whose location is sought in
+      the Geopriv architecture.  In many cases, the Target will be the
+      human user of a Device, but it can also be an object such as a
+      vehicle or shipping container to which a Device is attached.  In
+      some instances, the Target will be the Device itself.  The Target
+      is the entity whose privacy Geopriv seeks to protect.  Alice is
+      the Target in Figure 1.
+
+   Device:   The physical device, such as a mobile phone, PC, or
+      embedded micro-controller, whose location is tracked as a proxy
+      for the location of a Target.  Alice's mobile phone is the Device
+      in Figure 1.
+
+   Rule Maker (RM):   Performs the role of creating rules governing
+      access to location information for a Target.  In some cases, the
+      Target performs the Rule Maker role (as is the case with Alice),
+      and in other cases they are separate.  For example, a parent may
+      serve as the Rule Maker when the Target is his child, or a
+      corporate security officer may serve as the Rule Maker for devices
+      owned by the corporation but used by employees.  The Rule Maker is
+      also not necessarily the owner of the Device.  For example, a
+      corporation may provide a Device to an employee but permit the
+      employee to serve as the Rule Maker and set her own privacy rules.
+
+   Location Generator (LG):   Performs the roles of initially
+      determining or gathering the location of the Device and providing
+      it to Location Servers.  Location Generators may be any sort of
+      software or hardware used to obtain the Device's location.
+      Examples include Global Positioning System (GPS) chips and
+      cellular networks.  A Device may even perform the Location
+      Generator role for itself; Devices capable of unassisted
+      satellite-based positioning and Devices that accept manually
+      entered location information are two examples.  The wireless
+      location service plays the Location Generator role in Figure 1.
+
+   Location Server (LS):   Performs the roles of receiving location
+      information and rules, applying the rules to the location
+      information to determine what other entities, if any, can receive
+      location information, and providing the location to Location
+      Recipients.  Location Servers receive location information from
+      Location Generators and rules from Rule Makers, and then apply the
+      rules to the location information.  Location Servers may not
+      necessarily be "servers" in the colloquial sense of hosts in
+
+
+
+Barnes, et al.            Best Current Practice                [Page 10]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+      remote data centers servicing requests.  Rather, a Location Server
+      can be any software or hardware component that distributes
+      location information.  Examples include a server in an access
+      network, a presence server, or a Web browser or other software
+      running on a Device.  The above example includes three Location
+      Servers: Alice's mobile phone, the presence service, and Bob's PC.
+
+   Location Recipient (LR):   Performs the role of receiving location
+      information.  A Location Recipient may ask for a location
+      explicitly (by sending a query to a Location Server), or it may
+      receive a location asynchronously.  The presence service, Bob,
+      Friend-1, and Friend-2 are Location Recipients in Figure 1.
+
+   In general, these roles may or may not be performed by physically
+   separate entities, as demonstrated by the entities in Figure 1, many
+   of which perform multiple roles.  It is not uncommon for the same
+   entity to perform both the Location Generator and Location Server
+   roles, or both the Location Recipient and Location Server roles.  A
+   single entity may take on multiple roles simply by virtue of its own
+   capabilities and the permissions provided to it.
+
+   Although in the above example there is only a single Location
+   Generator and a single Rule Maker, in some cases a Location Server
+   may receive Location Objects from multiple Location Generators or
+   Rules from multiple Rule Makers.  Likewise, a single Location
+   Generator may publish location information to multiple Location
+   Servers, and a single Location Recipient may receive Location Objects
+   from multiple Location Servers.
+
+   There is a close relationship between a Target and its Device.  The
+   term "Device" is used when discussing protocol interactions, whereas
+   the term "Target" is used when discussing generically the person or
+   object being located and its privacy.  While in the example above
+   there is a one-to-one relationship between the Target and the Device,
+   Geopriv can also be used to convey location information about a
+   device that is not directly linked to a single individual or object,
+   such as a Device shared by multiple individuals.
+
+   Two data formats are necessary within this architecture:
+
+   Location Object (LO):   An object used to convey location information
+      together with Privacy Rules.  Geopriv supports both geodetic
+      location data (latitude, longitude, altitude, etc.) and civic
+      location data (street, city, state, etc.).  Either or both types
+      of location information may be present in a single LO (see the
+      considerations in [5] for LOs containing multiple locations).
+      Location Objects typically include some sort of identifier of the
+      Target.
+
+
+
+Barnes, et al.            Best Current Practice                [Page 11]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   Privacy Rule:   A directive that regulates an entity's activities
+      with respect to location information, including the collection,
+      use, disclosure, and retention of the location information.
+      Privacy Rules describe which entities may obtain location
+      information in what form (access control rules) and how location
+      information may be used by an entity (usage rules).
+
+   The whole example, using Geopriv roles and formats, is illustrated in
+   the following figure:
+
+   +----+
+   | LG |
+   +----+
+     ^
+     |
+   Positioning
+    Data
+     |
+     |    +------------Privacy Rules------------------>+----+
+     |    |                                      +---->| LR |--> ...
+     |    |                                      |     | LS |
+     v    |                                      |     +----+
+   +-------+                                     |
+   |Target |                +----+               |     +----+
+   |Device |--------------->| LR |---------------+---->| LR |
+   |  RM   |       LO       | LS |       LO      |     +----+
+   |  LS   |                +----+               |
+   +-------+                                     |
+                                                 |     +----+
+                                                 +---->| LR |
+                                                       +----+
+
+                     Figure 2: Basic Geopriv Scenario
+
+4.  The Location Life Cycle
+
+   The previous section gave an example of how an individual's location
+   can be distributed through the Internet.  In general, the location
+   life cycle breaks down into three phases:
+
+   1.  Positioning: A Location Generator determines the Device's
+       location.
+
+   2.  Distribution: Location Servers send location information to
+       Location Recipients, which may in turn act as Location Servers
+       and further distribute the location to other Location Recipients,
+       possibly several times.
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 12]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   3.  Use: A Location Recipient receives the location and uses it.
+
+   Each of these phases involves a different set of Geopriv roles, and
+   each has a different set of privacy and security implications.  The
+   Geopriv roles are mapped onto the location life cycle in the figure
+   below.
+
+                               +----------+
+                               |  Rule    |+
+                               |  Maker(s)||
+   Positioning                 |          ||
+     Data                      +----------+|
+       |                        +----------+
+       |                            | Rules
+       |                            |
+       |                            |
+       V                            V
+   +----------+                +----------+                +----------+
+   |Location  |  Location      | Location |+      LO       |Location  |
+   |Generator |--------------->| Server(s)||-------------->|Recipient |
+   |          |                |          ||               |          |
+   +----------+                +----------+|               +----------+
+                               +----------+
+   <-------------------------><---------------------------><----------->
+    Positioning                Distribution                 Use
+
+                       Figure 3: Location Life Cycle
+
+4.1.  Positioning
+
+   Positioning is the process by which the physical location of the
+   Device is computed, based on some observations about the Device's
+   situation in the physical world.  (This process goes by several other
+   names, including Location Determination or Sighting.)  The input to
+   the positioning process is some information about the Device, and the
+   outcome is that the LG knows the location of the Device.
+
+   In this section, we give a brief taxonomy of current positioning
+   systems, their requirements for protocol support, and the privacy and
+   security requirements for positioning.
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 13]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+4.1.1.  Determination Mechanisms and Protocols
+
+   While the specific positioning mechanisms that can be applied for a
+   given Device are strongly dependent on the physical situation and
+   capabilities of the Device, these mechanisms generally fall into the
+   three categories described in detail below:
+
+   o  Device-based
+
+   o  Network-based
+
+   o  Network-assisted
+
+   As suggested by the above names, a positioning scheme can rely on the
+   Device, an Internet-accessible resource (not necessarily a network
+   operator), or a combination of the two.  For a given scheme, the
+   nature of this reliance will dictate the protocol mechanisms needed
+   to support it.
+
+   With Device-based positioning mechanisms, the Device is capable of
+   determining its location by itself.  This is the case for a manually
+   entered location or for (unassisted) satellite-based positioning
+   using a Global Navigation Satellite System (GNSS).  In these cases,
+   the Device acts as its own LG, and there are no protocols required to
+   support positioning beyond those that transmit the positioning data
+   from the satellite to the user.
+
+   In network-based positioning schemes, an external LG (an Internet
+   host other than the Device) has access to sufficient information
+   about the Device, through out-of-band channels, to establish the
+   position of the Device.  The most common examples of this type of LG
+   are entities that have a physical relationship to the Device (such as
+   ISPs).  In wired networks, wiremap-based location is a network-based
+   technique; in wireless networks, timing and signal-strength-based
+   techniques that use measurements from base stations are considered to
+   be network-based.  Large-scale IP-to-geo databases (for example,
+   those based on WHOIS data or latency measurements) are also
+   considered to be network-based positioning mechanisms.
+
+   For network-based positioning as for Device-based, no protocols for
+   communication between the Device and the LG are strictly necessary to
+   support positioning, since positioning information is collected
+   outside of the location distribution system (at lower layers of the
+   network stack, for example).  This does not rule out the use of other
+   Internet protocols (like the Simple Network Management Protocol
+   (SNMP)) to collect inputs to the positioning process.  Rather, since
+   these inputs can only be used by certain LGs to determine location,
+   they are not controlled as private information.  Network-based
+
+
+
+Barnes, et al.            Best Current Practice                [Page 14]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   positioning often provides location information to protocols by which
+   the network informs a Device of its own location.  These are known as
+   Location Configuration Protocols; see Section 4.2.2 for further
+   discussion.
+
+   Network-assisted systems account for the greatest number and
+   diversity of positioning schemes.  In these systems, the work of
+   positioning is divided between the Device and an external LG via
+   some communication (possibly over the Internet), typically in one of
+   two ways:
+
+   o  The Device provides measurements to the LG, or
+
+   o  The LG provides assistance data to the Device.
+
+   "Measurements" are understood to be observations about the Device's
+   environment, ranging from wireless signal strengths to the Media
+   Access Control (MAC) address of a first-hop router.  "Assistance" is
+   the complement to measurement, namely the positioning information
+   that enables the computation of location based on measurements.  A
+   set of wireless base station locations (or wireless calibration
+   information) would be an assistance datum, as would be a table that
+   maps routers to buildings in a corporate campus.
+
+   For example, wireless and wired networks can serve as the basis for
+   network-assisted positioning.  In several current 802.11 positioning
+   systems, the Device sends measurements (e.g., MAC addresses and
+   signal strengths) to an LG, and the LG returns a location to the
+   client.  In wired networks, the Device can send its MAC address to
+   the LG, which can query the MAC-layer infrastructure to determine the
+   switch and port to which that MAC address is connected, then query a
+   wire map to determine the location at which the wire connected to
+   that port terminates.
+
+   As an aside, the common phrase "assisted GPS" ("assisted GNSS" more
+   broadly) actually encompasses techniques that transmit both
+   measurements and assistance data.  Systems in which the Device
+   provides the LG with GNSS measurements are measurement-based, while
+   those in which the assistance server provides ephemeris or almanac
+   data are assistance-based in the above terminology.  (Those familiar
+   with GNSS positioning will note that there are of course cases in
+   which both of these interactions occur within a single location
+   determination protocol, so the categories are not mutually
+   exclusive.)
+
+   Naturally, the exchange of measurement or positioning data between
+   the Device and the LG requires a protocol over which the information
+   is carried.  The structure of this protocol will depend on which of
+
+
+
+Barnes, et al.            Best Current Practice                [Page 15]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   the two patterns a network-assisted scheme follows.  Conversely, the
+   structure of the protocol will determine which of the two parties
+   (the Device, the LG, or both) is aware of the Device's location at
+   the end of the protocol interaction.
+
+4.1.2.  Privacy Considerations for Positioning
+
+   Positioning is the first point at which location may be associated
+   with a particular Device and may be associated with the Target's
+   identity.  Local identifiers, unlinked pseudonyms, or private
+   identifiers that are not linked to the real identity of the Target
+   should be used as forms of identity whenever possible.  This provides
+   privacy protection by disassociating the location from the Target's
+   identity before it is distributed.
+
+   At the conclusion of the positioning process, the entity acting as
+   the LG has the Device's location.  If the Device is performing the LG
+   role, then both the Device and LG have it.  If the entity acting as
+   the LG also performs the role of LS, the privacy considerations in
+   Section 4.2.4 apply.
+
+   In some deployment scenarios, positioning functions and distribution
+   functions may need to be provided by separate entities, in which case
+   the LG and LS roles will not be performed by the same entity.  In
+   this situation, the LG acts as a "dumb", non-privacy-aware
+   positioning resource, and the LS provides the privacy logic necessary
+   to support distribution (possibly with multiple LSes using the same
+   LG).  In order to allow the privacy-unaware LG to distribute location
+   information to these LSes while maintaining privacy, the relationship
+   between the LG and its set of LSes MUST be tightly constrained
+   (effectively "hard-wired").  That is, the LG MUST only provide
+   location information to a small fixed set of LSes, and each of these
+   LSes MUST comply with the requirements of Section 4.2.4.
+
+4.1.3.  Security Considerations for Positioning
+
+   Manipulation of the positioning process can expose location
+   information through two mechanisms:
+
+   1) A third party could guess or derive measurements about a specific
+   device and use them to get the location of that Device.  To mitigate
+   this risk, the LG SHOULD be able to authenticate and authorize
+   devices providing measurements and, if possible, verify that the
+   presented measurements are likely to be the actual physical values
+   measured by that client.  These security procedures rely on the type
+   of positioning being done, and may not be technically feasible in all
+   cases.
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 16]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   2) By eavesdropping, a third party may be able to obtain measurements
+   sent by the Device itself that indicate the rough position of the
+   Device.  To mitigate this risk, protocols used for positioning MUST
+   provide confidentiality and integrity protections in order to prevent
+   observation and modification of transmitted positioning data while en
+   route between the Target and the LG.
+
+   If an LG or a Target chooses to act as an LS, it inherits the
+   security requirements for an LS, described in Section 4.2.5.
+
+4.2.  Location Distribution
+
+   When an entity receives location information (from an LG or an LS)
+   and redistributes it to other entities, it acts as an LS.  Location
+   Distribution is the process by which one or more LSes provide LOs to
+   LRs in a privacy-preserving manner.
+
+   The role of an LS is thus two-fold: First, it must collect location
+   information and Rules that control access to that information.  Rules
+   can be communicated within an LO, within a protocol that carries LOs,
+   or through a separate protocol that carries Rules.  Second, the LS
+   must process requests for location information and apply the Rules to
+   these requests in order to determine whether it is authorized to
+   fulfill them by returning location information.
+
+   An LS thus has at least two types of interactions with other hosts,
+   namely receiving and sending LOs.  An LS may optionally implement a
+   third interaction, allowing Rule Makers to provision it with Rules.
+   The distinction between these two cases is important in practice,
+   because it determines whether the LS has a direct relationship with a
+   Rule Maker: An LS that accepts Rules directly from a Rule Maker has
+   such a relationship, while an LS that acquires all its Rules through
+   LOs does not.
+
+4.2.1.  Privacy Rules
+
+   Privacy Rules are the central mechanism in Geopriv for maintaining a
+   Target's privacy, because they provide a recipient of an LO (an LS or
+   LR) with information on how the LO may be used.
+
+   Throughout the Geopriv architecture, Privacy Rules are communicated
+   in rules languages with a defined syntax and semantics.  For example,
+   the Common Policy rules language has been defined [6] to provide a
+   framework for broad-based rule specifications.  Geopriv Policy [7]
+   defines a language for creating location-specific rules.  The XML
+   Configuration Access Protocol (XCAP) [8] can be used as a protocol to
+   install rules in both of these formats.
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 17]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   Privacy Rules follow a default-deny pattern: an empty set of Rules
+   implies that all requests for location information should be denied,
+   except requests made by the Target itself.  Each Rule adds to the
+   set, granting a specific permission.  Adding a Rule can only augment
+   privacy protections because all Rules are positive grants of
+   permission.
+
+   The following are examples of Privacy Rules governing location
+   distribution:
+
+   o  Retransmit location information when requested from example.com.
+
+   o  Retransmit only city and country.
+
+   o  Retransmit location information with no less than a 100-meter
+      radius of uncertainty.
+
+   o  Retransmit location information only for the next two weeks.
+
+   LSes enforce Privacy Rules in two ways: by denying requests for
+   location information, or by transforming the location information
+   before retransmitting it.
+
+   LSes may also receive Rules governing location retention, such as
+   "Retain location only for 48 hours".  Such Rules are simply
+   directives about how long the Target's location information can be
+   retained.
+
+   Privacy Rules can govern the behavior of both LSes and LRs.  Rules
+   that direct LSes about how to treat a Target's location information
+   are known as Local Rules.  Local Rules are used internally by the LS
+   to handle requests from LRs.  They are not distributed to LRs.
+
+   Forwarded Rules, on the other hand, travel inside LOs and direct LSes
+   and LRs about how to handle the location information they receive.
+   Because the Rules themselves may reveal potentially sensitive
+   information about the Target, only the minimal subset of Forwarded
+   Rules necessary to handle the LO is distributed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 18]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   An example can illustrate the interaction between Local Rules and
+   Forwarded Rules.  Suppose Alice provides the following Local Rules to
+   an LS:
+
+   o  The LS may retransmit Alice's precise location to Bob, who in turn
+      is permitted to retain the location information for one month.
+
+   o  The LS may retransmit Alice's city, state, and country to Steve,
+      who in turn is permitted to retain the location information for
+      one hour.
+
+   o  The LS may retransmit Alice's country to a photo-sharing Web site,
+      which in turn is permitted to retain the location information for
+      one year and retransmit it to any requesters.
+
+   When Steve asks for Alice's location, the LS can transmit to Steve
+   the limited location information (city, state, and country) along
+   with Forwarded Rules instructing Steve to (a) not further retransmit
+   Alice's location information, and (b) only retain the location
+   information for one hour.  By only sending these specifically
+   applicable Forwarded Rules to Steve (as opposed to the full set of
+   Local Rules), the LS is protecting Alice's privacy by not disclosing
+   to Steve that (for example) Alice allows Bob to obtain more precise
+   location information than Alice allows Steve to receive.
+
+   Geopriv is designed to be usable even by devices with constrained
+   processing capabilities.  To ensure that Forwarded Rules can be
+   processed on constrained devices, LOs are required to carry only a
+   limited set of Forwarded Rules, with an option to reference a more
+   robust set of external Rules.  The limited Rule set covers two
+   privacy aspects: how long the Target's location may be retained
+   ("Retention"), and whether or not the Target's location may be
+   retransmitted ("Retransmission").  An LO may contain a pointer to
+   more robust Rules, such as those shown in the set of four Rules at
+   the beginning of this section.
+
+4.2.2.  Location Configuration
+
+   Some entities performing the LG role are designed only to provide
+   Targets with their own locations, as opposed to distributing a
+   Target's location to others.  The process of providing a Target with
+   its own location is known within Geopriv as Location Configuration.
+   The term "Location Information Server" (LIS) is often used to
+   describe the entity that performs this function.  However, a LIS may
+   also perform other functions, such as providing a Target's location
+   to other entities.
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 19]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   A Location Configuration Protocol (LCP) [9] is one mechanism that can
+   be used by a Device to discover its own location from a LIS.  LCPs
+   provide functions in the way they obtain, transport, and deliver
+   location requests and responses between a LIS and a Device such that
+   the LIS can trust that the location requests and responses handled
+   via the LCP are in fact from/to the Target.  Several LCPs have been
+   developed within Geopriv [10] [11] [12] [13].
+
+   A LIS whose sole purpose is to perform Location Configuration need
+   only follow a simple privacy-preserving policy: transmit a Target's
+   location only to the Target itself.  This is known as the "LCP
+   policy".
+
+   Importantly, if an LS is also serving in the role of LG and it has
+   not been provisioned with Privacy Rules for a particular Target, it
+   MUST follow the LCP policy, whether it is a LIS or not.  In the
+   positioning phase, an entity serving the roles of both LG and LS that
+   has not received Privacy Rules must follow this policy.  The same is
+   true for any LS in the distribution phase.
+
+4.2.3.  Location References
+
+   The location distribution process occurs through a series of
+   transmissions of LOs: transmissions of location "by value".  Location
+   "by value" can be expressed in terms of geodetic location data
+   (latitude, longitude, altitude, etc.) and civic location data
+   (street, city, state, etc.).
+
+   A location can also be distributed "by reference", where a reference
+   is represented by a URI that can be dereferenced to obtain the LO.
+   This document summarizes the properties of location-by-reference that
+   are discussed at length in [14].
+
+   Distribution of location-by-reference (distribution of location URIs)
+   offers several benefits.  Location URIs are a more compact way of
+   transmitting location information, since URIs are usually smaller
+   than LOs.  A recipient of location information can make multiple
+   requests to a URI over time to receive updated location information
+   if the URI is configured to provide a fresh location rather than a
+   single "snapshot".
+
+   From a positioning perspective, location-by-reference can offer the
+   additional benefit of "just in time" positioning.  If a location is
+   distributed by reference, an entity acting as a combined LG/LS only
+   needs to perform positioning operations when a recipient dereferences
+   a previously distributed URI.
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 20]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   From a privacy perspective, distributing a location as a URI instead
+   of as an LO can help protect privacy by forcing each recipient of the
+   location to request location information from the referenced LS,
+   which can then apply access controls individually to each recipient.
+   But the benefit provided here is contingent on the LS applying access
+   controls.  If the LS does not apply an access control policy to
+   requests for a location URI (in other words, if it enforces the
+   "possession model" defined in [14]), then transmitting a location URI
+   presents the same privacy risks as transmitting the LO itself.
+   Moreover, the use of location URIs without access controls can
+   introduce additional privacy risks: If URIs are predictable, an
+   attacker to whom the URI has not been sent may be able to guess the
+   URI and use it to obtain the referenced LO.  To mitigate this,
+   location URIs without access controls need to be constructed so that
+   they contain a random component with sufficient entropy to make
+   guessing infeasible.
+
+4.2.4.  Privacy Considerations for Distribution
+
+   Location information MUST be accompanied by Rules throughout the
+   distribution process.  Otherwise, a recipient will not know what uses
+   are authorized, and will not be able to use the LO.  Consequently,
+   LOs MUST be able to express Rules that convey appropriate
+   authorizations.
+
+   An LS MUST only accept Rules from authorized Rule Makers.  For an LS
+   that receives Rules exclusively in LOs and has no direct relationship
+   with a Rule Maker, this requirement is met by applying the Rules
+   provided in an LO to the distribution of that LO.  For an LS with a
+   direct relationship to a Rule Maker, this requirement means that the
+   LS MUST be configurable with an RM authorization policy.  An LS
+   SHOULD define a prescribed set of RMs that may provide Rules for a
+   given Target or LO.  For example, an LS may only allow the Target to
+   set Rules for itself, or it might allow an RM to set Rules for
+   several Targets (e.g., a parent for children, or a corporate security
+   officer for employees).
+
+   No matter how Rules are provided to an LS, for each LO it receives,
+   it MUST combine all Rules that apply to the LO into a Rule set that
+   defines which transmissions are authorized, and it MUST transmit
+   location information only in ways that are authorized by these Rules.
+
+   An LS that receives Rules exclusively through LOs MUST examine the
+   Rules that accompany a given LO in order to determine how the LS may
+   use the LO.  If any Rules are included by reference, the LS SHOULD
+   attempt to download them.  If the LO includes no Rules that allow the
+   LS to transmit the LO to another entity, then the LS MUST NOT
+   transmit the LO.  If the LO contains no Rules at all -- for example,
+
+
+
+Barnes, et al.            Best Current Practice                [Page 21]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   if it is in a format with no Rules syntax -- then the LS MUST delete
+   it.  Emergency services provide an exception in that Rules can be
+   implicit; see [15]).  If the LO included Rules by reference, but
+   these Rules were not obtained for any reason, the LS MUST NOT
+   transmit the LO and MUST adhere to the provided value in the
+   retention-expires field.
+
+   An LS that receives Rules both directly from one or more Rule Makers
+   and through LOs MUST combine the Rules in a given LO with Rules it
+   has received from the RMs.  The strategy the LS uses to combine these
+   sets of Rules is a matter for local policy, depending on the relative
+   priority that the LS grants to each source of Rules.  Some example
+   policies are:
+
+   Union:   A transmission of location information is authorized if it
+      is authorized by either a rule in the LO or an RM-provided rule.
+
+   Intersection:   A transmission of location information is authorized
+      if it is authorized by both a rule in the LO and an RM-provided
+      rule.
+
+   RM Override:   A transmission of location information is authorized
+      if it is authorized by an RM-provided rule, regardless of the LO
+      Rules.
+
+   LO Override:   A transmission of location information is authorized
+      if it is authorized by an LO-provided rule, regardless of the RM
+      Rules.
+
+   The default combination policy for an LS that receives multiple rule
+   sets is to combine them according to procedures in Section 10 of
+   RFC 4745 [6].  Privacy rules always grant access; i.e., the default
+   is to deny access, and rules specify conditions under which access is
+   allowed.  Thus, when an LS is provided more than one policy document
+   that applies to a given LO, it has been instructed to provide access
+   when any of the rules apply.  That is, the "Union" policy is the
+   default policy for an LS with multiple sources of policy.  An LS MAY
+   choose to apply a more restrictive policy by ignoring some of the
+   grants of permission in the privacy rules provided.  The
+   "Intersection" policy and both "Override" policies listed above are
+   of this latter character.
+
+   Protocols that are used for managing rules should allow an RM to
+   retrieve from the LS the set of rules that will ultimately be
+   applied.  For example, in the basic HTTP-based protocol defined in
+   [16], an RM can use a GET request to retrieve the policy being
+   applied by the LS and a PUT request to specify new rules.
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 22]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   Different policies may be applicable in different scenarios.  In
+   cases where an external RM is more trusted than the source of the LO,
+   the "RM Override" policy may be suitable (for example, if the
+   external RM is the Target and the LO is provided by a third party).
+   Conversely, the "LO Override" policy is better suited to cases where
+   the LO provider is more trusted than the RM, for example, if the RM
+   is the user of a mobile device LS and the LO contains Rules from the
+   RM's parents or corporate security office.  The "Intersection" policy
+   takes the strictest view of the permission grants, giving equal
+   weight to all RMs (including the LO creator).
+
+   Each of these policies will also have different privacy consequences.
+   Following the "Intersection" policy ensures that the most privacy-
+   protective subset of all RMs' rules will be followed.  The "Union"
+   policy and both "Override" policies may defy the expectations of any
+   RM (including, potentially, the Target) whose policy is not followed.
+   For example, if a Target acting as an RM sets Rules and those Rules
+   are overridden by the application of a more permissive LO Override
+   policy that has been set by the Target's parent or employer acting as
+   an RM, the retransmission or retention of the Target's data may come
+   as a surprise to the Target.  For this reason, it is RECOMMENDED that
+   LSes provide a way for RMs to be able to find out which policy will
+   be applied to the distribution of a given LO.
+
+4.2.5.  Security Considerations for Distribution
+
+   An LS's decisions about how to transmit a location are based on the
+   identities of entities requesting information and other aspects of
+   requests for a location.  In order to ensure that these decisions are
+   made properly, the LS needs assurance of the reliability of
+   information on the identities of the entities with which the LS
+   interacts (including LRs, LSes, and RMs) and other information in the
+   request.
+
+   Protocols to convey LOs and protocols to convey Rules MUST provide
+   information on the identity of the recipient of location information
+   and the identity of the RM, respectively.  In order to ensure the
+   validity of this information, these protocols MUST allow for mutual
+   authentication of both parties, and MUST provide integrity protection
+   for protocol messages.  These security features ensure that the LG
+   has sufficient information (and sufficiently reliable information) to
+   make privacy decisions.
+
+
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 23]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   As they travel through the Internet, LOs necessarily pass through a
+   sequence of intermediaries, ranging from layer-2 switches to IP
+   routers to application-layer proxies and gateways.  The ability of an
+   LS to protect privacy by making access control decisions is reduced
+   if these intermediaries have access to an LO as it travels between
+   privacy-preserving entities.
+
+   Ideally, LOs SHOULD be transmitted with confidentiality protection
+   end-to-end between an LS that transmits location information and the
+   LR that receives it.  In some cases, the protocol conveying an LO
+   provides confidentiality protection as a built-in security solution
+   for its signaling (and potentially its data traffic).  In this case,
+   carrying an unprotected LO within such an encrypted channel is
+   sufficient.  Many protocols, however, are offering communication
+   modes where messages are either unprotected or protected on a hop-by-
+   hop basis (for example, between intermediaries in a store-and-forward
+   protocol).  In such a case, it is RECOMMENDED that the protocol allow
+   for the use of encrypted LOs, or for the transmission of a reference
+   to a location in place of an LO [14].
+
+4.3.  Location Use
+
+   The primary privacy requirement of an LR is to constrain its usage of
+   location information to the set of uses authorized by the Rules in an
+   LO.  If an LR only uses an LO in ways that have minimal privacy
+   impact -- specifically, if it does not transmit the LO to any other
+   entity, and does not retain the LO for longer than is required to
+   complete its interaction with the LS -- then no further action is
+   necessary for the LR to comply with Geopriv requirements.
+
+   As an example of this simplest case, if an LR (a) receives a
+   location, (b) immediately provides to the Target information or a
+   service based on the location, (c) does not retain the information,
+   and (d) does not retransmit the location to any other entity, then
+   the LR will comply with any set of Rules that are permissible under
+   Geopriv.  Thus, a service that, for example, only provides directions
+   to the closest bookstore in response to an input of a location, and
+   promptly then discards the input location, will be in compliance with
+   any Geopriv Rule set.
+
+   LRs that make other uses of an LO (e.g., those that store LOs or send
+   them to other service providers to obtain location-based services)
+   MUST meet the requirements below to assure that these uses are
+   authorized.
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 24]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+4.3.1.  Privacy Considerations for Use
+
+   The principal privacy requirement for LRs is to follow usage rules.
+   Any LR that wants to retransmit or retain the LO is REQUIRED to
+   examine the rules included with that LO.  Any usage the LR makes of
+   the LO MUST be explicitly authorized by these Rules.  Since Rules are
+   positive grants of permission, any action not explicitly authorized
+   is denied by default.
+
+4.3.2.  Security Considerations for Use
+
+   Since the LR role does not involve transmission of location
+   information, there are no protocol security considerations required
+   to support privacy, other than ensuring that data does not leak
+   unintentionally due to security breaches.
+
+   Aside from privacy, LRs often require some assurance that an LO is
+   reliable (assurance of the integrity, authenticity, and validity of
+   an LO), since LRs use LOs in order to deliver location-based
+   services.  Threats against this reliability, and corresponding
+   mitigations, are discussed in "Security Considerations" below.
+
+5.  Security Considerations
+
+   Security considerations related to the privacy of LOs are discussed
+   throughout this document.  In this section, we summarize those
+   concerns and consider security risks not related to privacy.
+
+   The life cycle of an LO often consists of a series of location
+   transmissions.  Protocols that carry location information can provide
+   strong assurances, but only for a single segment of the LO's life
+   cycle.  In particular, a protocol can provide integrity protection
+   and confidentiality for the data exchanged, and mutual authentication
+   of the parties involved in the protocol, by using a secure transport
+   such as IPSec [17] or Transport Layer Security (TLS) [18].
+
+   Additionally, if (1) the protocol provides mutual authentication for
+   every segment, and (2) every entity in the location distribution
+   chain exchanges information only with entities with whom it has a
+   trust relationship, entities can transitively obtain assurances
+   regarding the origin and ultimate destination of the LO.  Of course,
+   direct assurances are always preferred over assurances requiring
+   transitive trust, since they require fewer assumptions.
+
+   Using protocol mechanisms alone, the entities can receive assurances
+   only about a single hop in the distribution chain.  For example,
+   suppose that an LR receives location information from an LS over an
+   integrity- and confidentiality-protected channel.  The LR knows that
+
+
+
+Barnes, et al.            Best Current Practice                [Page 25]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   the transmitted LO has not been modified or observed en route.
+   However, the assurances provided by the protocol do not guarantee
+   that the transmitted LO was not corrupted before it was sent to the
+   LS (by a previous LS, for example).  Likewise, the LR can verify that
+   the LO was transmitted by the LS, but cannot verify the origin of the
+   LO if it did not originate with the LS.
+
+   Security mechanisms in protocols are thus unable to provide direct
+   assurances over multiple transmissions of an LO.  However, the
+   transmission of a location "by reference" can be used to effectively
+   turn multi-hop paths into single-hop paths.  If the multiple
+   transmissions of an LO are replaced by multiple transmissions of a
+   URI (a multi-hop dissemination channel), the LO need only traverse a
+   single hop, namely the dereference transaction between the LR and the
+   dereference server.  The requirements for securing a location passed
+   by reference [14] are applicable in this case.
+
+   The major threats to the security of LOs can be grouped into two
+   categories.  First, threats against the integrity and authenticity of
+   LOs can expose entities that rely on LOs.  Second, threats against
+   the confidentiality of LOs can allow unauthorized access to location
+   information.
+
+   An LO contains four essential types of information: identifiers for
+   the described Target, location information, timestamps, and Rules.
+   By grouping values of these various types together within a single
+   structure, an LO encodes a set of bindings among them.  That is, the
+   LO asserts that the identified Target was present at the given
+   location at the given time and that the given Rules express the
+   Target's desired policy at that time for the distribution of his
+   location.  Below, we provide a description of the assurances required
+   by each party involved in the location distribution in order to
+   mitigate the possible attacks on these bindings.
+
+   Rule Maker:   The Rule Maker is responsible for creating the Target's
+      Privacy Rules and for uploading them to the LSes.  The primary
+      assurance required by the Rule Maker is that the Target's Privacy
+      Rules are correctly associated with the Target's identity when
+      they are conveyed to each LS that handles the LO.  Ensuring the
+      integrity of the Privacy Rules distributed to the LSes prevents
+      rule-tampering attacks.  In many circumstances, the privacy policy
+      of the Target may itself be sensitive information; in these cases,
+      the Rule Maker also requires the assurance that the binding
+      between the Target's identity and the Target's Privacy Rules are
+      not deducible by anyone other than an authorized LS.
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 26]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   Location Server:   The Location Server is responsible for enforcing
+      the Target's Privacy Rules.  The first assurance required by the
+      LS is that the binding between the Target's Privacy Rules and the
+      Target's identity is authentic.  Authenticating and authorizing
+      the Rule Maker who creates, updates, and deletes the Privacy Rules
+      prevents rule-tampering attacks.  The LS has to ensure that the
+      authorization policies are not exposed to third parties, if so
+      desired by the Rule Maker and when the rules themselves are
+      privacy-sensitive.
+
+   Location Recipient:   The Location Recipient is the consumer of the
+      LO.  The LR thus requires assurances about the authenticity of the
+      bindings between the Target's location, the Target's identity, and
+      the time.  Ensuring the authenticity of these bindings helps to
+      prevent various attacks, such as falsifying the location,
+      modifying the timestamp, faking the identity, and replaying LOs.
+
+   Location Generator:   The primary assurance required by the Location
+      Generator is that the LS to which the LO is initially published is
+      one that is trusted to enforce the Target's Privacy Rules.
+      Authenticating the trusted LS mitigates the risk of server
+      impersonation attacks.  Additionally, the LG is responsible for
+      the location determination process, which is also sensible from a
+      security perspective because wrong input provided by external
+      entities can lead to undesirable disclosure or access to location
+      information.
+
+   Assurances as to the integrity and confidentiality of a Location
+   Object can be provided directly through the LO format.  RFC 4119 [19]
+   provides a description for the usage of Secure/Multipurpose Internet
+   Mail Extensions (S/MIME) to integrity and confidentiality protection.
+   Although such direct, end-to-end assurances are desirable, and these
+   mechanisms should be used whenever possible, there are many
+   deployment scenarios where directly securing an LO is impractical.
+   For example, in some deployment scenarios a direct trust relationship
+   may not exist between the creator of the Location Object and the
+   recipient.  Additionally, in a scenario where many recipients are
+   authorized to receive a given LO, the creator of the LO cannot
+   guarantee end-to-end confidentiality without knowing precisely which
+   recipient will receive the LO.  Many of these cases can, however, be
+   addressed by the usage of a location-by-reference mechanism, possibly
+   combined with an LO.
+
+
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 27]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+6.  Example Scenarios
+
+   This section contains a set of examples of how the Geopriv
+   architecture can be deployed in practice.  These examples are meant
+   to illustrate key points of the architecture, rather than to form an
+   exhaustive set of use cases.
+
+   For convenience and clarity in these examples, we assume that the
+   Privacy Rules that an LO carries are equivalent to those in a
+   Presence Information Data Format Location Object (PIDF-LO) [19] --
+   namely, that the principal Rules that can be set are limits on the
+   retransmission and retention of the LO.  While these two Rules are
+   the most well-known and important examples, the specific types of
+   Rules an LS or LR must consider will in general depend on the types
+   of LOs it processes.
+
+6.1.  Minimal Scenario
+
+   One of the simplest scenarios in the Geopriv architecture is when a
+   Device determines its own location and uses that LO to request a
+   service (e.g., by including the LO in an HTTP POST request [20] or
+   SIP INVITE message [21]), and the server delivers that service
+   immediately (e.g., in a 200 OK response in HTTP or SIP), without
+   retaining or retransmitting the Device's location.  The Device acts
+   as an LG by using a Device-based positioning algorithm (e.g., manual
+   entry) and as an LS by interpreting the rule and transmitting the LO.
+   The Target acts as a Rule Maker by specifying that the location
+   should be sent to the server.  The server acts as an LR by receiving
+   and using the LO.
+
+   In this case, the privacy of location information is maintained in
+   two steps: The first step is that the location is only transmitted as
+   directed by the single Rule Maker, namely the Target.  The second
+   step is simply the fact that the server, as LR, does not do anything
+   that creates a privacy risk -- it does not retain or retransmit the
+   location.  Because the server limits its behavior in this way, it
+   does not need to read the Rules in the LO, even though they were
+   provided -- no Rule would prevent it from using the location in this
+   safe manner.
+
+   The following outline summarizes this scenario:
+
+   o  Positioning: Device-based, Device=LG
+
+   o  Distribution hop 1: HTTP User Agent (UA) --> Ephemeral Web
+      service, privacy via user indication
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 28]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   o  Use: Ephemeral Web service delivers response without retaining or
+      retransmitting location
+
+   o  Key point:
+
+      *  LRs that do not behave in ways that risk privacy are Geopriv-
+         compliant by default.  No further action is necessary.
+
+6.2.  Location-Based Web Services
+
+   Many location-based services are delivered over the Web, using
+   Javascript code to orchestrate a series of HTTP requests for
+   location-specific information.  To support these applications,
+   browser extensions have been developed that support Device-based
+   positioning (manual entry and Global Positioning System (GPS)) and
+   network-assisted positioning (via Assisted GPS (AGPS), and
+   multilateration with 802.11 and cellular signals), exposing a
+   location to Web pages through Javascript APIs.
+
+   In this scenario, we consider a Target that uses a browser with a
+   network-assisted positioning extension.  When the Target uses this
+   browser to request location-based services from a Web page, the
+   browser prompts the user to grant the page permission to access the
+   user's location.  If the user grants permission, the browser
+   extension sends 802.11 signal strength measurements to a positioning
+   server, which then returns the position of the host.  The extension
+   constructs an LO with this location and Rules set by the user, then
+   passes the LO to the page through its Javascript API.  The page then
+   obtains location-relevant information using an XMLHttpRequest [22] to
+   a server in the same domain as the page and renders this information
+   to the user.
+
+   At first blush, this scenario seems much more complicated than the
+   minimal scenario above.  However, most of the privacy considerations
+   are actually the same.
+
+   The positioning phase in this scenario begins when the browser
+   extension contacts the positioning server.  The positioning server
+   acts as an LG.
+
+   The distribution phase actually occurs entirely within the Target
+   host.  This phase begins when the positioning server, now acting as
+   an LS, follows the LCP policy by providing the location only to the
+   Target.  The next hop in distribution occurs when the browser
+   extension (an entity under the control of the Target) passes an LO to
+   the Web page (an entity under the control of its author).  In this
+   phase, the browser extension acts as an LS, with the Target as the
+   sole Rule Maker; the user interface for rule-making is effectively a
+
+
+
+Barnes, et al.            Best Current Practice                [Page 29]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   protocol for conveying Rules, and the extension's API effectively
+   defines a way to communicate LOs and an LO format.  The Web site acts
+   as an LR when the Web page accepts the LO.
+
+   The use phase encompasses the Web site's use of the LO.  In this
+   context, the phrase "Web site" encompasses not only the Web page, but
+   also the dedicated supporting logic behind it.  Considering the
+   entire Web site as a recipient, rather than a single page, it becomes
+   clear that sending the LO in an XMLHttpRequest to a back-end server
+   is like passing it to a separate component of the LR, as opposed to
+   retransmitting it to another entity.  Thus, even in this case, where
+   location-relevant information is obtained from a back-end server, the
+   LR does not retain or retransmit the location, so its behavior is
+   "privacy-safe" -- it doesn't need to interpret the Rules in the LO.
+
+   However, consider a variation on this scenario where the Web page
+   requests additional information (a map, for instance) from a third-
+   party site.  In this case, since location information is being
+   transmitted to a third party, the Web site (either in the Web page or
+   in a back-end server) would need to verify that this transmission is
+   allowed by the LO's Privacy Rules.  Similarly, if the site wanted to
+   log the user's location information, then it would need to examine
+   the LO to determine how long this information can be retained.  In
+   such a case, if the LR needs to do something that is not allowed by
+   the Rules, it may have to deny service to the user, while hopefully
+   providing a message with the reason.  Nonetheless, if the Rules
+   permit retention or retransmission, even if this retransmission is
+   limited by access control rules, then the LR may do so to the extent
+   the Rules allow.
+
+   The following outline summarizes this scenario:
+
+   o  Positioning: Network-assisted, positioning server=LG
+
+   o  Rule installation: RM (=Target) gives permission to sites and sets
+      LO Rules
+
+   o  Distribution hop 1: positioning server=LS --> Target, privacy via
+      LCP policy
+
+   o  Distribution hop 2: Browser=LS --> Web site=LR, privacy via user
+      confirmation
+
+   o  Use: Back-end server delivers location-relevant information
+      without further retransmission, then deletes location; privacy via
+      safe behavior
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 30]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   o  Key points:
+
+      *  Privacy in this scenario is provided by a combination of
+         explicit user direction and Rules in an LO.
+
+      *  Distribution can occur within a host, between components that
+         do not trust each other.
+
+      *  Some transmissions of the location are actually internal to
+         an LR.
+
+      *  LRs that do things that might be constrained by Rules need to
+         verify that these actions are allowed for a particular LO.
+
+6.3.  Emergency Calling
+
+   Support for emergency calls by Voice-over-IP devices is a critical
+   use case for location information about Internet hosts.  The details
+   of the Internet architecture for emergency calling are described in
+   [23] [24].  In this architecture, there are three critical steps in
+   the placement of an emergency call, each involving location
+   information:
+
+   1.  Determine the location of the caller.
+
+   2.  Determine the proper Public Safety Answering Point (PSAP) for the
+       caller's location.
+
+   3.  Send a SIP INVITE message, including the caller's location, to
+       the PSAP.
+
+   The first step in an emergency call is to determine the location of
+   the caller.  This step is the positioning phase of the location life
+   cycle.  The location is determined by whatever means are available to
+   the caller's device, or to the network, if this step is being done by
+   a proxy.  The entity doing the positioning, whether the caller or a
+   proxy, acts as an LS, preserving the privacy of location information
+   by only including it in emergency calls.
+
+   The second step in an emergency call encompasses location
+   distribution and use.  The entity that is routing the emergency call
+   sends location information through the Location-to-Service
+   Translation (LoST) Protocol [15] to a mapping server.  In this role,
+   the routing entity acts as an LS and the LoST server acts as an LR.
+   The LO format within LoST does not allow Rules to be sent along with
+   the location, but because LoST is an application-specific protocol,
+   the sending of the location within a LoST message authorizes the LoST
+   server to use the location to complete the protocol, namely to route
+
+
+
+Barnes, et al.            Best Current Practice                [Page 31]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   the message as necessary through the LoST mapping architecture [25].
+   That is, the LoST server is authorized to complete the LoST protocol,
+   but to do nothing else.
+
+   The third step in an emergency call is again a combination of
+   distribution and use.  The caller, or another entity that inserts the
+   caller's location, acts as an LS, and the PSAP acts as an LR.  In
+   this specific example, the caller's location is transmitted either as
+   a PIDF-LO or as a reference that returns a PIDF-LO, or both; in the
+   latter case, the reference should be appropriately protected so that
+   only the PSAP has access.  In any case, the receipt of an LO implies
+   that the PSAP should obey the Rules in those LOs in order to preserve
+   privacy.  Depending on the regulatory environment, the PSAP may have
+   the option to ignore those constraints in order to respond to an
+   emergency, or it may be bound to respect these Rules in spite of the
+   emergency situation.
+
+   The following outline summarizes this scenario:
+
+   o  Positioning: Any
+
+   o  Distribution/use hop 1: Target=LS --> LoST infrastructure (no
+      Rules), privacy via authorization implicit in protocol
+
+   o  Distribution/use hop 2: Target=LS --> PSAP, privacy via Rules
+      in LO
+
+   o  Use: PSAP uses location to deliver emergency services
+
+   o  Key points:
+
+      *  Privacy in this scenario is provided by a combination of
+         explicit user direction, implicit authorization particular to a
+         protocol, and Rules in an LO.
+
+      *  LRs may be constrained to respect or ignore Privacy Rules by
+         local regulation.
+
+6.4.  Combination of Services
+
+   In modern Internet applications, users frequently receive information
+   via one channel and broadcast it via another.  In this sense, both
+   users and channels (e.g., Web services) become LSes.  Here we
+   consider a more complex example that illustrates this pattern across
+   multiple logical hops.
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 32]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   Suppose Alice as the Target subscribes to a wireless ISP that
+   determines her location using a network-based positioning technique,
+   e.g., via the location of the base station serving the Target, and
+   provides that information directly to a location-enhanced presence
+   provider.  This presence provider might use SIP, the Extensible
+   Messaging and Presence Protocol (XMPP) [26], or another protocol).
+   The location-enhanced presence provider allows Alice to specify Rules
+   for how this location is distributed: which friends should receive
+   Alice's location and what Rules they should get with it.  Alice uses
+   a few other location-enhanced services as well, so she sends Rules
+   that allow her location to be shared with those services, and that
+   allow those services to retain and retransmit her location.
+
+   Bob is one of Alice's friends, and he receives her location via this
+   location-enhanced presence service.  Noting that she's at their
+   favorite coffee shop, Bob wants to upload a photo of the two of them
+   at the coffee shop to a photo-sharing site, along with an LO that
+   marks the location.  Bob checks the Rules in Alice's LO and verifies
+   that the photo-sharing site is one of the services that Alice
+   authorized.  Seeing that Alice has authorized him to give the LO to
+   the photo-sharing site, he attaches it to the photo and uploads it.
+
+   Once the geo-tagged photo is uploaded, the photo-sharing site reads
+   the Rules in the LO and verifies that the site is authorized to store
+   the photo and to share it with others.  Since Alice has allowed the
+   site to retransmit and retain without any constraints, the site
+   fulfills Bob's request to make the geo-tagged photo publicly
+   accessible.
+
+   Eve, another user of the photo-sharing site, downloads the photo of
+   Alice and Bob at the coffee shop and receives Alice's LO along with
+   it.  Eve posts the photo and location to her public page on a social
+   networking site without checking the Rules, even though the LO
+   doesn't allow Eve to send the location anywhere else.  The social
+   networking site, however, observes that no retransmission or
+   retention are allowed, both of which it needs for a public posting,
+   and rejects the upload.
+
+   In terms of the location life cycle, this scenario consists of a
+   positioning step, followed by four distribution hops and use.
+   Positioning is the simplest step: An LG in Alice's ISP monitors her
+   location and transmits it to the presence service, maintaining
+   privacy by only transmitting the location information to a single
+   entity to which Alice has delegated privacy responsibilities.
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 33]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   The first distribution hop occurs when the presence server sends the
+   location to Bob.  In this transaction, the presence server acts as an
+   LS, Alice acts as an RM, and Bob acts as an LR.  The privacy of this
+   transaction is assured by the fact that Alice has installed Rules on
+   the presence server that dictate who it may allow to access her
+   location.  The second distribution hop is when Bob uploads the LO to
+   the photo-sharing site.  Here Bob acts as an LS, preserving the
+   privacy of location information by verifying that the Rules in the LO
+   allow him to upload it.  The third distribution hop is when the
+   photo-sharing site sends the LO to Eve, likewise following the Rules
+   -- but a different set of Rules than for Bob, since an LO can specify
+   different Rule sets for different LSes.
+
+   Eve is the fourth LS in the chain, and fails to comply with Geopriv
+   by not checking the Rules in the LO prior to uploading the LO to the
+   social networking site.  The site, however, is a responsible LR -- it
+   checks the Rules in the LO, sees that they don't allow it to use the
+   location as it needs to, and discards the LO.
+
+   The following outline summarizes this scenario:
+
+   o  Positioning: Network-based, LG in network, privacy via exclusive
+      relationship with presence service
+
+   o  Distribution/use hop 1: Presence server --> Bob, privacy via
+      Alice's access control rules
+
+   o  Distribution/use hop 2: Bob --> photo-sharing site, privacy via
+      Rules for Bob in LO
+
+   o  Distribution/use hop 3: Photo-sharing site --> Eve, privacy via
+      Rules for site in LO
+
+   o  Distribution/use hop 4: Eve --> Social networking site, violates
+      privacy by retransmitting
+
+   o  Use: Social networking site, privacy via checking Rules and
+      discarding
+
+   o  Key points:
+
+      *  Privacy can be preserved through multiple hops.
+
+      *  An LO can specify different Rules for different entities.
+
+      *  An LS can still disobey the Rules, but even then, the
+         architecture still works in some cases.
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 34]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+7.  Glossary
+
+   Various security-related terms not defined here are to be understood
+   in the sense defined in RFC 4949 [27].
+
+   $ Access Control Rule
+
+      A rule that describes which entities may receive location
+      information and in what form.
+
+   $ civic location
+
+      The geographic position of an entity in terms of a postal address
+      or civic landmark.  Examples of such data are room number, street
+      number, street name, city, postal code, county, state, and
+      country.
+
+   $ Device
+
+      The physical device, such as a mobile phone, PC, or embedded
+      micro-controller, whose location is tracked as a proxy for the
+      location of a Target.
+
+   $ geodetic location
+
+      The geographic position of an entity in a particular coordinate
+      system, for example, a latitude-longitude pair.
+
+   $ Local Rule
+
+      A Privacy Rule that directs a Location Server about how to treat a
+      Target's location information.  Local Rules are used internally by
+      a Location Server to handle requests from Location Recipients.
+      They are not distributed to Location Recipients.
+
+   $ Location Generator (LG)
+
+      Performs the role of initially determining or gathering the
+      location of a Target.  Location Generators may be any sort of
+      software or hardware used to obtain a Target's location.  Examples
+      include GPS chips and cellular networks.
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 35]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   $ Location Information Server (LIS)
+
+      An entity responsible for providing devices within an access
+      network with information about their own locations.  A Location
+      Information Server uses knowledge of the access network and its
+      physical topology to generate and distribute location information
+      to devices.
+
+   $ Location Object (LO)
+
+      A data unit that conveys location information together with
+      Privacy Rules within the Geopriv architecture.  A Location Object
+      may convey geodetic location data (latitude, longitude, altitude),
+      civic location data (street, city, state, etc.), or both.
+
+   $ Location Recipient (LR)
+
+      An ultimate end-point entity to which a Location Object is
+      distributed.  Location Recipients request location information
+      about a particular Target from a Location Server.  If allowed by
+      the appropriate Privacy Rules, a Location Recipient will receive
+      Location Objects describing the Target's location from the
+      Location Server.
+
+   $ Location Server (LS)
+
+      An entity that receives Location Objects from Location Generators,
+      Privacy Rules from Rule Makers, and location requests from
+      Location Recipients.  A Location Server applies the appropriate
+      Privacy Rules to a Location Object received from a Location
+      Generator and may disclose the Location Object, in compliance with
+      the Rules, to Location Recipients.
+
+      Location Servers may not necessarily be "servers" in the
+      colloquial sense of hosts in remote data centers servicing
+      requests.  Rather, a Location Server can be any software or
+      hardware component that receives and distributes location
+      information.  Examples include a positioning server (with a
+      location interface) in an access network, a presence server, or
+      a Web browser or other software running on a Target's device.
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 36]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   $ Privacy Rule
+
+      A directive that regulates an entity's activities with respect to
+      a Target's location information, including the collection, use,
+      disclosure, and retention of the location information.  Privacy
+      Rules describe how location information may be used by an entity,
+      the level of detail with which location information may be
+      described to an entity, and the conditions under which location
+      information may be disclosed to an entity.  Privacy Rules are
+      communicated from Rule Makers to Location Servers and conveyed in
+      Location Objects throughout the Geopriv architecture.
+
+   $ Rule
+
+      See Privacy Rule.
+
+   $ Rule Maker (RM)
+
+      An individual or entity that is authorized to set Privacy Rules
+      for a Target.  In some cases, a Rule Maker and a Target will be
+      the same individual or entity, and in other cases they will be
+      separate.  For example, a parent may serve as the Rule Maker when
+      the Target is his child.  The Rule Maker is also not necessarily
+      the owner of a Target device.  For example, a corporation may own
+      a device that it provides to an employee but permit the employee
+      to serve as the Rule Maker and set her own Privacy Rules.  Rule
+      Makers provide the Privacy Rules associated with a Target to
+      Location Servers.
+
+   $ Forwarded Rule
+
+      A Privacy Rule that travels inside a Location Object.  Forwarded
+      Rules direct Location Recipients about how to handle the location
+      information they receive.  Because the Forwarded Rules themselves
+      may reveal potentially sensitive information about a Target, only
+      the minimal subset of Forwarded Rules necessary for a Location
+      Recipient to handle a Location Object is distributed to the
+      Location Recipient.
+
+   $ Target
+
+      An individual or other entity whose location is sought in the
+      Geopriv architecture.  In many cases, the Target will be the human
+      user of a Device, or it may be an object such as a vehicle or
+      shipping container to which a Device is attached.  In some
+      instances, the Target will be the Device itself.  The Target is
+      the entity whose privacy Geopriv seeks to protect.
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 37]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   $ Usage Rule
+
+      A rule that describes what uses of location information are
+      authorized.
+
+8.  Acknowledgements
+
+   Section 5 is largely based on the security investigations conducted
+   as part of the Geopriv Layer-7 Location Configuration Protocol design
+   team, which produced [9].  We would like to thank all the members of
+   the design team.
+
+   We would also like to thank Marc Linsner and Martin Thomson for their
+   contributions regarding terminology and LCPs.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+9.2.  Informative References
+
+   [2]   Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
+         Polk, "Geopriv Requirements", RFC 3693, February 2004.
+
+   [3]   Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
+         Analysis of the Geopriv Protocol", RFC 3694, February 2004.
+
+   [4]   U.S. Department of Defense, "National Industrial Security
+         Program Operating Manual", DoD 5220-22M, January 1995.
+
+   [5]   Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
+         Presence Information Data Format Location Object (PIDF-LO)
+         Usage Clarification, Considerations, and Recommendations",
+         RFC 5491, March 2009.
+
+   [6]   Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
+         J., and J. Rosenberg, "Common Policy: A Document Format for
+         Expressing Privacy Preferences", RFC 4745, February 2007.
+
+   [7]   Schulzrinne, H., Ed., Tschofenig, H., Ed., Morris, J., Cuellar,
+         J., and J. Polk, "Geolocation Policy: A Document Format for
+         Expressing Privacy Preferences for Location Information", Work
+         in Progress, March 2011.
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 38]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   [8]   Rosenberg, J., "The Extensible Markup Language (XML)
+         Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
+
+   [9]   Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
+         Configuration Protocol: Problem Statement and Requirements",
+         RFC 5687, March 2010.
+
+   [10]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
+         Configuration Protocol Option for Coordinate-based Location
+         Configuration Information", RFC 3825, July 2004.
+
+   [11]  Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
+         and DHCPv6) Option for Civic Addresses Configuration
+         Information", RFC 4776, November 2006.
+
+   [12]  Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and
+         IPv6 Option for a Location Uniform Resource Identifier (URI)",
+         Work in Progress, February 2011.
+
+   [13]  Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
+         RFC 5985, September 2010.
+
+   [14]  Marshall, R., Ed., "Requirements for a Location-by-Reference
+         Mechanism", RFC 5808, May 2010.
+
+   [15]  Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig,
+         "LoST: A Location-to-Service Translation Protocol", RFC 5222,
+         August 2008.
+
+   [16]  Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig,
+         "Location Configuration Extensions for Policy Management", Work
+         in Progress, June 2011.
+
+   [17]  Kent, S. and K. Seo, "Security Architecture for the Internet
+         Protocol", RFC 4301, December 2005.
+
+   [18]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+         Protocol Version 1.2", RFC 5246, August 2008.
+
+   [19]  Peterson, J., "A Presence-based GEOPRIV Location Object
+         Format", RFC 4119, December 2005.
+
+   [20]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
+         HTTP/1.1", RFC 2616, June 1999.
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 39]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   [21]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+         Session Initiation Protocol", RFC 3261, June 2002.
+
+   [22]  World Wide Web Consortium, "The XMLHttpRequest Object", W3C
+         document http://www.w3.org/TR/XMLHttpRequest/, August 2010.
+
+   [23]  Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework
+         for Emergency Calling Using Internet Multimedia", Work
+         in Progress, October 2010.
+
+   [24]  Rosen, B. and J. Polk, "Best Current Practice for
+         Communications Services in support of Emergency Calling", Work
+         in Progress, March 2011.
+
+   [25]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
+         Framework", RFC 5582, September 2009.
+
+   [26]  Saint-Andre, P., "Extensible Messaging and Presence Protocol
+         (XMPP): Core", RFC 6120, March 2011.
+
+   [27]  Shirey, R., "Internet Security Glossary, Version 2", FYI 36,
+         RFC 4949, August 2007.
+
+   [28]  <http://creativecommons.org/>
+
+Authors' Addresses
+
+   Richard Barnes
+   BBN Technologies
+   9861 Broken Land Pkwy, Suite 400
+   Columbia, MD  21046
+   USA
+
+   Phone: +1 410 290 6169
+   EMail: rbarnes@bbn.com
+
+
+   Matt Lepinski
+   BBN Technologies
+   10 Moulton St.
+   Cambridge, MA  02138
+   USA
+
+   Phone: +1 617 873 5939
+   EMail: mlepinski@bbn.com
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 40]
+
+RFC 6280             Internet Location Architecture            July 2011
+
+
+   Alissa Cooper
+   Center for Democracy & Technology
+   1634 I Street NW, Suite 1100
+   Washington, DC
+   USA
+
+   EMail: acooper@cdt.org
+
+
+   John Morris
+   Center for Democracy & Technology
+   1634 I Street NW, Suite 1100
+   Washington, DC
+   USA
+
+   EMail: jmorris@cdt.org
+
+
+   Hannes Tschofenig
+   Nokia Siemens Networks
+   Linnoitustie 6
+   Espoo  02600
+   Finland
+
+   Phone: +358 (50) 4871445
+   EMail: Hannes.Tschofenig@gmx.net
+   URI:   http://www.tschofenig.priv.at
+
+
+   Henning Schulzrinne
+   Columbia University
+   Department of Computer Science
+   450 Computer Science Building
+   New York, NY  10027
+   US
+
+   Phone: +1 212 939 7004
+   EMail: hgs@cs.columbia.edu
+   URI:   http://www.cs.columbia.edu
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.            Best Current Practice                [Page 41]
+