A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)
Extracted elements (25)
Authorization by Possession uses the location URI itself as a shared secret; any entity that presents the URI is authorized. This model requires no authentication infrastructure, but once granted access cannot be easily revoked, and expiration of the URI is the primary limiting mechanism.
Mandatory support for HTTP GET ensures the location URI functions with generic HTTP user agents that are unaware it is a HELD URI, avoiding the need for specialized HELD-aware clients in all deployment scenarios.
Policy frameworks such as RFC 4745 are designed to degrade in a privacy-preserving direction: if a policy rule is conditioned on recipient identity and the protocol cannot assert that identity, the rule has no effect and the policy defaults to providing less information rather than more.
This document defaults to Authorization by Possession because no authentication mechanism is specified, making identity-based access control unavailable without future extensions. Selective disclosure via distinct URIs per recipient can substitute for identity-based authorization.
An 'http:' (non-TLS) location URI provides insufficient security in most deployments: the Rule Maker loses control over who receives location information, and the Location Recipient has no assurance of information integrity. Use is conditionally permitted only when another protection mechanism is in place.
Use of HELD as a dereference protocol is largely identical to its use as a location configuration protocol (RFC 5985), except that only 'locationRequest' is permitted, 'locationUriSet' MUST NOT appear in responses, and RFC 6155 device-identity parameters are always invalid and may be rejected.
A LIS MUST provide a HELD location response if it receives an HTTP GET request, rather than returning HTTP 405 (Method Not Allowed), to ensure interoperability with generic HTTP user agents.
HTTP GET requests to a HELD URI MUST be safe and idempotent per RFC 2616; there are no side effects of making the request, and a repeated request has no more effect than a single request.
Location Servers MUST be configured to issue only HTTPS URIs and respond only to HTTPS dereference requests, unless confidentiality and integrity protection are provided by another mechanism such as IPsec or a trusted network.
Location URIs MUST only be disclosed to authorized Location Recipients, as designated by the Rule Maker under the GEOPRIV architecture (RFC 6280).
Parameters and requests without known behavior for dereference MUST NOT be used. The LS MUST ignore parameters it does not understand unless they are known to be invalid; if understood and invalid, the LS MAY generate a HELD error response.
The HELD 'locationRequest' is the only request permitted for dereference; request parameters other than 'responseTime' and 'locationType' (including the 'exact' attribute) MUST NOT be accepted by the Location Server.
The Location Server MUST NOT generate location URIs or provide a 'locationUriSet' in response to a dereference request. If 'locationType' includes 'locationURI', the parameter is either ignored or rejected based on the 'exact' attribute.
The Location Server MUST NOT provide any information about the Target except its location unless policy from a Rule Maker allows otherwise, and MUST only provide an unlinked pseudonym in the 'entity' attribute of the PIDF-LO document unless the Rule Maker policy allows identity disclosure.
TLS MUST be used for dereferencing location URIs unless confidentiality and integrity are provided by some other mechanism. Location Recipients MUST authenticate the host identity using the domain name in the location URI per Section 3.1 of RFC 2818.
When TLS is used, the ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be used, and the Location Server MUST be authenticated per RFC 6125 to ensure the correct server is contacted.
Target identity protection requires both that the location URI not be associated with the Target's identity in any context, and that the PIDF-LO not contain Target identity information. The LS should use an unlinked pseudonym in the PIDF-LO 'entity' attribute to preserve anonymity.
Using authorization-by-possession location URIs in hop-by-hop protocols like SIP introduces on-path adversaries who may intercept the URI. This has implications for location-based applications such as emergency services and location-based routing, as discussed in RFC 6442.
An HTTP GET request to a HELD URI is treated as equivalent to a POST 'locationRequest' with 'locationType exact="false"' requesting both geodetic and civic location types. The LS returns a full HELD location response.
Content negotiation is supported via the HTTP 'Accept' header; a Location Recipient may include 'application/pidf+xml' to receive a bare PIDF-LO presence document in the HTTP response body rather than a wrapped HELD 'locationResponse' document.
The HELD 'locationRequest' element (with optional 'responseTime' and 'locationType' parameters) is the sole permitted request message when using HELD as a location dereference protocol over HTTP POST to an 'https:' or 'http:' location URI.
The Location Recipient MAY infer from a response bearing the content type 'application/held+xml' that the URI references a resource supporting HELD, enabling HELD-aware processing.
The overall dereference flow consists of three steps: (1) Target acquires a location URI from the LIS via a location configuration protocol; (2) Target conveys the URI to the Location Recipient; (3) Location Recipient dereferences the URI using HELD to obtain the PIDF-LO.
Privacy of location information is the primary security concern. TLS provides confidentiality and authentication of the server; authorization policies allow the Rule Maker to control access. The authorization-by-possession model further relies on TLS to protect the secrecy of the location URI itself during conveyance.
A minimal HELD dereference request is an HTTP POST with Content-Type 'application/held+xml' containing an empty 'locationRequest' element in namespace 'urn:ietf:params:xml:ns:geopriv:held'. The response carries a 'locationResponse' wrapping a PIDF-LO presence document.