RFC 6772
Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information 🧚
Okay bestie, this is RFC 6772 🎀. It's a Standards Track doc, so real implementers actually build on it, and it came out in January 2013. Its ISSN is 2070-1721. It doesn't list any obsoletes or updates in its header. 💅
It was written by H. Schulzrinne, Ed. (Columbia University), H. Tschofenig, Ed. (Nokia Siemens Networks), J. Cuellar (Siemens), J. Polk (Cisco), J. Morris, and M. Thomson (Microsoft). The whole squad 🫶
Abstract ✨
So this doc defines an authorization policy language for controlling who gets to see location information 📍. It builds on the Common Policy authorization framework and adds location-specific access control. The new condition elements let you restrict access to data based on the Target's current location 🦋
It also defines two algorithms for making returned location info less precise (reducing granularity). The first one is for civic location info, and the other one is for geodetic location info. Here's the tea: both come with limitations 💀. There are situations where they hide less than you'd want, and they might not be right for every application domain.
Status of This Memo ✨
This is an Internet Standards Track document 🌸
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6772 🔥
Copyright Notice ✨
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date it was published. Please actually read these, because they spell out your rights and restrictions for this document 🙈
Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License ⭐
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Structure of Geolocation Authorization Documents . . . . . 7
3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 7
4. Location-Specific Conditions . . . . . . . . . . . . . . . . . 7
4.1. Geodetic Location Condition Profile . . . . . . . . . . . 8
4.2. Civic Location Condition Profile . . . . . . . . . . . . . 9
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 9
6.2. Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 10
6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 10
6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 11
6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 12
6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 13
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Rule Example with Civic Location Condition . . . . . . . . 15
7.2. Rule Example with Geodetic Location Condition . . . . . . 16
7.3. Rule Example with Civic and Geodetic Location Condition . 17
7.4. Rule Example with Location-Based Transformations . . . . . 18
7.5. Location Obfuscation Example . . . . . . . . . . . . . . . 19
8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 23
9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 24
10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 26
10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 26
10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 26
10.4. MIME Media Type . . . . . . . . . . . . . . . . . . . . . 26
10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 26
10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 26
10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 26
10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 26
10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11.1. Geolocation Policy XML Schema Registration . . . . . . . . 27
11.2. Geolocation Policy Namespace Registration . . . . . . . . 27
11.3. Geolocation Policy Location Profile Registry . . . . . . . 28
11.4. Basic Location Profile XML Schema Registration . . . . . . 28
11.5. Basic Location Profile Namespace Registration . . . . . . 29
11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 29
12. Internationalization Considerations . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
13.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 30
13.2. Obfuscation . . . . . . . . . . . . . . . . . . . . . . . 31
13.3. Algorithm Limitations . . . . . . . . . . . . . . . . . . 32
13.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 33
13.5. Limitations of Obscuring Locations . . . . . . . . . . . . 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 38
Appendix B. Pseudocode . . . . . . . . . . . . . . . . . . . . . 391. Introduction ✨
Location information has to be protected against unauthorized access so people's privacy stays intact 🔒. RFC 6280 [RFC6280] defines a protocol-independent model for access to geographic information. That model has a Location Generator (LG), which figures out location information, and a Location Server (LS), which decides who gets access to it. There's also a Location Recipient (LR), which asks for and receives location information, and a Rule Maker (RM), which writes the authorization policies 📝 An authorization policy is basically a set of rules that controls what an entity can do with privacy-sensitive info, like location.
In this doc, the data object holding location information is called a Location Object (LO) 🦋. The basic rule set in the Presence Information Data Format Location Object (PIDF-LO) [RFC4119] can limit how long the Location Recipient gets to keep the info, and it can ban further distribution. It also points to an enhanced rule set and a human-readable privacy policy 🌸. But here's the catch: the basic rule set doesn't actually protect access to location info. It only communicates the user's privacy preferences 😭 This doc describes an enhanced rule set that gives way richer constraints on how LOs get distributed.
The enhanced rule set lets whoever uses these rules limit how long data is retained and enforce access restrictions on location data. That includes blocking dissemination to particular individuals, at particular times, or when the Target is in a specific region 🌈 The RM can also say that only certain parts of the Location Object may go to recipients, or that the resolution gets reduced for certain parts of it 💅
Here's how a typical sequence goes: a Location Server gets a query for location information about a particular Target 🧚 The authenticated identity of the Location Recipient, plus any other info sent with the request or generally available to the server, gets used to search the rule set. If more than one rule matches the condition element, the combined permission is evaluated according to Section 10 of [RFC4745] ✨ The result of the rule evaluation is applied to the location information, which can yield a modified Location Object that then gets delivered to the Location Recipient 🎀
This doc does not describe the protocol used to convey location info from the Location Server to the Location Recipient 🙈
This doc extends the Common Policy framework defined in [RFC4745] 👑 That doc gives an abstract framework for writing authorization rules. Each rule has conditions, actions, and transformations. Conditions decide the circumstances under which the entity running the rules (like a Location Server) is allowed to apply actions and transformations. In a location context, transformations control how a Location Server modifies the info elements it returns to the requestor, for example by reducing the granularity of the returned location info 🦋
This doc defines two algorithms for reducing the granularity of returned location info. The first is for civic location info (see Section 6.5.1), and the other one is for geodetic location info (see Section 6.5.2) 🌸 Both come with limitations. In other words, they only provide location obfuscation under certain conditions, so they might not suit every application domain 💀 Those limitations are written up in the Security Considerations section (see Section 13). The geodetic transformation algorithm in Section 6.5.2 helps with privacy risks for both stationary and moving Targets. Heads up though: moving Targets will reveal additional information to an adversary 👀 If applications have fancier privacy needs, more algorithms may need to be defined. This doc expects that extensions will come in the form of new algorithms, so it defines a registry for them (see Section 11.3) 📚
The XML schema defined in Section 9 extends the Common Policy schema by adding new child elements to the condition and transformation elements. This doc does not define any child elements for the action part of a rule 💖
Part 1 of 8. More parts are coming, so stay tuned! 🫶
2. Terminology ✨
okay bestie, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc get read the way [RFC2119] describes 🫶 Super important, because they're the words that tell you how strict things are.
This doc borrows a bunch of terms from [RFC6280] 🎀 Like Location Server (LS), Location Recipient (LR), Rule Maker (RM), Target, Location Generator (LG), and Location Object (LO). Then it adds its own terms, which are just as iconic 💅
Presentity or Target:
Okay so [RFC6280] calls the thing you need location info about the "Target" 📍 The presence model in [RFC2778] calls the entity that gives presence info to a presence service a "presentity" 🦋 A presentity in a presence system is just a Target in a location info system. Same girl, different name tag 💖
Watcher or Location Recipient:
The receiver of location info is the Location Recipient (LR) in [RFC6280] land ✨ A watcher in a presence system, meaning an entity that asks for presence info about a presentity, is a Location Recipient in a location info system. Main character energy 👑
Authorization policy:
An authorization policy is given by a rule set 📜 A rule set has an unordered list of (policy) rules 🌸 Each rule has a condition, an action, and a transformation component. Three parts, very tidy 🍓
Permission:
"Permission" is the word for the action and transformation components of a rule 🔑
Location Servers:
These are entities that evaluate the geolocation authorization policies 💜
Presence Servers:
The geolocation privacy architecture lines up with the presence architecture from [RFC4079] 🫶 So a "Presence Server" is an entity that distributes location info along with other presence-specific XML data elements. It's giving teamwork 🧚
3. Generic Processing
3.1. Structure of Geolocation Authorization Documents
A geolocation authorization document is an XML document, formatted according to the schema defined in [RFC4745] 📄 It inherits the media type of Common Policy documents, application/auth-policy+xml 🎀 As described in [RFC4745], this document is made of rules that contain three parts: conditions, actions, and transformations.
Each action or transformation (also called a permission) is a positive grant of information to the Location Recipient ✨ That's the lowkey genius part. There's a well-defined way to combine actions and transformations from several sources, and it's privacy enabling, because not having an action or transformation can only mean less info gets shown to a Location Recipient 🔒💖
3.2. Rule Transport
There are two ways the authorization rules in this document can get passed between different parties 🦋
- [RFC4119] lets enhanced authorization policies be referenced through a Uniform Resource Locator (URL) in the
ruleset-referenceelement 🔗 Theruleset-referenceelement is part of the basic rules that always travel with the Location Object 🎀 - Authorization policies might also be stored at a Location Server / Presence Server, for example 🗄️ So the Rule Maker needs a protocol to create, modify, and delete the authorization policies defined in this document. One such protocol is the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] 💅
4. Location-Specific Conditions
This section is all about the location-specific conditions of a rule 🌈 The <conditions> element holds zero or more <location-condition> child element(s). Here's the tea: <conditions> only evaluates to TRUE if all its child elements evaluate to TRUE 🫠 So having multiple <location-condition> elements is not normally useful. 🙈
The <location-condition> element MUST contain at least one <location> child element 🍓 It evaluates to TRUE if any of its child <location> elements matches the location of the Target. In other words, <location> elements are combined with a logical OR 🔀
The three attributes of <location> are 'profile', 'xml:lang', and 'label' 🏷️ The 'profile' attribute tells you which location profile is included as child elements in the <location> element. Two profiles are defined, geodetic and civic, in Sections 4.1 and 4.2 ✨ Each profile describes the conditions under which a <location> element evaluates to TRUE.
The 'label' attribute lets you add a human-readable description to each <location> element 💬 The 'xml:lang' attribute holds a language tag that gives more info for rendering the content of the 'label' attribute 🌍
The <location-condition> and <location> elements are extension points 🧩 If the entity evaluating the rules doesn't understand an extension, then that rule evaluates to FALSE. This makes a <conditions> element evaluate to FALSE if a <location-condition> element is unsupported 😬 A <location-condition> is considered TRUE if any of the <location> elements understood by the rule evaluator is TRUE.
4.1. Geodetic Location Condition Profile
The geodetic location profile is identified by the token 'geodetic-condition' 🌐 Rule Makers use it by placing a Geography Markup Language [GML] <Circle> element within the <location> element (as described in Section 5.2.3 of [RFC5491]) 💫
The <location> element with the geodetic info evaluates to TRUE if the Target's current location is completely within the described location (see Section 6.1.15.3 of [OGC-06-103r4]) 🎯 Note that the Target's actual location might be represented by any of the location shapes described in [RFC5491] 🔷 If the geodetic location of the Target is unknown, then the <location> element with the geodetic info evaluates to FALSE 🙃
Implementations MUST support the World Geodetic System 1984 (WGS 84) [NIMA.TR8350.2-3e] coordinate reference system, using the formal identifier from the European Petroleum Survey Group (EPSG) Geodetic Parameter Dataset (as formalized by the Open Geospatial Consortium (OGC)) 🗺️ That means this one:
2D: WGS 84 (latitude, longitude), as identified by the URN
"urn:ogc:def:crs:EPSG::4326". This is a two-dimensional CRS.A Coordinate Reference System (CRS) MUST be specified using the above URN notation only 📐 Implementations do not need to support user-defined CRSs, so you can chill on that one 😌
Implementations MUST specify the CRS using the srsName attribute on the outermost geometry element 🏷️ The CRS MUST NOT be changed for any sub-elements 🚫 And the srsDimension attribute MUST be omitted, since the number of dimensions in these CRSs is already known 🙌
4.2. Civic Location Condition Profile
The civic location profile is identified by the token 'civic-condition' 🏠 Rule Makers use it by placing a <civicAddress> element, defined in [RFC5139], within the <location> element 📫
All child elements of a <location> element that carry <civicAddress> elements MUST evaluate to TRUE (that's a logical AND) for the <location> element to evaluate to TRUE 💕 For each child element, its value gets compared to the value of the same element in the Target's civic location. The child element evaluates to TRUE if the two values are identical in an octet-by-octet comparison 🔍
A <location> element containing a <civic-condition> profile evaluates to FALSE if a civic address isn't present for the Target 🫥 This could happen if location info was removed by other rules or other transmitters of location info, or if only the geodetic location is known. Generally, it is RECOMMENDED behavior for an LS not to apply a translation from geodetic location to civic location (in other words, not to geocode the location) 🙅♀️
5. Actions
This document doesn't define any location-specific actions 🤷♀️ Easy.
6. Transformations
This document defines several elements that let Rule Makers specify transformations that:
- reduce the accuracy of the returned location information, and
- set the basic authorization policies carried inside the PIDF-LO 🎀
6.1. Set Retransmission-Allowed
This element changes, or creates a value for, the <retransmission-allowed> element in the PIDF-LO 🔁 The data type of the <set-retransmission-allowed> element is a boolean ✅
If the value of the <set-retransmission-allowed> element is TRUE, then the <retransmission-allowed> element in the PIDF-LO MUST be set to TRUE 💖 If the value is FALSE, then the <retransmission-allowed> element in the PIDF-LO MUST be set to FALSE 💔
If the <set-retransmission-allowed> element is absent, then the value of the <retransmission-allowed> element in the PIDF-LO MUST be kept unchanged 🔒 Or, if the PIDF-LO is created for the first time, then the value MUST be set to FALSE 🫣
6.2. Set Retention-Expiry
This transformation asks the LS to change or set the value of the <retention-expiry> element in the PIDF-LO ⏳ The data type of the <set-retention-expiry> element is a non-negative integer 🔢
The value you give the <set-retention-expiry> element is in seconds, and those seconds get added to the time that the LS provides location ⏱️ A value of zero requests that the information is not retained 🗑️
If the <set-retention-expiry> element is absent, then the value of the <retention-expiry> element in the PIDF-LO is kept unchanged 🧷 Or, if the PIDF-LO is created for the first time, then the value MUST be set to the current date 📅
6.3. Set Note-Well
This transformation asks the LS to change or set the value of the <note-well> element in the PIDF-LO 📝 The data type of the <set-note-well> element is a string 🎀
The value provided with the <set-note-well> element holds a privacy statement as a human-readable text string, and an 'xml:lang' attribute says what language that text is in 🌷
If the <set-note-well> element is absent, then the value of the <note-well> element in the PIDF-LO is kept unchanged 🫶 Or, if the PIDF-LO is created for the first time, then no content is provided for the <note-well> element 🌙
6.4. Keep Ruleset Reference
This transformation says whether the <external-ruleset> element in the PIDF-LO carries the extended authorization rules defined in [RFC4745] 📚 The data type of the <keep-rule-reference> element is boolean ✅
If the value of the <keep-rule-reference> element is TRUE, then the <external-ruleset> element in the PIDF-LO is kept unchanged when it's included 🫶 If the value is FALSE, then the <external-ruleset> element in the PIDF-LO MUST NOT contain a reference to an external rule set 🚫 The reference to the ruleset is removed, and no rules are carried as MIME bodies (in the case of Content-ID (cid:) URIs [RFC2392]) 💨
If the <keep-rule-reference> element is absent, then the value of the <external-ruleset> element in the PIDF-LO is kept unchanged when it's available 🌸 Or, if the PIDF-LO is created for the first time, then the <external-ruleset> element MUST NOT be included 💅
6.5. Provide Location ✨
okay bestie, the <provide-location> element holds child elements from one specific location profile, and that profile decides how zoomed-in the location you get back is 🔍 this is also called 'obfuscation' 🫣, and [DUCKHAM05] defines it as:
the means of deliberately degrading the quality of information about an individual's location in order to protect that individual's location privacy.
Location obscuring is genuinely hard 😩 The algorithms in this document are provided as examples only, so they're not the one true way. Section 13.5 covers the technical constraints if you want the deep dive 🤓
The reduction depends on what type of location goes in. This document defines two profiles:
- civic-transformation: If the <provide-location> element has a <provide-civic> child element, then civic location information is disclosed as described in Section 6.5.1, subject to availability.
- geodetic-transformation: If the <provide-location> element has a <provide-geo> child element, then geodetic location information is disclosed as described in Section 6.5.2, subject to availability.
The <provide-location> element MUST contain the 'profile' attribute if it contains child elements, and the child elements MUST be appropriate for the profile. 💅
If the <provide-location> element has no child elements, then both civic and geodetic location information is disclosed without reducing its granularity, subject to availability. In this case, the profile attribute MUST NOT be included. 🌸
6.5.1. Civic Location Profile
This profile uses the token 'civic-transformation' 🎀. It lets you specify civic location transformations with the <provide-civic> element, which restricts the level of civic location information the LS is permitted to disclose. The symbols for these levels are: 'country', 'region', 'city', 'building', and 'full'. Each level is given by a set of civic location data items such as <country> and <A1>, ..., <POM>, as defined in [RFC5139]. Each level includes all the elements included by the lower levels, so it's giving layers 🧁
The 'country' level includes only the <country> element. The 'region' level adds the <A1> element. The 'city' level adds the <A2> and <A3> elements. The 'building' level and the 'full' level add further civic location data, as shown below 👑
full
{<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>, <POD>,
<STS>, <HNO>, <HNS>, <LMK>, <LOC>, <PC>, <NAM>, <FLR>,
<BLD>,<UNIT>,<ROOM>,<PLC>, <PCN>, <POBOX>, <ADDCODE>, <SEAT>
<RD>, <RDSEC>, <RDBR>, <RDSUBBR>, <PRM>, <POM>}
|
|
building
{<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>
<POD>, <STS>, <HNO>, <HNS>, <LMK>, <PC>,
<RD>, <RDSEC>, <RDBR>, <RDSUBBR> <PRM>, <POM>}
|
|
city
{<country>, <A1>, <A2>, <A3>}
|
|
region
{<country>, <A1>}
|
|
country
{<country>}
|
|
none
{}The default value is "none". 🫶
The schema of the <provide-civic> element is defined in Section 8.
6.5.2. Geodetic Location Profile
This profile uses the token 'geodetic-transformation' 🦋 and only refers to the Coordinate Reference System (CRS) WGS 84 (urn:ogc:def:crs:EPSG::4326, 2D). It lets you specify geodetic location transformations with the <provide-geo> element, which may restrict the returned geodetic location information based on the value in the 'radius' attribute. That value is the radius in meters 📏
The schema of the <provide-geo> element is defined in Section 8.
The algorithm proceeds in six steps ✨ The first two steps don't depend on the measured position being obscured, so they should be run only once or very infrequently for each region and desired uncertainty. The steps are:
- Choose a geodesic projection with Cartesian coordinates and a surface you want to cover. Limit the worst-case distortion of the map as noted below.
- Given a desired uncertainty radius "d", choose a grid of so-called "landmarks" at a distance of at least d units apart from each other.
- Given a measured location
M=(m,n)on the surface, calculate its 4 closest landmarks on the grid, with coordinates:SW = (l,b),SE=(r,b),NW=(l,t),NE=(r,t). Thus,l<=m<randb<=n<t. See notes below. - Let
x=(m-l)/(r-l)andy=(n-b)/(t-b). x and y are the scaled local coordinates of the point M in the small grid square that contains it, where x and y range between 0 and 1. - Let
p = 0.2887 (=sqrt(3)/6)andq = 0.7113 (=1-p). Determine which of the following eight cases holds:
C1. x < p and y < p
C2. p <= x < q and y < x and y < 1-x
C3. q <= x and y < p
C4. p <= y < q and x <= y and y < 1-x
C5. p <= y < q and y < x and 1-x <= y
C6. x < p and q <= y
C7. p <= x < q and x <= y and 1-x <= y
C8. q <= x and q <= y- Depending on the case, let C (=Center) be:
C1: SW
C2: SW or SE
C3: SE
C4: SW or NW
C5: SE or NE
C6: NW
C7: NW or NE
C8: NEReturn the circle with center C and radius d. 🔥
Notes:
Regarding Step 1: The scale of a map is the ratio of a distance (a straight line) on the map to the corresponding air distance on the ground. For maps covering larger areas, a map projection from a sphere (or ellipsoid) to the plane introduces distortion, so the scale of the map isn't constant. Also, the real distance on the ground is taken along great circles, which may not correspond to straight lines on the map, depending on the projection used. Let's measure the (length) distortion of the map as the quotient between the maximal and the minimal scales on the map. The distortion MUST be below 1.5. (The minimum distortion is 1.0: if the region of the map is small, then the scale may be taken as a constant over the whole map.) 🗺️
Regarding Step 3: SW is mnemonic for southwest, b for bottom, l for left (SW=(l,b)), and so on, but the directions of the geodesic projection may be arbitrary. So SW may not be southwest of M, but it will be left and below M on the map. 🧭
7. Examples ✨
This section provides a few examples of authorization rules using the extensions defined in this document 💖
7.1. Rule Example with Civic Location Condition
This example illustrates a single rule that employs the civic location condition. It matches if the current location of the Target equals the content of the child elements of the <location> element. Requests match only if the Target is at a civic location with country set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to 'Munich', city division (A4) set to 'Perlach', street name (A6) set to 'Otto-Hahn-Ring', and house number (HNO) set to '6'. 🏠
No actions and transformation child elements are provided in this rule example. The actions and transformation could include presence-specific information when the Geolocation Policy framework is applied to the Presence Policy framework (see [RFC5025]). 🌈
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
<rule id="AA56i09">
<conditions>
<gp:location-condition>
<gp:location
profile="civic-condition"
xml:lang="en"
label="Siemens Neuperlach site 'Legoland'"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A4>Perlach</A4>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
</gp:location>
</gp:location-condition>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>7.2. Rule Example with Geodetic Location Condition
This example illustrates a rule that employs the geodetic location condition. The rule matches if the current location of the Target is inside the area specified by the polygon. The polygon uses the EPSG 4326 coordinate reference system. No altitude is included in this example. 🦋
<?xml version="1.0" encoding="UTF-8"?>
<ruleset
xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<rule id="BB56A19">
<conditions>
<gp:location-condition>
<gp:location
xml:lang="en"
label="Sydney Opera House"
profile="geodetic-condition">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-33.8570029378 151.2150070761</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">1500
</gs:radius>
</gs:Circle>
</gp:location>
</gp:location-condition>
</conditions>
<transformations/>
</rule>
</ruleset>7.3. Rule Example with Civic and Geodetic Location Condition
This example illustrates a rule that employs a mixed civic and geodetic location condition. Depending on the available type of location information, namely civic or geodetic location information, one of the location elements may match. 🎭
<?xml version="1.0" encoding="UTF-8"?>
<ruleset
xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<rule id="AA56i09">
<conditions>
<gp:location-condition>
<gp:location profile="civic-condition"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A4>Perlach</A4>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
</gp:location>
<gp:location profile="geodetic-condition">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.410649 150.87651</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">1500
</gs:radius>
</gs:Circle>
</gp:location>
</gp:location-condition>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>7.4. Rule Example with Location-Based Transformations ✨
okay so this example shows off all the transformations we just covered 💅 The <provide-civic> element says the civic location info gets blurred down to building level granularity 🏢 and if someone asks for geodetic location, the granularity reduction gets applied there too 🌍
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:lp="urn:ietf:params:xml:ns:basic-location-profiles">
<rule id="AA56i09">
<conditions/>
<actions/>
<transformations>
<gp:set-retransmission-allowed>false
</gp:set-retransmission-allowed>
<gp:set-retention-expiry>86400</gp:set-retention-expiry>
<gp:set-note-well xml:lang="en">My privacy policy goes here.
</gp:set-note-well>
<gp:keep-rule-reference>false
</gp:keep-rule-reference>
<gp:provide-location
profile="civic-transformation">
<lp:provide-civic>building</lp:provide-civic>
</gp:provide-location>
<gp:provide-location
profile="geodetic-transformation">
<lp:provide-geo radius="500"/>
</gp:provide-location>
</transformations>
</rule>
</ruleset>and this next rule is the shorthand 🫶 it makes the Target's current location available to Location Recipients with zero granularity reduction, so no blurring at all 🔥
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
<rule id="AA56ia9">
<conditions/>
<actions/>
<transformations>
<gp:provide-location/>
</transformations>
</rule>
</ruleset>7.5. Location Obfuscation Example 🙈
okay so picture this: you want to hide where people are in the continental USA 🇺🇸 let's walk through it step by step, bestie 🧚
Step 1:
First, you pick a geodesic projection 🗺️ if you're measuring location as latitude and longitude, the natural move is a rectangular projection. One latitudinal degree is about 110.6 kilometers, and a good approximation of a longitudinal degree at latitude phi is (pi/180)*M*cos(phi), where pi is approximately 3.1415 and M is the Earth's average meridional radius, approximately 6,367.5 km. For example, one longitudinal degree at 30 degrees (say, New Orleans) is 96.39 km, and the formula gives an estimate of 96.24, which is totally good enough for our purposes 💖
We're going to set up a grid not just for the continental USA but for the whole earth between latitudes 25 and 50 degrees, so it also covers the Mediterranean, South Europe, Japan, and the north of China 🌏 As we'll see below, the grid distortion (for not-too-large grids in this region) is approximately cos(25)/cos(50), which is 1.4099.
For our grid's origin, we pick the point at latitude 25 degrees and longitude 0 (Greenwich) 📍 Latitude 25 is just south of Florida, so it's south of the continental USA. (On the Southern Hemisphere, the origin should be north of the region being covered. If the region crosses the Equator, the origin should be on the Equator. That way, it's guaranteed that the latitudinal degree has the largest distance at the latitude of the origin.)
At 25 degrees, one degree east-west is approximately (pi/180)*M*cos(25) = 100.72 km ✨
The same procedure basically makes grids for:
- 45 degrees south to 45 degrees north: Tropics and subtropics, Africa, Australia
- 25 to 50 degrees (both north or south): Continental United States, Mediterranean, most of China; most of Chile and Argentina, New Zealand
- 35 to 55 degrees (both north or south): Southern and Central Europe
- 45 to 60 degrees (both north or south): Central and Northern Europe, Canada
- 55 to 65 degrees (both north or south): most of Scandinavia
- 60 to 70 degrees (both north or south): Alaska
Now here's the lowkey important bit 👀 we don't want to keep switching up the grid system, because that would leak more info about obscured locations when they're visited again and again. So the algorithm should prefer the grids above, with origin at the Greenwich meridian and at latitudes o=0, o=25, o=35, o=45, 0=55, and o=60 degrees (north), or at latitudes o=-25, o=-35, o=-45, 0=-55, and o=-60 degrees (the minus means "south") 🌸
Our choice for the continental USA is o=25 🇺🇸
For locations close to the poles, a different projection should be used (not discussed here) 🧊
Step 2:
To build the grid, we start at our chosen origin and place grid points at regular intervals along each axis (north-south and east-west), with a distance d between each one 📐
Let's make a grid for a desired uncertainty of d = 100km. At our origin, 100 km is roughly d1 = 100/100.72 = 0.993 degrees east-west, and d2 = 100/110.6 = 0.904 degrees north-south 🦋
(longitude = d1*i, latitude = 25+d2*j)The (i,j)-point in the grid (i and j are integers) has longitude d1*i and latitude 25+d2*j, measured in degrees. More generally, if the grid has origin at coordinates (0,o), measured in degrees, the (i,j)-point has coordinates (longitude = d1*i, latitude = o+d2*j). The grid has almost no distortion at the latitude of the origin, but it does get more distorted the further you go from it 🌈
The distance between two points in the grid at 25 degrees latitude is approximately 100 km, but just above the Canadian border, on the 50th degree, it's 0.993*(pi/180)*M*cos(50) = 70.92km. So the grid distortion is 100/70.92 = 1.41, which is acceptable (<1.5) ✅ (In the north-south direction, the grid has roughly no distortion. The vertical distance between two neighboring grid points is approximately 100 km.)
Step 3:
Now say you measure a position at M, with longitude -105 (the minus sign means 105 degrees west; without the minus, the point would be in China, 105 degrees east) and latitude 40 degrees (just north of Denver, CO) 🏔️ Point M is 105 degrees west and 15 degrees north of our origin (which has longitude 0 and latitude 25).
Let "floor" be the function that returns the largest integer smaller than or equal to a floating point number. To find SW, the closest grid point to the southwest of M=(m,n), we calculate:
i= floor(m/d1) = floor(-105/0.993) = -106
j= floor(n-o/d2) = floor(15/0.904) = 16Those are the indexes of SW on the grid. The coordinates of SW are then: (d1*i, 25+d2*j) = (-105.242, 39.467).
So:
l=d1*floor(m/d1) = -105.243
r=l+d1 = -105.243+0.993 = -104.250
b=o+d2*floor(n-o/d2) = 39.467
t=b+d2 = 39.467+0.904 = 40.371These are the formulas for l, r, b, and t in the general case of Cartesian projections based on latitude and longitude 🧠
Step 4:
Next, calculate x and y, the local coordinates of point M inside the small grid square that contains it. This part is easy 😌
x=(m-l)/(r-l) = [-105 -(-105.243)]/0.993 = 0.245
y=(n-b)/(t-b) = [40 - 39.467]/0.904 = 0.590Step 5:
First, compare x with p (0.2887) and 1-p (0.7113). x is smaller than p, so only cases 1, 4, or 6 could hold.
Also, compare y with p (0.2887) and 1-p (0.7113). y sits between them: p <= y < q. So we must be in case 4. To check, compare y (0.59) with x (0.245) and 1-x. y is larger than x and smaller than 1-x. We're in case C4 (p <= y < q and x <= y and y < 1-x) 🎯
Step 6:
Now we choose either SW or NW as the center of the circle 💅
The obscured location is the circle with radius 100 km and center at SW (coordinates: -105.243, 39.467) or NW (coordinates: -105.243, 40.371) 🫧
8. XML Schema for Basic Location Profiles 🎀
this section defines the location profiles that get used as child elements of the transformation element 💜
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:basic-location-profiles"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- profile="civic-transformation" -->
<xs:element name="provide-civic" default="none">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="building"/>
<xs:enumeration value="city"/>
<xs:enumeration value="region"/>
<xs:enumeration value="country"/>
<xs:enumeration value="none"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!-- profile="geodetic-transformation" -->
<xs:element name="provide-geo">
<xs:complexType>
<xs:attribute name="radius" type="xs:integer"/>
</xs:complexType>
</xs:element>
</xs:schema>9. XML Schema for Geolocation Policy ✨
okay so this section drops the full XML schema for the Geolocation Policy, which is basically the rulebook for how these policies are written 📜 It's built on top of the Common Policy schema from [RFC4745], so it's giving layers 🧁
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- Import Common Policy-->
<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- Geopriv Conditions -->
<xs:element name="location-condition"
type="gp:locationconditionType"/>
<xs:complexType name="locationconditionType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="location" type="gp:locationType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="locationType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="profile" type="xs:string"/>
<xs:attribute name="label" type="xs:string"/>
<xs:attribute ref="xml:lang" />
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- Geopriv transformations -->
<xs:element name="set-retransmission-allowed"
type="xs:boolean" default="false"/>
<xs:element name="set-retention-expiry"
type="xs:integer" default="0"/>
<xs:element name="set-note-well"
type="gp:notewellType"/>
<xs:element name="keep-rule-reference"
type="xs:boolean" default="false"/>
<xs:element name="provide-location"
type="gp:providelocationType"/>
<xs:complexType name="notewellType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="providelocationType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="profile" type="xs:string" />
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>10. XCAP Usage 🎀
this section is all about how clients can manage geolocation privacy documents on a server using XCAP 💌 If it's being used as part of a presence system, it uses the same Application Unique ID (AUID) as those rules. For the presence side of things, check out [RFC5025] 🦋
10.1. Application Unique ID
XCAP needs application usages to define a unique Application Unique ID (AUID), either in the IETF tree or a vendor tree. This specification defines the "geolocation-policy" AUID in the IETF tree, through the IANA registration in Section 11. 🔑
10.2. XML Schema
XCAP also needs application usages to define a schema for their documents. The schema for geolocation authorization documents is described in Section 9. 📐
10.3. Default Namespace
Every application usage has to define the default namespace for its documents, and for this one it's urn:ietf:params:xml:ns:geolocation-policy 🌈
10.4. MIME Media Type
XCAP needs application usages to define the MIME media type for documents they carry. Geolocation privacy authorization documents inherit the MIME type of Common Policy documents, which is application/auth-policy+xml 💜
10.5. Validation Constraints
This specification does not define additional constraints. Nothing extra to see here, bestie 🙈
10.6. Data Semantics
This document discusses the semantics of a geolocation privacy authorization. 🧠
10.7. Naming Conventions
When a Location Server gets a request to access location information of some user foo, it looks for all documents within http://[xcaproot]/geolocation-policy/users/foo and uses every document it finds beneath that point to guide the authorization policy. So the path tells the server where to look 🗺️✨
10.8. Resource Interdependencies
This application usage does not define additional resource interdependencies. No extra drama here 💅
10.9. Authorization Policies
This application usage doesn't change the default XCAP authorization policy, which says that only a user can read, write, or modify his/her own documents. A server can let privileged users change documents they don't own, but how those policies get set up and shown is outside the scope of this document. That's a server decision, not a spec one 🔐
11. IANA Considerations 🌸
there are a few IANA considerations for this specification, so here's the paperwork 📝
11.1. Geolocation Policy XML Schema Registration
This section registers an XML schema in the IETF XML Registry, following the guidelines in [RFC3688].
URI: urn:ietf:params:xml:schema:geolocation-policy
Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), Hannes Tschofenig (hannes.tschofenig@nsn.com).
XML: The XML schema to be registered is contained in Section 9. Its first line is
<?xml version="1.0" encoding="UTF-8"?>and its last line is
</xs:schema>11.2. Geolocation Policy Namespace Registration
This section registers a new XML namespace in the IETF XML Registry, following the guidelines in [RFC3688] 🫶
URI: urn:ietf:params:xml:ns:geolocation-policy
Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), Hannes Tschofenig (hannes.tschofenig@nsn.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Geolocation Policy Namespace</title>
</head>
<body>
<h1>Namespace for Geolocation Authorization Policies</h1>
<h2>urn:ietf:params:xml:schema:geolocation-policy</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6772.txt">
RFC 6772</a>.</p>
</body>
</html>
END11.3. Geolocation Policy Location Profile Registry
This document creates a registry of location profile names for the Geolocation Policy framework. Profile names are XML tokens. This registry will operate under RFC 5226 [RFC5226], Specification Required, which is giving very official vibes 📋
This document defines the following profile names:
geodetic-condition: Defined in Section 4.1.civic-condition: Defined in Section 4.2.geodetic-transformation: Defined in Section 6.5.2.civic-transformation: Defined in Section 6.5.1.
11.4. Basic Location Profile XML Schema Registration
This section registers an XML schema in the IETF XML Registry, following the guidelines in [RFC3688] 🗂️
URI: urn:ietf:params:xml:schema:basic-location-profiles
Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), Hannes Tschofenig (hannes.tschofenig@nsn.com).
XML: The XML schema to be registered is contained in Section 8. Its first line is
<?xml version="1.0" encoding="UTF-8"?>and its last line is
</xs:schema>11.5. Basic Location Profile Namespace Registration
This section registers a new XML namespace in the IETF XML Registry, following the guidelines in [RFC3688] 🌷
URI: urn:ietf:params:xml:ns:basic-location-profiles
Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), Hannes Tschofenig (hannes.tschofenig@nsn.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Basic Location Profile Namespace</title>
</head>
<body>
<h1>Namespace for Basic Location Profile</h1>
<h2>urn:ietf:params:xml:schema:basic-location-profiles</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6772.txt">
RFC 6772</a>.</p>
</body>
</html>
END11.6. XCAP Application Usage ID
This section registers an XCAP Application Unique ID (AUID) in the "XML-XCAP Application Unique IDs" registry, following the IANA procedures defined in [RFC4825] 🎟️
Name of the AUID: geolocation-policy
Description: Geolocation privacy rules are documents that describe the permissions that a Target has granted to Location Recipients that access information about his/her geographic location. 📍
12. Internationalization Considerations 🌍
the policies in this document are mostly for machine-to-machine talk, so a lot of the elements are tokens that aren't really meant for humans to read 🤖 If those tokens do end up in front of an end user, some localization might need to happen. The policies are still supposed to be made with humans in the loop though, so some elements and attributes do need internationalization thinking 💖 The content of the <label> element is provided by a human (the Rule Maker) and is also shown to a human. The location condition element (<location-condition>, using the civic location profile, see Section 4.2) and the <set-note-well> element (see Section 6.3) can both contain non-US-ASCII letters, so accents and emoji-adjacent vibes are welcome 🫶
The geolocation policies use XML, and all XML processors are required to understand UTF-8 and UTF-16 encodings. That means every entity that processes these policies MUST understand UTF-8- and UTF-16-encoded XML. On top of that, geolocation policy-aware entities MUST NOT encode XML with any encoding other than UTF-8 or UTF-16. Super strict, but it keeps things clean 🧼✨
13. Security Considerations 🔐
13.1. Introduction 💖
okay so this doc is all about letting users stop unauthorized peeps from getting their location info, and letting them limit who sees stuff based on where the Target is, using location-based conditions 📍. It's done with authorization policies 🔐. This work is built on a bunch of other docs: the security requirements live in [RFC6280], and a chat about generic security threats is in [RFC3694]. How permissions combine when there are multiple occurrences is covered in [RFC4745] 🧩.
Beyond the authorization policies, there are also ways to obfuscate location info 🌫️. Theory on location obfuscation is in [DUCKHAM05] and [IFIP07]. [DUCKHAM05] is the foundation, and [IFIP07] shows three types of obfuscation: enlarging the radius, shifting the center, and reducing the radius 🎯. The algorithm in Section 6.5.2 for geodetic location information obfuscation uses these techniques ✨.
Privacy needs for location info vary a LOT 💅. The two obfuscation algorithms in this doc give a basis for protecting against unauthorized disclosure of location info, but they do have limitations 🙈. Apps and users have wildly different needs, so there's an extension mechanism that supports defining and using different algorithms 🦋.
13.2. Obfuscation 🌸
Whenever location info gets returned to a Location Recipient, it includes the Target's location 👀. That's still true when the location is obfuscated, meaning the Location Server doesn't lie about where the Target is, it just hides them inside a bigger location shape 🫣. Even when the Target isn't moving, info can leak over time 😭. The Target's location might not be revealed within one particular grid region, but the size of that returned region matters too, along with exactly where the Target sits inside it 📐. Location shapes that are randomly computed will, over time, reveal more and more about the Target 💀.
Check out Figure 1 🧐. It shows three ellipses, a dotted area in the middle, and the Target's true location marked as 'x'. The ellipses are the location shapes a potential Location Recipient gets over time when asking for a Target's location info. Collecting that info over time lets the Location Recipient narrow the Target's potential location down to the dotted area in the center 🕵️♀️.
This is exactly why the algorithm in Section 6.5.2 uses a grid that makes sure the same location info is reported while the Target stays in the same geographical area 🗺️.
,-----.
,----,-'. `-.
,-' / `-. \
,' / _...._ `. \
/ ,-'......`._\ :
; /|...........\: |
| / :.....x......+ ;
: | \...........;| /
\ | \........./ | /
`. \ `-.....,' ,''
'-.\ `-----'|
``.-----' ,'
`._ _,'
`'''
Figure 1: Obfuscation: A Static TargetAn obscuring method that gives different results for consecutive requests can be exploited by recipients who want to use that property 😤. Rate limiting how often new obscured locations get generated, or giving the same obscured location to recipients for the same location, might limit the info that can be obtained 🚦. BUT note that providing a new obscured location based on a change in location gives some info away when recipients see the location change 👀.
When the Target is moving, the location transformations reveal info when switching from one privacy region to another 🚶♀️. Like, if a transformation says civic location is given at a 'building' level of granularity, floor levels, room numbers, and other details normally inside a building get hidden 🏢. However, when the Target moves from one building to the next, the movement is still recognizable, because the disclosed location info reflects the new civic location indicating the new building 🏃♀️💨. With extra knowledge about building entrances and floor plans, it'd be possible to learn even more 🤯.
13.3. Algorithm Limitations 🚨
The algorithm in Section 6.5.2 has some issues where info leaks: when moving, when switching from one privacy region to another, and also when a user regularly visits the same location 😩.
The first issue pops up if the algorithm only provides different location info (privacy region) once the previous one stops applying. The algorithm discloses new info the moment the Target is on the border of the old privacy region 🫠.
Another issue shows up if the algorithm produces different values for the same location that gets visited again and again 🏠. Say a user goes home every night 🌙. If the reported obfuscated locations are all randomly chosen, an analysis can reveal the home location with high precision 💥.
On top of that, combining an obscured location with public geographic info (highways, lakes, mountains, cities, etc.) may yield way more precise location info than anyone wants 🗻. But even without that, just observing movements, once or multiple times, means any obscuring algorithm can leak info about velocities or positions 🏎️💨. Say a user wants to disclose location info with a radius of r. The privacy region, a circle with that radius, has an area of A = pi * r^2 📏. An adversary observing the movements will deduce that the target is visiting, was visiting, or regularly visits, a region of size A1, which is smaller than A 👁️. The ratio A1/A should be, even in the worst case, larger than a fixed known number, so the user can predict the worst-case info leakage 🧮. The choices in Section 6.5.2 are such that this maximum leakage can be established: by any statistical procedures, without using external info (highways, etc., as discussed above), the quotient A1/A is larger than 0.13 (= 1/(5*1.5) ) 🎲. So, for instance, when choosing a provided location of size 1000 km^2, he will be leaking, in the worst case, the location within a region of size 130 km^2 😬.
13.4. Usability 🎀
There's a risk that end users write location-based policies in a way where very small changes in location give a significantly different level of info disclosure 😵💫. For example, a user might want to set authorization policies differently when they're in a specific area, like at home or in the office 🏡. Location might be the only factor in the policy that triggers a totally different action and transformation to run 🎬. The accuracy of location info isn't always good enough to unequivocally tell whether a location is inside a specific boundary [GEOPRIV-UNCERTAINTY] 🎯. In some situations, uncertainty in location info could produce unexpected results for end users 🫨. Giving users adequate feedback about potential errors from these limitations can help prevent unintentional info leakage 💡.
Users might create policies that make no sense 🤪. To avoid that, the software used to create the authorization policies should perform consistency checks, and when policies get uploaded to the policy servers, further checks can be done 🛡️. When XCAP is used to upload authorization policies, built-in XCAP features can carry error messages back to the user about an error condition 📨. Section 8.2.5 of [RFC4825] says some degree of application-specific checking is provided when authorization policies are added, modified, or deleted 🧐. The XCAP protocol may return a 409 response, which may contain a detailed conflict report with the <constraint-failure> element 🚫. A human-readable description of the problem can be put in the phrase attribute of that element 📝.
13.5. Limitations of Obscuring Locations 🫣
Location obscuring tries to remove info about the location of a Target 🙈. How effective it is depends on how much uncertainty a Location Recipient has about where the Target is 🌫️. A location-obscuring algorithm is effective if the Location Recipient can't recover a location with better uncertainty than the obscuring algorithm was told to add 🔒.
Effective location obscuring is hard 😤. The amount of info a determined and resourceful Location Recipient can recover may be way more than what's obvious at first glance 🔍. A concise summary of the challenges is in [DUCKHAM10] 📚.
A Location Recipient that has external info about the Target or the reported geographical area can make assumptions or guesses using that info to recover more accurate location info 🧠. This is true even when only a single location is reported, but it's especially true when multiple locations are reported for the same Target over time ⏳.
Also, a Location Recipient that tries to recover past locations for a Target can use later-reported locations to refine any recovered location further 🕰️. A location-obscuring algorithm typically doesn't know anything about the Target's future location 🔮.
How well location info can be degraded by an obscuring algorithm depends on the info the algorithm uses 📊. If the info available to the obscuring algorithm is both more extensive and more effectively used than the info available to the Location Recipient, then location obscuring might be effective 💪.
Obscured locations can still be useful where a Location Recipient wants to respect privacy 🫶. A privacy-respecting Location Recipient can choose to read the existence of uncertainty as a request from a Rule Maker not to recover location 🙏.
Location obscuring probably won't work against a more determined or resourceful adversary 😈. Withholding location info entirely is perhaps the most effective way to make sure it doesn't get recovered 🛑.
As a final caution: omitted data also conveys some info! 🚨 Selectively withholding info reveals that there's something worth hiding, and that can be used to reveal some of the info being withheld. For example, if location is only obscured around a user's home and office, then the lack of location for that user at a given time will likely mean they're at home at night and in the office during the day, which defeats the purpose of the controls 💀.
14. References ✨
14.1. Normative References
okay so these are the references the spec literally can't function without 💅 they're the must-reads, bestie 📚
- [GML] OpenGIS, "OpenGIS Geography Markup Language (GML) Implementation Specification, Version 3.1.1, OGC 03-105r1", July 2004,
<http://portal.opengeospatial.org/files/?artifact_id=4700>. - [NIMA.TR8350.2-3e] "Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition", NIMA TR8350.2, January 2000.
- [OGC-06-103r4] OpenGIS, "OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture", May 2011,
<http://www.opengeospatial.org/standards/sfa?>. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
- [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
- [RFC4745] 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. 🔒
- [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
- [RFC5491] 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. ✨
14.2. Informative References
these ones are the extra reading 🧠 super useful for the full picture, but the spec itself doesn't need them to work, so no pressure 🫶
- [DUCKHAM05] Duckham, M. and L. Kulik, "A Formal Model of Obfuscation and Negotiation for Location Privacy", In Proc. of the 3rd International Conference PERVASIVE 2005, Munich, Germany, May 2005. 🗺️
- [DUCKHAM10] Duckham, M., "Moving Forward: Location Privacy and Location Awareness", In Proc. 3rd ACM SIGSPATIAL Workshop on Security and Privacy in GIS and LBS (SPRINGL), ACM, November 2010.
- [GEO-SHAPE] Thomson, M., "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO", Work in Progress, December 2006.
- [GEOPRIV-UNCERTAINTY] Thomson, M. and J. Winterbottom, "Representation of Uncertainty and Confidence in PIDF-LO", Work in Progress, March 2012.
- [IFIP07] Ardagna, C., Cremonini, M., Damiani, E., De Capitani di Vimercati, S., and P. Samarati, "Location Privacy Protection through Obfuscation-Based Techniques", Proceedings of the 21st Annual IFIP WG 11.3 Working Conference on Data and Applications Security, Redondo Beach, CA, USA, July 2007.
- [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
- [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. 💬
- [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004. 🕵️
- [RFC4079] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005.
- [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
- [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
- [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011. 🏛️
Appendix A. Acknowledgments
okay the shoutouts 🎀 this part is so sweet
This document is informed by the discussions within the IETF GEOPRIV working group, including discussions at the GEOPRIV interim meeting in Washington, D.C., in 2003. 🌸
We really want to thank Allison Mankin <mankin@psg.com>, Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, and Jon Peterson <jon.peterson@neustar.biz> for helping make this document so much better 🙌
We'd also love to thank Christian Guenther for helping with an earlier version of this document. Johnny Vrancken gets a big thank you for his document reviews in September 2006, December 2006 and January 2007. James Winterbottom gave a super detailed review in November 2006, and Richard Barnes did the same in February 2008. 📝
This document uses text from "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO" [GEO-SHAPE], written by Martin Thomson. 🙏
Matt Lepinski and Richard Barnes get props for their comments on the geodetic location transformation procedure, and Richard even wrote a detailed text proposal for us 👏
Robert Sparks and Warren Kumari deserve so much love for their input on the location obfuscation discussion. Robert implemented several versions of the algorithm in the graphical language "Processing", which helped everyone really understand the problems with the algorithm that was illustrated before. He's literally the reason we get it now 💜
Thank you to Dan Romascanu, Yoshiko Chong, and Jari Urpalainen for their last call comments 🫶
And finally, a huge thank you to the following people for their feedback during the IESG, GenArt, and SecDir reviews: Jari Arkko, Lisa Dusseault, Eric Gray, Sam Hartman, Russ Housley, Cullen Jennings, Chris Newman, Jon Peterson, Tim Polk, Carl Reed, and Brian Rosen. You're all iconic 👑
Although John Morris is currently employed by the U.S. Government, he participated in the development of this document in his personal capacity, and the views expressed in the document may not reflect those of his employer. 🧾
Appendix B. Pseudocode 🧚
okay bestie, this appendix is the algorithm from 6.5.2 and 7.5 written out as pseudocode 💅 It's informal, so it's not a strict spec, but it shows exactly how the math works. There's also a bonus: it randomly picks between landmarks that are the same distance away, based on where the last location was. so cute 🦋
Constants
P = sqrt(3)/6 // approx 0.2887
q = 1 - p // approx 0.7113
Parameters
prob: real // prob is a parameter in the range
// 0.5 <= prob <=1
// recommended is a value for prob between 0.7 and 0.9
// the default of prob is 0.8
Inputs
M = (m,n) : real * real
// M is a pair of reals: m and n
// m is the longitude and n the latitude,
// respectively, of the measured location
// The values are given as real numbers, in the
// range: -180 < m <= 180; -90 < n < 90
// minus values for longitude m correspond to "West"
// minus values for latitude n correspond to "South"
radius : integer // the 'radius' or uncertainty,
// measured in meters
prev-M = (prev-m1, prev-n1): real * real
// the *previously* provided location, if available
// prev-m1 is the longitude and
// prev-n1 the latitude, respectively
o : real
// this is the reference latitude for the geodesic projection
// The value of 'o' is chosen according to the table below.
// The area you want to project MUST be included in
// between a minimal latitude and a maximal latitude
// given by the two first columns of the table.
// (Otherwise the transformation is not available).
// +------+------+--------------------------+-------+
// | min | max | | |
// | lat | lat | Examples | o |
// +------+------+--------------------------+-------+
// | | | Tropics and subtropics | |
// | -45 | 45 | Africa | 0 |
// | | | Australia | |
// +------+------+--------------------------+-------+
// | | | Continental US | |
// | 25 | 50 | Mediterranean | 25 |
// | | | most of China | |
// +------+------+--------------------------+-------+
// | | | | |
// | 35 | 55 | Southern and Central | 35 |
// | | | Europe | |
// +------+------+--------------------------+-------+
// | | | | |
// | 45 | 60 | Central and Northern | 45 |
// | | | Europe | |
// +------+------+--------------------------+-------+
// | | | | |
// | 55 | 65 | most of Scandinavia | 55 |
// | | | | |
// +------+------+--------------------------+-------+
// | | | | |
// | 60 | 70 | | 60 |
// | | | | |
// +------+------+--------------------------+-------+
// | | | most of | |
// | -50 | -25 | Chile and Argentina | -50 |
// | | | New Zealand | |
// +------+------+--------------------------+-------+
// | | | | |
// | -35 | -55 | | -35 |
// | | | | |
// +------+------+--------------------------+-------+
// | | | | |
// | -45 | -60 | | -45 |
// | | | | |
// +------+------+--------------------------+-------+
// | | | | |
// | -55 | -65 | | -55 |
// | | | | |
// +------+------+--------------------------+-------+
// | | | | |
// | -60 | -70 | | -60 |
// | | | | |
// +------+------+--------------------------+-------+
Outputs
M1 = (m1,n1) : real * real // longitude and latitude,
// respectively, of the provided location
Local Variables
d, d1, d2, l, r, b, t, x, y: real
SW, SE, NW, NE: real * real
// pairs of real numbers, interpreted as coordinates
// longitude and latitude, respectively
temp : Integer[1..8]
Function
choose(Ma, Mb: real * real): real * real;
// This function chooses either Ma or Mb
// depending on the parameter 'prob'
// and on prev-M1, the previous value of M1:
// If prev-M1 == Ma choose Ma with probability 'prob'
// If prev-M1 == Mb choose Mb with probability 'prob'
// Else choose Ma or Mb with probability 1/2
Begin
rand:= Random[0,1];
// a real random number between 0 and 1
If prev-M1 == Ma Then
If rand < prob Then choose := Ma;
Else choose := Mb; EndIf
Elseif prev-M1 == Mb Then
If rand < prob Then choose := Mb;
Else choose := Ma; EndIf
Else
If rand < 0.5 Then choose := Ma;
Else choose := Mb; EndIf
End // Function choose
Main // main procedure
Begin
d := radius/1000; // uncertainty, measured in km
d1:= (d * 180) / (pi*M*cos(o));
d2:= d / 110.6;
l := d1*floor(m/d1)
// "floor" returns the largest integer
// smaller or equal to a floating point number
r := l+d1;
b := o+d2*floor(n-o/d2);
t := b+d2;
x := (m-l)/(r-l);
y := (n-b)/(t-b);
SW := (l,b);
SE := (r,b);
NW := (l,t);
NE := (r,t);
If x < p and y < p Then M1 := SW;
Elseif x < p and q <= y Then M1 := NW;
Elseif q <= x and y < p Then M1 := SE;
Elseif q <= x and q <= y Then M1 := NE;
Elseif p <= x and x < q and y < x and y < 1-x
Then M1 := choose(SW,SE);
Elseif p <= y and y < q and x <= y and y < 1-x
Then M1 := choose(SW,NW);
Elseif p <= y and y < q and y < x and 1-x <= y
Then M1 := choose(SE,NE);
Elseif p <= x and x < q and x <= y and 1-x <= y
Then M1 := choose(NW,NE);
Endif
End // MainAuthors' Addresses 💖
here are the people who wrote this one, with all their contact deets 🎀
Henning Schulzrinne (editor)
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212-939-7042
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Hannes Tschofenig (editor)
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Jorge R. Cuellar
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Jorge.Cuellar@siemens.com
James Polk
Cisco
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
Phone: +1 817-271-3552
EMail: jmpolk@cisco.com
John B. Morris, Jr.
EMail: ietf@jmorris.org
Martin Thomson
Microsoft
3210 Porter Drive
Palo Alto, CA 94304
USA
Phone: +1 650-353-1925
EMail: martin.thomson@gmail.com📦 where this page comes from
- ietf: rfc6772 2013-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms