One document matched: draft-winterbottom-geopriv-held-context-04.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2818 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC3693 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml">
<!ENTITY RFC3688 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC4745 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4745.xml">
<!ENTITY RFC4825 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4825.xml">
<!ENTITY I-D.ietf-geopriv-http-location-delivery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml">
<!ENTITY I-D.ietf-geopriv-l7-lcp-ps PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-l7-lcp-ps.xml">
<!ENTITY I-D.ietf-geopriv-lbyr-requirements PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lbyr-requirements.xml">
<!ENTITY I-D.ietf-geopriv-lis-discovery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lis-discovery.xml">
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" ipr="trust200902">
<front>
<title abbrev="HELD Contexts">Establishing Location URI Contexts using HTTP-Enabled Location Delivery (HELD)</title>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 242 212938</phone>
<email>james.winterbottom@andrew.com</email>
<uri>http://www.andrew.com/products/geometrix</uri>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 242 212915</phone>
<email>martin.thomson@andrew.com</email>
<uri>http://www.andrew.com/products/geometrix</uri>
</address>
</author>
<date month="April" year="2009"/>
<area>Real-Time Applications and Infrastructure</area>
<workgroup>Geopriv</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes a protocol extension for the HTTP-Enabled Location Delivery (HELD) protocol. It allows a Target to manage their location information on a Location Information Server (LIS) through the application of constraints invoked by accessing a location URI. Constraints described in this memo restrict how often location can be accessed through a location URI, how long the URI is valid for, and the type of location information returned when a location URI is accessed. Extension points are also provided.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The HTTP Enabled Location Delivery (HELD) protocol specification <xref target="I-D.ietf-geopriv-http-location-delivery"/> provides a set of features that can be used by a Target to retrieve location information from a Location Information Server (LIS). The LIS is able to optionally provide a <xref target="I-D.ietf-geopriv-lbyr-requirements">location URI</xref>, which provides a reference to location information.
</t>
<t> A location URI that is provided by a LIS using the basic HELD specification, is essentially immutable once retrieved. There is no means provided of controlling how the URI is used. A default policy is applied to the URI, which is fixed until the location URI expires; a Location Recipient in possession of the location URI can retrieve the Target's location until the expiry time lapses.
</t>
<t>This basic mechanism may be reasonable in a limited set of applications, but is unacceptable in a broader range of applications. In particular, the ability to change policy dynamically is required to better protect the privacy of the Target. <xref target="I-D.ietf-geopriv-lbyr-requirements"/> enumerates several requirements relating to location URIs that cannot be achieved using the basic HELD specification. This specification provides support for these requirements in HELD.
</t>
<t>Two new forms of HELD request are defined by this document. These requests relate to the creation and maintenance of a <spanx style="emph">HELD context</spanx>, a concept that is explained in more detail in <xref target="context"/>.
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC2119"/>. </t>
<t>This document uses the terms defined in <xref target="RFC3693"/> (Target, Location Recipient, Location Server), <xref target="I-D.ietf-geopriv-lbyr-requirements"/> (location URI), and <xref target="I-D.ietf-geopriv-l7-lcp-ps"/> (Location Information Server, or LIS).
</t>
<t>The distinction between Location Server (LS) and Location Information Server (LIS) is important. LS is used to refer to the role that serves a location URI, whereas a LIS is the role that provides the location configuration. Both roles might be assumed by the same entity, but the roles could be separate.
</t>
</section>
<section anchor="context" title="HELD Contexts">
<t>A location URI is a reference to the current location of a Target. The host identified in the URI, the Location Server (LS), serves requests to a location URI using two classes of data:
<list style="hanging">
<t hangText="authorization policy:">Authorization policies are set by Rule Makers and determine whether the requester is permitted to receive location information and whether there are any constraints on that information.
</t>
<t hangText="location determination inputs:">Information on the identity of the Target and how location information for that Target can be acquired might be saved by the LS.
</t>
</list>
This information is associated with every location URI served by an LS. The collection of data used by the LS establishes a "context" for the location dereference request made by a Location Recipient.
</t>
<t>In <xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref>, the establishment of the necessary contextual information is implicit. Creation of a location URI implies that the LIS has provided the LS with sufficient information to service requests to that URI.
</t>
<t>This document provides a more explicit mechanism for the creation and management of the contextual information used in serving a location URI. This information - dubbed a "HELD context" (simply "context" in this document) - can be created, updated and destroyed at the request of the Device. In addition, a Device is able to establish authorization policies in the form of <xref target="RFC4745">common policy documents</xref> that provide greater control over how a location URI is served by the LS.
</t>
<section title="Simplified Model">
<t>The model assumed in this specification, shown in <xref target="model"/>, is a simplified variant of that in <xref target="RFC3693"/> that includes the LIS entity.
</t>
<figure anchor="model" title="HELD Contexts Model">
<artwork><![CDATA[
+------------+
| |
| Rule Maker | +-------------+ +-----------+
| | | | | |
+ - - -- - - + | Location | | Location |
| | | Server |-----------| Recipient |
| Target | | | (LDP) | |
| | + - - - - - - + +-----------+
+ - - -- - - + | | |
| | | Location | |
| Device |-----------| Information | |
| | (LCP) | Server | |
+------------+ | | |
| +-------------+ |
| |
`------------------(Conveyance)-------------------'
]]></artwork>
</figure>
<t>This model assumes some form of relationship between a Rule Maker, Target and Device; for instance, the Rule Maker and Target might be the same person. The Device is operated under the control of a Rule Maker and is able to provide authorization policies or disseminate location URIs in accordance with the Rule Maker's wishes.
</t>
<t>This document also assumes a relationship is assumed between LIS and LS. LIS and LS together generate location URIs and maintain context information. These roles could be filled by the same entity.
</t>
<t>The location configuration protocol (LCP) interface is extended by this document to include a rules interface for the Rule Maker associated with the Target and Device. This model does not preclude the existence of other Rule Makers that use other rules interfaces.
</t>
</section>
<section anchor="policies" title="Authorization Policies">
<t>A Device is able to specify an authorization policy when creating or updating a context. The authorization policy states which Location Recipients are able to access location information through the context and the associated URIs, plus any other constraints on this access.
</t>
<t>A Device is able to provide a policy document in the form of a <xref target="RFC4745">common policy document</xref> or an <spanx style="verb">https:</spanx> reference to one. Existence of an explicit authorization policy implies that the "authorization by access control lists" model (<xref target="I-D.ietf-geopriv-lbyr-requirements"/>) is to be applied. The LS uses the authorization policy document to control how location information is provided to Location Recipients.
</t>
<t>Absence of policy, or an explicit indication otherwise, indicates that the LS is permitted to apply the "authorization by possession" model (<xref target="I-D.ietf-geopriv-lbyr-requirements"/>). Any Location Recipient that proves possession of the location URI by making a location dereference request to the URI is granted permission to receive the location information. Location URIs for the associated context have random components with enough entropy to make possession more likely to be as a result of receiving the location URI from the Device than guesswork.
</t>
</section>
<section title="Context Lifetime">
<t>A HELD context has a finite lifetime. This limits the time that a context might refer to a Device that has since left the network. Of course, a LIS might have a means of detecting the absence of a given Device, invaliding any contexts when the Device is no longer present.
</t>
<t>The lifetime of the context is negotiated between Device and LIS. The Device requests a certain lifetime and the LIS provides a location URI that is valid for up to the requested time. A Device is able to extend the lifetime of a context by updating the context information. Given regular updates, a context might persist indefinitely, providing that authorization by possession is not used.
</t>
<t>A Device can request that the LIS remove context information, invalidating the associated location URIs, by the same mechanism used to extend the lifetime.
</t>
</section>
<section anchor="snapshot" title="Snapshot Contexts">
<t>At the time that a context is created, the Device is able to request that the context refer to a static document that is created at the time of request. The LIS creates a Location Object (LO) based on the associated HELD request parameters and stores the LO. All requests to the location URI created in response to this request are served based on the stored LO.
</t>
<t>This basic constraint on the context applies for the life of the context. Only the application of authorization policy rules can change what is provided to different Location Recipients. If authorization by possession is used, the associated location URI is different to a Location Object only in that it needs to be dereferenced.
</t>
</section>
</section>
<section anchor="details" title="Protocol Details">
<t>This specification introduces three new HELD messages, create context (<createContext>), update context (<updateContext>), and context response (<contextResponse>).
</t>
<t>All context-related messages are HELD messages, sent using the <spanx style="verb">application/held+xml</spanx> MIME type defined in <xref target="I-D.ietf-geopriv-http-location-delivery"/>.
</t>
<t>A LIS that does not understand this specification returns a HELD <spanx style="verb">unsupportedMessage</spanx> error code in a HELD <spanx style="verb">error</spanx> message. A LIS that does understand this specification returns errors associated with context operations in a HELD error message. New error codes relating to failed context operations are defined in <xref target="errors"/>.
</t>
<t>The specification assumes that the LIS was discovered as part of the <xref target="I-D.ietf-geopriv-lis-discovery">LIS discovery</xref> and that the LIS is able to provide location information.
</t>
<section anchor="createcontext" title="Create Context">
<t>The Device creates a context on the LIS using a create context message. A sample create context request is shown in <xref target="ex-create"/>.
</t>
<figure anchor="ex-create" title="Create Context Example">
<artwork><![CDATA[
<createContext
xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
<lifetime>7200</lifetime>
<snapshot>false</snapshot>
<policy>
<ruleset-reference>
http://policy.example.com/geolocation-policy/users/alice/index
</ruleset-reference>
</policy>
</createContext>
]]></artwork>
</figure>
<t>The following parameters of the create context request are defined:
<list style="hanging">
<t hangText="lifetime:">The maximum lifetime of the context in seconds. All create contexts requests include this parameter. The LIS MAY create the context with a shorter lifetime than was requested, but the lifetime MUST NOT be longer than was requested.
</t>
<t hangText="snapshot:">Whether the value provided to location Recipients is fixed from the time that the context is created (see <xref target="snapshot"/>). This a boolean parameter with a default value of <spanx style="verb">false</spanx>, meaning that the context the Target's location at the time that the location URI is dereferenced.
</t>
<t hangText="policy:">An authorization policy, either included directly as an instance of a <xref target="RFC4745">common policy</xref> document, or by reference as a URI. Only one of the following forms of policy are permitted:
<list style="hanging">
<t hangText="cp:ruleset:">The Device is able to provide an authorization policy explicitly in the request by including a common policy document in the create context request. A <spanx style="verb">ruleset</spanx> element is included as a child of the <spanx style="verb">policy</spanx> element.
</t>
<t hangText="ruleset-reference:">Alternatively, a reference to a policy document can be included using the <spanx style="verb">ruleset-reference</spanx> element. A Rule Maker might maintain an authorization policy on a server (perhaps with <xref target="RFC4825">XCAP</xref>). This reference MUST be an <spanx style="verb">https:</spanx> URI. The LS MUST retrieve the policy before granting any Location Recipient access to location information; the policy MAY either be retrieved immediately or as a Location Recipient makes a request. The LS can be expected to retrieve the policy document once only, but it MAY be retrieved multiple times.
<vspace blankLines="1"/>
Note that the LIS could be unable to detect errors in policy before sending a response to a request that includes this element. A successful context response might be sent, even if the policy document cannot be retrieved by the LIS or the referenced policy document is not understood by the LIS.
</t>
<t hangText="possession:">Absence of policy information in a create context request implies that <xref target="I-D.ietf-geopriv-lbyr-requirements">authorization by possession</xref> is used for the context. The <spanx style="verb">possession</spanx> element provides an explicit indication that this policy is to be applied.
</t>
<t hangText="otherPolicy:">Alternative policy information might be provided. This element is provided to allow for expansion. A LIS MAY reject requests that contain policy that it does not understand with the <spanx style="verb">badPolicy</spanx> error code.
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="updatecontext" title="Update Context">
<t>A Device is able to update policy or change the lifetime of a context using an update context request. Other context parameters defined in other specification might also be updated using this method.
</t>
<t>Once created, a context that contains a <spanx style="verb">snapshot</spanx> of the Target's location cannot be made dynamic; the same applies in converse, a dynamic context cannot be made into a static snapshot.
</t>
<t>A Device might maintain more than one HELD context; therefore, the request needs to identify the context to be updated. The <spanx style="verb">context-id</spanx> is included in this message.
</t>
<figure anchor="ex-update" title="Update Context Example">
<artwork><![CDATA[
<updateContext
xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
<context-id>uhvuhdbnuiehudbnvcujevuijeijcvij3</context-id>
<lifetime>3600</lifetime>
<policy>
<cp:ruleset xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<!-- authorization policy rules -->
</cp:ruleset>
</policy>
</updateContext>
]]></artwork>
</figure>
<t>When a Device includes a <spanx style="verb">lifetime</spanx> element in an update context message, the lifetime of the context is modified. If the requested lifetime is longer than the time remaining before the context expires, the context lifetime is lengthened. If the requested lifetime is shorter than the remaining time, the context lifetime is shortened.
</t>
<t>A context that is updated continuously can be maintained indefinitely using this mechanism. The LIS MAY provide a shorter lifetime than the requested time. In particular, the total lifetime of contexts that use authorization by possession MUST be limited.
</t>
<t>This mechanism also allows for the cancellation of contexts. The Device indicates a context lifetime of 0 in the update context request. The LIS MAY also terminate a context immediately if the lifetime value is less than 10 seconds.
</t>
<figure anchor="ex-terminate" title="Update Context Termination Example">
<artwork><![CDATA[
<updateContext
xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
<context-id>uhvuhdbnuiehudbnvcujevuijeijcvij3</context-id>
<lifetime>0</lifetime>
<policy>
<possession/>
</policy>
</updateContext>
]]></artwork>
</figure>
<t>When an update context request contains policy information, that policy information replaces any existing policy. Omitting the <spanx style="verb">policy</spanx> element means that the previous policy remains unchanged. If a <spanx style="verb">ruleset-reference</spanx> element is provided, the LS MUST retrieve the referenced policy document before serving subsequent requests from Location Recipients. Conditional HTTP requests, such as those containing the <spanx style="verb">If-Modified-Since</spanx> header MAY be used to avoid retrieval of the entire policy.
</t>
<t>The rules regarding the construction of location URIs in <xref target="I-D.ietf-geopriv-lbyr-requirements"/> differ based on the authorization model used. The LIS MUST NOT permit a change in policy if the location URIs associated with the context do not meet the requirements for the updated authorization model. See <xref target="idandurirules"/> for more details.
</t>
</section>
<section anchor="contextresponse" title="Context Response Message">
<t>The context response message is sent in response to a create context request or an update context request. This message includes information about the context that has been created, updated or destroyed.
</t>
<t>The <spanx style="verb">code</spanx> attribute of the context response indicates what action was accomplished by the request:
<list style="hanging">
<t hangText="created:">The context was successfully created.</t>
<t hangText="updated:">The context was successfully updated.</t>
<t hangText="destroyed:">The context was destroyed.</t>
</list>
</t>
<t>The context response contains a <spanx style="verb">context</spanx> element that includes information about the context that was the subject of the request.
<list style="hanging">
<t hangText="id:">A value that uniquely identifies the context within the context of the LIS. This identifier is used to identify a context for update context requests. Knowledge of this value is used by the LIS to authenticate and authorize update context requests. The Target MUST keep this value secret.
</t>
<t hangText="expires:">The time at which the context will expire. After this time, all location URIs that reference this context no longer work.
</t>
<t hangText="snapshot:">Whether the context contains a snapshot of the Target's location. This value has a default value of <spanx style="verb">false</spanx>.
</t>
</list>
</t>
<t>The LIS also provides a set of URIs that can used to access the Target's location using the created context. The set of URIs does not change over the lifetime of the context.
</t>
<t>A context response message sent in reply to the create context message in <xref target="ex-create"/> might look like <xref target="ex-response"/>.
</t>
<figure anchor="ex-response" title="Context Response Example">
<artwork><![CDATA[
<contextResponse code="created"
xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
<context id="uhvuhdbnuiehudbnvcujevuijeijcvij4"
snapshot="false" expires="2007-11-01T13:30:00">
<locationUriSet>
<locationURI>
https://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4
</locationURI>
<locationURI>
pres:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769
</locationURI>
</locationUriSet>
</context>
</contextResponse>
]]></artwork>
</figure>
</section>
<section anchor="errors" title="Context Errors">
<t>A set of new HELD error codes are minted for use in context requests and responses:
<list style="hanging">
<t hangText="badPolicy:">The LIS (or LS) was unable to use the included policy due to it being invalid, badly formed, or inaccessible (when <spanx style="verb">ruleset-reference</spanx> is used). A LIS MAY return an error with this code if the policy contains no rules that could be used under any circumstances. For instance, all the rules might have validity intervals that do not correspond with the lifetime of the URI, or rules might require authentication modes that are not supported by the LS.
</t>
<t hangText="unknownContext:">The LIS was unable to find the context, possibly because the context identifier provided was invalid or because the context has already expired.
</t>
<t hangText="contextFailure:">The LIS was unable to create or update the context.
</t>
</list>
</t>
<t>Any other HELD error message can be provided in response to a create or update context request.
</t>
<figure anchor="ex-error" title="Example Error Message">
<preamble>The following HELD error is sent in response to a create context request where the LIS indicates that snapshot is not supported.
</preamble>
<artwork><![CDATA[
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="contextFailure" message="Snapshot is not supported"/>
]]></artwork>
</figure>
</section>
<section anchor="idandurirules" title="Location URI and Context Identifier Generation Rules">
<t>Location URIs generated by a LIS (or LS) MUST meet the construction requirements in <xref target="I-D.ietf-geopriv-lbyr-requirements"/>. In particular, the requirements for a location URI that operates on the authorization by possession model are more stringent than one that operates on an authorization policy.
</t>
<t>Location URIs that operate on authorization by possession MUST be difficult to guess. Inclusion of a sequence of characters with at least 128 bits of random entropy is RECOMMENDED. More entropy might be required for location URIs with longer lifetimes. If the LIS permits changing of the authorization model that applies to a context, then the more stringent requirements MUST be complied with.
</t>
<t>The context identifier provided by the LIS to the Target in the context response message MUST be unique. Context identifiers are secrets used to indicate authorization for context update requests. Therefore, context identifiers MUST NOT be easily guessable. Inclusion of a sequence of characters with at least 128 bits of random entropy is RECOMMENDED.
</t>
<t>A location URI MUST NOT include information that could be used in any way to derive the value of a context identifier. Similarly, context identifiers MUST NOT be based on Target identity.
</t>
<t>New contexts MUST have unique location URIs that have not previously been used for other contexts, even if the previous context was for the same Target.
</t>
</section>
</section>
<section anchor="schema" title="XML Schema">
<figure>
<artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:context"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ctxt="urn:ietf:params:xml:ns:geopriv:held:context"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:context">
HELD Context Management
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This document defines messages for HELD context management.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
<xs:complexType name="policyType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:element name="ruleset-reference" type="xs:anyURI"/>
<xs:element ref="cp:ruleset"/>
<xs:element name="possession" type="ctxt:empty"/>
<xs:element name="otherPolicy" type="xs:anyType"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="createContextType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="lifeTime" type="xs:nonNegativeInteger"/>
<xs:element name="snapshot" type="xs:boolean"/>
<xs:element name="policy" type="ctxt:policyType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="updateContextType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="context-id" type="xs:NCName"/>
<xs:element name="lifeTime" type="xs:nonNegativeInteger"
minOccurs="0"/>
<xs:element name="policy" type="ctxt:policyType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="codeType">
<xs:restriction base="xs:token">
<xs:enumeration value="created"/>
<xs:enumeration value="updated"/>
<xs:enumeration value="destroyed"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="uriSetType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationURI" type="xs:anyURI"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="contextType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="locationUriSet" type="ctxt:uriSetType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:attribute name="expires" type="xs:dateTime"
use="required"/>
<xs:attribute name="snapshot" type="xs:boolean"
use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="contextResponseType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="context" type="ctxt:contextType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="code" type="ctxt:codeType"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="createContext" type="ctxt:createContextType"/>
<xs:element name="updateContext" type="ctxt:updateContextType"/>
<xs:element name="contextResponse" type="ctxt:contextResponseType"/>
</xs:schema>
]]></artwork>
</figure>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The data that is maintained in a HELD context is privacy sensitive information. This information is provided by a Device for the purposes of providing authorized Location Recipients with location information. The LIS MUST NOT use the information it stores in a HELD context for anything other than serving requests to the associated location URIs.
</t>
<t>The LS MUST enforce the authorization policy established by the Device. The authorization policy determines which Location Recipients are permitted to receive location information, and how that location information is provided. An authorization policy can be updated by the Device at any time using the update context request; after the LIS responds to this request, the authorization policy applies to all subsequent requests from Location Recipients.
</t>
<t>An authorization policy can be referenced using <spanx style="verb">ruleset-reference</spanx> in a create context or update context request. The LS MUST retrieve any referenced authorization policy using <xref target="RFC2818">HTTP over TLS</xref> before providing location information to any Location Recipient.
</t>
<t>Context identifiers are confidential information shared only between LIS and Device. Location URIs are also confidential if authorization by possession is chosen by the device, in which case the location URI is shared only between LIS, Device and authorized Location Recipients. The LIS MUST ensure that context identifiers and location URIs are constructed following the rules described in <xref target="idandurirules"/> of this document.
</t>
<t><xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref> mandates the use of TLS for exchanges between a Device and the LIS. TLS provides confidentiality, protection from modification, LIS (and possibly Device) authentication. Messages related to HELD contexts contain information that requires the same protections.
</t>
<section title="Multiple Contexts from the 'Same' Target">
<t>It is conceivable that a LIS will be required to provide location to Devices residing behind a NAT. A home gateway is a good example of a situation where the relatively small geographic area served by the gateway is adequately served by a LIS external to that network. Devices within the home network appear to have the same identity information to a LIS - requests all originate from the same IP address. In this case, each Device might create its own context on the LIS. The LIS treats each context individually even though the LIS might be unable to distinguish between the actual Devices making the requests.
</t>
<t>It is also possible that a single Device could request multiple contexts. Devices might have multiple users, or multiple applications running that each have have different privileges, different privacy requirements or different Rule Makers. Therefore, might create different contexts for different uses: each might a different policy that reflects the needs of the user or application. Information provided by a Device related to a context MUST NOT be used by the LIS outside of that context.
</t>
<t>The state information maintained by the LIS or LS in providing a context presents a denial of service attack vector. Limiting the number of contexts that the LIS allows to be created can protect against such attacks. Any limits need to consider the usage pattern expected. If home gateways are commonly deployed in the access network, then the LIS MUST allow for more than one context for each discrete identifier. However, to ensure that LIS resources are not exhausted, the LIS MUST limit the number of contexts that it permits from each identifier.
</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document registers the schema and associated namespace with IANA. </t>
<section
title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:context">
<t>This section registers a new XML namespace, <spanx style="verb"
>urn:ietf:params:xml:ns:geopriv:held:context</spanx>, as per the guidelines in <xref
target="RFC3688"/>. <list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:held:context</t>
<t>Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), James
Winterbottom (james.winterbottom@andrew.com).</t>
<t>XML: <figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Context Management Messages</title>
</head>
<body>
<h1>Namespace for HELD Context Management Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:context</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XML Schema Registration">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:geopriv:held:context</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), James
Winterbottom (james.winterbottom@andrew.com).</t>
<t hangText="Schema:">The XML for this schema can be found as the entirety of <xref
target="schema"/> of this document. </t>
</list>
</t>
</section>
<section title="HELD Error Code Registration">
<t>Reference: <xref target="errors"/> of RFCXXXX (i.e., this document) specifies the following HELD error codes:
<list>
<t>badPolicy</t>
<t>unknownContext</t>
<t>contextFailure</t>
</list>
These error codes and their descriptions are added to the HELD error code respository defined in <xref target="I-D.ietf-geopriv-http-location-delivery"/>.
</t>
</section>
</section>
<section title="Acknowledgements">
<t>Thanks to Adam Muhlbauer and Neil Justusson for their comments on the pre-version of this draft. </t>
<t>Thanks also to Tim Zelinski and Michael Diponio, who pointed out a problems while implementing an early revision of this specification.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2818;
&RFC3688;
&RFC4745;
&I-D.ietf-geopriv-http-location-delivery;
</references>
<references title="Informative References">
&RFC3693;
&RFC4825;
&I-D.ietf-geopriv-l7-lcp-ps;
&I-D.ietf-geopriv-lbyr-requirements;
&I-D.ietf-geopriv-lis-discovery;
</references>
<section title="Compliance to Location by Reference Requirements">
<t>This section describes how HELD and this specification comply to the location configuration protocol requirements stipulated in <xref target="I-D.ietf-geopriv-lbyr-requirements"/>.
<list style="format C%d.">
<t>"Location URI support: The configuration protocol MUST support a location reference in URI form."
<vspace blankLines="1"/>
Compliant: HELD only provides location references in URI form.
</t>
<t>"Location URI expiration: When a location URI has a limited validity interval, its lifetime MUST be indicated."
<vspace blankLines="1"/>
Compliant: All location URIs provided expire; the context response message indicates when the URI expires.
</t>
<t>"Location URI cancellation: The location configuration protocol MUST support the ability to request a cancellation of a specific location URI."
<vspace blankLines="1"/>
Compliant: Updating a context with a lifetime set to zero cancels a context.
</t>
<t>"Location Information Masking: The location URI form MUST, through randomization and uniqueness, ensure that any location specific information embedded within the location URI itself is kept obscure during location configuration."
<vspace blankLines="1"/>
Compliant: With an explicit reference to this requirement, the URIs produced for a HELD context are required to comply with this condition.
</t>
<t>"User Identity Protection: The location URI MUST NOT contain any user identifying information that identifies the user, device or address of record, (e.g., which includes phone extensions, badge numbers, first or last names, etc.), within the URI form."
<vspace blankLines="1"/>
Compliant: With an explicit reference to this requirement, the URIs produced for a HELD context are required to comply with this condition.
</t>
<t>"Reuse indicator: There SHOULD be a way to allow a client to control whether a location URI can be resolved once only, or multiple times."
<vspace blankLines="1"/>
Not compliant.
</t>
<t>"Validity Interval Indication: A location configuration protocol MUST provide an indication of the location URI validity interval (i.e., expiry time) when present."
<vspace blankLines="1"/>
Compliant: The <spanx style="verb">expires</spanx> attribute indicates the time when the context becomes invalid.
</t>
<t>"Location only: The location URI MUST NOT point to any information about the Target other than it's location."
<vspace blankLines="1"/>
Compliant: PIDF-LO documents that are produced by the LS in response to a request at the URI do not contain Target identification, unless policy states otherwise.
</t>
<t>"Location URI Not guessable: Where location URIs are used publicly, any location URI MUST be constructed using properties of uniqueness and cryptographically random sequences so that it is not guessable. (Note that the number of bits depends to some extent on the number of active location URIs that might exist at the one time; 128-bit is most likely enough for the near term.)"
<vspace blankLines="1"/>
Compliant: <xref target="idandurirules"/> describes how this requirement is met by implementations.
</t>
<t>"Location URI Optional: In the case of user-provided authorization policies, where anonymous or non-guessable location URIs are not warranted, the location configuration protocol MAY support optional location URI forms."
<vspace blankLines="1"/>
Not compliant: The format of location URIs generated by the LIS cannot be influenced through any of the parameters described in this document.
</t>
<t>"Location URI Authorization Model: The location configuration protocol SHOULD indicate whether the requested location URI conforms to the access control authorization model or the possession authorization model."
<vspace blankLines="1"/>
Compliant: The authorization model is explicitly selected by the Device in the request.
</t>
<t>"Location URI Lifetime: A location URI SHOULD have an associated expiration lifetime (i.e., validity interval), and MUST have an validity interval if used with the possession authorization model."
<vspace blankLines="1"/>
Duplicate requirement.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:47:46 |