| GEOPRIV | H. Schulzrinne, Ed. |
| Internet-Draft | Columbia University |
| Intended status: Standards Track | H. Tschofenig, Ed. |
| Expires: February 20, 2013 | Nokia Siemens Networks |
| J. Cuellar | |
| Siemens | |
| J. Polk | |
| Cisco | |
| J. Morris | |
| M. Thomson | |
| Microsoft | |
| August 21, 2012 |
Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.
Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information while the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 20, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Location information needs to be protected against unauthorized access to preserve the privacy of humans. In RFC 6280 [RFC6280], a protocol-independent model for access to geographic information is defined. The model includes a Location Generator (LG) that determines location information, a Location Server (LS) that authorizes access to location information, a Location Recipient (LR) that requests and receives location information, and a Rule Maker (RM) that writes authorization policies. An authorization policy is a set of rules that regulates an entity's activities with respect to privacy-sensitive information, such as location information.
The data object containing location information in the context of this document is referred to as a Location Object (LO). The basic rule set defined in the Presence Information Data Format Location Object (PIDF-LO) [RFC4119] can restrict how long the Location Recipient is allowed to retain the information, and it can prohibit further distribution. It also contains a reference to an enhanced rule set and a human readable privacy policy. The basic rule set does not access to location information. This document describes an enhanced rule set that provides richer constraints on the distribution of LOs.
The enhanced rule set allows the entity that uses the rules defined in this document to restrict the retention and to enforce access restrictions on location data, including prohibiting any dissemination to particular individuals, during particular times or when the Target is located in a specific region. The RM can also stipulate that only certain parts of the Location Object are to be distributed to recipients or that the resolution is reduced for parts of the Location Object.
In the typical sequence of operations, a Location Server receives a query for location information for a particular Target. The requestor's identity will likely be revealed as part of this request for location information. The authenticated identity of the Location Recipient, together with other information provided with the request or generally available to the server, is then used for searching through the rule set. If more than one rule matches the condition element, then the combined permission is evaluated according to the description in Section 10 of [RFC4745]. The result of the rule evalation is applied to the location information, yielding a possibly modified Location Object that is delivered to the Location Recipient.
This document does not describe the protocol used to convey location information from the Location Server to the Location Recipient.
This document extends the Common Policy framework defined in [RFC4745]. That document provides an abstract framework for expressing authorization rules. As specified there, each such rule consists of conditions, actions and transformations. Conditions determine under which circumstances the entity executing the rules, such as a Location Server, is permitted to apply actions and transformations. Transformations regulate in a location information context how a Location Server modifies the information elements that are returned to the requestor by, for example, reducing the granularity of returned location information.
This document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information (see Section 6.5.1) while the other one applies to geodetic location information (see Section 6.5.2). Both algorithms come with limitations, i.e. they provide location obfuscation under certain conditions and may therefore not be appropriate for all application domains. These limitations are documented within the security consideration section (see Section 13). It is worth pointing out that the geodetic transformation algorithm Section 6.5.2 deals with privacy risks related to targets that are stationary, as well as to moving targets. However, with respect to movement there are restriction as to what information can be hidden from an adversary. To cover applications that have more sophisticated privacy requirements additional algorithms may need to be defined. This document forsees extensions in the form of new algorithms and therefore defines a registy (see Section 11.3).
The XML schema defined in Section 9 extends the Common Policy schema by introducing new child elements to the condition and transformation elements. This document does not define child elements for the action part of a rule.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses the terminology of RFC 6280 [RFC6280], such as Location Server (LS), Location Recipient (LR), Rule Maker (RM), Target, Location Generator (LG) and Location Object (LO). This document uses the following terminology:
In this document we use the term Location Servers as the entities that evaluate the geolocation authorization policies. The geolocation privacy architecture is, as described in RFC 4079 [RFC4079], aligned with the presence architecture and a Presence Server is therefore an entity that distributes location information along with other presence-specific XML data elements.
A geolocation authorization document is an XML document, formatted according to the schema defined in [RFC4745]. Geolocation authorization documents inherit the media type of common policy documents, application/auth-policy+xml. As described in [RFC4745], this document is composed of rules which contain three parts - conditions, actions, and transformations. Each action or transformation, which is also called a permission, has the property of being a positive grant of information to the Location Recipient. As a result, there is a well-defined mechanism for combining actions and transformations obtained from several sources. This mechanism is privacy enabling, since the lack of any action or transformation can only result in less information being presented to a Location Recipient.
There are two ways the authorization rules described in this document may be conveyed between different parties:
This section describes the location-specific conditions of a rule. The <conditions> element contains zero or more <location-condition> child element(s). The >conditions> element only evaluates to TRUE if all child elements evaluate to TRUE, therefore multiple <location-condition> elements are not normally useful.
The <location-condition> element MUST contain at least one <location> child element. The <location-condition> element evaluates to TRUE if any of its child >location> elements matches the location of the target, i.e., >location> elements are combined using a logical OR.
The three attributes of <location> are 'profile', 'xml:lang' and 'label'. The 'profile' indicates the location profile that is included as child elements in the <location> element. Two location profiles, geodetic and civic, are defined in Section 4.1 and Section 4.2. Each profile describes under what conditions a <location> element evaluates to TRUE.
The 'label' attribute allows a human readable description to be added to each <location> element. The 'xml:lang' attribute contains a language tag providing further information for rendering of the content of the 'label' attribute.
The <location-condition> and the <location> elements provide extension points. An extension that is not understood by the entity evaluating the rules then this rule evaluates to FALSE. This causes a >conditions> element to evaluate to FALSE if a >location-condition> element is unsupported, but allows a >location-condition> to be TRUE if an child >location> is not understood as long as an understoof >location> is TRUE.
The geodetic location profile is identified by the token 'geodetic-condition'. Rule Makers use this profile by placing a GML [GML] <Circle> element within the <location> element (as described in Section 5.2.3 of [RFC5491]).
The <location> element containing the information for the geodetic location profile evaluates to TRUE if the current location of the Target 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 containing the information for the geodetic location profile evaluates to FALSE.
Implementations MUST support the 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)):
A CRS MUST be specified using the above URN notation only, implementations do not need to support user-defined CRSs.
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, since the number of dimensions in these CRSs is known.
The civic location profile is identified by the token 'civic-condition'. Rule Makers use this profile by placing a <civicAddress> element, defined in [RFC5139], within the <location> element.
All child elements of <location> element that carry <civicAddress> elements MUST evaluate to TRUE (i.e., logical AND) in order for the <location> element to evaluate to TRUE. For each child element, the value of that element is 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 based on a octet-by-octet comparison.
A <location> element containing a >civic-condition> profile evaluates to FALSE if a civic address is not present for the Target. For example, this could occur if location information has been removed by other rules or other transmitters of location information or if only the geodetic location is known. In general, it is RECOMMENDED behavior for a LS not to apply a translation from geodetic location to civic location (i.e., geocode the location).
This document does not define location-specific actions.
This document defines several elements that allow Rule Makers to specify transformations that
This element specifies a change to or the creation of 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 set to TRUE then the <retransmission-allowed> element in the PIDF-LO MUST be set to TRUE. If the value of the <set-retransmission-allowed> element is set to 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.
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 provided with the <set-retention-expiry> element indicates seconds and these seconds are 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.
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 contains a privacy statement as a human readable text string and an 'xml:lang' attribute denotes the language of the human readable text.
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.
This transformation specifies 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 set to TRUE, then the <external-ruleset> element in the PIDF-LO is kept unchanged when included. If the value of the <keep-rule-reference> element is set to 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 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 available or, if the PIDF-LO is created for the first time then the <external-ruleset> element MUST NOT be included.
The <provide-location> element contains child elements of a specific location profile that controls the granularity of returned location information. This form of location granularity reduction is also called 'obfuscation' and is defined in [duckham05] as
Location obscuring presents a number of technical challenges. The algorithms provided in this document are provided as examples only. A discussion of the technical constraints on location obscuring is included in Section 13.5.
The functionality of location granularity reduction depends on the type of location provided as input. This document defines two profiles for reduction, namely:
The <provide-location> element MUST contain the 'profile' attribute if it contains child elements and the 'profile' attribute MUST match with the contained child elements.
If the <provide-location> element has no child elements then civic, as well as, geodetic location information is disclosed without reducing its granularity, subject to availability. In this case the profile attribute MUST NOT be included.
This profile uses the token 'civic-transformation'. This profile allows civic location transformations to be specified by means of the <provide-civic> element that restricts the level of civic location information the LS is permitted to disclose. The symbols of these levels are: 'country', 'region', 'city', 'building', '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 elements included by the lower levels.
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.
This profile uses the token 'geodetic-transformation' and refers only to the Coordinate Reference System (CRS) WGS 84 (urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic location transformations to be specified by means of the <provide-geo> element that may restrict the returned geodetic location information based on the value provided in the 'radius' attribute. The value of the 'radius' attribute expresses the radius in meters.
The schema of the <provide-geo> element is defined in Section 8.
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
C1: SW C2: SW or SE C3: SE C4: SW or NW C5: SE or NE C6: NW C7: NW or NE C8: NE
The algorithm proceeds in 6 steps. The first two steps are independent of the measured position to be obscured. Those two steps should be run only once or rather seldom (for every region and desired uncertainty). The steps are:
Return the circle with center C and radius d.
Notes:
This section provides a few examples for authorization rules using the extensions defined in this document.
This example illustrates a single rule that employs the civic location condition. It matches if the current location of the Target equal 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>
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>
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>
This example shows the transformations specified in this document. The <provide-civic> element indicates that the available civic location information is reduced to building level granularity. If geodetic location information is requested then a granularity reduction is provided as well.
<?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 in 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>
The following rule describes the short-hand notation for making the current location of the Target available to Location Recipients without granularity reduction.
<?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>
Suppose you want to obscure positions in the continental USA.
Since we do not want to often change grid system (this would leak more information about obscured locations when they are repeatedly visited), the algorithm should prefer to use the grids discussed 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 to indicate "south").
This section defines the location profiles 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>
This section presents the XML schema that defines the Geolocation Policy schema described in this document. The Geolocation Policy schema extends the Common Policy schema (see [RFC4745]).
<?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>
The following section defines the details necessary for clients to manipulate geolocation privacy documents from a server using XCAP. If used as part of a presence system, it uses the same AUID as those rules. See [RFC5025] for a description of the XCAP usage in context with presence authorization rules.
XCAP requires application usages to define a unique application usage ID (AUID) in either the IETF tree or a vendor tree. This specification defines the "geolocation-policy" AUID within the IETF tree, via the IANA registration in Section 11.
XCAP requires application usages to define a schema for their documents. The schema for geolocation authorization documents is described in Section 9.
XCAP requires application usages to define the default namespace for their documents. The default namespace is urn:ietf:params:xml:ns:geolocation-policy.
XCAP requires application usages to define the MIME media type for documents they carry. Geolocation privacy authorization documents inherit the MIME type of common policy documents, application/auth-policy+xml.
This specification does not define additional constraints.
This document discusses the semantics of a geolocation privacy authorization.
When a Location Server receives a request to access location information of some user foo, it will look for all documents within http://[xcaproot]/geolocation-policy/users/foo, and use all documents found beneath that point to guide authorization policy.
This application usage does not define additional resource interdependencies.
This application usage does not modify the default XCAP authorization policy, which is that only a user can read, write or modify his/her own documents. A server can allow privileged users to modify documents that they do not own, but the establishment and indication of such policies is outside the scope of this document.
There are several IANA considerations associated with this specification.
<?xml version="1.0" encoding="UTF-8"?>
</xs:schema>
This section registers an XML schema in the IETF XML Registry as per the guidelines in [RFC3688].
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="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
This section registers a new XML namespace in the IETF XML Registry as per the guidelines in [RFC3688].
This document creates a registry of location profile names for the Geolocation Policy framework. Profile names are XML tokens. This registry will operate in accordance with RFC 5226 [RFC5226], Specification Required.
This document defines the following profile names:
<?xml version="1.0" encoding="UTF-8"?>
</xs:schema>
This section registers an XML schema in the IETF XML Registry as per the guidelines in [RFC3688].
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="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
This section registers a new XML namespace in the IETF XML Registry as per the guidelines in [RFC3688].
This section registers an XCAP Application Unique ID (AUID) in the "XML-XCAP Application Unique IDs" registry according to 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.
The policies described in this document are mostly meant for machine-to-machine communications; as such, many of its elements are tokens not meant for direct human consumption. If these tokens are presented to the end user, some localization may need to occur. The policies are, however, supposed to be created with the help of humans and some of the elements and attributes are subject to internationalization considerations. The content of the <label> element is meant to be provided by a human (the Rule Maker) and also displayed to a human. Furthermore, the location condition element (using the civic location profile, see Section 4.2) and the <set-note-well> element (see Section 6.3) may contain non-US-ASCII letters.
The geolocation polices utilize XML and all XML processors are required to understand UTF-8 and UTF-16 encodings, and therefore all entities processing these policies MUST understand UTF-8 and UTF-16 encoded XML. Additionally, geolocation policy aware entities MUST NOT encode XML with encodings other than UTF-8 or UTF-16.
This document aims to allow users to prevent unauthorized access to location information and to restrict access to information dependent on geolocation (via location based conditions). This is accomplished using authorization policies. This work builds on a series of other documents: Security requirements are described in [RFC6280] and a discussion of generic security threats is available with [RFC3694]. Aspects of combining permissions in cases of multiple occurrence are addressed in [RFC4745].
In addition to the authorization policies, mechanisms for obfuscating location information are described. A theoretical treatment of location obfuscation is provided in [duckham05] and in [ifip07]. [duckham05] provides the foundation and [ifip07] illustrates three different types of location obfuscation by enlarging the radius, by shifting the center, and by reducing the radius. The algorithm in Section 6.5.2 for geodetic location information obfuscation uses of these techniques.
The privacy protection requirements for altering location information vary. The two obfuscation algorithms in this document provide a basis for protecting against unauthorized disclosure of location information they have limitations. Application and user requirements vary widely; therefore, an extension mechanism is support for defining and using different algorithms.
Whenever location information is returned to a location recipient it contains the location of the Target. This is also true when location is obfuscated, i.e. the location server does not lie about the Target's location but instead hides it within a larger location shape. Even without the Target's movement there is a danger that information will be revealed over time. While the target's location is not revealed within a particular region of the grid, the size of that returned region matters as well as the precise location of the Target within that region. Returning location shapes that are randomly computed will over time reveal more and more information about the Target.
Consider the drawing in Figure 1, which shows three ellipses, a dotted area in the middle, and the Target's true location marked as 'x'. The ellipses illustrate the location shapes as received by a potential location recipient over time for requests of a target's location information. Collecting information about the returned location information over time allows the location recipient to narrow the potential location of the target down to the dotted area in the center of the graph.
For this purpose the algorithm described in Section 6.5.2 uses a grid that ensures the same location information is reported while the target remains in the same geographical area.
,-----.
,----,-'. `-.
,-' / `-. \
,' / _...._ `. \
/ ,-'......`._\ :
; /|...........\: |
| / :.....x......+ ;
: | \...........;| /
\ | \........./ | /
`. \ `-.....,' ,''
'-.\ `-----'|
``.-----' ,'
`._ _,'
`'''
Figure 1: Obfuscation: A Static Target
An obscuring method that returns different results for consecutive requests can be exploited by recipients wishing to use this property. Rate limiting the generation of new obscured locations or providing the same obscured location to recipients for the same location might limit the information that can be obtained. Note however that providing a new obscured location based on a change in location provides some information to recipients when they observe a change in location.
When the Target is moving then the location transformations reveal information when switching from one privacy region to another one. For example, when a transformation indicates that civic location is provided at a 'building' level of granularity, floor levels, room numbers, and other details normally internal to a building would be hidden. However, when the Target moves from one building to the next one then the movement would still be recognizable as the disclosed location information would be reflected by the new civic location information indicating the new building. With additional knowledge about building entrances and floor plans it would be possible to learn additional amount of information.
The algorithm presented in Section 6.5.2 has some issues where information is leaked: when moving, switching from one privacy region to another one; and also when the user regularly visits the same location.
The first issue arises if the algorithm provides different location information (privacy region) only when the previous one becomes inapplicable. The algorithm discloses new information the moment that the target is on the border of the old privacy region.
Another issue arises if the algorithm produces the different values for the same location that is repeatedly visited. Suppose 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.
In addition to these concerns, the combination of an obscured location with public geographic information (highways, lakes, mountains, cities, etc) may render a much more precise location information than is desired. But even without it, just observing movements, once or multiple times, any obscuring algorithm can leak information about velocities or positions. Suppose a user wants to disclose location information 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 information that the target is, was, or regularly visits, a region of size A1, smaller than A. The quotient of the sizes A1/A should be, even in the worst case, larger than a fixed known number, in order that the user knows what is the maximal information leakage he has. The choices of Section 6.5.2 are such that this maximum leakage can be established: by any statistical procedures, without using external information (highways, etc. as discussed above), the quotient A1/A is larger than 0.13 (= 1/(5*1.5) ). Thus, for instance, when choosing a provided location of size 1000 km^2, he will be leaking, in worst case, the location within a region of size 130 km^2.
There is the risk that end users are specifying their location-based policies in such a way that very small changes in location yields a significantly different level of information disclosure. For example, a user might want to set authorization policies differently when they are in a specific geographical area (e.g., at home, in the office). Location might be the only factor in the policy that triggers a very different action and transformation to be executed. The accuracy of location information is not always sufficient to unequivocally determine whether a location is within a specific boundary [I-D.thomson-geopriv-uncertainty]. In some situations uncertainty in location information could produce unexpected results for end users. Providing adequate user feedback about potential errors arising from these limitation can help prevent unintentional information leakage.
Users might create policies that are non-sensical. To avoid such cases the software used to create the authorization policies should perform consistency checks and when authorization policies are uploaded to the policy servers then further checks can be performed. When XCAP is used to upload authorization policies then built-in features of XCAP can be utilized to convey error messages back to the user about an error condition. Section 8.2.5 of [RFC4825] indicates that some degree of application specific checking is provided when authorization policies are added, modified or deleted. The XCAP protocol may return a 409 response with a response that may contain a detailed conflict report containing the <constraint-failure> element. A human readable description of the problem can be indicated in the 'phrase' attribute of that element.
Location obscuring attempts to remove information about the location of a Target. The effectiveness of location obscuring is determined by how much uncertainty a Location Recipient has about the location of the Target. A location obscuring algorithm is effective if the Location Recipient cannot recover a location with better uncertainty than the obscuring algorithm was instructed to add.
Effective location obscuring is difficult. The amount of information that can be recovered by a determined and resourceful Location Recipient can be considerably more than is immediately apparent. A concise summary of the challenges is included in [duckham10].
A Location Recipient in possession of external information about the Target or geographical area that is reported can make assumptions or guesses aided by that information to recover more accurate location information. This is true even when a single location is reported, but it is especially true when multiple locations are reported for the same Target over time.
Furthermore, a Location Recipient that attempts to recover past locations for a Target can use later reported locations to further refine any recovered location. A location obscuring algorithm typically does not have any information about the future location of the Target.
The degree to which location information can be effectively degraded by an obscuring algorithm depends on the information that is used by the obscuring algorithm. If the information available to the obscuring algorithm is both more extensive and more effectively employed than the information available to the Location Recipient, then location obscuring might be effective.
Obscured locations can still serve a purpose where a Location Recipient is willing to respect privacy. A privacy-respecting Location Recipient can choose to interpret the existence of uncertainty as a request from a Rule Maker to not recover location.
Location obscuring is unlikely to be effective against a more determined or resourceful adversary. Withholding location information entirely is perhaps the most effective method of ensuring that it is not recovered.
A caution: omitted data also conveys some information. Selective withholding of information reveals that there is something worth hiding. That information might be used to reveal something of the information that is being withheld. For example, if location is only obscured around a user's home and office then the lack of location for that user and the current time will likely mean that the user is at home at night and in the office during the day, defeating the purpose of the controls.
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 particularly want to thank Allison Mankin <mankin@psg.com>, Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, Jon Peterson <jon.peterson@neustar.biz> for their help in improving the quality of this document.
We would like to thank Christian Guenther for his help with an earlier version of this document. Furthermore, we would like to thank Johnny Vrancken for his document reviews in September 2006, December 2006 and January 2007. James Winterbottom provided a detailed review in November 2006. Richard Barnes gave a detailed review in February 2008.
This document uses text from [I-D.thomson-geopriv-geo-shape]. Therefore, we would like to thank Martin Thomson for his work in [I-D.thomson-geopriv-geo-shape]. We would also like to thank Martin Thomson, Matt Lepinski and Richard Barnes for their comments regarding the geodetic location transformation procedure. Richard provided us with a detailed text proposal.
Robert Sparks, Martin Thomson, and Warren Kumari deserve thanks for their input on the location obfuscation discussion. Robert implemented various versions of the algorithm in the graphical language "Processing" and thereby helped us tremendously to understand problems with the previously illustrated algorithm.
We would like to thank Dan Romascanu, Yoshiko Chong and Jari Urpalainen for their last call comments.
Finally, we would like to thank the following individuals for their feedback as part of the IESG, GenArt, and SecDir review: Jari Arkko, Eric Gray, Russ Housley, Carl Reed, Martin Thomson, Lisa Dusseault, Chris Newman, Jon Peterson, Sam Hartman, Cullen Jennings, Tim Polk, and Brian Rosen.
This section provides an informal description for the algorithm described in Section 6.5.2 in form of pseudo-code.
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 uncertainity,
// 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 | South and Central | 35 |
// | | | Europe | |
// +------+------+--------------------------+-------+
// | | | | |
// | 45 | 60 | Central and North | 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
// lomgitude 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; // uncertainity, 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 // Main