RFC 3693
Geopriv Requirements
Geopriv Requirements 🎀
okay so this is RFC 3693, and it's giving dream team. It was written by J. Cuellar (Siemens AG), J. Morris (Center for Democracy & Technology), D. Mulligan (Samuelson Law, Technology & Public Policy Clinic), J. Peterson (NeuStar), and J. Polk (Cisco). It's dated February 2004 and sits in the Informational category 💖. Its header has no Obsoletes or Updates line, so it doesn't replace or change any other RFC. It's filed under the Network Working Group.
Status of this Memo 📜
This memo is information for the Internet community 🌸. It does not set any kind of Internet standard, and distribution is totally unlimited.
Copyright Notice ©️
Copyright (C) The Internet Society (2004). All Rights Reserved. 💜
Abstract ✨
Location-based services, navigation apps, emergency services, field equipment management, and other location-dependent services all need geographic location info about a Target (like a user, a resource, or some other entity) 🧚. We need to gather and transfer that location info securely, and at the same time protect the privacy of the people involved. Major privacy energy 🔒.
This document is all about the authorization, security, and privacy requirements for those location-dependent services. Specifically, it covers the requirements for the Geopriv Location Object (LO) and for the protocols that use it. The LO is basically meant to be the main data structure in every Geopriv protocol exchange, so it can move location data securely 🦋.
Table of Contents 🗂️
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document. . . . . . . . . . . . . . . 4
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Primary Geopriv Entities . . . . . . . . . . . . . . . . . . . 6
5. Further Geopriv Terminology. . . . . . . . . . . . . . . . . . 7
5.1. Location Information and Sighting. . . . . . . . . . . . 7
5.2. The Location Object and Using Protocol . . . . . . . . . 9
5.3. Trusted vs. Non-trusted Data Flows . . . . . . . . . . . 10
5.4. Further Geopriv Principals . . . . . . . . . . . . . . . 10
5.5. Privacy Rules. . . . . . . . . . . . . . . . . . . . . . 12
5.6. Identifiers, Authentication and Authorization. . . . . . 13
6. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 15
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Location Object. . . . . . . . . . . . . . . . . . . . . 19
7.2. The Using Protocol . . . . . . . . . . . . . . . . . . . 21
7.3. Rule based Location Data Transfer. . . . . . . . . . . . 21
7.4. Location Object Privacy and Security . . . . . . . . . . 22
7.4.1. Identity Protection. . . . . . . . . . . . . . . 22
7.4.2. Authentication Requirements. . . . . . . . . . . 23
7.4.3. Actions to be secured. . . . . . . . . . . . . . 23
7.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
8.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 24
8.2. Securing the Privacy Rules . . . . . . . . . . . . . . . 24
8.3. Emergency Case . . . . . . . . . . . . . . . . . . . . . 24
8.4. Identities and Anonymity . . . . . . . . . . . . . . . . 25
8.5. Unintended Target. . . . . . . . . . . . . . . . . . . . 26
9. Protocol and LO Issues for later Consideration . . . . . . . . 26
9.1. Multiple Locations in one LO . . . . . . . . . . . . . . 26
9.2. Translation Fields . . . . . . . . . . . . . . . . . . . 26
9.3. Truth Flag . . . . . . . . . . . . . . . . . . . . . . . 27
9.4. Timing Information Format. . . . . . . . . . . . . . . . 27
9.5. The Name Space of Identifiers. . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative Reference . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 301. Overview ✨
Location-based services (apps that need geographic location info as input) are becoming super common 📍. Collecting and transferring location info about a particular Target can have big privacy implications, so a key goal of this protocol is to protect privacy according to Privacy Rules set by the "user/owner of the Target." More precisely, in this document's terminology (see Section 3 and 5.4 below), that person is the "Rule Maker" 👑.
Two things are central to the location-based services privacy situation 🫶. The first is the identity of every entity that can access raw location data, derive or compute location, or access derived or computed location info. The second is whether those entities can be trusted to know and follow the user's Privacy Rules 💅.
The main principles guiding the requirements in this document are:
- Security of Location Object transmission is essential 🔐. It protects the integrity and confidentiality of location info, which means authenticating both the sender and the receiver of the Location Object, and securing the Location Object itself.
- User-controlled Privacy Rules play a critical role 👑. They spell out the restrictions or permissions set by the "user" (or, as defined below, the "Rule Maker"). They specify the conditions a Location Server needs to meet before it can forward Location Information to a Location Recipient, plus the conditions and purposes the Location Information can be used for.
- One type of Privacy Rules says how location info should be filtered depending on who the recipient is 🌈. Filtering means reducing the precision or resolution of the data. A typical rule might look like: "my location can only be disclosed to the owner of such credentials in such precision or resolution" (e.g., "my co-workers can be told the city I am currently in") 🏙️.
- The Location Object should be able to carry a limited but core set of Privacy Rules 🎀. The exact form or expressiveness of those Rules, whether in the core set or the full set, isn't covered further in this document. Future documents from this working group will dig into it more 🦋.
- Whenever it makes sense, location info shouldn't be linked to the user's real identity, or to a static identifier that's easy to trace back to them 🙈. That includes Personally Identifiable Information like a name, mailing address, phone number, social security number, email address, or username. Instead, the user should be able to pick which local identifier, unlinked pseudonym, or private identifier gets bound to the location info 🧚.
- The user may want to hide the real identities of themselves and their partners, not just from eavesdroppers but also from the other entities taking part in the protocol 🌸.
Total anonymity might not be right for some applications, because of legal constraints or because some location services genuinely need explicit identification 🙃. But most of the time, location services only need some kind of authorization info and/or anonymous identifiers for the entities involved 💜.
2. Conventions Used in this Document 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Please note the capitals, bestie 💖.
Also, the requirements here are about the generic Location Object and about the protocols used for location services 🔥. So most of them are about capabilities that are mandatory-to-implement ✅. For example, requiring that implementations support integrity is not the same thing as requiring that all protocol traffic be authenticated 🙈.
A mandatory-to-use requirement is different from a mandatory-to-implement one. The example given is that the user always gets a notice when their location data was not authenticated 🚨. That's a practice that's mandatory-to-use, not just something implementations have to be able to do 💀.
3. Glossary ✨
okay so before we dive in, here's a quick cheat sheet of the basic terms. Each one gets a proper, more formal definition later in the doc, so think of this as the preview 🎀
- Location Generator (LG): the entity that first figures out or gathers the location of the Target and builds Location Objects that describe it 📍
- Location Object (LO): an object that carries location information (and maybe privacy rules too). Geopriv security mechanisms and privacy rules get applied to it 🔐
- Location Recipient (LR): the entity that receives location information 💌 It might have asked for the location directly by sending a query to a location server, or it might just get it asynchronously, no ask needed
- Location Server (LS): the entity that LGs publish Location Objects to. It's also where queries from location receivers land, and it's the one that applies the rules the rule maker set up 🏠
- Precision: how many significant digits a value has been reliably measured to 🔢
- Principal: the holder or subject of the credentials. Think a workstation user, or a network server 🧑💻
- Resolution: how fine the detail is that you can actually tell apart in a measured area. For Geopriv, that means the finite area inside some closed borders (like latitude and longitude boundaries) 🗺️
- Rule Holder: the entity that provides the rules for a particular target's location info distribution. It can either 'push' rules to a location server, or the location server can 'pull' them from the Rule Holder 📬
- Rule Maker: the authority that creates the rules governing who gets access to a target's location info. Usually that's the target themselves 👑
- Rule, or Privacy Rule: a directive that controls what an entity does with location information. That includes collecting it, using it, disclosing it, and keeping it 🛡️
- Target: a person or other entity whose location gets communicated by a Geopriv Location Object 🎯
- Using Protocol: a protocol that carries a Location Object 🚚
- Viewer: a Principal that consumes the location info communicated by a Geopriv Location Object, but doesn't pass it along any further 👀
Resolution and Precision are super close cousins 👯 You can 'reduce' either one to make location info coarser. Resolution gets reduced by defining an off-center perimeter around a user's location, or by just making the area bigger (like going from state to country). Precision gets reduced by dropping significant digits from the positioning info, like rounding longitude and latitude from seconds to minutes. Another WG document goes into way more detail on this, so go check it out if you're curious 🤓
4. Primary Geopriv Entities
okay here's the picture of the main Geopriv entities in a simple, basic architecture 🧩 Just a heads up, it doesn't claim to be complete, and it doesn't mean the entities have to be physically separate boxes in all cases.
+----------+
| Rule |
| Holder |
| |
+----+-----+
|
rule|interface
V
+----------+ +----------+ +----------+
|Location | publication | Location | notification |Location |
|Generator +-------------->| Server +-------------->|Recipient |
| | interface | | interface | |
+----------+ +----------+ +----------+There are four primary Entities, and here's the tea on each one:
- Location Generator (LG): the entity that first determines or gathers the Target's location and creates Location Objects describing it. LGs publish those Location Objects to Location Servers. How the LG actually learns the Location Information is outside the scope of the Geopriv Protocol, so that's not on us 🤷♀️
- Location Server (LS): the LS receives Location Object publications from LGs, and it may get subscriptions from Location Recipients. It applies the rules (which it learns from the Rule Holder) to the LOs it gets from LGs, and then notifies LRs of the resulting LOs whenever that's needed 🙌
- Location Recipient (LR): the LR receives notifications of Location Objects from Location Servers. It may show those LOs to a user or an automaton in some way 📲
- Rule Holder (RH): the RH houses the Privacy Rules for receiving, filtering, and distributing Location Objects for specific Targets. An LS may query an RH for a set of rules, or the RH may push rules to an LS. The rules in the Rule Holder get populated by the Rule Maker 🗂️
So Location Generation is basically the process of gathering Location Information, maybe from multiple sources, at an IP-based Geopriv Entity (that's the LG), which then talks to the other Geopriv Entities 💬
Rules MUST be authenticated and protected. 🔒 How that gets done, and especially how keys get distributed to the RM and other authorities, is outside the scope of this document. See also Section 8.2, "Securing the Privacy Rules", for more. This one's important, bestie, don't skip it 😭
The interfaces between the Geopriv entities aren't necessarily protocol interfaces. They could just be internal interfaces inside one composed device 🖥️ In some architectures, the Location Generator, Rule Holder, and Location Server might all live in the same device. There may also be several Rule Holders enforcing the Privacy Rules at one particular Location Server 💅
5. Further Geopriv Terminology
okay so this section has the terms that go beyond the primary entities. They do two things: (1) they show up in the requirements section of this document, and (2) they add more detail on the usage model the Geopriv Location Object is designed for. These terms will get used more in a separate scenarios document and elsewhere 🎬
5.1. Location Information and Sighting
the main focus of the Geopriv working group is on information about a Target's location that is NOT based on generally or publicly available sources. Instead it's about private info that a Target, a Target's Device, or a Target's network or service provider gives or creates 🔐 That said, the Geopriv Location Object could totally still be used to carry location info from public sources too 🌸
- Location Information: a relatively specific way of describing where a Device is located 📍
This Location Information might have been figured out in a bunch of different ways, including:
- (a) derived or computed from info that's generally not available to the public (like stuff mainly available to a network or service provider)
- (b) determined by a Device that might not be publicly addressable or accessible in general
- (c) input or otherwise provided by a Target
For example, the Location Information could include:
- (a) info calculated by triangulating on a wireless signal against cell phone towers 📱
- (b) longitude and latitude info determined by a Device with GPS (global positioning satellite) capabilities 🛰️
- (c) info manually entered into a cell phone or laptop by a Target in response to a query ⌨️
- (d) info automatically delivered by some other IP protocol, like at device configuration via DHCP ⚙️
Now here's what's excluded from this definition: figuring out location info completely without the knowledge or consent of the Target (or the Target's network or access service provider), based on generally available info like an IP or e-mail address 🙅♀️ Sure, an IP address can sometimes let someone guess (at least roughly) where you are. Commercial services even exist that give rough location based on IP addresses. Right now that kind of info is usually less precise than the stuff this document is about. But this type of location computation still raises big potential privacy and public privacy concerns, so bestie, be careful 😬 Those scenarios are generally outside the scope of this document, though.
Within any given location-based transaction, the INITIAL determination of location (and therefore the initial creation of Location Information) is called a Sighting. 👀
- Sighting: the initial determination of location based on non-public info (like we talked about in the Location Information definition), and the initial creation of Location Information 🎯
Some version of the sighting info ends up in the Location Object. Abstractly, it's made of two separate data fields:
(Identifier, Location)Here, Identifier is the identifier assigned to the Target being sighted, and Location is the current position of that sighted Target 🦋 Not every entity has access to exactly the same sighting info, which is a whole thing. A sighting can get transformed into a new sighting pair:
(Identifier-1, Location-1)before a Location Generator or Location Server gives it to a Location Recipient. When that happens, Identifier-1 may be a Pseudonym, and Location-1 may have less precision or resolution than the original value 🎭 Privacy glow-up, iykyk 💖
5.2. The Location Object and Using Protocol
Okay bestie 🎀 so a MAIN goal of the Geopriv working group is to define a Location Object (LO) ✨. It's giving "one package that carries BOTH the location AND the privacy instructions" 🎁
- Location Object (LO): This data contains the Location Information of the Target, plus other fields like an identity or pseudonym of the Target, time information, core Privacy Rules, authenticators, and so on. Most of the fields are optional, and that includes the Location Information itself 🫶
Here's the tea 🍵: nothing is said about what a missing field means. A partially filled object MAY be understood implicitly as a request to complete it 💅 And if there's no time information, that MAY implicitly mean "at the current time" or "at a very recent time", but it could be read a different way depending on the context 🙈
The "using protocol" is the protocol that reads or modifies the Location Object 🧚 A protocol that just moves the LO around as a string of bits without looking inside (like an IP storage protocol could do) is NOT a using protocol. It's only a transport protocol 🚚 But, and this is a big but 💀, the entity or protocol that made the transport protocol move the LO is still responsible for handling it properly: distribution, protection, usage, retention, and storage, all based on the rules that apply to that LO. No passing the buck, bestie 😤
The security and privacy mechanisms that protect the LO come in two flavours 🍓 First, the Location Object definition MUST include the fields or mechanisms used to secure the LO as such. The LO MAY be secured, for example, with cryptographic checksums or encryption as part of the LO itself. Second, the using protocol may also provide security mechanisms to securely transport the Location Object 🔐
When you're designing the LO, the design should observe that the security mechanisms of the Location Object itself are to be preferred. So the definition of the LO MUST include some minimal crypto functionality (Req. 14 and 15). And if the RM specifies the use of a particular LO security mechanism, it MUST be used (Req. 4). Non-negotiable, periodt 👑
5.3. Trusted vs. Non-trusted Data Flows
Location information gets used in SUPER different environments 🌈 Sometimes the participants have longstanding relationships, and other times they just have one-off interactions with no prior contract or other contact at all 🦋
Those different relationships raise different concerns for how privacy rules get implemented, including how Privacy Rules get communicated 📣 For example, a public Rule Holder might be unnecessary in a trusted environment, where there are more efficient ways to handle privacy issues ✨ Two terms cover the basic types of data flows:
- Trusted Data Flow: A data flow governed by a pre-existing contractual relationship that addresses location privacy 🤝
- Non-trusted Data Flow: A data flow that is NOT governed by a pre-existing contractual relationship that addresses location privacy 👀
5.4. Further Geopriv Principals
Now let's meet the cast 💖
- Target: The entity whose location is wanted by the Location Recipient. Usually the Target is the human "user" of a Device, or an object like a vehicle or shipping container that the Device is attached to. Sometimes the Target is the Device itself 🚗
- Device: The technical device that tracks location as a proxy for the location of a Target 📱
A Device could be a cell phone, a Global Positioning Satellite (GPS) receiver, a laptop with a wireless access Device, or a transmitter that emits a signal that can be tracked or located 🛰️ Sometimes the Target is basically doing the Device's job too, like when they type in location information themselves through a web browser 🫠
- Rule Maker (RM): The individual or entity with the authority to set the applicable Privacy Rules for a potential Geopriv Target 👑 Usually that's the owner of the Device, but it can also be the user who has the Device in their hands. Parents might control what happens to the location info from a kid's cell phone 🧸 A company might own a phone and give it to an employee, but still let the employee set the privacy rules 💼
There are four situations where the Privacy Rules of the Rule Maker might get some kind of constraint or override 🚨
- Emergency services (like E911 in the United States): local or national laws may require accurate location information to be sent in certain defined emergency call situations. The Geopriv Working Group MUST facilitate this 🚑
- Legal interception: the RM may not know about an override directive from a legal authority. The Working Group doesn't expect to make any particular accommodation for this situation 🕵️
- Employment or other contractual relationships: the owner of a particular location (like a corporate campus) may put constraints on how a Rule Maker uses Privacy Rules. The Working Group doesn't expect to make any particular accommodation for this either 🏢
- Governmental constraints: it's conceivable that a government authority may try to constrain a Rule Maker's use of Privacy Rules in non-emergency situations. Again, no particular accommodation is expected from the Working Group 🏛️
Keep going, we're almost done 🧚
- Viewer: An individual or entity that receives location data about a Target, and does NOT pass the location information (or information based on the Target's location, like driving directions to or from the Target) on to any party OTHER than the Target or the Rule Maker 👀
- Data Transporter: An entity or network that receives and forwards data without processing or altering it 🚛 A Data Transporter could theoretically be involved in almost any transmission between a Device and a Location Server, between a Location Server and a second Location Server, or between a Location Server and a Viewer. Some location tracking scenarios might not involve a Data Transporter at all 🌸
- Access Provider (AP): The domain that provides the initial network access, or other data communications services that are essential for the Device's communications functions (or for the computer equipment the Device runs in) 📡 The AP is often a wireless carrier, an Internet Service Provider, or an internal corporate network, and it often contains the LG. Sometimes the AP has a "dumb" LG, one that transmits Geopriv LOs but doesn't use any part of the Geopriv Location Object. Other cases might not involve any AP at all, or the AP might only act as a Data Transporter 💅
- Location Storage: A Device or entity that stores raw or processed Location Information (like a database) for any period longer than what's needed to finish an immediate transaction about that Location Information 🗄️
Why does this matter? 😭 Where and how Location Storage keeps its data is crucial for privacy, because it can influence what Location Information could eventually get revealed, whether through later distribution, a technical breach, or legal processes 🔍
5.5. Privacy Rules
Privacy Rules are rules that govern an entity's activities with respect to location and other information 📜 That includes, but isn't limited to, collecting, using, disclosing, and retaining location information. These rules are generally based on fair information practices, as laid out in (for example) the OECD Guidelines on the Protection of Privacy and Transporter Flows of Personal Data [OECD] 🌷
- Privacy Rule: A rule, or set of rules, that regulates an entity's activities with respect to location information, including its collection, use, disclosure, and retention. Specifically, the Rule describes how location information may be used by an entity, and which transformed location information may be released to which entities under which conditions. Rules must be obeyed; they are not advisory 🚫
A full set of Privacy Rules will likely include some rules with only one possible technical meaning, and some rules that depend on a locality's prevailing laws and customs 🌍 For example, a distribution rule like "my location can only be disclosed to the owner of such credentials and in such precision or resolution" has clear-cut implications for the protocol that uses the LO 🎯 But other rules, like retention or usage Rules, may have unclear technical consequences for the protocol or for the entities involved 🤔 For example, the exact scope of a retention rule stating "you may not store my location for more than 2 days" may partly depend on local laws or customs ⏳
5.6. Identifiers, Authentication and Authorization 🔐
Anonymity is the property of being not identifiable (within a set of subjects) 🫣. It's the base case for privacy 💖. If you can't stay anonymous, you might not be able to control your own privacy at all 😭.
Unlinkability is what lets a user make multiple uses of resources or services without anyone being able to connect those uses to each other 🧩. Basically, entities have to be unable to figure out whether the same user caused certain specific operations in the system 🙈 [ISO99]. A pseudonym is just a bit string that's unique as an ID and works for end-point authentication ✨.
Unlinked Pseudonym: Here the pseudonym and its holder are, at least at first, not connected in anybody's knowledge, except maybe the holder themselves or a trusted server of the user 🦋. See [Pfi01] (there the term is called Initially Unlinked Pseudonym).
Okay so, "authentication" gets used in different ways 🙃. Some people say authentication ties an entity to a more or less well-known identity. So if A authenticates another entity B as being "id-B", then the label "id-B" is well-known, or at least linkable, to that entity 👀. In that case "id-B" is called a publicly known identifier, and the authentication is "explicit" 🎀.
Explicit Authentication: This is when you verify a claimed identity as the sole originator of a message (message authentication) or as the end-point of a channel (entity authentication) 💅. The identity can also be easily traced back to the real identity of the entity, like a pre-existing static label from a predefined name space (telephone number, name, etc.) 📞.
Authorization: This is the act of deciding whether a particular right, like access to some resource, can be granted to whoever presents a particular credential 🔑.
Depending on the type of credential, authorization may or may not imply Explicit Authentication 🌸.
6. Scenarios and Explanatory Discussion ✨
Bestie, this part is where we walk through short scenarios to show how these terms and attributes describe location information transactions 🗺️. There are additional illustrative scenarios in a separate document, so don't worry, there's more 💜.
SCENARIO 1: GPS Device with Internal Computing Power: Closed System 🛰️
So in this one, the Target wants to know their location using the Global Positioning System (GPS), and the Device can process the raw data on its own to figure out where it is 🧭. The Device picks up transmissions from the GPS satellites, computes the location internally, and displays it. It's a closed system 🔒. For this example and the ones after it, we assume the GPS satellite broadcasts some signal and has no info about the identity or whereabouts of the Devices using that signal 🤐.
GPS Satellite
|
| Sighting (not a Geopriv Interface)
|
|
|
V GPS Device
--------------------------------------------------
/ \
| Location ----- Location ----- Location |
| Generator Server Storage |
\ | /
-------------------------------------------|------
|
| Notification
| Interface
|
------------|------
/ V \
/ Target Location \
| Recipient |
| |
\ Rule Maker /
\ /
-------------------In this scenario the GPS Device is both the AP and the LG 📱. The interaction happens in a Trusted environment because it happens in the Rule Maker's Device 💖.
SCENARIO 2: Cell Phone Roaming 📶
Here a cell phone is used outside its home service area (roaming) 🌍. The cell phone service provider (cell phone Corp 2) also outsourced the accounting of cell phone usage 🧾. The cell phone isn't GPS-enabled, so the location gets derived by the cell phone network the Target and Device are roaming in 📡. When the Target wants to use the cell phone, cell phone Corp 1 (AP) provides the roaming service, and sends the raw usage data (e.g., duration of call, location in the roaming network, etc.) to cell phone Corp 2, the home service provider 📤. Corp 2 hands the raw data to the accounting company, which processes it for the accounting statements 💸. Finally, the raw data gets sent to a data warehouse, where it's stored in a Location Server (e.g., computer server) 🗄️.
Cell Phone Corp 1 Cell Phone Corp 2
----------------- -----------------
Sighting / \ Publish / \
Device ----- | Data Transporter | --------- | Data Transporter |
Target \ / Interface \ /
----------------- / -----------------
/ |
/ | Notification
/ | Interface
----------- |
/ V
------------ / ----------
/ \ / / \
/ Location \ / | Location |
| Storage | Location Info | Storage |
| |<----------------- | |
| Location | | Location |
| Recipient | | Recipient |
\ / \ /
------------- ----------Here, cell phone Corp 1 is the AP and the LG 🏢. In this scenario, Corp 2 is likely to be a Trusted entity, but Corp 1 may be Non-trusted 🤔.
SCENARIO 3: Mobile Communities and Location-Based Services 👯♀️
This next figure shows a really common setup 💅, where a user wants to find friends or colleagues, or share their position with them or with a Location-Based Service Provider 📍. Some of the messages use a Location Object to carry things like identities or pseudonyms, credentials and proof-of-possession of them, Rules, and Location Data Information, including Data Types and Precision or Resolution 🧾. Messages that don't use the Location Object are outside the scope of the Geopriv WG, but they should be mentioned for understandability, so they show up in the figure as starred arrows ("***>") ⭐.
+---------+ +------------+
| | | |
| Location|<** | Public |
|Generator| * | Rule Holder|
| | * | |
+---------+\ * +------------+
\ *3 1a* *
\ * * *
\ ** *
\ * * *1a
\* * *
* \ * *
* \ * *
* \4 * *
* \ * V
* \->+-----------+
+----------+ 1 | Location |
| Rule |--------------------->| Server + |
| Maker | | Private |
+----------+ |Rule Holder|
+-----------+
^ |
3| |5
| V
+----------+
| Location |
| Recipient|
+----------+Let's say the Rule Maker and the Target are both registered with the Location Server 🤝. The RM has somehow proven to the LS that they really are the owner of the privacy rights of the Target (the Target is usually a Device owned by the Rule Maker) 📲. The Rule Maker and the Location Server have agreed on the keys, credentials and cryptographic material they'll use to authenticate each other, and in particular to authenticate or sign the Rules 🔐. How that was done is outside the scope of this document 🙃.
1: Rule Transfer: The Rule Maker sends a Rule to the Location Server 📨. This Rule may or may not be a field in a Location Object.
1a: Signed Rule: Alternatively, the Rule Maker can write a Rule and put it in a Public Rule Holder 📚. The entities access the repository to read the signed Rules.
2: Location Information Request: The Location Recipient asks for location information for a Target 🙋♀️. In this request, the Location Recipient can pick which location information data type they prefer. One way of requesting Location Information MAY be sending a partially filled Location Object, including only the identities of the Target and Location Recipient and the desired Data Type and precision or resolution, and providing proof of possession of the required credentials. But whether or not the using protocol understands this partially filled object as a request MAY depend on the using protocol or on the context 🤷♀️. The Location Recipient could also ask for periodic location information updates, but this is probably out of the scope of Geopriv 🌙.
3: Locate: When a Location Server gets a Location Information Request for a Target that has no current location information, the server may ask the Location Generator to locate the Target 🔍.
4: Location Information: The Location Generator sends the "full" location information to the Location Server 🗺️. This Location Information may or may not be embedded in a Location Object.
5: Filtered Location Information: The Location Server sends the location information to the Location Recipient 💌. The information may be filtered, meaning that in general a less precise or a computed version of the information gets delivered 🫧.
7. Requirements 📋
7.1. Location Object
Okay bestie, remember this whole doc is mostly about setting requirements on how the LO gets defined 💅 So some requirements read like this: "The LO definition MUST contain Field 'A' as an optional field." That one means:
- the document that defines the LO MUST define the LO field 'A',
- the field 'A' MUST be defined as optional to use (an instance of a LO MAY or may not contain the field 'A').
Other requirements read like this: "The LO definition MUST contain Field 'A', which MAY be an optional field." That one means:
- the document that defines the LO MUST define the LO field 'A',
- the field 'A' MAY be defined as optional or not to use. If it is defined as optional to use, any instance of an LO MAY or may not contain the field 'A'; if it is not optional, all instances of LOs MUST contain the field 'A'.
Req. 1. (Location Object generalities) 🌸
1.1) Geopriv MUST define one Location Object (LO) -- both in syntax and semantics -- that must be supported by all Geopriv entities.
1.2) Some fields of the Location Object MAY be optional. This means that an instance of a Location Object MAY or may not contain the fields.
1.3) Some fields of the Location Object MAY be defined as "extensions". This means that the syntax or semantics of these fields is not fully defined in the basic Location Object definition, but their use may be private to one or more of the using protocols.
1.4) The Location Object MUST be extensible, allowing the definition of new attributes or fields.
1.5) The object MUST be suitable for requesting and receiving a location.
1.6) The object MUST permit (but not require) the Privacy Rules to be enforced by a third party.
1.7) The object MUST be usable in a variety of protocols, such as HTTP and SIP, as well as local APIs.
1.8) The object MUST be usable in a secure manner even by applications on constrained devices.
Req. 2. (Location Object fields) The Location Object definition MUST contain the following Fields, which MAY be optional to use: 🎀
2.1) Target Identifier
2.2) Location Recipient Identity. This identity may be a multicast or group identity, used to include the Location Object in multicast-based using protocols.
2.3) Location Recipient Credential
2.4) Location Recipient Proof-of-Possession of the Credential
2.5) Location Field
2.5.1) Motion and direction vectors. This field MUST be optional.
2.6) Location Data Type. When transmitting the Location Object, the sender and the receiver must agree on the data type of the location information. The using protocol may specify that the data type information is part of the Location Object or that the sender and receiver have agreed on it before the actual data transfer.
2.7) Timing information:
- (a) When was the Location Information accurate? (sighting time)
- (b) Until when considered current? TTL (Time-to-live) (This is different than a privacy rule setting a limit on data retention)
2.8) Rule Field: this field MAY be a referral to an applicable Rule (for instance, a URI to a full Rule), or it MAY contain a Limited Rule (see Req. 11), or both.
2.9) Security-headers and -trailers (for instance encryption information, hashes, or signatures) (see Req. 14 and 15).
2.10) Version number
Req. 3. (Location Data Types) 🦋
3.1) The Location Object MUST define at least one Location Data Type to be supported by all Geopriv receivers (entities that receive LOs).
3.2) The Location Object SHOULD define two Location Data Types: one for latitude / longitude / altitude coordinates and one for civil locations (City, Street, Number) supported by all Geopriv receivers (entities that receive LOs).
3.3) The latitude / longitude / altitude Data Type SHOULD also support a delta format in addition to an absolute one, used for the purpose of reducing the size of the packages or the security and confidentiality needs.
3.4) The Location Object definition SHOULD agree on further Location Data Types supported by some Geopriv entities and defined by other organizations.
7.2. The Using Protocol
Req. 4. The using protocol has to obey the privacy and security instructions coded in the Location Object and in the corresponding Rules regarding the transmission and storage of the LO. 🔒
Req. 5. The using protocol will typically facilitate that the keys associated with the credentials are transported to the respective parties, that is, key establishment is the responsibility of the using protocol. 🗝️
Req. 6. (Single Message Transfer) In particular, for tracking of small target devices, the design should allow a single message/packet transmission of location as a complete transaction. 📦
Other requirements on the using protocol are out of the scope of this document, but might be the subject of future efforts from this working group. See also Section 9 (Protocol and LO Issues for later Consideration).
7.3. Rule based Location Data Transfer
Req. 7. (LS Rules) The decision of a Location Server to provide a Location Recipient access to Location Information MUST be based on Rule Maker-defined Privacy Rules. 👑
It is outside of our scope how Privacy Rules are managed and how a Location Server has access to the Privacy Rules. Note that it might be that some rules contain private information not intended for untrusted parties.
Req. 8. (LG Rules) Even if a Location Generator is unaware of and lacks access to the full Privacy Rules defined by the Rule Maker, the Location Generator MUST transmit Location Information in compliance with instructions set by the Rule Maker. Such compliance MAY be accomplished by the Location Generator transmitting the LO only to a URI designated by the Rule Maker.
Req. 9. (Viewer Rules) A Viewer does not need to be aware of the full Rules defined by the Rule Maker (because a Viewer SHOULD NOT retransmit Location Information), and thus a Viewer SHOULD receive only the subset of Privacy Rules necessary for the Viewer to handle the LO in compliance with the full Privacy Rules (such as, instruction on the time period for which the LO can be retained). 🙈
Req. 10. (Full Rule language) Geopriv MAY specify a Rule language capable of expressing a wide range of privacy rules concerning location information. This Rule language MAY be an existing one, an adaptation of an existing one or a new Rule language, and it SHOULD be as simple as possible. ✨
Req. 11. (Limited Rule language) Geopriv MUST specify a limited Rule language capable of expressing a limited set of privacy rules concerning location information. This Rule language MAY be an existing one, an adaptation of an existing one or a new Rule language. The Location Object MUST include sufficient fields and data to express the limited set of privacy rules. 🍓
7.4. Location Object Privacy and Security
7.4.1. Identity Protection
Req. 12. (Identity Protection) The Location Object MUST support use of Unlinked Pseudonyms in the corresponding identification fields of Rule Maker, Target, Device, and Location Recipient. Since Unlinked Pseudonyms are simply bit strings that are not linked initially to a well-known identity, this requirement boils down to saying that the name space for Identifiers used in the LO has to be large enough to contain many unused strings. 🦋
7.4.2. Authentication Requirements
Req. 13. (Credential Requirements) The using protocol and the Location Object SHOULD allow the use of different credential types, including privacy-enhancing credentials (for instance those described in [Bra00] or [Cha85]).
7.4.3. Actions to be secured
Req. 14. (Security Features) The Location Object MUST support fields suitable for protecting the Object to provide the following security features: 🛡️
14.1) Mutual end-point authentication: the using protocol is able to authenticate both parties in a Location Object transmission,
14.2) Data object integrity: the LO is secured from modification by unauthorized entities during transmission and storage,
14.3) Data object confidentiality: the LO is secured from eavesdropping (unauthorized reading) during transmission and storage, and
14.4) Replay protection: an old LO may not be replayed by an adversary or by the same entity that used the LO itself (except perhaps during a small window of time that is configurable or accepted by the Rule Maker).
Req. 15. (Minimal Crypto) 🔐
15.1) Geopriv MUST specify a minimum mandatory to implement Location Object security, including mandatory to implement crypto algorithms for digital signature algorithms and encryption algorithms.
15.2) It MAY also define further mandatory to implement Location Object security mechanisms for message authentication codes (MACs) or other purposes.
15.3) The protocol SHOULD allow a bypass if authentication fails in an emergency call.
The issue addressed in the last point is that an emergency call in some unfavorable situations may not be completed if the minimal authentication fails. This is probably not what the user would like to happen. The user may prefer an unauthenticated call to an unauthenticated emergency server over no call completion at all, even at the risk that he is talking to an attacker or that his information is not secured. 🚨
7.5. Non-Requirements
Non-Req. 1. (Bridging to non-IP networks) The Geopriv specification SHOULD NOT specify the bridging to non-IP networks (PSTN, etc). 🚫
8. Security Considerations ⚠️
The purpose of the Geopriv Location Object and the requirements on the using protocol are to allow a Privacy Rule-controlled disclosure of location information for location services. 👑
8.1. Traffic Analysis
The information carried within the Location Object is secured in a way compliant with the privacy and security Rules of the Rule Maker, but other information, carried in other objects or headers are in general not secured in the same way. This means that Geopriv may not as a general matter, secure the Target against general traffic analysis attacks or other forms of privacy violations. 👀
8.2. Securing the Privacy Rules
The Privacy Rules of the Rule Maker regarding the location of the Target may be accessible to a Location Server in a public or non-public Rule Holder, or they may be carried by the Location Object, or they may be presented by the Location Recipient as capabilities or tokens. Each type of Rule has to be secured its own particular way. 🔑
The rules in a non-public Rule Holder are typically authenticated using a MAC (Message Authentication Code) or a signature, depending on the type of keys used. The rules in a public Rule Holder (one that in principle may be accessed directly by several entities, for instance several Location Servers) are typically digitally signed. Rule Fields in an LO are secured as part of the LO itself. A Geopriv Token (a token or ticket issued by the Rule Maker to a Location Recipient, expressing the explicit consent of the Rule Maker to access his location information) is authenticated or signed. 💖
8.3. Emergency Case 🚨
okay so picture this: an emergency call where the authentication fails because the authentication center can't authenticate itself 😭 this is in the Req 15.3 bypass zone. one way to handle it is to let the user write a Rule that picks what happens:
- "If the emergency server does not authenticate itself, send the location information anyway", or
- "If the emergency server does not authenticate itself, let the call fail".
next, what if the authentication fails because the user can't authenticate itself? then the question is whose Rule wins 🤔 it's reasonable to use a default one: this location information can only be sent to an emergency center. main character safety rule 💖
the third situation is the one that needs a closer look. what if the user can't authenticate itself AND the emergency center can't be authenticated either? it's reasonable to send the Location Information anyway, but are there any security threats that must be considered? 👀 bestie, that's a whole vibe check, and we need to think it through carefully 💅
8.4. Identities and Anonymity 🦋
the use of Unlinked Pseudonyms is necessary to get anonymity. no way around it 🙈
the point of using Unlinked Pseudonyms is this: the using protocol should be able to hide the real identity of the Rule Maker, the Target, and the Device from Location Servers or Location Recipients, if the RM requires it. also, the using protocol SHOULD be able to hide the real identity of the Location Recipient from the Location Server.
now that last one is lowkey iconic. the Target isn't worried about the Server knowing where they are. it's about the Server figuring out who their business partners are, and from that, their habits and stuff 🫣 hiding Location Recipient identities matters for a few reasons: (a) that knowledge could be used to work out who the Target is, (b) knowing the Recipient's identity could embarrass the Target or leak confidential info, and (c) a dossier of who's been getting a Target's location over a long stretch of time can reveal habits, movements, and more. 📂
even if the location service providers promise to respect privacy, are legally required to protect it, and misbehavior or negligence of the Location Server can be ruled out, there's still a risk that personal data ends up in the wrong hands. outsider attacks, insider access, technical or human mistakes, or legal processes can all do it 😬 so yeah, we can't just trust vibes.
sometimes a Location Server has to know who is supplying the Privacy Rules for a particular Target. other times it's enough to know that the supplier is authorized to do so ✨
8.5. Unintended Target 🌸
an Unintended Target is a person or object that gets tracked by being close to the Target. this happens most often when the Target isn't a person. for example, the Target might be a rental car with a GPS Device, used to keep track of car inventory. the rental company probably doesn't care where the driver is, but the driver's privacy is still implicitly affected 🚗💨
Geopriv may or may not protect or affect the privacy of Unintended Targets, but the impact on Unintended Targets should be acknowledged. so we say it out loud, periodt 🫶
9. Protocol and LO Issues for later Consideration 🧚
this section quickly talks about issues with the Location Object or the protocol that popped up while earlier versions of this document were being discussed. spicy leftovers, let's go 🌶️
9.1. Multiple Locations in one LO 📍
a location Field is meant to represent one point or one region in space (1, 2, or 3 dimensional, your pick). whether you can include multiple locations is discussed in another document. the current rough consensus is this: the LO definition MAY allow the Location Field to be optional, to appear exactly one time, or to occur several times. each Location Field may contain one or more "Location Representations", and each one is meant to represent a different measurement or a different formatting of the same position.
but there are other ways to use multiple Location Fields and multiple representations too 👀 maybe several Location Fields report the same sighting in different formats, or multiple sightings at different times, or multiple sensor locations for the same device, or other stuff that might depend on the using protocol. this is all for further discussion 💜
9.2. Translation Fields 🌐
it's possible to include fields that indicate one location is a translation of another. if you do that, you can also have a field to identify the translator, both as identity and method. very organized, very iconic 💅
9.3. Truth Flag 🤥
Geopriv MUST be silent on the truth or lack-of-truth of the location information contained in the LO. so the LO MUST NOT provide an attribute saying "I am (or am not) telling you the whole truth." that's a no-drama rule 🙅♀️✨
9.4. Timing Information Format ⏰
the format of timing information is out of scope for this document. someone else's problem, bestie 🫠
9.5. The Name Space of Identifiers 🏷️
who gets to define the Identities? can the using protocol define the Identifiers, or must it use and authenticate Pseudonyms proposed by the Rules, picked independently of the using protocol? 🤔 if the using protocol has a proper namespace, with lots of unused names that can be used as pseudonyms and swapped out regularly, then the Location Object may be able to use that namespace. the user would probably have to write their Rules using that namespace too. and note that the pseudonyms need to change regularly, because figuring out who's behind an unlinked pseudonym can be super easy 😩
there are some perks to letting the using protocol define the namespace:
- the embedded authentication would be easier, since the using protocol usually already has the credentials for the authentication identity in place, and the "embedded" authentication would be independent of the form of Identifiers,
- the size of the names would be fixed.
on the flip side, the benefits of letting the Rule choose the identifiers are:
- the user has control over their own anonymity, and
- interworking of multiple systems with Location Object across protocol boundaries gets easier. 🌈
10. Acknowledgements 💌
we want to thank the members of the IETF Geopriv WG for their comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison Mankin, Randall Gellens, and the participants of the Geopriv meetings in San Diego and Yokohama gave detailed comments or text. you're all iconic 🫶
11. References 📚
11.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.11.2. Informative References
[Bra00] Stefan A.: Rethinking Public Key Infrastructures and
Digital Certificates : Building in Privacy, MIT Press;
ISBN: 0262024918; 1st edition, August, 2000
[Cha85] Chaum, David: Security without Identification, Card
Computers to make Big Brother Obsolete. Original Version
appeared in: Communications of the ACM, vol. 28 no. 10,
October 1985 pp. 1030-1044. Revised version available at
http://www.chaum.com/articles/
[ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/.
[OECD] OECD Guidelines on the Protection of Privacy and
Transborder Flows of Personal Data, http://www.oecd.org.
[Pfi01] Pfitzmann, Andreas; Koehntopp, Marit: Anonymity,
Unobservability, and Pseudonymity - A Proposal for
Terminology; in: H Federrath (Ed.): Designing Privacy
Enhancing Technologies; Proc. Workshop on Design Issues in
Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer
versions available at
http://www.koehntopp.de/marit/pub/anon12. Authors' Addresses 🖋️
Jorge R Cuellar
Siemens AG
Corporate Technology
CT IC 3
81730 Munich, Germany
EMail: Jorge.Cuellar@siemens.com
John B. Morris, Jr.
Director, Internet Standards, Technology & Privacy Project
Center for Democracy & Technology
1634 I Street NW, Suite 1100
Washington, D.C. 20006 USA
EMail: jmorris@cdt.org
URI: http://www.cdt.org
Deirdre K. Mulligan
Samuelson Law, Technology & Public Policy Clinic
Boalt Hall School of Law
University of California
Berkeley, CA 94720 USA
EMail: dmulligan@law.berkeley.edu
URI: http://www.law.berkeley.edu/cenpro/samuelson/
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 5707
Concord, CA 94520 USA
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082 USA
EMail: jmpolk@cisco.com13. Full Copyright Statement ©️
Copyright (C) The Internet Society (2004). this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 💖
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🔐
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. it also doesn't represent that it has made any independent effort to identify any such rights. info on the procedures for rights in RFC documents is in BCP 78 and BCP 79.
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use such proprietary rights can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 🌷
funding for the RFC Editor function is currently provided by the Internet Society. thank you for keeping the lights on, fr fr ✨
📦 where this page comes from
- ietf: rfc3693 2004-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms