GEOPRIV H. Schulzrinne, Ed.
Internet-Draft Columbia University
Intended status: Standards Track H. Tschofenig, Ed.
Expires: April 4, 2008 Nokia Siemens Networks
J. Morris
CDT
J. Cuellar
Siemens
J. Polk
Cisco
October 2, 2007
Geolocation Policy: A Document Format for Expressing Privacy Preferences
for Location Information
draft-ietf-geopriv-policy-13.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 April 4, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Schulzrinne, et al. Expires April 4, 2008 [Page 1]
Internet-Draft Geolocation Policy October 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 location-specific
transformation elements to reduce the granularity of the returned
location information.
Schulzrinne, et al. Expires April 4, 2008 [Page 2]
Internet-Draft Geolocation Policy October 2007
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. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 11
6.2. Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 11
6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 12
6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 12
6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 13
6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 14
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Rule Example with Location-based Transformations . . . . . 16
8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 19
9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 20
10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 22
10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 22
10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 22
10.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 22
10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 22
10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 22
10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 22
10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 23
10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11.1. Geolocation Policy XML Schema Registration . . . . . . . . 24
11.2. Geolocation Policy Namespace Registration . . . . . . . . 24
11.3. Geolocation Policy Location Profile Registry . . . . . . . 25
11.4. Basic Location Profile XML Schema Registration . . . . . . 25
11.5. Basic Location Profile Namespace Registration . . . . . . 26
11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Schulzrinne, et al. Expires April 4, 2008 [Page 3]
Internet-Draft Geolocation Policy October 2007
1. Introduction
Location information needs to be protected against unauthorized
access to preserve the privacy of humans. In RFC 3693 [3], 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) [4] 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's
sphere setting contains a particular value. 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 from a Watcher for a
particular Target, via the using protocol [3]. 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
[1]. 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 April 4, 2008 [Page 4]
Internet-Draft Geolocation Policy October 2007
information from the Location Server to the Location Recipient (i.e.,
the using protocol; see RFC 3693 [3]).
This document extends the Common Policy framework defined in [1].
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, 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. When a rule is available then it has the
semantic of a 'permit' action. 'Deny' actions are not supported by
this document. This document furthermore does not specify child
elements for the condition part of a rule.
Schulzrinne, et al. Expires April 4, 2008 [Page 5]
Internet-Draft Geolocation Policy October 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 [2].
This document reuses the terminology of RFC 3693 [3], 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 [3] uses the term Target to identify the object or person
of which location information is required. The presence model
described in RFC 2778 [5] 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 [3]. 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 (policy) rules. Each rule has a
condition, an action and a transformation component.
Permission:
The term permission refers to the action and transformation
components of a rule.
The term 'using protocol' is defined in [3] and refers to the
protocol that is used to request access to and to return privacy
sensitive data items.
In this document we use the term Location Servers as the entities
that evaluate the geolocation authorization policies. The
Schulzrinne, et al. Expires April 4, 2008 [Page 6]
Internet-Draft Geolocation Policy October 2007
geolocation privacy architecture is, as motivated in RFC 4079 [6],
aligned with the presence architecture and a Presence Server is
therefore an entity that may distribute location information along
with other presence-specific XML data elements.
Schulzrinne, et al. Expires April 4, 2008 [Page 7]
Internet-Draft Geolocation Policy October 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 [1]. Geolocation authorization
documents inherit the MIME type of common policy documents,
application/auth-policy+xml. As described in [1], 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 [4] 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) [7].
Schulzrinne, et al. Expires April 4, 2008 [Page 8]
Internet-Draft Geolocation Policy October 2007
4. Conditions
This document does not define location-specific conditions.
Schulzrinne, et al. Expires April 4, 2008 [Page 9]
Internet-Draft Geolocation Policy October 2007
5. Actions
This document does not define location-specific actions.
Schulzrinne, et al. Expires April 4, 2008 [Page 10]
Internet-Draft Geolocation Policy October 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
<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.
6.2. Set Retention-Expiry
This transformation asks the LS to change or set the value of the
<retention-expiry> element in the PIDF-LO. The data type of the
<set-retention-expiry> element is an integer.
The value provided with the <set-retention-expiry> element indicates
seconds and these seconds are added to the current date.
If the <set-retention-expiry> element is absent then the value of the
<retention-expiry> element in the PIDF-LO is kept unchanged or, if
the PIDF-LO is created for the first time, then the value MUST be set
to the current date.
6.3. Set Note-Well
This transformation asks the LS to change or set the value of the
<note-well> element in the PIDF-LO. The data type of the <set-note-
well> element is a string.
The value provided with the <set-note-well> element contains a
privacy statement as a human readable text string and an 'xml:lang'
Schulzrinne, et al. Expires April 4, 2008 [Page 11]
Internet-Draft Geolocation Policy October 2007
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.
6.4. Keep Ruleset Reference
This transformation allows to influence whether the <external-
ruleset> element in the PIDF-LO carries the extended authorization
rules defined in [1]. 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 CID URIs).
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.
6.5. Provide Location
The <provide-location> 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 <provide-location> element has a <provide-civic> child
element then civic location information is disclosed as described
in Section 6.5.1, subject to availability.
o If the <provide-location> element has a <provide-geo> child
element then geodetic location information is disclosed as
described in Section 6.5.2, subject to availability.
The <provide-location> element MUST contain the 'profile' attribute
if it contains child elements and the 'profile' attribute MUST match
with the contained child elements. The <provide-location> element
MUST contain the 'profile' attribute if it contains child elements.
Schulzrinne, et al. Expires April 4, 2008 [Page 12]
Internet-Draft Geolocation Policy October 2007
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.
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
<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 [8]. 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
Schulzrinne, et al. Expires April 4, 2008 [Page 13]
Internet-Draft Geolocation Policy October 2007
{}
The default value is "none".
The schema of the <provide-civic> element is defined in Section 8.
6.5.2. Geodetic Location Profile
This profile uses the token 'geodetic-transformation' and 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 <provide-
geo> element that restricts the resolution of geodetic location
information based on the value provided in the <latitude-resolution>,
<longitude-resolution> and <altitude-resolution> child elements of
the <provide-geo> 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)/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' for r 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. A value of r=10,000 is sufficiently
large in order not to reduce the granularity of the returned location
information. If r is set to 0.0667 (i.e., 1/r = 15) then a timezone-
level resolution is provided.
Next, we show an example where we assume a nominal latitude value of
n=38.89868.
Schulzrinne, et al. Expires April 4, 2008 [Page 14]
Internet-Draft Geolocation Policy October 2007
Value r Computed n'
---------------------------
0.01 0.0
0.1 40.0
0.5 38.0
1 39.0
5 38.8
10 38.9
50,000 38.8987
The schema of the <provide-geo> element is defined in Section 8.
Schulzrinne, et al. Expires April 4, 2008 [Page 15]
Internet-Draft Geolocation Policy October 2007
7. Examples
This section provides a few examples for authorization rules using
the extensions defined in this document.
7.1. Rule Example with Location-based Transformations
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.
Schulzrinne, et al. Expires April 4, 2008 [Page 16]
Internet-Draft Geolocation Policy October 2007
<?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>
<sphere value="home"/>
</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>
<lp:latitude-resolution>0.01
</lp:latitude-resolution>
<lp:longitude-resolution>0.01
</lp:longitude-resolution>
<lp:altitude-resolution>0.01
</lp:altitude-resolution>
</lp:provide-geo>
</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.
Schulzrinne, et al. Expires April 4, 2008 [Page 17]
Internet-Draft Geolocation Policy October 2007
<?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>
<sphere value="office"/>
</condition>
<actions/>
<transformations>
<gp:provide-location/>
</transformations>
</rule>
</ruleset>
Schulzrinne, et al. Expires April 4, 2008 [Page 18]
Internet-Draft Geolocation Policy October 2007
8. XML Schema for Basic Location Profiles
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:sequence>
<xs:element name="latitude-resolution"
type="xs:double" minOccurs="0"
maxOccurs="1" default="0"/>
<xs:element name="longitude-resolution"
type="xs:double" minOccurs="0"
maxOccurs="1" default="0"/>
<xs:element name="altitude-resolution"
type="xs:double" minOccurs="0"
maxOccurs="1" default="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Schulzrinne, et al. Expires April 4, 2008 [Page 19]
Internet-Draft Geolocation Policy October 2007
9. XML Schema for Geolocation Policy
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 [1]).
<?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 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:textType"/>
<xs:element name="keep-rule-reference"
type="xs:boolean" default="false"/>
<xs:element name="provide-location"
type="gp:providelocationType"/>
<xs:complexType name="textType">
<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">
Schulzrinne, et al. Expires April 4, 2008 [Page 20]
Internet-Draft Geolocation Policy October 2007
<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>
Schulzrinne, et al. Expires April 4, 2008 [Page 21]
Internet-Draft Geolocation Policy October 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 [9] 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 April 4, 2008 [Page 22]
Internet-Draft Geolocation Policy October 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 April 4, 2008 [Page 23]
Internet-Draft Geolocation Policy October 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@nsn.com).
XML: The XML schema to be registered is contained in Section 9. Its
first line is
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
</xs:schema>
11.2. Geolocation Policy Namespace Registration
URI: urn:ietf:params:xml:ns:geolocation-policy
Registrant Contact: IETF Geopriv Working Group, Hannes Tschofenig
(hannes.tschofenig@nsn.com).
XML:
Schulzrinne, et al. Expires April 4, 2008 [Page 24]
Internet-Draft Geolocation Policy October 2007
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
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 [10],
Standards Action.
This document defines the following profile names:
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@nsn.com).
XML: The XML schema to be registered is contained in Section 8. Its
first line is
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
Schulzrinne, et al. Expires April 4, 2008 [Page 25]
Internet-Draft Geolocation Policy October 2007
</xs:schema>
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@nsn.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Basic Location Profile Namespace</title>
</head>
<body>
<h1>Namespace for Basic Location Profile</h1>
<h2>urn:ietf:params:xml:schema:basic-location-profiles</h2>
<p>See <a href="[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
11.6. XCAP Application Usage ID
This section registers an XCAP Application Usage ID (AUID) according
to the IANA procedures defined in [7].
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.
Schulzrinne, et al. Expires April 4, 2008 [Page 26]
Internet-Draft Geolocation Policy October 2007
12. Security Considerations
This document aims to allow Rule Makers to prevent the unintended
disclosure of location information information to third parties.
This is accomplished through the usage of transformations that are
part of rules, see Section 6. Security requirements are described in
[3] and a discussion of generic security threats is available with
[11]. Aspects of combining permissions in cases of multiple
occurrence are treated in [1]).
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. Hence, room numbers,
floors etc. 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 streets it
would be possible to learn a certain amont of information. It is
therefore important to ensure that selected privacy regions are not
chosen too small when mobility is a concern and that a random number
to is added to the position of the Target, with an absolute value of
half the privacy region. The latter aspect is only applicable for
geodetic information or when geodetic information is translated to
civic information by the Location Server.
Schulzrinne, et al. Expires April 4, 2008 [Page 27]
Internet-Draft Geolocation Policy October 2007
13. References
13.1. Normative References
[1] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
J., and J. Rosenberg, "Common Policy: A Document Format for
Expressing Privacy Preferences", RFC 4745, February 2007.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
13.2. Informative References
[3] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[4] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[6] Peterson, J., "A Presence Architecture for the Distribution of
GEOPRIV Location Objects", RFC 4079, July 2005.
[7] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[8] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
progress), February 2007.
[9] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-10 (work in progress),
July 2007.
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[11] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
Analysis of the Geopriv Protocol", RFC 3694, February 2004.
Schulzrinne, et al. Expires April 4, 2008 [Page 28]
Internet-Draft Geolocation Policy October 2007
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.
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
Schulzrinne, et al. Expires April 4, 2008 [Page 29]
Internet-Draft Geolocation Policy October 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)
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@nsn.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 April 4, 2008 [Page 30]
Internet-Draft Geolocation Policy October 2007
James Polk
Cisco
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
Email: jmpolk@cisco.com
Schulzrinne, et al. Expires April 4, 2008 [Page 31]
Internet-Draft Geolocation Policy October 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 April 4, 2008 [Page 32]
