Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
Extracted elements (29)
An extension mechanism (the Location Profile Registry) is defined rather than mandating a single obfuscation algorithm, because no single algorithm suits all application domains. The registry with Specification Required policy allows future algorithms to be added as requirements evolve.
The geodetic obfuscation algorithm uses a fixed grid of landmarks rather than randomly computed regions to prevent incremental information leakage. Random obfuscation reveals more and more about the Target's location over time (illustrated by the intersecting ellipses figure); a fixed grid ensures the same location is reported for all requests while the Target remains in the same cell.
If an extension element within <location-condition> is not understood by the rule evaluator, the entire rule evaluates to FALSE. However, a <location-condition> is considered TRUE if any <location> element understood by the evaluator is TRUE, allowing partial forward compatibility.
When used as part of a presence system, geolocation policy documents use the same XCAP AUID ('geolocation-policy') and inherit the MIME type application/auth-policy+xml from Common Policy (RFC 4745). Geolocation policy is aligned with the presence architecture per RFC 4079, so Presence Servers act as Location Servers.
All entities processing geolocation policies MUST understand UTF-8- and UTF-16-encoded XML, and MUST NOT encode XML with encodings other than UTF-8 or UTF-16.
If <keep-rule-reference> is FALSE, the <external-ruleset> element in the PIDF-LO MUST NOT contain a reference to an external rule set, and references are removed including any MIME body cid: URIs. If absent and the PIDF-LO is created for the first time, the <external-ruleset> element MUST NOT be included.
If <set-retransmission-allowed> is TRUE, the PIDF-LO <retransmission-allowed> MUST be set to TRUE; if FALSE, it MUST be set to FALSE. If absent and the PIDF-LO is created for the first time, the value MUST be set to FALSE.
Implementations MUST specify the CRS using the 'srsName' attribute on the outermost geometry element. The CRS MUST NOT be changed for any sub-elements. The 'srsDimension' attribute MUST be omitted.
Implementations MUST support the WGS 84 coordinate reference system (urn:ogc:def:crs:EPSG::4326, 2D) for geodetic location conditions. A CRS MUST be specified using this URN notation only; user-defined CRSs need not be supported.
It is RECOMMENDED that a Location Server not apply a translation from geodetic location to civic location (geocoding) when evaluating a civic-condition profile.
The <location-condition> element MUST contain at least one <location> child element.
The map distortion (ratio of maximal to minimal scale) for the geodesic projection used in the geodetic obfuscation algorithm MUST be below 1.5.
The <provide-location> element MUST contain the 'profile' attribute if it contains child elements, and child elements MUST be appropriate for the declared profile.
A geolocation authorization document is an XML document formatted according to the Common Policy schema (RFC 4745), using the media type application/auth-policy+xml. Each rule contains three parts: conditions, actions, and transformations. Permissions are positive grants of information, so the absence of any permission results in less information being disclosed.
The civic location condition profile (token: 'civic-condition') uses a <civicAddress> element (RFC 5139) within <location>. All child elements of the <location> are combined with logical AND; each child element is compared by octet-by-octet string comparison to the Target's civic location. The condition evaluates to FALSE if the Target has no civic address.
The civic-transformation profile uses the <provide-civic> element with levels: 'none', 'country', 'region', 'city', 'building', and 'full'. Each level is a superset of all lower levels (e.g., 'city' includes country, A1, A2, A3). The default value is 'none'.
The geodetic location condition profile (token: 'geodetic-condition') uses a GML <Circle> element within <location>. The condition evaluates to TRUE if the Target's current location is completely within the described location. If the Target's geodetic location is unknown, the condition evaluates to FALSE.
The geodetic-transformation profile uses the <provide-geo> element with a 'radius' attribute (integer, in meters). The six-step algorithm maps a measured location M to one of four grid landmarks (SW, SE, NW, NE) and returns a circle of the specified radius centered on that landmark, ensuring consistent obfuscation while the Target remains in the same grid cell.
The <location-condition> element contains one or more <location> child elements. Multiple <location> elements are combined with logical OR (the condition is TRUE if any child matches the Target's location). Multiple <location-condition> elements within <conditions> are combined with logical AND.
The <provide-location> element controls the granularity of returned location information (obfuscation). It may contain a <provide-civic> child (civic-transformation profile) or a <provide-geo> child (geodetic-transformation profile). If it has no child elements, full civic and geodetic location is disclosed without granularity reduction and the 'profile' attribute MUST NOT be included.
The <set-note-well> transformation (string with xml:lang attribute) sets a human-readable privacy statement in the PIDF-LO <note-well> element. If absent and the PIDF-LO is newly created, no content is provided for <note-well>.
The <set-retention-expiry> transformation (non-negative integer, in seconds) is added to the time the LS provides location to compute the <retention-expiry> in the PIDF-LO. A value of zero requests that the information not be retained. If absent and the PIDF-LO is newly created, the value MUST be set to the current date.
The <set-retransmission-allowed> transformation (boolean) controls the <retransmission-allowed> element in the PIDF-LO. If absent and the PIDF-LO is newly created, the value MUST default to FALSE.
This document creates the 'Geolocation Policy Location Profile Registry' operating under RFC 5226 Specification Required policy. Initial entries are: geodetic-condition (Section 4.1), civic-condition (Section 4.2), geodetic-transformation (Section 6.5.2), and civic-transformation (Section 6.5.1).
This document registers the XML schema urn:ietf:params:xml:schema:basic-location-profiles and namespace urn:ietf:params:xml:ns:basic-location-profiles in the IETF XML Registry, and registers the XCAP AUID 'geolocation-policy' in the XML-XCAP Application Unique IDs registry.
Location obfuscation does not prevent information leakage over time. Even when returning consistent grid-based regions, a Location Recipient can narrow down the Target's true location by collecting multiple reports. The geodetic algorithm mitigates this by returning the same obscured location while the Target stays in the same grid cell, but transitions between cells still reveal movement.
Location obscuring is unlikely to be effective against a determined or resourceful adversary. Withholding location entirely is the most effective privacy protection. Selective withholding itself conveys information: if location is only obscured around a user's home and office, the absence of location at specific times reveals the user's presence at those locations.
The geodetic obfuscation algorithm has inherent leakage: the maximum statistical leakage ensures A1/A > 0.13 (= 1/(5*1.5)), meaning for a provided location of size 1000 km², the Target's location may be recoverable within ~130 km². Combination with public geographic information (roads, lakes, buildings) can yield even more precise recovery.
Usability risks arise when very small location changes trigger significantly different disclosure levels. Location uncertainty may produce unexpected policy evaluation results. Software creating authorization policies should perform consistency checks, and XCAP's 409 conflict response with <constraint-failure> can communicate errors back to users.