RFC 4119
A Presence-based GEOPRIV Location Object Format
RFC 4119 🎀 A Presence-based GEOPRIV Location Object Format
Written by J. Peterson from NeuStar 💅 It's a Standards Track doc, dated December 2005 🦋. The title block doesn't list any RFCs it obsoletes or updates, so there aren't any to chase down 🫶
Status of This Memo 💌
This doc specifies an Internet standards track protocol for the Internet community and asks for discussion and suggestions for improvements 🔥 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨ Distribution of this memo is unlimited 🌈
Copyright Notice 🔒
Copyright (C) The Internet Society (2005) 💜
Abstract 🧚
This doc describes an object format for carrying geographical information on the Internet 🗺️ This location object extends the Presence Information Data Format (PIDF). PIDF was designed for communicating privacy-sensitive presence information, and it has similar properties 🫶
Table of Contents 📚
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Location Object Format ..........................................4
2.1. Baseline PIDF Usage ........................................4
2.2. Extensions to PIDF for Location and Usage Rules ............5
2.2.1. 'location-info' Element .............................5
2.2.2. 'usage-rules' Element ...............................7
2.2.3. 'method' Element ....................................9
2.2.4. 'provided-by' Element ...............................9
2.2.5. Schema Definitions .................................10
2.3. Example Location Objects ..................................14
3. Carrying PIDF in a Using Protocol ..............................15
4. Securing PIDF ..................................................15
5. Security Considerations ........................................17
6. IANA Considerations ............................................17
6.1. 'method' Tokens ...........................................17
6.2. 'provided-by' Elements ....................................18
6.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10 .....................18
7. Acknowledgements ...............................................19
A. Appendix: NENA Provided-by Schema ..............................20
A.1. dataProvider XML Schema ...................................21
Normative References ..............................................22
Informative References ............................................221. Introduction ✨
Geographical location info describes a physical position in the world that may match the past, present, or future location of a person, event, or device 🗺️ Tons of apps on the Internet today benefit from sharing location info, like mapping and navigation apps, "friend finders" on cell phones, and so on 📍 But these apps can reveal where a person is in ways that go against the user's preferences 😭 Privacy slip-ups can come from weak protocol security, which lets eavesdroppers capture location info, from not being able to express or honor user preferences, or from similar flaws common in existing systems 💀 Unwanted disclosure of someone's physical location is one of the more serious privacy issues users face on the Internet 🚨
So there's a clear need to convey geographical location info inside an object that holds a user's privacy and disclosure preferences and is protected by strong cryptographic security 🔐 Earlier work [13] noticed this problem has some resemblance to the general problem of communicating and securing presence information on the Internet 👀 Presence (defined in [12]) gives a real-time communications disposition for a user, so it has similar needs for selective distribution and security 💅
That's why this doc extends the XML-based Presence Information Data Format (PIDF [2]) to let location info be wrapped inside a presence document 🎀
This doc doesn't invent a new format for location info itself 🙅♀️ Plenty of existing formats based on civic location, geographic coordinates, and the like have been built in other standards forums 🌸 Instead, it defines an object that's suitable for both identifying and encapsulating those preexisting formats, and for providing adequate security and policy controls over how location info gets distributed across the Internet 🦋
The location object described here can be used independently of any "using protocol," as the term is defined in the GEOPRIV requirements [10] 💖 It's considered a perk of this proposal that existing presence protocols (such as [14]) would natively accept the location object format defined here, and could compose location info with other presence info, because this location object is an extension of PIDF 🧚 But using this location object format isn't limited to presence-using protocols. Any protocol that can carry XML or MIME types can carry PIDF 🌈
Some of the requirements in [10] and [11] are about data collection and usage policies tied to location objects 📜 This doc gives only the minimum markup a user needs to express the privacy preferences the GEOPRIV requirements call for (the three basic elements in [11]) ✨ It does not show how a full XML-based ruleset, meeting the needs of Location Servers, could be embedded in PIDF 🙈 The assumption is that other protocols (such as HTTP) will move rules between Rule Holders and Location Servers, and that full rulesets will be defined in a separate document 🫶
1.1. Conventions Used in This Document 🎀
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] 📖
2. Location Object Format 🦋
2.1. Baseline PIDF Usage 💖
The GEOPRIV requirements [10] (or REQ for short) call for a name for the person, place, or thing that location info describes (REQ 2.1) 🏷️ PIDF already has one: every PIDF document has an "entity" attribute on the 'presence' element, which holds the URI of the entity whose presence the document describes 💜 So if location info lives in a PIDF document, the URI in that "entity" attribute tells you who the location info is about (the 'presentity') 🎯 That URI generally uses the "pres" URI scheme defined in [3], and these URIs can work as unlinkable pseudonyms (per REQ 12) 🥷✨
PIDF can optionally contain a 'contact' element, which gives a URI where the presentity can be reached through some means of communication 📞 The URI scheme in the 'contact' value usually hints at how to reach them. If it's the SIP URI scheme, for example, SIP can be used, and so on 📱 Location info can show up without any associated means of communication, so the 'contact' element may or may not be present, depending on what the creator of the PIDF document wants 🤷♀️
PIDF can optionally contain a 'timestamp' element that marks the time the PIDF document was created 🕰️ This element corresponds to REQ 2.7a ⏰
PIDF has a 'status' element, which is mandatory 🔒 'status' can contain an optional child element, 'basic', that describes the presentity's communications disposition in very broad terms: either OPEN or CLOSED 🚪 For this doc's purposes, 'basic' status doesn't have to be included 💁♀️ But if communications disposition is included in a PIDF document beyond just geolocation, then 'basic' status may appear in a PIDF document that uses these extensions 🌈
PIDF also has a 'tuple' umbrella element, which holds an "id" element. That "id" identifies a segment of presence info so changes to it can be tracked over time, as multiple presence notifications come in 🔍 'timestamp', 'status', and 'contact' are all composed under 'tuple' 🧩
2.2. Extensions to PIDF for Location and Usage Rules 🌈
This XML Schema extends the 'status' element of PIDF with a complex element called 'geopriv' 👑 Two major subelements live inside geopriv: one for location info and one for usage rules 🗺️📜 Both are mandatory, and each gets its own section later on 💅 By composing these two subelements under 'geopriv', the usage rules are clearly and explicitly tied to the location info 🫶
For extensibility (see REQ 1.4), the schema lets any other subelements appear under the 'geopriv' element 🧚 Two other optional subelements are included in this doc: one that says how the geographical location was determined, and one that lets you explicitly name the entity that provided the info 🎀
2.2.1. 'location-info' Element 💖
Okay bestie, this is the part where the actual location lives 🗺️ Every 'geopriv' element MUST contain one 'location-info' element. A 'location-info' element holds one or more chunks of location information (per REQ 2.5). The format of that location information (REQ 2.6) is identified by the imported XML Schema, the one that describes the namespace in question. Also, all PIDF documents that contain a 'geopriv' element MUST contain one or more import directives that say which XML Schema(s) are used for geographic location formats 🧚
To keep GEOPRIV implementations interoperable, everyone needs to support the same baseline location format (see REQ 3.1). Since it satisfies REQ 2.5.1, this document assumes that Geography Markup Language (GML) 3.0 [15] shall be this mandatory format (a MUST implement for all PIDF implementations supporting the 'geopriv' element) 🎀
GML is extraordinarily thorough and versatile. It can model all kinds of geographic object types, topologies, metadata, coordinate reference systems, and units of measurement 🌈 The simplest package for GML that supports location information is the 'feature.xsd' schema. Even though 'feature.xsd' can express complicated geographical concepts, it needs very little markup to give you basic coordinate points for the most common cases 💅 Various format descriptions (including latitude/longitude based location information) are supported by Feature (see section 7.4.1.4 of [15] for examples), which lives here:
urn:opengis:specification:gml:schema-xsd:feature:v3.0Importing the Feature schema also transitively imports the necessary GML baseline schemas, so you get those for free ✨
Complex features are also available in GML, like modeling topologies and polygons, directions and vectors, or temporal indications of the time for which a particular location is valid for a target. But those need extra schemas imported 🔥 For the purposes of baseline interoperability as defined by this document, only support for the 'feature.xsd' GML schema is REQUIRED.
Implementations MAY support the civic location format (civicLoc) defined in Section 2.2.5. civicLoc provides the following elements:
+----------------------+----------------------+---------------------+
| Label | Description | Example |
+----------------------+----------------------+---------------------+
| country | The country is | US |
| | identified by the | |
| | two-letter ISO 3166 | |
| | code. | |
| | | |
| A1 | national | New York |
| | subdivisions (state, | |
| | region, province, | |
| | prefecture) | |
| | | |
| A2 | county, parish, gun | King's County |
| | (JP), district (IN) | |
| | | |
| A3 | city, township, shi | New York |
| | (JP) | |
| | | |
| A4 | city division, | Manhattan |
| | borough, city | |
| | district, ward, chou | |
| | (JP) | |
| | | |
| A5 | neighborhood, block | Morningside Heights |
| | | |
| A6 | street | Broadway |
| | | |
| PRD | Leading street | N, W |
| | direction | |
| | | |
| POD | Trailing street | SW |
| | suffix | |
| | | |
| STS | Street suffix | Avenue, Platz, |
| | | Street |
| | | |
| HNO | House number, | 123 |
| | numeric part only. | |
| | | |
| HNS | House number suffix | A, 1/2 |
| | | |
| LMK | Landmark or vanity | Low Library |
| | address | |
| | | |
| LOC | Additional location | Room 543 |
| | information | |
| | | |
| FLR | Floor | 5 |
| | | |
| NAM | Name (residence, | Joe's Barbershop |
| | business or office | |
| | occupant) | |
| | | |
| PC | Postal code | 10027-0401 |
+----------------------+----------------------+---------------------+Either the GML 3.0 geographical information format element or the location format element ('civicLoc') defined in this document MAY appear in a 'location-info' element. Both MAY also be used in the same 'location-info' element. So in summary: the feature.xsd schema of GML 3.0 MUST be supported by implementations compliant with this specification, and the civicLoc format MAY be supported by implementations compliant with this specification 🫶
2.2.2. 'usage-rules' Element 🔒
At the time this document was written, the policy requirements for GEOPRIV objects weren't definitively completed. Still, the 'usage-rules' element exists to satisfy REQ 2.8 and the requirements of the GEOPRIV policy requirements [11] document. Each 'geopriv' element MUST contain one 'usage-rules' element, even if the Rule Maker has requested that all subelements be given their default values 🌸
Following the policy requirements 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 limits retransmission, one limits retention, and one contains a reference to external rulesets. Those three fields are instantiated here by the first three elements. The fourth element gives you a generic space for human-readable policy directives. Any of these fields MAY be present in a Location Object 'usage-rules' element, and 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', distributing this Location is permitted (barring an existing out-of-band 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 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 also not present, then the value MUST be assumed to be twenty-four hours from the time at which the Location Object is received by the Location Recipient. 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 ⏳'ruleset-reference': This field contains a URI that indicates where a fuller ruleset of policies, related to this object, can be found. This URI SHOULD use the HTTPS URI scheme. If it does, 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. The URI MAY, alternatively, use the CID URI scheme [7], in which case it MUST denote a MIME body carried with the Location Object by the using protocol. Rulesets carried as MIME bodies SHOULD be encrypted and signed by the Rule Maker. Unsigned rulesets SHOULD NOT be honored by Location Servers or Location Recipients. Note that in order to avoid network lookups that result in an authorization failure, creators of Location Objects MAY put HTTPS-based ruleset-references into an encrypted external MIME body referenced by a CID. That way, recipients of the Location Object that are unable to decrypt the external MIME body will not learn the HTTPS URI unless they are able to decrypt the MIME body 🕵️♀️'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 🎀
Okay so the optional provided-by element tells you which entity or organization actually handed over the location info, beyond what you could already guess from the domain on the signing certificate 🔍. Here's a cute (made-up) game-system example:
<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. 📋
Not everyone needs this one, tbh. The provided-by element is for special requirements where the extra overhead (IANA registration, a bigger location object) and the possibility of location info leaking are acceptable tradeoffs 💅.
In general, the entity that supplied the location info is already communicated by the subjectAltName of the certificate the location object is signed with, so this element is unnecessary. 'Provided-by' is meaningful in particular cases when the creator of a location object wants to point at a specific system or party inside a complex administrative domain, including situations envisioned for providing emergency services in a diverse national context 🚨. It might help, for example, the recipient of a malformed or misleading location object figure out which particular system malfunctioned 🛠️.
Heads up, bestie: this info can accidentally tell the receiver more than you meant it to. It can raise the effective resolution of the geospatial or civic info, or even reveal location info that was supposed to stay totally protected 🙈.
Think about what might have made Columbia University choose to register and use the provided-by element. If an example LO only includes state-level info, then saying it was provided by Columbia University is a strong hint that the Target is actually in a four-block area in Manhattan 😳. So this element should be used only when organizational functions strongly would depend on it. In all but those usages, the subjectAltName of the certificate will suffice, and 'provided-by' SHOULD NOT be used. 💀
2.2.5. Schema Definitions 📚
Quick note: the XML namespace [4] for this extension to PIDF has a version number of 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 was split out from the basic geolocation object so it can be reused. 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. It's giving simple and easy ✨.
<?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). Think of them as the bare-bones, no-filter version 🧸.
The following XML instance document is an example of using simple GML 3.0 markup with a few of the policy directives specified above, all inside 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 using the civicLoc object with a few of the policy directives specified above, inside 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, so PIDF can be carried in any protocol that's capable of carrying XML 📦. A MIME type has also been registered for PIDF: application/pidf+xml. That means PIDF may be carried as a MIME body in protocols that use MIME (like SMTP, HTTP, or SIP), with an encapsulating set of MIME headers that includes 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 ✨
okay so there are lots of ways to lock down XML docs 🔐 XML itself can do partial stuff like element-level encryption and digital signature properties, but that's not what we're doing here 💅
for this doc we're only looking at securing a whole PIDF document at once, not element by element 🎀 None of the requirements [10] say only some of a location object needs protection while the rest stays open 🙈 Honestly any setup like that would open up privacy leaks, so MIME-level security is the move 💖
S/MIME [5] lets you apply security properties (confidentiality, integrity, and authentication) to the contents of a MIME body 🦋 So every PIDF implementation that supports the XML Schema extensions for location information in this document MUST support S/MIME 🔥 Specifically they MUST support the CMS [6] EnvelopedData and SignedData content types, which handle encryption and digital signatures, respectively 💜 The authors think this covers REQs 2.10, 13, 14.1, 14.2, 14.3, and 14.4 ✨
Also, all compliant applications MUST implement the AES encryption algorithm for S/MIME, as specified in [8] (and per REQ 15.1) 👑 And obviously implementations MUST also support the baseline encryption and digital signature algorithms from the S/MIME spec 🫶
S/MIME usually means X.509 [9] certificates 🌸 So to encrypt something end-to-end for a specific destination (a Location Recipient), the Location Generator needs credentials, typically an X.509 certificate issued to that Recipient 🧚 Implementations of this spec SHOULD support X.509 certificates for S/MIME, and they MUST support password-based CMS encryption (see [6]) 🍓 Any symmetric keying system SHOULD derive high-entropy content encoding keys (CEKs) 🔐 And when X.509 certificates are used to sign PIDF Location Objects, the subjectAltName of the certificate SHOULD use the "pres" URI scheme 🌈
Here's one deployment model they had in mind for S/MIME in PIDF docs 🎀 Location Servers hold X.509 certificates and share secrets with Location Generators and Location Recipients 🦋 When a Generator sends location info 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 info to a Recipient, it can be encrypted with password-based CMS encryption 💅 That way you can still get encryption even when the Location Recipient doesn't have its own X.509 certificate 🫶
S/MIME was built for end-to-end security between email peers that talk through multiple servers (mail transfer agents) that don't modify message bodies 💀 But there's at least one case where Location Servers DO modify Location Objects: when they enforce policies on behalf of the Rule Maker 😭 For example, a Rule Maker might say location info should be coarsened (made less specific) before it goes to certain recipients 🙈 If the Location Server couldn't modify a Location Object because it was encrypted, signed, or both, it couldn't do that job at all 💔 So when a Location Generator wants to let a Location Server modify these messages, they MAY encrypt them with a key the Location Server can decrypt (the digital signature can still come from the Location Generator's certificate, of course) 🔥 After changing the Location Object, the Location Server can re-sign it with its own credentials, and encrypt it with any keys issued to the Location Recipient if the Server knows them 👑
Note that policies for data collection and usage of location information, as far as they're carried inside a location object, are covered in Section 2.2.2 🌸
5. Security Considerations 🔐
okay this section is the scary-but-important part 😭 The threats facing an Internet protocol that carries geolocation information are laid out in [16] 🦋 The requirements identified in that threat analysis got folded into [10], especially Section 7.4 ✨ This document tries to comply with the security requirements from both of those efforts, as far as they apply to the location object itself (not the using protocol) 💜
Security of the location object defined here, including the normative requirements for implementations, is covered in Section 4 🎀 It focuses on end-to-end integrity and confidentiality properties applied to a location object for its whole lifetime, via S/MIME 🫶
Security requirements for using protocols (like authenticating subscribers to geographic information, etc.) are totally out of scope for this doc 🙈
6. IANA Considerations 🌈
6.1. 'method' Tokens 🍓
This doc asks IANA to create a brand new registry for 'method' tokens tied to the PIDF-LO object 💖 'method' tokens are text strings that show how the location info in a PIDF-LO object was derived or discovered 🧚 Any party may register new 'method' tokens with IANA as needed, first-come-first-serve 👑
This section pre-registers 7 new 'method' tokens for the 'method' element described above in Section 2.2.3 ✨ Here they are:
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 doc asks IANA to set up a new registry of XML namespaces for 'provided-by' elements used with PIDF-LO objects 🦋 Any new XML namespace registered for 'provided-by' MUST be reviewed by an Expert Reviewer designated by the IESG 🔥
This doc 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, following the guidelines in [4] 🌸 Here's the registration:
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>
END7. Acknowledgements 💖
This doc was put together with help from lots of folks in the GEOPRIV IETF working group 🧚 Huge special thanks to Carl Reed of OpenGIS for a super close read 👑
The civic location format in this doc was proposed by Henning Schulzrinne for communicating location info in DHCP, and it was taken over in its entirety for this doc ✨
James M. Polk wrote the text about the 'method' element and a big chunk of the 'provided-by' element 🌈 Nadine Abbott wrote the text of Appendix A 🫶
A. Appendix: NENA Provided-By Schema 🎀
This appendix registers the XML namespace urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider and the schema below, for use 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 PIDF-LO implementers, and they MAY support the dataProvider namespace 🌸 Other registrants of 'provided-by' namespaces are invited to use this registration as an informative example 🦋 Here's the registration:
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>
ENDA.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 notavailable.</xs:documentation>
</xs:annotation>
<xs:union memberTypes="xs:anyURI">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="10"/>
<xs:enumeration value="NOT FOUND"/>
<xs:enumeration value="UNAVAILABLE"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:schema>Normative References 📚
okay bestie, these are the docs the spec literally can't function without 🫶 Each one is a whole vibe, so here they are with all their deets:
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, October 2003.
[4] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January 2004.
[5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[7] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[8] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
Informative References 🔍
these ones are the extra reading, the "ooh tell me more" section 🧚✨
[10] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[11] Morris, J., Mulligan, D., and J. Cuellar, "Core Privacy Protections for Geopriv Location Object", Work in Progress, June 2003.
[12] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[13] Peterson, J., "A Presence Architecture for the Distribution of Geopriv Location Objects", Work in Progress, February 20003.
[14] 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.
[15] OpenGIS, "Open Geography Markup Language (GML) Implementation Specification", OGC 02-023r4, January 2003, <http://www.opengeospatial.org/specs/?page=specs>.
[16] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
Author's Address 🏡
this is where you find the author, Jon Peterson, over at NeuStar 💌
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/Full Copyright Statement ⚖️
okay the legal stuff, but make it cute 🎀 Copyright (C) The Internet Society (2005) 💖
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 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 🧠
so about the IP stuff, ngl it's a lot but here's the tea ☕
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. It also doesn't 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. 🫶
Acknowledgement 🙏
last but definitely not least, the people keeping the lights on 🌈 Funding for the RFC Editor function is currently provided by the Internet Society. ✨👑
📦 where this page comes from
- ietf: rfc4119 2005-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms