GEOPRIV H. Schulzrinne
Internet-Draft Columbia U.
Expires: August 16, 2004 J. Morris
CDT
H. Tschofenig
J. Cuellar
Siemens
J. Polk
Cisco
February 16, 2004
Geopriv Policy
draft-ietf-geopriv-policy-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 16, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines an authorization policies language for
controling access to location-based presence information. This
language extends the common policy markup language towards
location-specific access control needs.
Schulzrinne, et al. Expires August 16, 2004 [Page 1]
Internet-Draft Geopriv Policy February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Basic Data Model and Processing . . . . . . . . . . . . . . . 6
4. Rule Transport . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 SIP Message Body . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Location Object . . . . . . . . . . . . . . . . . . . . . . . 7
5. Securing the Location Object . . . . . . . . . . . . . . . . . 9
6. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Civil Location . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Geospatial Location . . . . . . . . . . . . . . . . . . . . . 10
7. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Transformations . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Set D (Distribute) Flag . . . . . . . . . . . . . . . . . . . 13
8.2 Set R (Retention) Time . . . . . . . . . . . . . . . . . . . . 13
8.3 Keep Rule (RR) . . . . . . . . . . . . . . . . . . . . . . . . 14
8.4 Provide Civil Location . . . . . . . . . . . . . . . . . . . . 14
8.5 Provide Geospatial Location . . . . . . . . . . . . . . . . . 14
8.6 Provide Timezone Flag . . . . . . . . . . . . . . . . . . . . 15
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . 27
Schulzrinne, et al. Expires August 16, 2004 [Page 2]
Internet-Draft Geopriv Policy February 2004
1. Introduction
Location information needs to be protected against unauthorized
access to preserve privacy of the owner of the location information.
The Geopriv working group has defined a protocol-independent model
for access to geographic information. The model includes a Location
Generator (LG) that produces Location Information (LI), a Location
Server (LS) that authorizes access to LI, a location recipient (LR)
that requests and receives information, and a Rulemaker (RM) that
provides policy rules to the LS which enforce access control policies
on access to a target.
Two policy namespaces have been defined. The first basic rule set [7]
can restrict how long the receiver can retain the information and it
can prohibit any further distribution of the information. It does not
allow to customize information to specific receivers, for example.
This document describes an enhanced rule set that provides richer
constraints on the distribution of the Location Objects (LOs). We
assume that a basic location object [7] can contain a reference to
additional rule sets.
We refer to any entity that uses the rules in this document to
restrict the retention or distribution of information as a Rule
Enforcer (RE). Typically, these are LS and LR. A rule set allows the
RE to enforce access restrictions on location data, including
prohibiting any dissemination to particular individuals or during
particular times. The RM can also stipulate that only certain parts
of the location object are distributed to recipients or that the
resolution of parts of the location object is limited.
The abstract sequence of operations used in Geopriv can roughly be
described as follows. The LS receives either a query for location
information of a particular Target, via the using protocol. The using
protocol provides the identity of the requestor, either at the time
of the query or subscription to the location information. The
authenticated identity of the LR, together with other information
provided by the using protocol or generally available to the server,
is then used for searching through the rule set. All matching rules
are combined according to a merging algorithm described in [8]. The
resulting rule is applied to the location data, yielding a possibly
modified location object that is delivered to the location recipient.
Note that the protocols used to query location information (between
LS and LR), update policies at the LS and the protocol between the LG
to LS and from LS to LR do not have to be the same. Geopriv or this
document does not mandate a specific protocol for any of them.
This document integrates into and extends the framework defined in
Schulzrinne, et al. Expires August 16, 2004 [Page 3]
Internet-Draft Geopriv Policy February 2004
[8]. That document provides an abstract authorization framework for
expressing policy rules. As specified there, each such rule consists
of a 'conditions', an 'actions', and a 'transformations' part.
Conditions determine under which circumstances the LS is permitted to
perform 'actions' (e.g., subscription to a service).
'Transformations' implement a mechanism to optionally modify
information elements returned to the requestor (e.g., to reduce the
granularity of location information). The term 'transformation' is
also known as 'provisional action'.
The Geopriv policy markup language introduced by the schema in
section Section 10 extends the common policy markup language (see
[8]) by introducing new members of the 'condition' and
'transformation' substitution groups defined there. To express civil
location information, it makes use of the schema in section 2.2.3 of
[5] that defines the 'civilAddress' complex type.
Schulzrinne, et al. Expires August 16, 2004 [Page 4]
Internet-Draft Geopriv Policy February 2004
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 [1].
This document reuses the terminology of [3]. This section assists in
the alignment between the terminology defined in [8] and Geopriv.
PT - Presentity / Target: Geopriv uses the term Target to identify
the identity of which location information is required.
RM - Rule Maker: The entity RM corresponds to the Geopriv Rulemaker.
PS - (Authorization) Policy Server: The PS corresponds to the
Location Server (LS) in the Geopriv terminology.
WR - Watcher / Recipient: The WR represents the Location Recipient
(LR) in the Geopriv terminology.
An 'authorization policy' is given by a 'rule set'. A 'rule set'
contains an unordered list of 'rules'. A 'rule' has a 'conditions',
an 'actions' and a 'transformations' part.
The term 'permission' indicates the action and transformation
components of a 'rule'.
The terms 'authorization policy', 'policy' and 'rule set' are used
interchangable.
The terms 'authorization policy rule', 'policy rule' and 'rule' are
used interchangable.
The term 'using protocol' is defined in [3]. It refers to the
protocol which is used to request access to and to return privacy
sensitive data items.
Schulzrinne, et al. Expires August 16, 2004 [Page 5]
Internet-Draft Geopriv Policy February 2004
3. Basic Data Model and Processing
As the Geopriv policy markup language defined in section Section 10
extends the common policy markup language in [8], this document
completely adopts the basic data model as introduced in section 6 of
[8].
Schulzrinne, et al. Expires August 16, 2004 [Page 6]
Internet-Draft Geopriv Policy February 2004
4. Rule Transport
We make no assumption as to how rules are conveyed to entities within
the network. Purely as examples, we below describe a few plausible
options. None of the rule elements depend on the properties of how
rule sets are conveyed to an LS or LR. Mechanisms may allow partial
updates of rule sets. A partial update is an update which modifies
only parts of the rule set in contrast to a full update. To simplify
such partial updates, each rule is equipped with an identifier (see
[8]).
Transaction semantics for policy rule update is not required since
'permit only' and 'additive permissions' properties have to be used.
These properties also prevent inconsistency during concurrent query
and update operations.
4.1 HTTP
A rule set could be uploaded to the LS via an HTTP POST operation or
more fully-featured WEBDAV. Each rule could be modeled as a single
'file', with the rule identifier as a file name. (Since multiple
rules may have the LR identity in the condition part of the rule, the
LR identity cannot be used.) One example of this approach includes
XCAP [6].
The rule set can also be referenced from within a location object.
The attribute 'ruleset-reference' specified in Section 2.2.2 of [7]
contains an URI that indicates where a rule set related to this
object can be found. The URI MAY alternatively use the CID URI scheme
in which case it MUST denote a MIME body carried with the Location
Object by the using protocol.
4.2 SIP Message Body
The rule set can be carried, as a separate MIME message body, in the
SIP message that conveys location information from a LG (a SIP UAC)
via an LS (a SIP proxy) to an LR (a SIP UAS). The rule set would then
govern the behavior expected of the LR.
4.3 Location Object
The rule set can be carried in LOs in two ways: by reference and by
value. In any case the 'ruleset-reference' attribute inside the LO
[7] points to the location of the rules. The LG or the LS can attach
the rule set (or a pointer to it) to the location object.
One of the transformations of the rule set is the removal of the rule
set described here before further transmission. Only the whole rule
Schulzrinne, et al. Expires August 16, 2004 [Page 7]
Internet-Draft Geopriv Policy February 2004
set can be removed and not individual elements (for example some
conditions). Before transmitting the rules to the LR the rule set
SHOULD be removed since the rule set might disclose prefences of the
rule maker which entities to trust and to which other entities no
trust is available. Revealing this information might have neative
implication for the RM itself. The RM is, however, in the position to
prevent disclosure of these rules by enforcing the necessary steps.
Schulzrinne, et al. Expires August 16, 2004 [Page 8]
Internet-Draft Geopriv Policy February 2004
5. Securing the Location Object
The Geopriv requirements draft [3] addresses the minimal security
protection required for the LO: Mutual end-point authentication, data
object integrity, data object confidentiality and replay protection.
As proposed in [5] S/MIME SHOULD be used. Protection for the LO also
includes an attached rule set.
Protection is likely to be necessary against adversaries who
eavesdrop on the communication between the LS and the LR or the LG
and the LS, who tamper with the LO or who replay previously recorded
LOs. Securing the communication between RM and LS depends on the
protocol which is used to perform the desired actions (e.g., https).
The communication between the LG and the LS can also be secured using
channel security.
If the LO is integrity and confidentiality-protected then the
receiving entity (LS or LR) has to be able to decrypt and to verify
the LO. Since the policy rules described in this document allow the
modification of the LO (via granularity reduction or by setting
flags), it is not possible to forward the LO without reapplying the
cryptographic protection. This is particularly true for the LS as it
is not the final consumer of the LO.
When the LS protects the LO for transmission to the LR (after
successful authorization), then the authenticated identity can be
used to select a security association to apply proper protection of
the location object. Securing the LO for multiple LRs is not
provided.
Instead of encrypting the LO, the LG could digitally sign the LO,
offering integrity, but no confidentiality. However, if the LS needs
to perform modifications on the LO, then it would have to break the
digital signature and may apply its own digital signature.
Since the LO is generally distributed to more than one LR, the LG
lacks the necessary information about the recipient and thus cannot
usually apply confidentially protection.
By default, the LS re-signs LOs if the signed LO has been modified
according to the rule set. If the LS receives an LO that it cannot
decrypt, it discards it if and only if the rule requires modification
of the content.
It remains for further study whether there should be an action that
discards an LO that is signed or encrypted and needs to be modified
according to the matching rule set.
Schulzrinne, et al. Expires August 16, 2004 [Page 9]
Internet-Draft Geopriv Policy February 2004
6. Conditions
This section describes the location-specific conditions of a rule,
namely the civil and geo-spatial location conditions.
6.1 Civil Location
The <civil-loc-condition> element matches if the current location of
the target matches all the values specified in the child elements of
this element. The <civil-loc-condition> is of 'civilAddress' complex
type defined in section 2.2.3 of [5]. It includes a number of fields,
including the country (expressed as a two-letter ISO 3166 code), and
the administrative units A1 through A6 of [10]. This designation
offers street-level precision.
If the civil location of the target is not known, rules that contain
a civil location never match. (This case may occur, for example, if
location information has been removed by earlier transmitters of
location information or if only the geospatial location is known.)
If any of the elements <A1> through <A6> are specified, <country>
also MUST to be specified. The schema does not enforce that the
specification uniquely identifies a particular location. For example,
it would be possible to omit the region and match only on city name,
so that any city sharing that name within a country would match. This
'feature' is primarily designed to deal with users that may not know
the administrative divisions between country and city level. For
example, many users may not know the county for cities in the United
States.
6.2 Geospatial Location
Geospatial location conditions can be expressed by means of the
<geospatial-loc-condition> element. Such a condition makes the rule
match if the Target being subject of the rule is currently located
within the trapezoid on the surface of the earth that is bounded by
the values of longitude and latitude elements <longitude1>,
<longitude2>, <latitude1>, and <latitude2>, regardless of the
altitude value, if present; Figure 1 shows this. The northern
boundary of this trapezoid is on the latitude given by the value of
the <latitude1> element correspondingly, the southern boundary is
given by the value of the <latitude2> element. The western boundary
of this trapezoid is on the longitude given by the value of the
<longitude1> element, and its eastern boundary is on the longitude
given by the value of the <longitude2> element. These four boundaries
can be of virtually any earthbound size. This is a means for reducing
resolution in coordinate location.
Schulzrinne, et al. Expires August 16, 2004 [Page 10]
Internet-Draft Geopriv Policy February 2004
<latitude1>
_________________________
/ \
/ \
/ _________ \
<longitude1> / / \ \<longitude2>
/ / Target \ \
/ / \ \
/ /---------------\ \
/ \
/ \
/ \
/---------------------------------------------\
<latitude2>
Figure 1: Example Trapezoids North of the Equator
The Target knows where it is (shown as the inner trapezoid). This
trapezoid might be greater in size than the dimensions of the Target
due to precision of the measuring device issues. The rule is a match
if the outer trapezoid falls completely outside the boundaries of the
inner trapezoid.
Schulzrinne, et al. Expires August 16, 2004 [Page 11]
Internet-Draft Geopriv Policy February 2004
7. Actions
According to the common policy framework [8], actions and
transformations included in a rule determine which operations the LS
MUST execute after having received from a LR a location data access
request that matches all conditions of this rule. Transformations
exclusively specify LS-side operations that lead to a modification of
the location data items requested by the LR. Actions, on the other
hand, specify all remaining types of operations the LS is obliged to
execute, i.e., all operations that are not of transformation type.
This document does not define new, location-specific actions, but it
inherits the 'confirmation' action defined in [8].
Schulzrinne, et al. Expires August 16, 2004 [Page 12]
Internet-Draft Geopriv Policy February 2004
8. Transformations
[Editors' note: This section still needs a lot of work, since there
is a general problem concerning the formulation of permissions and
the combining rules stated in the current version of the common
policy document. The <latitude-resolution> transformation of data
type Integer, for instance, does not fit to the combining rule that
builds maxima of Integer-valued permissions. A combining rule that
prescribes the computation of the minimum of single latitude
resolution values would be more appropriate for this permission. This
combining permissions issue could lead to substancial modifications
to the combining rules section of the common policy document, and
consequently to changes of the common policy and the geopriv policy
markup languages and of this section.]
In addition to the transformations below, the LS MAY translate, add
or remove location information. For example, they may add timezone
information based on civil information.
All transformations are privacy-safe, i.e., if a transformation is
NULL (i.e., if the attribute is not present or empty in a policy
rule), the LS removes the corresponding location information from the
LO and leaves the LO flags undisturbed.
Extensions to this document may define other transformations.
8.1 Set D (Distribute) Flag
This transformation sets the D flag in the location object to either
'true' or 'false'. A value of 'true' means the recipient of the LO
is allowed to further distribute it. A value of 'false' prevents
further distribution.
The value NULL keeps the D flag in the LO as is. The default value is
'false'.
8.2 Set R (Retention) Time
The retention transformation sets the retention value in the location
object to the current time plus the time provided in the element,
measured in seconds.
The value NULL keeps the retention time in the LO as is. If no
previous value is available then the LS sets it a configured default
value.
Schulzrinne, et al. Expires August 16, 2004 [Page 13]
Internet-Draft Geopriv Policy February 2004
8.3 Keep Rule (RR)
If the Keep Rule (RR) flag is set, any extended rules included in the
location object are kept.
8.4 Provide Civil Location
The Provide Civil Location transformation restricts the civil
location to one of six levels, from lowest to highest: null,
country, region, city, building, full. 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 civil location data as shown
below.
If this action is NULL, all civil information is removed from the LO.
The lattice for this attribute has the following shape:
Full
{<Country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>,
<PRD>, <POD>, <STS>, <HNO>, <HNS>, <LMK>, <LOC>, <PC>,
<NAM>, <FLR>, <ZIP>}
|
Building
{<Country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>,
<PRD>, <POD>, <STS>, <HNO>, <HNS>, <LMK>, <PC>, <ZIP>}
|
City
{<Country>, <A1>, <A2>}
|
Region
{<Country>, <A1>}
|
Country
{<Country>}
|
'NULL'
{}
8.5 Provide Geospatial Location
The Provide Geospatial Location transformation restricts the
resolution of the geospatial location information to the number of
Schulzrinne, et al. Expires August 16, 2004 [Page 14]
Internet-Draft Geopriv Policy February 2004
bits provided, separately for longitude and latitude. The default
value is zero.
For purposes of this transformation, longitude and latitude are
treated as a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. Altitude is treated as a fixed-point 22-bit
integer part with a 8-bit fraction, measured in meters. This
corresponds to the representation in [9], but does not constrain the
representation in the location object.
If the transformation value is NULL, all geospatial location
information is removed from the LO.
8.6 Provide Timezone Flag
The 'Provide Timezone' transformation indicates the inclusion or
removal of timezone information of the target, i.e., the offset from
UTC. The value of 'false' causes timezone information to be excluded
from the LO.
If the transformation value is NULL, all timezone information is
removed from the LO.
Schulzrinne, et al. Expires August 16, 2004 [Page 15]
Internet-Draft Geopriv Policy February 2004
9. Example
The example of this section illustrates a rule set with a single
rule. The conditions given in this rule match to a location requestor
named ted@example.com (provided as a SIP URI in our example). The
rule is valid for one year (2003-10-01 to 2004-10-01). Requests only
match if the target is at his main office in a Siemens site in
Munich. This is specified by means of the content of the
<civil-loc-condition> element. The syntax of this content complies
with the 'civilAddress' complex type defined in section 2.2.3 of [5].
A confirmation action for the subscription is not necessary. The
<transformations> section indicates that all civil location
information is provided to the location requestor. The distribution
flag is set to 'false' and the rules included in the LO are left
unmodified.
<?xml version="1.0" encoding="UTF-8"?>
<cp:ruleset
xmlns:gp="urn:ietf:params:xml:ns:geopriv-policy"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:geopriv-policy gp01.xsd
urn:ietf:params:xml:ns:common-policy cp00.xsd">
<cp:rule id="AA56i09">
<cp:conditions>
<cp:validity>
<cp:from>2003-10-01T17:00:00+01:00</cp:from>
<cp:to>2004-10-01T00:00:00+01:00</cp:to>
</cp:validity>
<gp:civil-loc-condition>
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A4>Perlach</A4>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
</gp:civil-loc-condition>
</cp:conditions>
<cp:actions>
<cp:confirmation>false</cp:confirmation>
</cp:actions>
Schulzrinne, et al. Expires August 16, 2004 [Page 16]
Internet-Draft Geopriv Policy February 2004
<cp:transformations>
<gp:civil-loc-transformation>full</gp:civil-loc-transformation>
<gp:set-distribution>false</gp:set-distribution>
<gp:keep-rules>true</gp:keep-rules>
</cp:transformations>
</cp:rule>
</cp:ruleset>
In case of a policy consisting of more than one rule and a request
for location information that let multiple rules match, there must be
a procedure for combining the permissions contained in the matching
rules. This procedure is defined in [8], section 10.
Schulzrinne, et al. Expires August 16, 2004 [Page 17]
Internet-Draft Geopriv Policy February 2004
10. XML Schema
This section specifies an XML schema for the authorization policies
described in the previous sections. The Geopriv policy markup
language introduced by this schema extends the common policy markup
language (see [8]) by introducing new members of the 'condition' and
'transformation' substitution groups whose heads (namely the elements
<condition> and <transformation>) are specified by the common policy
schema (once again, see [8]). This way, the Geopriv policy markup
language specializes the common rules markup language towards
location-based presence information. To this end, the following
schema imports the vocabulary of the common policy markup language.
Furthermore, to express civil location information, it imports the
'civilAddress' complex type as defined in section 2.2.3 of [5].
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv-policy"
xmlns:gp="urn:ietf:params:xml:ns:geopriv-policy"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:common-policy"
schemaLocation="cp00.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
schemaLocation="civilLoc.xsd"/>
<!-- Geopriv conditions -->
<xs:element name="civil-loc-condition" type="cl:civilAddress"
substitutionGroup="cp:condition"/>
<xs:element name="geospatial-loc-condition" substitutionGroup="cp:condition">
<xs:complexType>
<xs:all>
<xs:element name="longitude1" type="xs:double"/>
<xs:element name="longitude2" type="xs:double"/>
<xs:element name="latitude1" type="xs:double"/>
<xs:element name="latitude2" type="xs:double"/>
</xs:all>
</xs:complexType>
</xs:element>
Schulzrinne, et al. Expires August 16, 2004 [Page 18]
Internet-Draft Geopriv Policy February 2004
<!-- Geopriv transformations -->
<xs:element name="civil-loc-transformation"
substitutionGroup="cp:transformation">
<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:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="set-retention" type="xs:integer"
substitutionGroup="cp:transformation"/>
<xs:element name="set-distribution" type="xs:boolean"
substitutionGroup="cp:transformation"/>
<xs:element name="keep-rules" type="xs:boolean"
substitutionGroup="cp:transformation"/>
<xs:element name="longitude-resolution" type="xs:integer"
substitutionGroup="cp:transformation"/>
<xs:element name="latitude-resolution" type="xs:integer"
substitutionGroup="cp:transformation"/>
<xs:element name="altitude-resolution" type="xs:integer"
substitutionGroup="cp:transformation"/>
<xs:element name="provide-timezone" type="xs:boolean"
substitutionGroup="cp:transformation"/>
</xs:schema>
Schulzrinne, et al. Expires August 16, 2004 [Page 19]
Internet-Draft Geopriv Policy February 2004
11. Security Considerations
This document aims to make it simple for users to prevent the
unintended disclosure of private information to third parties. The
described policies accomplish this task. Security threats for the
Geopriv model are described in [2] and are applicable to this draft
as well. Requirements are addressed in [3]. Section 5 addresses
issues of protecting the policy rules within the LO and location
information itself. Aspects of privacy-safe combining permissions is
illustrated in Section 8.
Schulzrinne, et al. Expires August 16, 2004 [Page 20]
Internet-Draft Geopriv Policy February 2004
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
[2] Danley, M., "Threat Analysis of the geopriv Protocol",
draft-ietf-geopriv-threat-analysis-01 (work in progress),
September 2003.
[3] Cuellar, J., Morris, J., Mulligan, D., Peterson, D. and D. Polk,
"Geopriv requirements", draft-ietf-geopriv-reqs-04 (work in
progress), October 2003.
Schulzrinne, et al. Expires August 16, 2004 [Page 21]
Internet-Draft Geopriv Policy February 2004
Informative References
[4] Rosenberg, J., "Extensible Markup Language (XML) Configuration
Access Protocol (XCAP) Usages for Setting Presence
Authorization", draft-ietf-simple-xcap-auth-usage-00 (work in
progress), June 2003.
[5] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", draft-ietf-geopriv-pidf-lo-01 (work in progress),
February 2004.
[6] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-01 (work in progress), October 2003.
[7] Peterson, J., "A Presence Architecture for the Distribution of
Geopriv Location Objects", draft-peterson-geopriv-pres-00 (work
in progress), February 2003.
[8] Tschofenig, H., Morris, J., Cuellar, J., Polk, J., Schulzrinne,
H. and J. Rosenberg, "Common Policy",
draft-ietf-geopriv-common-policy-00 (work in progress),
February 2004.
[9] Polk, J., Schnizlein, J. and M. Linsner, "DHC Location Object
within GEOPRIV", draft-ietf-geopriv-dhcp-lo-option-00 (work in
progress), January 2003.
[10] Schulzrinne, H., "DHCP Option for Civil Location",
draft-ietf-geopriv-dhcp-civil-00 (work in progress), July 2003.
[11] Tschofenig, H., Morris, J., Cuellar, J., Polk, J. and H.
Schulzrinne, "Policy Rules for Disclosure and Modification of
Geographic Information", draft-ietf-geopriv-policy-00 (work in
progress), November 2003.
Schulzrinne, et al. Expires August 16, 2004 [Page 22]
Internet-Draft Geopriv Policy February 2004
Authors' Addresses
Henning Schulzrinne
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
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
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Jorge.Cuellar@siemens.com
URI: http://www.cdt.org
Jorge R. Cuellar
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Jorge.Cuellar@siemens.com
URI: http://www.cdt.org
Schulzrinne, et al. Expires August 16, 2004 [Page 23]
Internet-Draft Geopriv Policy February 2004
James Polk
Cisco
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
EMail: jmpolk@cisco.com
Schulzrinne, et al. Expires August 16, 2004 [Page 24]
Internet-Draft Geopriv Policy February 2004
Appendix A. Contributors
We would like to thank Christian Guenther for his help with the XML
schema in this document.
Christian Guenther
Siemens AG
Corporate Technology
81730 Munich
Email: christian.guenther@siemens.com
Germany
Schulzrinne, et al. Expires August 16, 2004 [Page 25]
Internet-Draft Geopriv Policy February 2004
Appendix B. Acknowledgments
This document is partially based on the discussions within the IETF
GEOPRIV working group. Discussions at the Geopriv Interim Meeting
2003 in Washington, D.C. helped the working group to make progress on
the authorization policies based on the discussions among the
participants.
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 time discussing a
number of details with us. They helped us to improve the quality of
this document.
Schulzrinne, et al. Expires August 16, 2004 [Page 26]
Internet-Draft Geopriv Policy February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Schulzrinne, et al. Expires August 16, 2004 [Page 27]
Internet-Draft Geopriv Policy February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne, et al. Expires August 16, 2004 [Page 28]
