’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. ’method’ Element
The optional ’method’ element describes the way that the location
information was derived or discovered. An example of this element
(for a geographical position system) is:
<method>gps</method>
The possible values of the ’method’ element are enumerated within an
IANA registry. Implementations MUST limit the use of this method to
the values shepherded by IANA. This document pre-populates the IANA
registry with seven possible values; see Section 6.1 for more
information.
The ’method’ element is useful, for example, when multiple sources
are reporting location information for a given user, and some means
of determining location might be considered more authoritative than
others (i.e., a dynamic, real-time position system versus static
provisioning associated with a target device). However, note that
inclusion of ’method’ might reveal sensitive information when the
generator is providing intentionally coarsened location information.
For example, when a LO is transmitted with ’DHCP’ as the ’method’,
but the location information indicates only the city in which the
generator is located, the sender has good justification to suspect
that some location information is being withheld.
2.2.4. ’provided-by’ Element
The optional ’provided-by’ element describes the entity or
organization that supplied this location information (beyond the
domain information that can be inferred from a signing certificate).
An example of this element (for a made-up game system) might be:
<provided-by>
<test:game>
West5
</test:game>
</provided-by>
Values for the ’provided-by’ element MUST be IANA-registered XML
namespaces; see Section 6.2 for more information.
The ’provided-by’ element is not intended for use by most entities,
but rather to meet special requirements for which overhead (IANA
registration, location object size) and potential location
information leakage are acceptable choices.
In general cases, the entity that supplied location information is
communicated by the subjectAltName of the certificate with which the
location object is signed; thus, this element is unnecessary.
’Provided-by’ is meaningful in particular cases when the creator of a
location object wants to designate a particular system or party
within a complex administrative domain, including situations
envisioned for providing emergency services in a diverse national
context. It might assist, for example, the recipient of a malformed
or misleading location object in identifying the particular system
that malfunctioned.
Users should be aware that this information can inadvertently provide
additional information to the receiver, increasing the effective
resolution of the geospatial or civic information, or even revealing
some location information, when it was meant to be entirely
protected. Consider if there were circumstances that influenced
Columbia University to elect to register and use the provided-by
element. If an example LO includes only state-level information,
then including the fact that the location information was provided by
Columbia University provides a strong indication that the Target is
actually located in a four-block area in Manhattan. Accordingly,
this element should be used only when organizational functions
strongly would depend on it. In all but such usages, the
subjectAltName of the certificate will suffice, and ’provided-by’
SHOULD NOT be used.
2.2.5. Schema Definitions
Note that the XML namespace [4] for this extension to PIDF contains a
version number 1.0 (as per REQ 2.10).
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace=
"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" />
<!-- 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"/>
<xs:element name="geopriv" type="tns:geopriv"/>
<xs:complexType name="geopriv">
<xs:sequence>
<xs:element name="location-info" type="tns:locInfoType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="usage-rules" type="gbp:locPolicyType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="method" type="tns:locMethod"
minOccurs="0" maxOccurs="1"/>
<xs:element name="provided-by" type="tns:locProvidedBy"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locInfoType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locMethod">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="locProvidedBy">
<xs:sequence>
<xs:any namespace="##other" processContents="skip"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
The ’geopriv10’ schema imports, for the ’usage-rules’ element, the
following policy schema. This schema has been broken out from the
basic geolocation object in order to allow for its reuse. The
semantics associated with these elements, described in Section 2.2.2,
apply only to the use of these elements to define policy for
geolocation objects; any other use of ’usage-rules’ must characterize
its own semantics for all ’usage-rules’ subelements.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- 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"/>
<xs:complexType name="locPolicyType">
<xs:sequence>
<xs:element name="retransmission-allowed" type="xs:boolean"
minOccurs="0" maxOccurs="1"/>
<xs:element name="retention-expiry" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:element name="external-ruleset" type="xs:anyURI"
minOccurs="0" maxOccurs="1"/>
<xs:element name="note-well" type="tns:notewell"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="notewell">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
The following schema is a trivial representation of civic location
that MAY be implemented by entities compliant with this
specification.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:complexType name="civicAddress">
<xs:sequence>
<xs:element name="country" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A1" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A2" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A3" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A4" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A5" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A6" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="PRD" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="POD" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="STS" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="HNO" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="HNS" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="LMK" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="LOC" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="FLR" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="NAM" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="PC" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
2.3. Example Location Objects
Note that these examples show PIDF documents without any MIME headers
or security applied to them (see Section 4 below).
The following XML instance document is an example of the use of a
simple GML 3.0 markup with a few of the policy directives specified
above within a PIDF document. The GPS coordinates given in the ’gml’
element are for San Francisco, CA.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point1" srsName="epsg:4326">
<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
The following XML instance document is an example of the use of the
civicLoc object with a few of the policy directives specified above
within a PIDF document.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>New York</cl:A1>
<cl:A3>New York</cl:A3>
<cl:A6>Broadway</cl:A6>
<cl:HNO>123</cl:HNO>
<cl:LOC>Suite 75</cl:LOC>
<cl:PC>10027-0401</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
3. Carrying PIDF in a Using Protocol
A PIDF document is an XML document; therefore, PIDF might be carried
in any protocol capable of carrying XML. A MIME type has also been
registered for PIDF: ’application/pidf+xml’. PIDF may therefore be
carried as a MIME body in protocols that use MIME (such as SMTP,
HTTP, or SIP) with an encapsulating set of MIME headers, including a
Content-Type of ’application/pidf+xml’.
Further specification of the behavior of using protocols (including
subscribing to or requesting presence information) is outside the
scope of this document.
4. Securing PIDF
There are a number of ways in which XML documents can be secured.
XML itself supports several ways of partially securing documents,
including element-level encryption and digital signature properties.
For the purposes of this document, only the securing of a PIDF
document as a whole, rather than element-by-element security, is
considered. None of the requirements [10] suggest that only part of
the information in a location object might need to be protected while
other parts are unprotected; virtually any such configuration would
introduce potentials for privacy leakage. Consequently, the use of
MIME-level security is appropriate.
S/MIME [5] allows security properties (including confidentiality,
integrity, and authentication properties) to be applied to the
contents of a MIME body. Therefore, all PIDF implementations that
support the XML Schema extensions for location information described
in this document MUST support S/MIME; in particular, they MUST
support the CMS [6] EnvelopedData and SignedData content types, which
are used for encryption and digital signatures, respectively. It is
believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3,
and 14.4.
Additionally, all compliant applications MUST implement the AES
encryption algorithm for S/MIME, as specified in [8] (and per REQ
15.1). Of course, implementations MUST also support the baseline
encryption and digital signature algorithms described in the S/MIME
specification.
S/MIME generally entails the use of X.509 [9] certificates. In order
to encrypt a request for a particular destination end-to-end (i.e.,
to a Location Recipient), the Location Generator must possess
credentials (typically an X.509 certificate) that have been issued to
the Location Recipient. Implementations of this specification SHOULD
support X.509 certificates for S/MIME, and MUST support password-
based CMS encryption (see [6]). Any symmetric keying systems SHOULD
derive high-entropy content encoding keys (CEKs). When X.509
certificates are used to sign PIDF Location Objects, the
subjectAltName of the certificate SHOULD use the "pres" URI scheme.
One envisioned deployment model for S/MIME in PIDF documents is the
following. Location Servers hold X.509 certificates and share
secrets with Location Generators and Location Recipients. When a
Generator sends location information to a Server, it can be encrypted
with S/MIME (or any lower-layer encryption specific to the using
protocol). When a Server forwards location information to a
Recipient, location information can be encrypted with password-based
CMS encryption. This allows the use of encryption when the Location
Recipient does not possess its own X.509 certificate.
S/MIME was designed for end-to-end security between email peers that
communicate through multiple servers (i.e mail transfer agents) that
do not modify message bodies. There is, however, at least one
instance in which Location Servers modify Location Objects: when
Location Servers enforce policies on behalf of the Rule Maker. For
example, a Rule Maker may specify that Location Information should be
coarsened (made less specific) before it is transmitted to particular
recipients. If the Location Server were unable to modify a Location
Object, because it was encrypted, signed, or both, it would be unable
to accomplish this function. Consequently, when a Location Generator
wants to allow a Location Server to modify such messages, they MAY
encrypt such messages with a key that can be decrypted by the
Location Server (the digital signature, of course, can still be
created with keying material from the Location Generator’s
certificate). After modifying the Location Object, the Location
Server can re-sign the Object with its own credentials (encrypting it
with any keys issued to the Location Recipient, if they are known to
the Server).
Note that policies for data collection and usage of location
information, in so far as they are carried within a location object,
are discussed in Section 2.2.2.
5. Security Considerations
The threats facing an Internet protocol that carries geolocation
information are detailed in [16]. The requirements that were
identified in that analysis of the threat model were incorporated
into [10], in particular within Section 7.4. This document aims to
be compliant with the security requirements derived from those two
undertakings, in so far as they apply to the location object itself
(as opposed to the using protocol).
Security of the location object defined in this document, including
normative requirements for implementations, is discussed in Section
4. This security focuses on end-to-end integrity and confidentiality
properties that are applied to a location object for its lifetime via
S/MIME.
Security requirements associated with using protocols (including
authentication of subscribers to geographical information, etc.) are
outside the scope of this document.
6. IANA Considerations
6.1. ’method’ Tokens
This document requests that the IANA create a new registry for
’method’ tokens associated with the PIDF-LO object. ’method’ tokens
are text strings designating the manner in which location information
in a PIDF-LO object has been derived or discovered. Any party may
register new ’method’ tokens with the IANA, as needed, on a first-
come-first-serve basis.
This section pre-registers 7 new ’method’ tokens associated with the
’method’ element described above in Section 2.2.3:
GPS: Global Positioning System
A-GPS: GPS with assistance
Manual: entered manually by an operator or user, e.g., based on
subscriber billing or service location information
DHCP: provided by DHCP (used for wireline access networks, see
802.11 below)
Triangulation: triangulated from time-of-arrival, signal strength,
or similar measurements
Cell: location of the cellular radio antenna
802.11: 802.11 access point (used for DHCP-based provisioning over
wireless access networks)
6.2. ’provided-by’ Elements
This document requests that IANA create a new registry of XML
namespaces for ’provided-by’ elements for use with PIDF-LO objects.
Registrations of new XML namespaces that are used for ’provided-by’
MUST be reviewed by an Expert Reviewer designated by the IESG.
This document pre-registers a single XML namespace for ’provided-by’,
which is given in Appendix A.
6.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10
This section registers a new XML namespace, as per the guidelines in
[4].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:pidf:geopriv10.
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Jon Peterson (jon.peterson@neustar.biz).
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>GEOPRIV PIDF Extensions</title>
</head>
<body>
<h1>PIDF Extensions of Geographical Information and Privacy</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">
RFC4119</a>.</p>
</body>
</html>
END
7. Acknowledgements
This document was produced with the assistance of many members of the
GEOPRIV IETF working group. Special thanks to Carl Reed of OpenGIS
for a close read of the document.
The civic location format described in this document was proposed by
Henning Schulzrinne for communicating location information in DHCP,
and has been appropriated in its entirety for this document.
James M. Polk provided the text related to the ’method’ element, and
much of the text for the ’provided-by’ element. The text of Appendix
A was written by Nadine Abbott.
A. Appendix: NENA Provided-By Schema
The following registers the XML namespace
urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider and the associated
schema below, for usage within the ’provided-by’ element of PIDF-LO.
The dataProvider namespace was developed by the US National Emergency
Number Administration (NENA) for next-generation emergency
communications needs.
This appendix is non-normative for implementers of PIDF-LO
implementations and MAY support the dataProvider namespace. Other
registrants of ’provided-by’ namespaces are invited to use the
registration below as an informative example.
URI: The URI for this namespace is
urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider
Registrant Contact: NENA, VoIP working group & IETF, GEOPRIV
working group, (geopriv@ietf.org), Nadine Abbott
(nabbott@telcordia.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>NENA dataProvider Schema for PIDF-LO</title>
</head>
<body>
<h1>NENA dataProvider Schema for ’provided-by’ in PIDF-LO</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">
RFC4119</a>.</p>
</body>
</html>
END
A.1. dataProvider XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) by
Patricia Bluhm (HBF Group) -->
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="nena" type="tns:DataProviderIDType"/>
<xs:complexType name="DataProviderIDType">
<xs:annotation>
<xs:documentation>NENA registered Company ID
for Service Provider supplying location information</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="DataProviderID"
type="tns:NENACompanyIDType" minOccurs="0"/>
<xs:element name="TelURI"
type="tns:TelURI_24x7Type" minOccurs="0"/>
<xs:element name="URL" type="xs:anyURI"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<xs:simpleType name="NENACompanyIDType">
<xs:annotation>
<xs:documentation>NENA registered Company
ID.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="5"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="TelURI_24x7Type">
<xs:annotation>
<xs:documentation>24x7 Tel URI for the
caller’s [location data] service provider. To be used for contacting
service provider to resolve problems with location data. Possible
values TN number, enumerated values when not
available.</xs:documentation>
</xs:annotation>
<xs:union memberTypes="xs:anyURI">
<xs:simpleType>
<xs:restriction base="xs:string">