GEOPRIV WG J. Peterson
Internet-Draft NeuStar
Expires: December 21, 2003 June 22, 2003
A Presence-based GEOPRIV Location Object Format
draft-peterson-geopriv-pidf-lo-00
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 December 21, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a object format for carrying geographical
information on the Internet. This location object extends the
Presence Information Data Format (PIDF), which was designed for
communicating privacy-sensitive presence information and has similar
properties.
Peterson Expires December 21, 2003 [Page 1]
Internet-Draft GEOPRIV Location Obj June 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Location Object Format . . . . . . . . . . . . . . . . . . . 4
2.1 Baseline PIDF Usage . . . . . . . . . . . . . . . . . . . . 4
2.2 Extensions to PIDF for Location and Privacy Policy . . . . . 5
2.2.1 'location-info' element . . . . . . . . . . . . . . . . . . 5
2.2.2 'usage-rules' element . . . . . . . . . . . . . . . . . . . 6
2.2.3 Schema definition . . . . . . . . . . . . . . . . . . . . . 7
2.3 Example Location Object . . . . . . . . . . . . . . . . . . 8
3. Carrying PIDF in a Using Protocol . . . . . . . . . . . . . 9
4. Securing PIDF . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
6.1 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10 . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
A. To Do and Unmet requirements . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . 12
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . 15
Peterson Expires December 21, 2003 [Page 2]
Internet-Draft GEOPRIV Location Obj June 2003
1. Introduction
Geographical location information describes a physical position in
the world that may correspond to the past, present or future location
of a person or device. Numerous applications used in the Internet
today benefit from sharing location information (including mapping/
navigation applications, 'friend finders' on cell phones, and so on).
However, such applications may disclose the whereabouts of a person
in a manner contrary to the user's preferences. Privacy lapses may
result from poor protocol security (which permits eavesdroppers to
capture location information), inability to articulate or accommodate
user preferences, or similar defects common in existing systems. The
privacy concerns surrounding the unwanted disclosure of a person's
physical location are among the more serious that confront users on
the Internet.
Consequently, a need has been identified to convey geographical
location information within an object that includes a user's privacy
and disclosure preferences and which is protected by strong
cryptographic security. Previous work [11] has observed that this
problem bears some resembles to the general problem of communicating
and securing presence information on the Internet. Presence (which
is defined in [10]) provides a real-time communications disposition
to a user that have similar requirements for selective distribution
and security.
Therefore, this document extends the XML-based Presence Information
Data Format (PIDF [2]) to allow the encapsulation of location
information within a presence document.
This document does not invent any format for location information
itself. Numerous already existing formats based on civil location,
spatial coordinates, and the like have been developed in other
standards fora. Instead, this document defines an object that is
suitable for both identifying and encapsulating pre-existing location
information formats and for providing adequate security and policy
controls to regulate the distribution of location information over
the Internet.
The location object described in this document can be used
independently of any 'using protocol' as the term is defined in the
GEOPRIV requirements [8]. It is considered an advantage of this
proposal that existing presence protocols (such as [13]) would
natively accommodate the location object format defined in this
document, and be capable of composing location information with other
presence information, since this location object is an extension of
PIDF. However, any protocol that can carry XML or MIME types can
carry PIDF.
Peterson Expires December 21, 2003 [Page 3]
Internet-Draft GEOPRIV Location Obj June 2003
Some of the requirements in [8] concern data collection and usage
policies associated with location objects. This document does not
provide a markup suitable for a user to express the necessary privacy
preferences as specified by the geopriv requirements. However, this
document does demonstrate how an XML-based privacy preference
document could be embedded within a PIDF document.
2. Location Object Format
2.1 Baseline PIDF Usage
The GEOPRIV requirements [8] (or REQ for short throughout this
section) specify the need for a name for the person, place or thing
that location information describes (REQ 2.1). PIDF has such an
identifier already, since every PIDF document has "entity" attribute
of the "presence" element that signifies the URI of the entity whose
presence the document describes. Similarly, if location information
is contained in a PIDF document, the URI in the "entity" attribute of
the "presence" element indicates the target of that location
information. The URI in the "entity" attribute should use the "pres"
URI scheme defined in [3]. URIs can serve as "unlinkable pseudonyms"
(per REQ 12).
PIDF optionally contains a "contact" element that contains a URI
where the presentity can be reached by some means of communication
(usually, the URI scheme in the value of the "contact" element gives
some sense of how the presentity can be reached: if it uses the SIP
URI scheme, for example, SIP can be used, and so on). Location
information can be provided without any associated means of
communication - thus, the "contact" element may or may not be
present, as desired by the creator of the PIDF document.
PIDF optionally contains a "timestamp" element that designates the
time at which the PIDF was created. This element corresponds to REQ
2.7a.
PIDF contains a "status" element, which is mandatory. "status"
contains an optional child element "basic" that describes the
presentity's communications disposition (in the very broad terms:
either OPEN or CLOSED). For the purposes of this document, it is not
necessary for "basic" status to be included. If, however,
communications disposition is included in a PIDF document above and
beyond geolocation, then "basic" status may appear in a PIDF document
that uses these extensions.
PIDF also contains a "tuple" element, which is used to uniquely
identify a segment of presence information so that changes to this
Peterson Expires December 21, 2003 [Page 4]
Internet-Draft GEOPRIV Location Obj June 2003
information can be tracked over time (as multiple notifications of
presence are received).
2.2 Extensions to PIDF for Location and Privacy Policy
This XML Schema extends the "status" element of PIDF with a complex
element called "geopriv". There are two major subelements that are
encapsulated within geopriv: one for location information, and one
for usage rules. Both of these subelements are mandatory, and are
described in subsequent sections.
There are also a few other elements which are contained within the
geopriv element in support of the GEOPRIV requirements.
2.2.1 'location-info' element
Each 'geopriv' element MUST contain one 'location-info' element. A
'location-info' element consists of one or more chunks of location
information (per REQ 2.5). The format of the location information
(REQ 2.6) is identified by the imported XML Schema describing the
namespace in question. All PIDF documents that contain a 'geopriv'
element MUST contain one or more import directive indicating the XML
Schema(s) that will be used as geolocation formats.
In order to ensure interoperability of GEOPRIV implementations, it is
necessary to select a baseline location format that all compliant
implementations support (see REQ 3.1). At this time, there is not
sufficient working group consensus within the GEOPRIV WG to award
this distinction to any particular location format. Without applying
any particular selection criteria (apart from REQs 2.5.1), this
document works from the assumption that GML 3.0 [14] will be this
mandatory format (MUST implement for all PIDF implementations
supporting the 'geopriv' element).
The Geography Markup Language (GML) is an extraordinarily thorough
and versatile system for modeling all manner of geographic topologies
and objects. The simplest package for GML supporting location
information is the 'feature.xsd' schema. Various format descriptions
(including latitude/longitude based location information) is
supported by Feature (see section 7.4.1.4 of [14] for examples).
This resides here:
urn:opengis:specification:gml:schema-xsd:feature:v3.0
Note that by importing the Feature schema, necessary GML baseline
schemas are transitively imported.
Peterson Expires December 21, 2003 [Page 5]
Internet-Draft GEOPRIV Location Obj June 2003
Complex features (such as modeling topologies and polygons,
directions and vectors, temporal indications of the time for which a
particular location is valid for a target) are also available in GML,
but require importing additional schemas. For the purposes of this
document, only support for the feature.xsd GML schema is REQUIRED.
2.2.2 'usage-rules' element
At the time this document was written, the policy requirements for
GEOPRIV objects were not definitively completed. However, the
'usage-rules' element exists to satisfy REQ 2.8, and the requirements
of the GEOPRIV policy requirements [9] document. Each 'geopriv'
element SHOULD contain one 'usage-rules' element - Location
Generators MAY not include this element ONLY IF users have
specifically requested that all sub-elements given below are
unnecessary to protect this Location Object.
Following to that document (Section 3.1), there are three fields that
need to be expressible in Location Objects throughout their lifecycle
(from Generator to Recipient): one field that limit retransmission,
one that limit retention, and one that contains a reference to
external rulesets. Those three fields are instantiated here by the
first three elements. The fourth element provides a generic space
for human-readable policy directives. Any of these fields MAY be
present in a Location Object 'usage-rules' element; none are required
to be.
'retransmission-allowed': When the value of this element is 'no',
the Recipient of this Location Object is not permitted to share
the enclosed Location Information, or the object as a whole, with
other parties. When the value of this element is 'yes', sharing
this Location Object or information is permitted (barring an
existing agreement or obligation to the contrary). By default,
the value MUST be assumed to be 'no'. Implementations MUST
include this field, with a value of 'no', if the Rule Maker
specifies no preference.
'retention-expires': This field specifies an absolute date at
which time the Recipient is no longer permitted to possess the
location information and its encapsulating Location Object - both
may be retained only up until the time specified by this field.
By default, the value MUST be assumed to be twenty-four hours from
the 'timestamp' element in the PIDF document, if present; if the
'timestamp' element is not present, then twenty-four hours from
the time at which the Location Object is received. If the value
in the 'retention-expires' element has already passed when the
Location Recipient receives the Location Object, the Recipient
MUST discard the Location Object immediately.
Peterson Expires December 21, 2003 [Page 6]
Internet-Draft GEOPRIV Location Obj June 2003
'ruleset-reference': This field contains a URI to a network server
that holds rules appropriate for this Location Object. This
SHOULD be an HTTPS URI, and the server that holds these rules MUST
authenticate any attempt to access these rules - usage rules
themselves may divulge private information about a Target or Rule
Maker. Location Recipients SHOULD NOT attempt to dereference this
URI - it is intended only for the consumption of Location Servers.
'note-well': This field contains a block of text containing
further generic privacy directives. These directives are intended
to be human-readable only, not to be processed by any automaton.
2.2.3 Schema definition
Note that the XML namespace [4] for this extension to PIDF contains a
version number 1.0 (as per REQ 2.10).
See RFCXXXX.
END Normative References [1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and J. Peterson, "CPIM Presence Information Data Format", draft- ietf-impp-cpim-pidf-07 (work in progress), August 2001. [3] Peterson, J., "Common Profile for Presence (CPP)", draft-ietf- impp-pres-03 (work in progress), May 2003. [4] Mealling, M., "The IETF XML Registry", draft-mealling-iana- xmlns-registry-05 (work in progress), June 2003. [5] Ramsdell, B., "S/MIME Version 3 Message Specification", draft- ietf-smime-rfc2633bis-03 (work in progress), January 2003. [6] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 2002. [7] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS", draft-ietf-smime-aes-alg-06 (work in progress), January 2003. Informative References [8] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work in progress), February 2003. Peterson Expires December 21, 2003 [Page 12] Internet-Draft GEOPRIV Location Obj June 2003 [9] Morris, J., Mulligan, D. and J. Cuellar, "Core Privacy Protections for Geopriv Location Object", draft-morris-geopriv- core-01 (work in progress), March 2003. [10] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [11] Peterson, J., "A Presence Architecture for the Distribution of Geopriv Location Objects", draft-peterson-geopriv-pres-00 (work in progress), February 20003. [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [14] OpenGIS, "", OGC 02-023r4, January 2003,