GEOPRIV H. Schulzrinne, Ed. Internet-Draft Columbia U. Intended status: Standards Track H. Tschofenig, Ed. Expires: August 6, 2007 Siemens Networks GmbH & Co KG J. Morris CDT J. Cuellar Siemens J. Polk Cisco February 2, 2007 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information draft-ietf-geopriv-policy-11.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Schulzrinne, et al. Expires August 6, 2007 [Page 1] Internet-Draft Geolocation Policy February 2007 Abstract This document defines an authorization policy language for controling 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 based on the current location of the Target. Furthermore, it offers location- specific transformation elements to reduce the granularity of the returned location information. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Structure of Geolocation Authorization Documents . . . . . 8 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 8 4. Location-specific Conditions . . . . . . . . . . . . . . . . . 9 4.1. Geodetic Location Condition Profile . . . . . . . . . . . 9 4.2. Civic Location Condition Profile . . . . . . . . . . . . . 10 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 12 6.2. Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 12 6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 13 6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 13 6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 14 6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 15 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Rule Example with Civic Location Condition . . . . . . . . 16 7.2. Rule Example with Geodetic Location Condition . . . . . . 17 7.3. Rule Example with Civic and Geodetic Location Condition . 18 7.4. Rule Example with Location-based Transformations . . . . . 19 8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 22 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 25 10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 25 10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 25 10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 25 10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 25 10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 25 10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 25 10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 26 10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 26 Schulzrinne, et al. Expires August 6, 2007 [Page 2] Internet-Draft Geolocation Policy February 2007 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. Security Considerations . . . . . . . . . . . . . . . . . . . 31 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 13.2. Informative References . . . . . . . . . . . . . . . . . . 32 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 37 Schulzrinne, et al. Expires August 6, 2007 [Page 3] Internet-Draft Geolocation Policy February 2007 1. Introduction Location information needs to be protected against unauthorized access to preserve the privacy of humans. In RFC 3693 [1], 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) [2] 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, however, does not allow to control access to location information based on specific Location Recipients. This document describes an enhanced rule set that provides richer constraints on the distribution of LOs. The 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 of parts of the Location Object is reduced. The typical sequence of operations is as follows. A Location Server receives a query for location information for a particular Target, via the using protocol [1]. The using protocol provides the identity of the requestor, either at the time of the query or when subscribing to the location information. The authenticated identity of the Location Recipient, together with other information provided by the using protocol 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 [3]. 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 Schulzrinne, et al. Expires August 6, 2007 [Page 4] Internet-Draft Geolocation Policy February 2007 information from the Location Server to the Location Recipient (i.e., the using protocol; see RFC 3693 [1]). This document extends the Common Policy framework defined in [3]. That document provides an abstract framework for expressing authorization policy rules. As specified there, each such rule consists of conditions, actions and transformations. Conditions determine under which circumstances the entity executing the rules, for example 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, for example, by reducing the granularity of returned location information. 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. Schulzrinne, et al. Expires August 6, 2007 [Page 5] Internet-Draft Geolocation Policy February 2007 2. Terminology 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 [4]. This document reuses the terminology of RFC 3693 [1], 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: Presentity or Target: RFC 3693 [1] uses the term Target to identify the object or person of which location information is required. The presence model described in RFC 2778 [11] uses the term presentity to describe the entity that provides presence information to a presence service. A Presentity in a presence system is a Target in a location information system. Watcher or Location Recipient: The receiver of location information is the Location Recipient (LR) in the terminology of RFC 3693 [1]. A watcher in a presence system, i.e., an entity that requests presence information about a presentity, is a Location Recipient in a location information system. Authorization policy: An authorization policy is given by a rule set. A rule set contains an unordered list of rules. Each rule has a condition, an action and a transformation component. The terms 'authorization policy', 'policy', 'rule set', 'authorization policy rule', 'policy rule' and 'rule' are used interchangeable. Permission: The term permission refers to the action and transformation components of a rule. The term 'using protocol' is defined in [1] and refers to the protocol that is used to request access to and to return privacy sensitive data items. Schulzrinne, et al. Expires August 6, 2007 [Page 6] Internet-Draft Geolocation Policy February 2007 In this document we use the term Location Servers as the entities that evaluate the geolocation authorization policies. The geolocation privacy architecture is, as motivated in RFC 4079 [12], 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. Schulzrinne, et al. Expires August 6, 2007 [Page 7] Internet-Draft Geolocation Policy February 2007 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 [3]. Geolocation authorization documents inherit the MIME type of common policy documents, application/auth-policy+xml. As described in [3], 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 safe, since the lack of any action or transformation can only result in less information being presented to a Location Recipient. 3.2. Rule Transport There are two ways how the authorization rules described in this document may be conveyed between different parties: o RFC 4119 [2] allows enhanced authorization policies to be referenced via a Uniform Resource Locator (URL) in the 'ruleset- reference' element. The ruleset-reference' element is part of the basic rules that always travel with the Location Object. o Authorization policies might, for example, also be stored at a Location Server / Presence Server. The Rule Maker therefore needs to use a protocol to create, modify and delete the authorization policies defined in this document. Such a protocol is available with the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [5]. Schulzrinne, et al. Expires August 6, 2007 [Page 8] Internet-Draft Geolocation Policy February 2007 4. Location-specific Conditions This section describes the location-specific conditions of a rule, namely the civic and geodetic location conditions. The element MAY contain zero, one or an unbounded number of child element(s). Providing more than one child element may not be useful since all child elements of the element must evaluate to TRUE in order for the element to be TRUE. The element MUST contain at least one child element. The element evaluates to TRUE if any of its child elements is TRUE, i.e., a logical OR. A location profile needs to describe under what conditions each element evaluates to TRUE. This document defines two location profiles, one civic and one geodetic location profile. The and the elements provide extension points. If an extension is not understood by the entity evaluating the rules then this rule evaluates to FALSE. 4.1. Geodetic Location Condition Profile The geodetic location profile is identified by the token 'geodetic- condition'. Rule Makers use this profile by placing a GML [6] element within the element. The element containing the information for the geodetic location profile evaluates to TRUE if the current location of the Target is within the described Polygon. This might require a point- in-polygon, polygon-in-polygon, or a similar computation. If the geodetic location of the Target is unknown then the element containing the information for the geodetic location profile evaluates to FALSE. The polygon that uses the "gml:Polygon" element is specified by a sequence of points. A polygon requires at least four points, where the first and last point MUST be the same. Points specified in a polygon MUST be coplanar. However, implementations SHOULD be prepared to accept small variations that might occur depending on whether the the polygon is specified on a plane in space, or only relative to the ellipsoid. To avoid implementation complexity, implementations MAY choose to not support polygons that include varying altitude. Therefore, two polygon forms are permitted: polygons specified using EPSG 4326, and polygons specified using EPSG 4979 with a constant altitude value. Schulzrinne, et al. Expires August 6, 2007 [Page 9] Internet-Draft Geolocation Policy February 2007 Interpolation between points is linear, as defined for the "gml: LinearRing" element. Implementations SHOULD minimize this interpolation error by ensuring that the sides of polygons are as short as possible. Implementations are REQUIRED to support the following coordinate reference systems based on WGS 84 [7]. These are identified using the European Petroleum Survey Group (EPSG) Geodetic Parameter Dataset, as formalized by the Open Geospatial Consortium (OGC): 2D: WGS 84 (latitude, longitude), as identified by the URN "urn:ogc:def:crs:EPSG::4326". This is a two dimensional CRS. 3D: WGS 84 (latitude, longitude, altitude), as identified by the URN "urn:ogc:def:crs:EPSG::4979". This is a three dimensional CRS. 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. 4.2. Civic Location Condition Profile The civic location profile is identified by the token 'civic- condition'. Rule Makers use this profile by placing a element, defined in [8], within the element. All child elements of element that carry civicAddress elements MUST evaluate to TRUE (i.e., logical AND) in order for the element to evaluate to TRUE. For each element value a string-by-string comparison is performed. If the civic location of the Target is unknown, then the element containing the information for the civic location profile evaluates to FALSE. This case may occur, for example, if location information has been removed by earlier transmitters of location information or if only the geodetic location is known. Schulzrinne, et al. Expires August 6, 2007 [Page 10] Internet-Draft Geolocation Policy February 2007 5. Actions This document does not define location-specific actions. Schulzrinne, et al. Expires August 6, 2007 [Page 11] Internet-Draft Geolocation Policy February 2007 6. Transformations This document defines several elements that allow Rule Makers to specify transformations that o reduce the accuracy of the returned location information, and o set the basic authorization policies carried inside the PIDF-LO. 6.1. Set Retransmission-Allowed This element asks the LS to change or set the value of the element in the PIDF-LO. The data type of the element is a boolean. If the value of the element is set to TRUE then the element in the PIDF-LO MUST be set to TRUE. If the value of the element is set to FALSE, then the element in the PIDF-LO MUST to be set to FALSE. If the element is absent then the value of the 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 element in the PIDF-LO. The data type of the element is an integer. The value provided with the element indicates seconds and these seconds are added to the current date. If the element is absent then the value of the 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 element in the PIDF-LO. The data type of the element is a string. The value provided with the element contains a privacy statement as a human readable text string and an 'xml:lang' Schulzrinne, et al. Expires August 6, 2007 [Page 12] Internet-Draft Geolocation Policy February 2007 attribute denotes the language of the human readable text. If the element is absent, then the value of the 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 element. 6.4. Keep Ruleset Reference This transformation allows to influence whether the element in the PIDF-LO carries the extended authorization rules defined in [3]. The data type of the element is Boolean. If the value of the element is set to TRUE, then the element in the PIDF-LO is kept unchanged when included. If the value of the element is set to FALSE, then the element in the PIDF-LO MUST NOT contain a reference. The reference to the ruleset is removed and no rules are carried as MIME bodies (in case of CID URIs). If the element is absent, then the value of the element in the PIDF-LO is kept unchanged when available or, if the PIDF-LO is created for the first time then the element MUST NOT be included. 6.5. Provide Location The element contains child elements of a specific location profile that controls the granularity of returned location information. This document defines two location profiles, namely: o If the element has a child element then civic location information is disclosed as described in Section 6.5.1, subject to availability. o If the element has a child element then geodetic location information is disclosed as described in Section 6.5.2, subject to availability. The element MUST contain the 'profile' attribute if it contains child elements and the 'profile' attribute MUST match with the contained child elements. The element MUST contain the 'profile' attribute if it contains child elements. Schulzrinne, et al. Expires August 6, 2007 [Page 13] Internet-Draft Geolocation Policy February 2007 If the 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. 6.5.1. Civic Location Profile This profile uses the token 'civic-transformation'. This profile allows civic location transformations to be specified by means of the 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 and , ..., , as defined in [8]. Each level includes all elements included by the lower levels. The 'country' level includes only the element; the 'region' level adds the element; the 'city' level adds the and elements; the 'building' level and the 'full' level add further civic location data as shown below. full {, , , , , , , , , , , , , , , , , ,,,, , , , , , , , } | | building {, , , , , , , , , , , , , , , , , } | | city {, , , } | | region {, } | | country {} | | none Schulzrinne, et al. Expires August 6, 2007 [Page 14] Internet-Draft Geolocation Policy February 2007 {} The default value is "none". The schema of the element is defined in Section 8. 6.5.2. Geodetic Location Profile 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) and WGS 84 (urn:ogc:def:crs:EPSG::4979, 3D). This profile allows geodetic location transformations to be specified by means of the element that restricts the resolution of geodetic location information based on the value provided in the , and child elements of the element. The resolution is specified as a real number r. Assume that the variable n represents the nominal coordinate value (longitude, latitude or altitude), the rounded value is computed as n'=FLOOR(n*r + 0.5) * 1/r Small r values indicate that the granularity of the returned location information will be reduced. The smaller the value r is the larger is the granularity reduction. The value '0' is used to indicate that location MUST NOT be distributed. Per default the value '0' is assumed. A large r value indicates that a large amount of the available location information will be distributed. The larger the value r is the more precise the returned location information is. The maximum is infinity, the symbol "INF", indicating that the available information is disclosed without reduction of the granularity. Next, we show an example where we assume a nominal latitude value of n=38.89868. Value r Computed n' --------------------------- 0.01 89.0000 0.1 43.9000 1 39.4000 10 38.9490 100 38.9037 The schema of the element is defined in Section 8. Schulzrinne, et al. Expires August 6, 2007 [Page 15] Internet-Draft Geolocation Policy February 2007 7. Examples This section provides a few examples for authorization policy 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 equal the content of the child elements of the 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 [13]). DE Bavaria Munich Perlach Otto-Hahn-Ring 6 Schulzrinne, et al. Expires August 6, 2007 [Page 16] Internet-Draft Geolocation Policy February 2007 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. 42.556844 -73.248157 42.549631 -73.237283 42.539087 -73.240328 42.535756 -73.254242 42.542969 -73.265115 42.553513 -73.262075 42.556844 -73.248157 The following alternative example shows the same polygon with a constant altitude included that is specified using EPSG 4979 and the "gml:posList" element. The "gml:posList" element is interpreted as a list with the dimension of the CRS indicating how many values are required for each point. Schulzrinne, et al. Expires August 6, 2007 [Page 17] Internet-Draft Geolocation Policy February 2007 42.556844 -73.248157 36.6 42.549631 -73.237283 36.6 42.539087 -73.240328 36.6 42.535756 -73.254242 36.6 42.542969 -73.265115 36.6 42.553513 -73.262075 36.6 42.556844 -73.248157 36.6 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. Schulzrinne, et al. Expires August 6, 2007 [Page 18] Internet-Draft Geolocation Policy February 2007 DE Bavaria Munich Perlach Otto-Hahn-Ring 6 42.556844 -73.248157 42.549631 -73.237283 42.539087 -73.240328 42.535756 -73.254242 42.542969 -73.265115 42.553513 -73.262075 42.556844 -73.248157 7.4. Rule Example with Location-based Transformations This example shows the transformations specified in this document. The 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. Schulzrinne, et al. Expires August 6, 2007 [Page 19] Internet-Draft Geolocation Policy February 2007 false 86400 My privacy policy goes in here. false building 0.01 0.01 0.01 The following rule describes the short-hand notation for making the current location of the Target available to Location Recipients without granularity reduction. Schulzrinne, et al. Expires August 6, 2007 [Page 20] Internet-Draft Geolocation Policy February 2007 Schulzrinne, et al. Expires August 6, 2007 [Page 21] Internet-Draft Geolocation Policy February 2007 8. XML Schema for Basic Location Profiles This section defines the location profiles used as child elements of the transformation element. Schulzrinne, et al. Expires August 6, 2007 [Page 22] Internet-Draft Geolocation Policy February 2007 9. XML 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 [3]) by introducing new members of the 'condition' and 'transformation' substitution groups whose heads (namely the elements and ). Schulzrinne, et al. Expires August 6, 2007 [Page 23] Internet-Draft Geolocation Policy February 2007 Schulzrinne, et al. Expires August 6, 2007 [Page 24] Internet-Draft Geolocation Policy February 2007 10. XCAP Usage 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 [13] for a description of the XCAP usage in context with presence authorization rules. 10.1. Application Unique ID 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. 10.2. XML Schema XCAP requires application usages to define a schema for their documents. The schema for geolocation authorization documents is described in Section 9. 10.3. Default Namespace XCAP requires application usages to define the default namespace for their documents. The default namespace is urn:ietf:params:xml:ns:geolocation-policy. 10.4. MIME Type XCAP requires application usages to defined the MIME type for documents they carry. Geolocation privacy authorization documents inherit the MIME type of common policy documents, application/ auth-policy+xml. 10.5. Validation Constraints This specification does not define additional constraints. 10.6. Data Semantics This document discusses the semantics of a geolocation privacy authorization. 10.7. Naming Conventions 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 Schulzrinne, et al. Expires August 6, 2007 [Page 25] Internet-Draft Geolocation Policy February 2007 found beneath that point to guide authorization policy. 10.8. Resource Interdependencies This application usage does not define additional resource interdependencies. 10.9. Authorization Policies 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. Schulzrinne, et al. Expires August 6, 2007 [Page 26] Internet-Draft Geolocation Policy February 2007 11. IANA Considerations There are several IANA considerations associated with this specification. 11.1. Geolocation Policy XML Schema Registration URI: urn:ietf:params:xml:schema:geolocation-policy Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig (hannes.tschofenig@siemens.com). XML: The XML schema to be registered is contained in Section 9. Its first line is and its last line is 11.2. Geolocation Policy Namespace Registration URI: urn:ietf:params:xml:ns:geolocation-policy Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig (hannes.tschofenig@siemens.com). XML: Schulzrinne, et al. Expires August 6, 2007 [Page 27] Internet-Draft Geolocation Policy February 2007 BEGIN Geolocation Policy Namespace

Namespace for Geolocation Authorization Policies

urn:ietf:params:xml:schema:geolocation-policy

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

END 11.3. Geolocation Policy Location Profile Registry This document seeks to create a registry of location profile names for the Geolocation Policy framework. Profile names are XML tokens. This registry will operate in accordance with RFC 2434 [9], Standards Action. 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 URI: urn:ietf:params:xml:schema:basic-location-profiles Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig (hannes.tschofenig@siemens.com). Schulzrinne, et al. Expires August 6, 2007 [Page 28] Internet-Draft Geolocation Policy February 2007 XML: The XML schema to be registered is contained in Section 9. Its first line is and its last line is 11.5. Basic Location Profile Namespace Registration URI: urn:ietf:params:xml:ns:basic-location-profiles Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig (hannes.tschofenig@siemens.com). XML: BEGIN Basic Location Profile Namespace

Namespace for Basic Location Profile

urn:ietf:params:xml:schema:basic-location-profiles

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

END 11.6. XCAP Application Usage ID This section registers an XCAP Application Usage ID (AUID) according to the IANA procedures defined in [5]. 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 Schulzrinne, et al. Expires August 6, 2007 [Page 29] Internet-Draft Geolocation Policy February 2007 access information about his/her geographic location. Schulzrinne, et al. Expires August 6, 2007 [Page 30] Internet-Draft Geolocation Policy February 2007 12. Security Considerations This document aims to make it simple for users to prevent the unintended disclosure of private information to third parties. Security requirements are described in [1] and a discussion of generic security threats is available with [10]. Aspects of combining permissions in cases of multiple occurrence are treated in [3]). The concept of location-based conditions are introduced in Section 4 and mechanisms to reduce the granularity of returned location information is specified in Section 6. Schulzrinne, et al. Expires August 6, 2007 [Page 31] Internet-Draft Geolocation Policy February 2007 13. References 13.1. Normative References [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [3] Schulzrinne, H., "Common Policy: A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-11 (work in progress), August 2006. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [5] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-12 (work in progress), October 2006. [6] OpenGIS, "OpenGIS Geography Markup Language (GML) Implementation Specification, Version 3.00, OGC 02 023r4", http://www.opengeospatial.org/docs/02-023r4.pdf, January 2003. [7] OpenGIS, "US National Imagery and Mapping Agency, "Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition, NIMA TR8350.2", , January 2000. [8] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in progress), September 2006. [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [10] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004. 13.2. Informative References [11] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [12] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005. Schulzrinne, et al. Expires August 6, 2007 [Page 32] Internet-Draft Geolocation Policy February 2007 [13] Rosenberg, J., "Presence Authorization Rules", draft-ietf-simple-presence-rules-08 (work in progress), October 2006. [14] Thomson, M., "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03 (work in progress), December 2006. [15] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. Schulzrinne, et al. Expires August 6, 2007 [Page 33] Internet-Draft Geolocation Policy February 2007 Appendix A. Acknowledgments 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 , Randall Gellens , Andrew Newton , Ted Hardie , Jon Peterson 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 a several document reviews and the suggestions he provided between September 2006, December 2006 and January 2007. James Winterbottom provided a detailed review in November 2006. This document uses text from [14]. Therefore, we would like to thank Martin Thomson for his work in [14]. Schulzrinne, et al. Expires August 6, 2007 [Page 34] Internet-Draft Geolocation Policy February 2007 Authors' Addresses 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) Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 USA Email: jmorris@cdt.org URI: http://www.cdt.org Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Jorge.Cuellar@siemens.com Schulzrinne, et al. Expires August 6, 2007 [Page 35] Internet-Draft Geolocation Policy February 2007 James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA Email: jmpolk@cisco.com Schulzrinne, et al. Expires August 6, 2007 [Page 36] Internet-Draft Geolocation Policy February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Schulzrinne, et al. Expires August 6, 2007 [Page 37]