RFC 6280
An Architecture for Location and Location Privacy in Internet Applications
RFC 6280 is a Best Current Practice (BCP 160 🌸, ISSN 2070-1721) from the IETF, published July 2011. Its authors are R. Barnes and M. Lepinski (BBN Technologies), A. Cooper and J. Morris (Center for Democracy & Technology), H. Tschofenig (Nokia Siemens Networks), and H. Schulzrinne (Columbia University) 🧚. It updates RFC 3693 and RFC 3694. The header doesn't list anything it obsoletes, so nothing gets replaced 💅
An Architecture for Location and Location Privacy in Internet Applications 🦋
Abstract
Okay so location-based services are everywhere now 🗺️ Navigation apps, emergency services, and tools for managing equipment out in the field all need geographic location info about Internet hosts, their users, and other related entities. These apps have to gather and transfer that location info securely, and they also have to protect the privacy of the people involved 😭 This document lays out an architecture for privacy-preserving location-based services on the Internet. It focuses on the authorization, security, and privacy requirements for the data formats and protocols these services use 💜
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). More info on BCPs is in Section 2 of RFC 5741 ✨
For info on the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6280 🎀
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.
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 ....................................381. Introduction ✨
Location-based services (apps that need info about where an individual or device is) are getting more and more common on the Internet 🌍 Navigation and directions, emergency services, friend finders, managing equipment in the field, and tons of other apps all need geographic location info about Internet hosts, their users, and other related entities. As location accuracy gets better and it gets cheaper to calculate and obtain, location info will probably become even more pervasive in Internet-based services. So it's essential that location info is sent and accessed in a secure and privacy-protective way. That's key for these services to succeed, and it also cuts down on the privacy harms that could come from wide deployment and use 🫶
Standards for sending location info over the Internet have a big job, because they give us a technical basis for privacy and security protection 🔐 This document describes a standardized, privacy- and security-focused architecture for location-based services on the Internet, called the Geopriv architecture 💅 Its central piece is the location object. A location object carries both location info about an individual or device and the user-specified privacy rules that govern that info. As location info 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. It also makes sure location info is only sent in compliance with the user's privacy rules 👑
This doc has two goals 🎀 First, the architecture revises and expands on the basic Geopriv Requirements [2] [3]. It clarifies how those privacy concerns and the Geopriv architecture apply to use cases that have come up since those documents were published. Second, it gives a general intro to Geopriv and Internet location-based services, so it's a good first read if you're new to Geopriv 🌸
1.1. Binding Rules to Data 🔗
Okay this is the core idea of Geopriv: location info is always bound to privacy rules 🙌 That way, any entity that receives location info knows how it's allowed to use it. The rules can be simple directives ("do not share my location with others"), or more detailed 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 putting the user's preferences into a structure that travels with the location info, the chance those preferences get honored goes way up. Like, no recipient of the location info can pretend they didn't know about users' preferences for how their location may be used 💀 Binding privacy rules to location info also shows users' desire for and expectations of privacy, which helps social and legal systems protect those expectations 🦋
Binding usage rules to sensitive info is a common way to protect info. Several emerging schemes for expressing copyright info let rules travel together with copyrighted works. The Creative Commons [28] model is the most famous example. It lets a work's owner set four types of rules ("Attribution", "Noncommercial", "No Derivative Works", and "ShareAlike") that govern how the work is used later. Once the author sets those rules, they're shipped along with the work itself, so every recipient knows the copyright terms 📚
Classification systems for controlling sensitive documents inside an organization work the same way 🗂️ When a document is created, it gets a marking like "SECRET" or "PROPRIETARY". From that marking, each recipient knows the document should only be shared with people who are authorized to access documents with that marking. Classification markings can also carry other kinds of rules, like how long the marking stays valid (a declassification date) ⏳ The United States Department of Defense guidelines for classification [4] are one example.
1.2. Location-Specific Privacy Risks 🚨
Location-based services do raise some privacy concerns that show up with all personal info. But a lot of those concerns get heightened, and some are unique to location info 😭
Location info is often generated on or by mobile devices. People usually carry their phones and other mobile devices everywhere, so location data can be collected everywhere and at any time, often without the user doing anything 📱 It can reveal both what a person is doing and where they're doing it. For example, location data can reveal that someone was at a particular medical clinic at a particular time 🩺 Because location info is so everywhere, the risks of stalking and domestic violence can go up too, if perpetrators are able to use (or abuse) location-based services to get location info about their victims 🙈
Governments and law enforcers around the world are also really interested in location info 👀 Detailed records of people's movements should not automatically make it easy for governments to track their citizens. But in some jurisdictions, the laws that say what government agents must do to get location data are either non-existent or out of date ⚖️
1.3. Privacy Paradigms 🎀
Okay so traditionally, the privacy you get for your data online has mostly been decided by whoever receives it. 😭 Internet users might know what a company does with their data, or might not. Even when they do know, the choice has usually been all or nothing: share it with that entity, or don't. Users have almost never gotten to tell recipients what their own privacy preferences are and have those preferences actually respected. 💅
This is so problematic bestie, because the recipient's interests and the data subject's interests often don't line up. 🙈 Both sides might agree that data should be collected, used, disclosed, and retained as needed to deliver a particular service to the data subject. But they may disagree about everything else. For example, an Internet user might happily give his email address on a Web site to get a newsletter, but he might not want that site sharing his address with marketers, and the site might make money from doing exactly that. Giving the address for both purposes is not the best option from the user's point of view, and neither is refusing to give it at all. 💀
Geopriv breaks away from this paradigm. As explained above, location information can be uniquely sensitive. ✨ At the same time, location-based services keep popping up everywhere, and they increasingly need standard protocols for passing location information between services and entities. Geopriv recognizes both of these things, so instead of letting the recipients of the information decide how it will be used, it lets data subjects express their choices about their own location information. 🦋 The mix of higher privacy risk and the need for standardization pushed the Geopriv designers to move away from the usual Internet privacy model and empower users to express their privacy preferences about how their location information is used. 👑
Geopriv does not, by itself, provide technical means that can guarantee users' location privacy rules will be honored by recipients. 🥺 The privacy protections in the Geopriv architecture mostly come from the fact that recipients of location information are told about the relevant privacy rules and are expected to only use location information in accordance with those rules. The distributed nature of the architecture inherently limits how far compliance can be guaranteed and verified by technical means. Section 5 describes how some security mechanisms can address this to a limited extent. 🧚
That said, by binding privacy rules to location information, Geopriv gives valuable information about users' privacy preferences, so non-technical forces such as legal contracts, governmental consumer protection authorities, and marketplace feedback can do a better job enforcing those preferences. 🫶 If a commercial recipient of location information, for example, violates the location rules bound to the information, then in a growing number of countries that recipient can be charged with violating consumer or data protection laws. Without binding rules to location information, consumer protection authorities would have a much harder time protecting 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 rest of this document, capitalized terms defined in Section 7 refer to Geopriv-specific roles and formats, and the same terms written in all lowercase refer generically to those terms. 🌈
3. Overview of the Architecture 🗺️
This section gives you an overview of the Geopriv architecture for the secure and private distribution of location information on the Internet. ✨ We walk through the three phases of the "location life cycle" -- positioning, distribution, and use -- and talk about how the components of the architecture fit into each phase. The next section goes deeper into how each phase can be achieved in a private and secure way. 💖
The risks discussed in the previous section all come from unauthorized disclosure or use of location information. So the Geopriv architecture has two fundamental privacy goals: 🎯
- Ensure that location information is distributed only to authorized entities, and
- Provide information to those entities about how they are authorized to use the location information.
If both of these goals are met, every party that receives location information will also receive directives about how it can use that information. Privacy-preserving entities will only engage in authorized uses, and entities that violate privacy will do so knowingly, since they were told what is authorized (and so, implicitly, what is not). 😤
Privacy rules and their distribution are therefore the central technical components of the privacy system, because they tell location recipients how they are authorized to use that information. The two goals above are made possible by two classes of rules: 💜
- Access control rules: Rules that describe which entities may receive location information and in what form
- Usage rules: Rules that describe what uses of location information are authorized
Inside this privacy framework, security mechanisms support 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 go beyond privacy, for example, by assuring location recipients that location information was faithfully transmitted to them by its creator. 🔐
3.1. Basic Geopriv Scenario 🫧
As location information moves among Internet hosts, it goes through a "location life cycle": first the location is computed from some external information (positioning), then it is transmitted from one host to another (distribution), and finally it is used by a recipient (use). 🔄
Let's use an example. Suppose Alice is using a mobile device, she learns her location from a wireless location service, and she wants to share her location privately with her friends through a presence service. 📱 Alice clearly needs to give the presence server her location and rules about which friends can be given her location. To let Alice's friends preserve her privacy, they also need to be given 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 gives them her location. This way, every friend who receives Alice's location has been 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 can't claim he didn't know the rules. 😌
Some of Alice's friends will want to use Alice's location only for their own purposes, for example, to meet up with her or to plot her location over time. The usage rules they receive tell them what they can and cannot do (for example, Alice might not want them keeping her location for more than, say, two weeks). ⏳
Now consider one friend, Bob, who wants to send Alice's location to some of his own 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, plus rules to give to those recipients. If the rules he got from the presence server authorize him to pass Alice's location on 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 get Alice's location from Bob want to distribute it further, they must go through the same process as Bob. 🔁
Here's the whole example 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 🌸
3.2. Roles and Data Formats ✨
okay so the example above shows off the six basic roles in the Geopriv architecture 💅 let's go through them bestie!
- Target: An individual or other entity whose location is sought in the Geopriv architecture. In many cases the Target is the human user of a Device, but it can also be an object like a vehicle or shipping container that a Device is attached to. Sometimes the Target is the Device itself 🧚 The Target is the entity whose privacy Geopriv is trying to protect. Alice is the Target in Figure 1.
- Device: The physical device, like a mobile phone, PC, or embedded micro-controller, whose location gets tracked as a stand-in for the location of a Target. Alice's mobile phone is the Device in Figure 1 📱
- Rule Maker (RM): The one who creates the rules that control who gets access to location information for a Target. Sometimes the Target is also the Rule Maker (like Alice), and sometimes they're different people. For example, a parent might be the Rule Maker when the Target is their child, or a corporate security officer might be the Rule Maker for devices the company owns but employees use. The Rule Maker also isn't necessarily the owner of the Device 👀 like, a corporation might give an employee a Device but let her be the Rule Maker and set her own privacy rules. main character behavior 💅
- Location Generator (LG): The one who figures out the location of the Device at the start and passes it along to Location Servers. A Location Generator can be any software or hardware used to get the Device's location, like Global Positioning System (GPS) chips and cellular networks 🛰️ A Device can even be its own Location Generator! Devices that can do satellite-based positioning on their own, and Devices that accept manually entered location info, are two examples. The wireless location service is the Location Generator in Figure 1.
- Location Server (LS): The one who receives location information and rules, applies the rules to that location information to decide what other entities (if any) can receive it, and then provides the location to Location Recipients. Location Servers get location information from Location Generators and rules from Rule Makers, then apply the rules. Now, these don't have to be "servers" in the colloquial sense of hosts in remote data centers answering requests 🙈 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 example above has three Location Servers: Alice's mobile phone, the presence service, and Bob's PC.
- Location Recipient (LR): The one who receives location information. A Location Recipient can ask for a location explicitly (by sending a query to a Location Server), or it can 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. Figure 1 shows this, since many of its entities perform multiple roles 🌈 It's super common for the same entity to be both the Location Generator and the Location Server, or both the Location Recipient and the Location Server. One entity can take on multiple roles just based on its own capabilities and the permissions it's been given.
Even though the example only has a single Location Generator and a single Rule Maker, a Location Server can receive Location Objects from multiple Location Generators or Rules from multiple Rule Makers. Likewise, one Location Generator can publish location information to multiple Location Servers, and one Location Recipient can receive Location Objects from multiple Location Servers 🫶
There's a close relationship between a Target and its Device 💖 The term "Device" is used when we're talking about protocol interactions, while "Target" is used when we're talking generically about the person or object being located and their privacy. In the example, the Target and the Device have a one-to-one relationship, but Geopriv can also be used to convey location information about a device that isn't directly linked to a single individual or object, like a Device shared by multiple individuals 👑
Two data formats are necessary in 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 can be 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.
- Privacy Rule: A directive that regulates an entity's activities with respect to location information, including the collection, use, disclosure, and retention of that location information. Privacy Rules describe which entities may obtain location information in what form (access control rules) and how an entity may use location information (usage rules) 🔒
Here's the whole example, using Geopriv roles and formats, in one picture ✨
+----+
| LG |
+----+
^
|
Positioning
Data
|
| +------------Privacy Rules------------------>+----+
| | +---->| LR |--> ...
| | | | LS |
v | | +----+
+-------+ |
|Target | +----+ | +----+
|Device |--------------->| LR |---------------+---->| LR |
| RM | LO | LS | LO | +----+
| LS | +----+ |
+-------+ |
| +----+
+---->| LR |
+----+
Figure 2: Basic Geopriv Scenario4. The Location Life Cycle ✨
okay so the last section showed how one person's location can get passed around the Internet 🌸 Generally, the location life cycle breaks down into three phases:
- Positioning: A Location Generator figures out the Device's location.
- Distribution: Location Servers send location information to Location Recipients, and those Location Recipients can act as Location Servers themselves and pass the location along to other Location Recipients, maybe several times 🔁
- Use: A Location Recipient gets the location and uses it.
Each of these phases involves a different set of Geopriv roles, and each has its own privacy and security implications 🙈 The Geopriv roles get mapped onto the 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 Cycle4.1. Positioning 🧭
Positioning is the process of computing the physical location of the Device based on some observations about the Device's situation in the physical world. (This process also goes by other names, like Location Determination or Sighting.) The input to positioning is some information about the Device, and the result is that the LG knows where the Device is 💜
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 ✨
4.1.1. Determination Mechanisms and Protocols ✨
okay so the exact positioning tricks a Device can use totally depend on its physical situation and what it's capable of 💅 but they generally fall into three buckets:
- Device-based
- Network-based
- Network-assisted
As the names kinda spoil, a positioning scheme can rely on the Device, on an Internet-accessible resource (which doesn't have to be a network operator 👀), or on a combo of both. For any given scheme, the nature of that reliance decides which protocol mechanisms it needs 🧚
With Device-based positioning, the Device can figure out where it is all by itself 🫶 That's the case for a manually entered location, or for (unassisted) satellite-based positioning using a Global Navigation Satellite System (GNSS). Here the Device acts as its own LG, and there are no protocols needed to support positioning beyond the ones that carry the positioning data from the satellite to the user 🛰️
Network-based schemes are a different vibe 🌸 An external LG (an Internet host other than the Device) has enough info about the Device, through out-of-band channels, to pin down its position. The most common LGs here are entities with a physical relationship to the Device, like ISPs. In wired networks, wiremap-based location is a network-based technique. In wireless networks, timing and signal-strength techniques that use measurements from base stations count as network-based too. Large-scale IP-to-geo databases (for example, ones based on WHOIS data or latency measurements) are also considered network-based positioning mechanisms 🗺️
For network-based positioning, just like Device-based, no protocols for communication between the Device and the LG are strictly necessary to support positioning, since the positioning info is collected outside of the location distribution system (at lower layers of the network stack, for example). That doesn't rule out other Internet protocols (like the Simple Network Management Protocol (SNMP)) being used to collect inputs to the positioning process 🙌 But since those inputs can only be used by certain LGs to work out a location, they aren't controlled as private information. Network-based positioning often hands location info to protocols where the network tells a Device where it is itself. These are known as Location Configuration Protocols; see Section 4.2.2 for further discussion 🎀
Network-assisted systems have the greatest number and diversity of positioning schemes, lowkey the most chaotic 🌈 Here the work of positioning gets split between the Device and an external LG through some communication (possibly over the Internet), typically in one of two ways:
- The Device provides measurements to the LG, or
- The LG provides assistance data to the Device.
"Measurements" are 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: the positioning info that makes it possible to compute a location from those measurements. A set of wireless base station locations (or wireless calibration information) would be an assistance datum, and so would a table that maps routers to buildings on a corporate campus 🏢
For example, wireless and wired networks can both be 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 sends a location back to the client 💖 In wired networks, the Device can send its MAC address to the LG, which can query the MAC-layer infrastructure to find the switch and port that MAC address is connected to, then query a wire map to find the location where the wire connected to that port terminates 🔌
As an aside (iykyk 🙈), the common phrase "assisted GPS" ("assisted GNSS" more broadly) actually covers techniques that transmit both measurements and assistance data. Systems where the Device gives the LG GNSS measurements are measurement-based, while systems where the assistance server provides ephemeris or almanac data are assistance-based in the terminology above. (If you're into GNSS positioning, you'll notice that there are of course cases where both of these interactions happen within a single location determination protocol, so the categories aren't mutually exclusive 🤓)
Naturally, the exchange of measurement or positioning data between the Device and the LG needs a protocol to carry the info. The structure of that protocol depends on which of the two patterns a network-assisted scheme follows 🧩 And the other way around: the structure of the protocol decides which of the two parties (the Device, the LG, or both) knows the Device's location at the end of the protocol interaction 👑
4.1.2. Privacy Considerations for Positioning
Positioning is the first point where location can be associated with a particular Device and possibly with the Target's identity, so this is a big moment 😭 Local identifiers, unlinked pseudonyms, or private identifiers that aren't linked to the Target's real identity should be used as forms of identity whenever possible. This gives privacy protection by disconnecting the location from the Target's identity before it gets distributed 🦋
At the end 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 the 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 deployments, positioning functions and distribution functions may need to be provided by separate entities, so the LG and LS roles won't 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 needed to support distribution (possibly with multiple LSes using the same LG) 🧠 To let the privacy-unaware LG distribute location information to these LSes while still keeping privacy, the relationship between the LG and its set of LSes MUST be tightly constrained (effectively "hard-wired") 🔒 That means 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. No wiggle room, bestie 🚫
4.1.3. Security Considerations for Positioning
Messing with the positioning process can expose location information in two ways, and both are giving danger 💀
- A third party could guess or derive measurements about a specific device and use them to get that Device's location. 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 depend on the type of positioning being done, and they may not be technically feasible in all cases 🕵️♀️
- By eavesdropping, a third party may be able to obtain measurements sent by the Device itself that indicate its rough position. 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 it's 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. Main character energy, but with homework 📚
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 kind of two-fold 👯 First, it has to 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 those requests, so it can determine whether it's authorized to fulfill them by returning location information 🫶
An LS has at least two types of interactions with other hosts, namely receiving and sending LOs ✨ An LS may optionally implement a third interaction, which allows Rule Makers to provision it with Rules. The distinction between these cases really matters in practice, because it decides whether the LS has a direct relationship with a Rule Maker. An LS that accepts Rules directly from a Rule Maker has that relationship, while an LS that acquires all its Rules through LOs does not 🌷
4.2.1. Privacy Rules ✨
okay so Privacy Rules are literally the main character of Geopriv 💅 They're how the Target's privacy actually stays protected, because they tell whoever gets an LO (an LS or an LR) how that location info is allowed to be used. no cap, it's the whole vibe.
All through the Geopriv architecture, Privacy Rules get written in rules languages with a defined syntax and semantics. For example, the Common Policy rules language was defined in [6] as a framework for broad-based rule specs 📜. Geopriv Policy [7] is the language for location-specific rules 🗺️. And the XML Configuration Access Protocol (XCAP) [8] can be used to install rules in either of these formats 🎀.
Privacy Rules follow a default-deny pattern 🔒. An empty set of Rules means every request for location information should be denied, except requests the Target makes for its own location 🫶. Each Rule adds to the set and grants one specific permission. Adding a Rule can only make privacy stronger, because every Rule is a positive grant of permission. so no sneaky loopholes 🙌
Here are some examples of Privacy Rules for location distribution:
- Retransmit location information when requested from example.com.
- Retransmit only city and country.
- Retransmit location information with no less than a 100-meter radius of uncertainty.
- Retransmit location information only for the next two weeks.
LSes enforce Privacy Rules in two ways: they either deny the request for location information, or they transform the location information before retransmitting it 🦋
LSes can also get Rules about location retention, like "Retain location only for 48 hours". These are just directives about how long the Target's location information can be kept ⏳
Privacy Rules can control what both LSes and LRs do 👑. Rules that tell an LS how to treat a Target's location information are called Local Rules. The LS uses Local Rules internally to handle requests from LRs, and they are not distributed to LRs. they stay home 🏠
Forwarded Rules are different 💜. They travel inside LOs and tell LSes and LRs how to handle the location information they receive. Since the Rules themselves can reveal sensitive stuff about the Target, only the minimal subset of Forwarded Rules needed to handle the LO gets distributed 🤫
Let's look at an example of how Local Rules and Forwarded Rules work together 🍓. Say Alice gives an LS these Local Rules:
- The LS may retransmit Alice's precise location to Bob, who in turn is permitted to retain the location information for one month.
- 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.
- 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 send Steve the limited location information (city, state, and country) along with Forwarded Rules telling Steve to (a) not further retransmit Alice's location information, and (b) only retain the location information for one hour. By sending Steve only these specifically applicable Forwarded Rules (and not the full set of Local Rules), the LS protects Alice's privacy 🫣 Steve never finds out, for example, that Alice lets Bob get more precise location information than she lets Steve receive. Keeping that private is the whole point 💖
Geopriv is designed to be usable even by devices with constrained processing capabilities 🧚. So 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 can contain a pointer to more robust Rules, like the set of four Rules at the beginning of this section 🌈
4.2.2. Location Configuration 🎀
Some entities doing the LG role are designed only to give Targets their own locations, rather than passing a Target's location on to others. In Geopriv, the process of giving a Target its own location is called Location Configuration 🗺️ The term "Location Information Server" (LIS) is often used for the entity that does this job. However, a LIS can also do other things, like giving a Target's location to other entities 💅
A Location Configuration Protocol (LCP) [9] is one way a Device can discover its own location from a LIS 📍 LCPs define how location requests and responses get obtained, transported, and delivered between a LIS and a Device, so the LIS can trust that the requests and responses handled via the LCP really are from or to the Target 🔐. Several LCPs have been developed within Geopriv [10] [11] [12] [13] 🦋
A LIS whose only purpose is Location Configuration just needs a simple privacy-preserving policy: send a Target's location only to the Target itself 🫶. This is called the "LCP policy".
Here's the important bit 🚨: if an LS is also acting as an LG and it hasn't been given Privacy Rules for a particular Target, it MUST follow the LCP policy, whether or not it is a LIS. During positioning, an entity doing both the LG and LS roles that has not received Privacy Rules must follow this policy too. The same goes for any LS in the distribution phase 💀
4.2.3. Location References 🌸
Location distribution happens through a series of LO transmissions, meaning location "by value" 💌. Location "by value" can be written as geodetic location data (latitude, longitude, altitude, etc.) or civic location data (street, city, state, etc.) 🍓
A location can also be distributed "by reference" 🔗. A reference is a URI that can be dereferenced to get the LO. This document summarizes the properties of location-by-reference that are discussed at length in [14], so go check there if you want the full tea ☕
Distributing location-by-reference (distributing location URIs) has a bunch of perks ✨. Location URIs are a more compact way to send location info, since URIs are usually smaller than LOs 🧚. If the URI is set up to give a fresh location instead of a single "snapshot", a recipient can make multiple requests to it over time to get updated location info 🔄
From a positioning point of view, location-by-reference can offer the extra benefit of "just in time" positioning ⏰. If a location is distributed by reference, an entity acting as a combined LG/LS only needs to do positioning operations when a recipient dereferences a previously distributed URI 🙌
From a privacy point of view, sending a location as a URI instead of as an LO can help protect privacy 🛡️. It forces each recipient to request the location from the referenced LS, and the LS can then apply access controls to each recipient individually. But this benefit only works if the LS actually applies access controls 🫣. If the LS doesn't apply an access control policy to requests for a location URI (in other words, if it enforces the "possession model" defined in [14]), then sending a location URI carries the same privacy risks as sending the LO itself 😭
It gets worse, though 💀. Using location URIs without access controls can add extra privacy risks. If URIs are predictable, an attacker who was never sent the URI might be able to guess it and use it to get the referenced LO. To prevent this, location URIs without access controls need to be built so they contain a random component with enough entropy to make guessing infeasible 🔐🌈
4.2.4. Privacy Considerations for Distribution ✨
Okay bestie, the distribution journey is giving "Rules ride along with the location, always" 💖. Location information MUST be accompanied by Rules throughout the distribution process. Otherwise, a recipient won't know what uses are authorized and won't be able to use the LO 💀. So LOs MUST be able to express Rules that convey appropriate authorizations 🎀.
An LS MUST only accept Rules from authorized Rule Makers 👑. If an LS gets Rules exclusively in LOs and has no direct relationship with a Rule Maker, this is handled by applying the Rules provided in an LO to the distribution of that LO. If an LS does have a direct relationship with a Rule Maker, 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 show up at 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. It MUST also 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 so it knows how it may use that 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, if it's in a format with no Rules syntax), then the LS MUST delete it 🗑️. Emergency services get an exception, since Rules can be implicit there; 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 the Rules it has received from the RMs. The strategy for combining these sets of Rules is a matter for local policy, depending on the relative priority the LS gives 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. In other words, the default is to deny access, and rules specify the conditions under which access is allowed 🙅♀️. So when an LS is given more than one policy document that applies to a given LO, it has been told to provide access when any of the rules apply. That means the "Union" policy is the default 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 stricter kind 🥀.
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 the LS is applying, and a PUT request to specify new rules 📬.
Different policies may be applicable in different scenarios 🌈. When an external RM is more trusted than the source of the LO, the "RM Override" policy may be a good fit (for example, if the external RM is the Target and the LO is provided by a third party) 🦋. On the flip side, the "LO Override" policy suits cases where the LO provider is more trusted than the RM. For example, the RM might be 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 comes with its own privacy consequences 😬. Following the "Intersection" policy ensures that the most privacy-protective subset of all RMs' rules is followed. The "Union" policy and both "Override" policies may go against the expectations of any RM (including, potentially, the Target) whose policy isn't followed. For example, say a Target acting as an RM sets Rules, and those Rules get overridden by a more permissive LO Override policy set by the Target's parent or employer acting as an RM. Then the retransmission or retention of the Target's data may come as a total surprise to the Target 😱. For this reason, it is RECOMMENDED that LSes provide a way for RMs 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 the entities requesting information, along with other aspects of requests for a location. To make sure those decisions are made properly, the LS needs assurance that the information about the identities of the entities it interacts with (including LRs, LSes, and RMs), and the other information in the request, is reliable 🕵️♀️.
Protocols that convey LOs and protocols that convey Rules MUST provide information on the identity of the recipient of location information and the identity of the RM, respectively. To make sure this information is valid, these protocols MUST allow for mutual authentication of both parties, and MUST provide integrity protection for protocol messages. These security features make sure the LG has enough information (and reliable enough information) to make privacy decisions 🛡️.
As they travel across the Internet, LOs necessarily pass through a chain of intermediaries, ranging from layer-2 switches to IP routers to application-layer proxies and gateways 🌐. An LS's ability to protect privacy through access control decisions is weakened if these intermediaries can see 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 carrying an LO provides confidentiality protection as a built-in security solution for its signaling (and potentially its data traffic). In that case, carrying an unprotected LO inside such an encrypted channel is sufficient ✅. However, many protocols offer 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 limit 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 with minimal privacy impact (specifically, if it doesn't transmit the LO to any other entity, and doesn't retain the LO for longer than it needs to finish its interaction with the LS), then no further action is needed for the LR to comply with Geopriv requirements 🌸.
Here's the simplest case. Say an LR (a) receives a location, (b) immediately provides the Target with information or a service based on that location, (c) doesn't retain the information, and (d) doesn't retransmit the location to any other entity. Then the LR will comply with any set of Rules that are permissible under Geopriv 🙌. So a service that only provides directions to the closest bookstore in response to an input location, and promptly discards that input location, will be in compliance with any Geopriv Rule set 📚.
LRs that make other uses of an LO (e.g., ones that store LOs or send them to other service providers to get location-based services) MUST meet the requirements below to make sure these uses are authorized 💅.
4.3.1. Privacy Considerations for Use 🫧
The main 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 that isn't explicitly authorized is denied by default 🚫.
4.3.2. Security Considerations for Use 🛠️
Since the LR role doesn't involve transmitting location information, there are no protocol security considerations required to support privacy, other than making sure data doesn't leak unintentionally due to security breaches 🙈.
Aside from privacy, LRs often need some assurance that an LO is reliable (assurance of the integrity, authenticity, and validity of an LO), since LRs use LOs to deliver location-based services 💖. The threats against this reliability, and the corresponding mitigations, are discussed in "Security Considerations" below 🧚.
5. Security Considerations 🔐✨
okay bestie, the privacy stuff for LOs (location objects) is all over this doc already 🫶 so in this section we're gathering those worries in one place and also looking at security risks that aren't really about privacy. let's go 💅
The life cycle of an LO is usually a bunch of location transmissions passed along 🦋 Protocols that carry location info can give you strong assurances, but only for ONE segment of that life cycle 😭 Like, a protocol can give you integrity protection and confidentiality for the data being exchanged, plus mutual authentication of everyone in the protocol, by running over a secure transport such as IPSec [17] or Transport Layer Security (TLS) [18]. Iconic 👑
It gets extra good if (1) the protocol does mutual authentication on every segment, AND (2) every entity in the distribution chain only talks to entities it has a trust relationship with. Then entities can transitively get assurances about where the LO came from and where it's ultimately going 🧚 Direct assurances are always the better move though, because they need fewer assumptions 💖
Protocol mechanisms alone only get you assurances about a single hop in the distribution chain 🌸 Say an LR gets location info from an LS over an integrity- and confidentiality-protected channel. The LR knows the LO wasn't modified or peeked at en route. BUT the protocol can't guarantee the LO wasn't corrupted before it reached the LS (by a previous LS, for example) 🙈 And the LR can verify the LO came from the LS, but it can't verify where the LO originally came from if it didn't start with the LS. Not ideal, not me.
So yeah, security mechanisms in protocols can't give you direct assurances across multiple transmissions of an LO. BUT here's the plot twist ✨ sending a location "by reference" can effectively turn multi-hop paths into single-hop paths 🔥 If the multiple transmissions of an LO get swapped for multiple transmissions of a URI (a multi-hop dissemination channel), the LO only has to traverse a single hop: the dereference transaction between the LR and the dereference server. The requirements for securing a location passed by reference [14] apply here 🫶
The major threats to LO security fall into two buckets. First, threats against the integrity and authenticity of LOs can expose entities that rely on LOs 😭 Second, threats against the confidentiality of LOs can let unauthorized people access location info 💀
An LO carries four essential types of info: identifiers for the described Target, location information, timestamps, and Rules 💜 By bundling values of these different types together in one structure, the LO encodes a set of bindings among them. In other words, the LO asserts that the identified Target was at the given location at the given time, and that the given Rules express the Target's desired policy at that time for distributing their location. Below, we describe the assurances each party in location distribution needs, so the possible attacks on these bindings get mitigated 🛡️✨
Rule Maker: The Rule Maker creates the Target's Privacy Rules and uploads them to the LSes 🎀 The main assurance the Rule Maker needs is that the Target's Privacy Rules are correctly associated with the Target's identity when they're conveyed to each LS that handles the LO. Protecting the integrity of the Privacy Rules distributed to the LSes prevents rule-tampering attacks. Sometimes the Target's privacy policy is itself sensitive info 🙈 In those cases, the Rule Maker also needs assurance that the binding between the Target's identity and their Privacy Rules can't be figured out by anyone other than an authorized LS.
Location Server: The Location Server enforces the Target's Privacy Rules 👑 The first assurance the LS needs 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 also has to make sure the authorization policies aren't exposed to third parties, if the Rule Maker wants that and the rules are privacy-sensitive 🔐
Location Recipient: The Location Recipient is the consumer of the LO 🦋 So the LR needs assurances about the authenticity of the bindings between the Target's location, the Target's identity, and the time. Making sure these bindings are authentic helps prevent a bunch of attacks, like falsifying the location, modifying the timestamp, faking the identity, and replaying LOs 😭
Location Generator: The main assurance the Location Generator needs is that the LS the LO is first published to is one that's trusted to enforce the Target's Privacy Rules 🧚 Authenticating the trusted LS reduces the risk of server impersonation attacks. The LG is also responsible for the location determination process, which matters for security too, because wrong input from external entities can lead to unwanted disclosure or access to location info 💅
Okay now the integrity and confidentiality of a Location Object can be handled directly through the LO format 💖 RFC 4119 [19] describes using Secure/Multipurpose Internet Mail Extensions (S/MIME) for integrity and confidentiality protection. Direct, end-to-end assurances are super desirable, and these mechanisms should be used whenever possible 🫶 BUT there are plenty of deployment scenarios where directly securing an LO is impractical 🙈 For example, in some scenarios there's no direct trust relationship between the creator of the Location Object and the recipient. Also, if lots of recipients are authorized to get a given LO, the creator can't guarantee end-to-end confidentiality without knowing exactly which recipient will receive it. Many of these cases can still be handled by location-by-reference, possibly combined with an LO 🌈
6. Example Scenarios 🎀
This section has a set of examples of how the Geopriv architecture can be deployed in real life ✨ They're meant to show the key points of the architecture, NOT to be an exhaustive list of use cases 💜
For clarity in these examples, we assume the Privacy Rules an LO carries are equivalent to the ones in a Presence Information Data Format Location Object (PIDF-LO) [19]. So basically, the main Rules that can be set are limits on the retransmission and retention of the LO 🦋 Those two are the most well-known and important examples, but the specific types of Rules an LS or LR has to consider will generally depend on the types of LOs it processes 💅
6.1. Minimal Scenario 🧚
One of the simplest scenarios in Geopriv is when a Device works out its own location and uses that LO to request a service (for example, by including the LO in an HTTP POST request [20] or a SIP INVITE message [21]). The server then delivers the service right away (for example, in a 200 OK response in HTTP or SIP), without keeping or passing along the Device's location 🌸 The Device acts as an LG by using a Device-based positioning algorithm (for example, 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, privacy of location info is kept in two steps 🔥 Step one: the location is only transmitted as directed by the single Rule Maker, which is the Target. Step two: the server, as LR, just doesn't do anything that creates a privacy risk. It doesn't retain or retransmit the location 😭 Because the server limits its behavior like this, it doesn't need to read the Rules in the LO, even though they were provided. No Rule would stop it from using the location in this safe way 🙌
Here's the outline for this scenario:
- Positioning: Device-based,
Device=LG - Distribution hop 1:
HTTP User Agent (UA) --> Ephemeral Web service, privacy via user indication - Use: Ephemeral Web service delivers response without retaining or retransmitting location
- 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 🌐
Okay so a LOT of location-based services live on the Web now, and they use Javascript code to orchestrate a bunch of HTTP requests for location-specific info ✨. To make that work, browser extensions were built to 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) 📡. They expose a location to Web pages through Javascript APIs, which is giving main character energy 💅.
In this scenario, we're looking at a Target using 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 asks the user to grant the page permission to access their location 🙈. If the user says yes, the browser extension sends 802.11 signal strength measurements to a positioning server, and the server sends back the position of the host 📍. The extension then builds an LO with this location and the Rules set by the user, and passes the LO to the page through its Javascript API. The page uses an XMLHttpRequest [22] to hit a server in the same domain as the page, and then it renders the info to the user 💖.
At first blush this scenario seems way more complicated than the minimal scenario above 😭. But ngl, most of the privacy considerations are actually the same 🫶.
The positioning phase starts when the browser extension contacts the positioning server 🧚. The positioning server acts as an LG.
The distribution phase actually happens 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 happens 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 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 covers the Web site's use of the LO. Here, the phrase "Web site" includes not only the Web page, but also the dedicated supporting logic behind it 🌈. If you think of the entire Web site as a recipient (instead of just 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, rather than retransmitting it to another entity 🧠. So even in this case, where the location-relevant information comes from a back-end server, the LR does not retain or retransmit the location. That means its behavior is "privacy-safe", and it doesn't need to interpret the Rules in the LO ✨.
Now consider a variation where the Web page requests additional information (a map, for instance) from a third-party site 👀. 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, it would need to examine the LO to determine how long this information can be retained. In that case, if the LR needs to do something the Rules don't allow, it may have to deny service to the user, while hopefully providing a message with the reason 🙅♀️. Still, if the Rules permit retention or retransmission (even if that 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 📝:
- Positioning: Network-assisted, positioning server=LG
- Rule installation: RM (=Target) gives permission to sites and sets LO Rules
- Distribution hop 1: positioning server=LS --> Target, privacy via LCP policy
- Distribution hop 2: Browser=LS --> Web site=LR, privacy via user confirmation
- Use: Back-end server delivers location-relevant information without further retransmission, then deletes location; privacy via safe behavior
- 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 placing an emergency call, and each one involves location information 💖:
- Determine the location of the caller.
- Determine the proper Public Safety Answering Point (PSAP) for the caller's location.
- Send a SIP INVITE message, including the caller's location, to the PSAP.
Step one is determining where the caller is. This 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 a proxy is doing this step. The entity doing the positioning (whether that's the caller or a proxy) acts as an LS, and it preserves the privacy of location information by only including it in emergency calls 🫶.
Step two covers location distribution and use 🔁. The entity 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, sending the location within a LoST message authorizes the LoST server to use the location to complete the protocol, namely to route the message as necessary through the LoST mapping architecture [25]. So the LoST server is authorized to complete the LoST protocol, but to do nothing else 🎯.
Step three 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, receiving 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 📝:
- Positioning: Any
- Distribution/use hop 1: Target=LS --> LoST infrastructure (no Rules), privacy via authorization implicit in protocol
- Distribution/use hop 2: Target=LS --> PSAP, privacy via Rules in LO
- Use: PSAP uses location to deliver emergency services
- 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
okay so 💅 in modern Internet apps, users get info through one channel and then broadcast it through another, which means both users and channels (think Web services) become LSes 🔥 bestie this is the lowkey iconic part, so we're looking at a more complex example that shows this pattern across multiple logical hops ✨
Say Alice is the Target 🎀 and she subscribes to a wireless ISP that figures out her location with a network-based positioning technique, like using the location of the base station serving the Target, and then sends that info straight to a location-enhanced presence provider. That provider might use SIP, the Extensible Messaging and Presence Protocol (XMPP) [26], or another protocol). The location-enhanced presence provider lets Alice decide how her location gets distributed: which friends get it and what Rules they get along with it 🦋 Alice also uses a few other location-enhanced services, so she sends Rules that let her location go to those services and let those services keep it and pass it on again 💖
Bob is one of Alice's friends and he gets her location through this location-enhanced presence service 🌸 He sees she's at their favorite coffee shop, so he wants to upload a photo of the two of them there to a photo-sharing site, with an LO that marks the location 📸 Bob checks the Rules in Alice's LO and confirms the photo-sharing site is one of the services Alice authorized. Since she gave him permission to hand the LO to that site, he attaches it to the photo and uploads it 🫶
Once the geo-tagged photo is up, the photo-sharing site reads the Rules in the LO and checks that it's allowed to store the photo and share it with others 👑 Alice let the site retransmit and retain it with no constraints, so the site goes ahead and makes Bob's geo-tagged photo publicly accessible 🌈
Now Eve, another user of the photo-sharing site, downloads the photo of Alice and Bob at the coffee shop and gets Alice's LO with it 🙈 Eve posts the photo and location on her public page on a social networking site without checking the Rules, even though the LO doesn't let Eve send the location anywhere else 😭 The social networking site, though, notices that retransmission and retention aren't allowed, and a public posting needs both, so it rejects the upload 💀 literally the site said no and we love to see it 🫶
Looking at the location life cycle, this scenario has a positioning step, then four distribution hops, and then use 🧚 Positioning is the simplest part: an LG in Alice's ISP monitors her location and sends it to the presence service. Privacy is kept because the location goes to just one entity that Alice has delegated privacy responsibilities to 🦋
The first distribution hop happens 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. This one is private because Alice has installed Rules on the presence server that decide who it can let access her location 🎀 The second hop is when Bob uploads the LO to the photo-sharing site. Here Bob acts as an LS and keeps the location private by checking that the Rules in the LO let him upload it 🌸 The third hop is when the photo-sharing site sends the LO to Eve, and it follows the Rules too, but these are a different set of Rules than the ones for Bob, since an LO can specify different Rule sets for different LSes ✨
Eve is the fourth LS in the chain, and she fails Geopriv by not checking the Rules in the LO before uploading it to the social networking site 😭 The site, though, is a responsible LR. It checks the Rules in the LO, sees they don't let it use the location the way it needs to, and throws the LO away 👑
Here's the quick outline of this scenario:
- Positioning: Network-based, LG in network, privacy via exclusive relationship with presence service
- Distribution/use hop 1:
Presence server --> Bob, privacy via Alice's access control rules - Distribution/use hop 2:
Bob --> photo-sharing site, privacy via Rules for Bob in LO - Distribution/use hop 3:
Photo-sharing site --> Eve, privacy via Rules for site in LO - Distribution/use hop 4:
Eve --> Social networking site, violates privacy by retransmitting - Use: Social networking site, privacy via checking Rules and discarding
- 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.
7. Glossary
Various security-related terms not defined here are to be understood in the sense defined in RFC 4949 [27] 🧐 so go check that one if you need it, bestie 🌟
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 🛰️
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 💅
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 🦋
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 ✨
okay so this is the bibliography for the "nice to know" stuff 📚💖 these are the ones the document points at for background, not things you have to read to get it.
[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.
[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.
[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 💌
Here's where to find the people who wrote this, bestie 🫶 Each address is kept exactly as published.
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046
USA
Phone: +1 410 290 6169
EMail: rbarnes@bbn.comMatt Lepinski
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Phone: +1 617 873 5939
EMail: mlepinski@bbn.comAlissa Cooper
Center for Democracy & Technology
1634 I Street NW, Suite 1100
Washington, DC
USA
EMail: acooper@cdt.orgJohn Morris
Center for Democracy & Technology
1634 I Street NW, Suite 1100
Washington, DC
USA
EMail: jmorris@cdt.orgHannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.atHenning 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.eduAnd that's the whole RFC, bestie! 🌈💖✨
📦 where this page comes from
- ietf: rfc6280 2011-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms