A Presence-based GEOPRIV Location Object Format
updated by
- rfc-5139 — Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)
- rfc-5491 — GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations
- rfc-7459 — Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO)
Extracted elements (28)
MIME-level (whole-document) S/MIME security was chosen over XML element-level encryption/signatures because virtually any partial-protection configuration creates a risk of privacy leakage; protecting the PIDF document as a unit avoids these configuration pitfalls.
PIDF was chosen as the basis for the GEOPRIV location object because presence information has similar requirements for selective distribution, privacy-sensitive handling, and security, making it a natural fit for encapsulating location data without inventing a new format.
The 'usage-rules' schema is factored into a separate 'basicPolicy' namespace (urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy) to allow its reuse outside the core geopriv schema. The document notes that the semantics defined here apply only to the geopriv usage; any other reuse must define its own semantics.
PIDF-LO can be carried in any protocol capable of carrying XML or MIME. The registered MIME type is 'application/pidf+xml', enabling transport over SMTP, HTTP, SIP, or any other MIME-capable protocol without modification to those protocols.
All compliant applications MUST implement AES encryption for S/MIME as specified in RFC 3565, and MUST also support the baseline S/MIME encryption and digital signature algorithms. Implementations MUST support password-based CMS encryption.
All PIDF implementations supporting the geopriv XML Schema extensions MUST support S/MIME, specifically the CMS EnvelopedData content type (encryption) and SignedData content type (digital signatures).
Each 'geopriv' element MUST contain exactly one 'location-info' element (minOccurs=1, maxOccurs=1). Furthermore, all PIDF documents containing a 'geopriv' element MUST include one or more XML import directives indicating the schemas used for geographic location formats.
Each 'geopriv' element MUST contain exactly one 'usage-rules' element, even when the Rule Maker requests all subelements take their default values.
GML 3.0 ('feature.xsd' schema at urn:opengis:specification:gml:schema-xsd:feature:v3.0) is a MUST-implement baseline location format for all PIDF implementations that support the 'geopriv' element. The civicLoc format is a MAY.
Implementations SHOULD support X.509 certificates for S/MIME. When X.509 certificates are used to sign PIDF Location Objects, the subjectAltName of the certificate SHOULD use the 'pres' URI scheme.
The default value of 'retention-expires' MUST be assumed to be twenty-four hours from the PIDF 'timestamp' element (or from time of receipt if 'timestamp' is absent). If the value has already passed when the Location Recipient receives the object, the Recipient MUST discard it immediately.
The default value of 'retransmission-allowed' MUST be assumed to be 'no'; implementations MUST include this field with value 'no' if the Rule Maker specifies no preference.
The 'ruleset-reference' URI SHOULD use the HTTPS scheme; if it does, the server holding the rules MUST authenticate any access attempt. Rulesets carried as MIME bodies SHOULD be encrypted and signed by the Rule Maker; unsigned rulesets SHOULD NOT be honored by Location Servers or Recipients.
Values for the 'provided-by' element MUST be IANA-registered XML namespaces; new namespaces require review by an Expert Reviewer designated by the IESG.
Values of the 'method' element MUST be limited to values registered in the IANA 'method' token registry.
Including the 'method' element may inadvertently reveal that location information has been coarsened; for example, a 'DHCP' method tag paired with only city-level location strongly signals withheld information. Implementers should weigh this disclosure risk when including the 'method' element.
The 'provided-by' element can increase the effective resolution of location information or reveal protected location details; for example, identifying Columbia University as provider effectively narrows a target's location to a four-block area even if only state-level coordinates are included. The element SHOULD NOT be used unless organizational functions strongly depend on it.
The 'geopriv' element extends the 'status' element of PIDF and serves as the top-level container for location information. It has two mandatory subelements ('location-info' and 'usage-rules') and two optional subelements ('method' and 'provided-by'), plus extensibility slots for arbitrary other elements.
The 'location-info' element is a mandatory child of 'geopriv' and contains one or more chunks of location information in an imported XML format. The format is identified by the imported XML Schema namespace; both GML 3.0 and civicLoc formats are recognized.
The optional 'method' element is a text string describing how location information was derived (e.g., GPS, DHCP, Triangulation). Its permissible values are drawn exclusively from an IANA-managed registry pre-populated with seven tokens.
The optional 'provided-by' element identifies the entity or organization that supplied the location information, beyond what can be inferred from a signing certificate's subjectAltName. Its content must be elements from an IANA-registered XML namespace.
The 'usage-rules' element is a mandatory child of 'geopriv' and carries policy fields governing how the enclosed location may be used: 'retransmission-allowed', 'retention-expiry', 'external-ruleset' (a URI), and 'note-well' (human-readable directives). All four subelements are optional within the element, but the element itself is mandatory.
A new IANA registry for 'method' tokens is created, designating the manner in which location information was derived. Registration is open to any party on a first-come-first-serve basis. Seven initial tokens are registered: GPS, A-GPS, Manual, DHCP, Triangulation, Cell, 802.11.
A new IANA registry of XML namespaces for 'provided-by' elements is created for use with PIDF-LO objects. New registrations require Expert Review. The NENA dataProvider namespace (urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider) is pre-registered.
A URN sub-namespace is registered: urn:ietf:params:xml:ns:pidf:geopriv10, per the guidelines in RFC 3688 (the IETF XML Registry). This namespace is versioned '10' to satisfy the GEOPRIV requirement for version identification (REQ 2.10).
The document mandates end-to-end security via S/MIME applied to the PIDF document as a whole rather than per-element, because any partial protection configuration introduces potential for privacy leakage. S/MIME provides confidentiality, integrity, and authentication across the object's lifetime.
When a Location Server must modify a Location Object (e.g., to coarsen location before forwarding), end-to-end S/MIME encryption must be relaxed: the Generator MAY encrypt with a key decryptable by the Location Server, which then re-signs and re-encrypts for the Recipient. This is a necessary exception to the end-to-end model.
The civicLoc format ('civicAddress' type in namespace urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc) represents civic address location using up to 17 optional string fields: country (ISO 3166 two-letter code), A1–A6 (hierarchical administrative subdivisions), PRD, POD, STS (street directionals/suffix), HNO, HNS (house number and suffix), LMK, LOC, FLR, NAM, and PC (postal code). All fields are optional xs:string elements.