The HELD Protocol and Semantics
The HTTP Enabled Location Delivery (HELD) protocol (see Reference 3) is a location acquisition protocol designed specifically to meet the requirements for the LIS Target Interface, Third-Party Interface, Trusted-Party Query Interface, and Call-Back Interface. It is a web services protocol with the schema specification provided in Appendix B and protocol bindings provided in Appendix D. This section focuses on the HTTP binding as this is the recommended implementation for Devices.
When using the HTTP binding with the HELD protocol, connectivity between the Target and the LIS is done using secure HTTP (https). The LIS is identified by an HTTP URL, which for now will be assumed to be known to the Device. The LIS must identify itself to a connecting Target using an X.509 server-side certificate asserted for the access domain in which the Target and LIS reside. The following sections explain the HELD protocol in detail. Subsequent chapters will look at how these fundamentals can be applied to real network deployments to provide access-independent location acquisition.
HELD is designed to provide basic location acquisition functionality but in a manner that is easily extensible. This extensibility is possible because of the way in which HELD messages have been structured to allow additional identifiers and data to be passed from the client to the LIS. Additional identifiers and parameters are used depending on applications and network configurations; references to several HELD extensions are made throughout the remainder of the book.
Target Location Acquisition
The HELD protocol supports first and foremost a Target requesting its own location from a LIS using the previously defined Target Interface. The HELD protocol makes the assumption that location is required and will be used in the form of a PIDF-LO. This means that an End-Point can use the location object returned to it from the LIS and need not craft a PIDF-LO object based on certain pieces of data, as is the case with DHCP and LLDP-MED acquisition methods.
Basic Location Request
The most basic location request supported by the HELD protocol is the unqualified location request, where a Target is asking for any and all location information that the LIS may have on a Target's whereabouts (see Figure 4.6).
Figure 4.6: An unqualified location request.
The HELD protocol XML for this request would be
<locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held"/>
The HTTP binding for the HELD protocol has been designed specifically so that it can perform this type of requesting using a simple HTTP GET to the provided LIS URL. The resulting PIDF-LO may contain one or more location elements depending on what physical location information the LIS is able to determine. The LIS must ensure that rules outlined in Reference 4 are adhered to in order to ensure that the location information can be correctly interpreted by subsequent users of this information.
Qualified Location Requests
The unqualified location request is certainly easy to implement, but it only provides what the LIS wants to give, which may not be specifically what the user is after. The HELD protocol supports the notion of a qualified location request, which allows the user to specify what type of location information they are interested in (see Figure 4.7).
Figure 4.7: A qualified location request.
There are five types of locations that a user can ask for: any, geodetic, civic, jurisdictionalCivic, and postalCivic. These types are described in detail in the following subsections. A HELD protocol request asking for geodetic location, a jurisdictionalCivic address, and a postalCivic address would look something like:
<locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held"> <locationType> geodetic jurisdictionalCivic postalCivic </locationType> </locationRequest>
It should be noted that a user can request a location in any one, or all, of the above formats at the same time and that the LIS should construct a PIDF-LO such that the location types are in the same order in which they were requested.
The any Location Type
any, as the name suggests, doesn't really provide any qualification at all. It simply says to the LIS that the Target is interested in any location information that the LIS can provide on the Target's whereabouts. Locations returned by the LIS when the any qualifier is specified must include a location that is suitable for routing emergency calls in the area local to the end-point. Other locations may also be returned, but the emergency location is mandatory. Since a LIS covers the jurisdiction of interest, it may be assumed that the LIS can provide a location that is in the correct form for that jurisdiction.
The geodetic Location Type
geodetic is the way that the Target indicates to the LIS that it is interested in a location specified using latitude and longitude coordinates. The GeoShape specification (see Reference 5) leverages and extends the GML3.1.1 specification to describe the legal shapes that can be used to define the location of a Target in geodetic terms within a PIDF-LO. The HELD protocol mandates that any returned geodetic location must conform to the GeoShape specification. The shapes defined in the GeoShape specification are described in Chapter 2.
Different shape types generally have their origins in different determination techniques, so the type returned will likely be based on how the LIS determined the location of the Target. Choice of shape type should be made with care, in particular when being used for emergency services applications where all shape types may not be considered acceptable. For example, out of the eight shape types defined in GeoShape, only Point, Circle, and Sphere would be usable with the North American i2 specification (see Reference 6) [NENA-i2] due to restrictions imposed over the V-E2 interface defined in the specification. Extreme care needs to be taken if converting from one shape type to another so as not to introduce unnecessarily large errors in the resulting location.
The civic Location Type
The civic type is specified by the Target when they want a street address; they are not really interested in whether it is a postal or some sort of jurisdictional address. In response to this request, the LIS should provide the civic address (or addresses, if there are more than one) that it has for the Target.
The jurisdictionalCivic Location Type
A jurisdictionalCivic address is the address of the Target formed in such a way that it identifies not only the premises in which the Target is located, but also specifies the lowest level of governmental community in whose jurisdiction the Target is located. Often, this will be the normal street address, but in some situations it is not. Emergency service dispatch in the United States, for example, is done to a jurisdictional address, providing a standard postal street address instead may result in an emergency call not being routed correctly, or services being dispatched to the wrong location.
When civic address information is required for emergency services, the Target should request a jurisdictionalCivic location. If the Target requests the general civic location type and a jurisdictionalCivic type in the same request, then the LIS should ignore the request for the general civic type and only provide jurisdictionalCivic information.
When requesting a jurisdictionalCivic location type the default behavior of the LIS is to try and satisfy this request, but if it can't, it may just return the location in any form including geodetic.
The postalCivic Location Type
The postalCivic address is the address that one might use to send a letter or parcel to the Target. Often, this will be the same as the jurisdictional address, but as was described previously, this is not always the case. A postal address may not be appropriate for describing the physical location of a person; post office boxes are common for postal addresses. A LIS is not always able to provide this information.
If the user requests the general civic location type and a postalCivic type in the same request, then the LIS should ignore the request for the general civic type and only provide postalCivic information. If postalCivic and jurisdictionalCivic are requested in the same request, then the LIS should return both and construct the PIDF-LO to return the addresses in the same order in which they were requested.
When requesting a postalCivic location type, the default behavior of the LIS is to try and satisfy this request, but if it can't, it may just return a location in any form, including geodetic.
The exact Qualifier
When requesting a particular type of location by setting the value of the locationType parameter in the location request, the default behavior of the LIS is to try and satisfy this request, but if it can't, it may just return whatever information it has. Sometimes this is not good enough, and the user will need to know precisely if the information it has asked for has been returned. The HELD protocol supports this qualifier through the exact attribute contained in the locationType element. If the user wants to make sure that they only get what they ask for, then they can set this attribute to be true, and the LIS will return an error if any of the requested data cannot be provided. Inclusion of the exact attribute is optional, and when not provided it is assumed to have a value of false.
<locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held"> <locationType exact="true"> geodetic </locationType> </locationRequest>
The signed Qualifier
There are three implicit expectations of any node providing location information:
-
The information provided is current.
-
The information is accurate at the time it is provided.
-
The information is attributed to the specified target.
These same expectations are the basis for location dependability, which was described in Chapter 1. The degree of need for dependability of location information tends to increase when the cost of acting on misinformation is high. The signed attribute allows the user to request location information that has been digitally signed by the LIS, binding location and time to the Target.
<locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held" signed="true"> <locationType exact="true"> jurisdictionalCivic </locationType> </locationRequest>
A signed location may result in the whole PIDF-LO being signed using the techniques outlined in Reference 7. The drawback with this is that if the requestor was the Target, and he/she wishes to add things to the PIDF-LO, they can't do so without breaking the signature. A better way to sign the PIDF-LO is to use the XML transform provided in Appendix B. This transform excludes select parts of the PIDF-LO document, so a Target may modify those sections without impacting the dependability of the location information.
The responseTime Qualifier
If the requestor wants a response within a certain time, then he/she can set the responseTime qualifier to inform the LIS of this requirement. Sometimes an LIS will have more than one location determination option available, often with varying degrees of accuracy. The responseTime qualifier provides the LIS with criteria to choose a location determination mechanism. Where the LIS has a choice, it should always choose the location determination technique that will yield the most accurate result within the provided responseTime.
The responseTime can be specified as a number of seconds-2.2-or it can be specified as an XML period-PT2.2S. Either form is acceptable.
<locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held" responseTime="PT2.2S"> <locationType exact="true"> jurisdictionalCivic geodetic </locationType> </locationRequest> <locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held" responseTime="2.2"> <locationType exact="true"> jurisdictionalCivic geodetic </locationType> </locationRequest>
The responseTime qualifier acts as a hint to the LIS. The LIS can use this time to select location determination methods that provide the best accuracy within this time. However, the requester must ultimately make a decision about whether or not to wait for a response, and whether the response is taking too long. Furthermore, the responseTime qualifier is optional, and if not provided, the LIS should always try to provide the most accurate location that satisfies the overall criteria of the location request.
Requesting a Location Reference
The HELD protocol supports location references in the form of a location URI, which can be requested by a Target instead of a literal location. The location reference model allows the Target to delegate its location distribution function to the LIS. To ensure that the LIS honors the Target's location authorization and privacy policies, the Target provides the LIS with a set of rules defining the policies applicable to the Target. The LIS needs to store these rules and ensure they are invoked whenever the location URI is accessed. Further, these rules and the location URI need to be linked to the Target and its location inside the LIS. The HELD protocol manages these data and their association through a context. A Target therefore requests a location URI by asking the LIS to create a context.
Location URIs in the HELD protocol must not contain any information that could be used to identify the device or Target. That is, they must not include things such as the IP or MAC address of the Target. The HELD protocol recommends that the location URI contains the public address of the LIS and a randomly generated sequence of characters that the LIS can use to uniquely identify the context-containing Target information.
Creating a Context
To create a context, the Target issues a createContext HELD message to the LIS, and includes rules that describe who may request the location of the Target. The rules may be provided directly from the Target to the LIS, in which case the rules are specified in accordance with Reference 8. For example, if the Target only wanted its VoIP call server to be able to request its location, it may create a context using the following message structure. Note that in addition to the rules, the Target must specify how long they wish the context to remain active on the LIS for. This is specified with the mandatory lifetime element.
<createContext xmlns="http://sitacs.uow.edu.au/ns/location/held"> <lifetime>PT2H</lifetime> <rules> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <rule > <conditions> <identity> <one BOLD">sip:mycallserver@goodcalls.com"/> </identity> </conditions> </rule> </ruleset> </rules> </createContext>
Providing access rules to the LIS using common policy is fine but may become onerous if the set of rules is complex and large. An alternative is for the Target to provide the LIS with a URI indicating where the LIS can obtain the Target's rules from. This is done by providing a rulesetURI.
<createContext xmlns="http://sitacs.uow.edu.au/ns/location/held"> <lifetime>PT2H</lifetime> <rules> <rulesetURI> https://www.example.com/~user/privacy/rulesat.xml </rulesetURI> </rules> </createContext>
A Target may wish to keep much of its access policy hidden from a visited network, in which case it could adopt the location subscription approach described in Chapter 2. In this model, the core of the Target's policies reside in the home presence server, and only the presence server may request location from the LIS. This is easily accomplished using the first createContext example shown earlier.
When an LIS receives a set of rules from the Target, it will process them to make sure they make sense. If the LIS discovers a problem, it will send an error to the Target indicating that a problem was found. If the Target sent the LIS a rulesetURI, then the LIS will go off and fetch the ruleset, if the LIS is unable to fetch from the URI, or there is something wrong with the retrieved ruleset, then the LIS will inform the Target by way of an error message.
contextResponse: The Target's Handle to a Context
When a Target creates a context on the LIS using the createContext message, it needs a means of being able to identify the context on the LIS so that it can make changes to rules, and as we will see in subsequent sections, changes to other Target data in the context. The Target is provided a handle to the context via the HELD contextResponse message which is returned by the LIS after successfully processing a createContext message from the Target. The context handle returned to the Target by the LIS is a URI, and is referred to as a location URI.
As shown in Figure 4.8, the contextResponse message consists of an expiry time, a list of URIs, and a password. The expiry time indicates to the Target the time at which the context on the LIS will expire, this time may be shorter than, but never longer than, the context 1ifeTime requested by the Target.
Figure 4.8: HELD context creation messaging.
The contextResponse includes a list of location URIs that the Target may hand out to would-be Location Recipients. Each URI in the list will be for a different URI schema, for example, sip, sips, or https. Each URI points to the same Target context on the LIS. The purpose of supporting multiple URI types is to allow flexibility in the range of applications that can access location information.
Finally, the contextResponse message contains a password which the Target will use when requesting the LIS to make changes to the data stored in the context.
<contextResponse xmlns="http://sitacs.uow.edu.au/ns/location/held" code="200" message="OK"> <context expires="2006-01-01T13:00:00"> <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o</locationURI> <locationURI>sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769</locationURI> <password>38cdj38mjcd-0-=54821kj28mp1qms.1</password> </context> </contextResponse>
Context Data
In addition to the access rules and lifetime parameters provided by the Target when it creates a context on the LIS, the Target can provide other directives to the LIS including a profile, and call-back information. These additional fields are addressed in subsequent sections.
The profile Element
The profile element provides the Target with a way to instruct the LIS as to what information in addition to location should be included in any PIDF-LO generated in order to describe the whereabouts of the Target. The profile consists of four optional elements.
The PIDF-LO defined in Reference 9 was described in detail in Chapter 2. To recap, the PIDF-LO takes the base document for transporting presence information-the PIDF is defined in Reference 10 and adds a structure to contain location information and rules on how that location information may be stored, transported, and used. The profile element specifically allows the Target to dictate how the LIS should populate the <retention-expires>, <retransmission-allowed>, and <external-ruleset> fields in the <usage-rules> ement of the PIDF-LO.
Asserting User Identity Using HELD
Knowing where a device is raises some concerns as to the privacy and associated rights extended to users of such devices, and while these concerns should not be discounted, the relevance of knowing the address of a temporary IP address or some other transitory network identifier should not be carried to the extreme either. A strong legitimate concern regarding privacy arises when user identity and location information are explicitly bound together in such a way that it is easy to discern who is at a specific location at a specific point in time. And while there are privacy considerations that need to be taken into account when binding identity to location information, having this data bound together can provide strong assurances to service providers as to the integrity of the information and to whom it pertains.
Figure 4.9: HELD context lifeTime and LocationURI usage.
The HELD protocol provides three mechanisms for a user to assert his/her identity to the LIS and are primarily designed to be used where a greater degree of trust by the Location Recipient is required. The first is for the user to simply provide the LIS with a URI that the LIS will use as the value of the presentity for all location objects created in order to describe the location of the end-point. The other two mechanisms make use of the SAML Assertion and EncryptedAssertion methods.
A HELD Target is able to tell the LIS what value to employ for the presentity element using the presentity field of the profile structure in a corresponding HELD message, with the intent being that the LIS will populate the presentity of any PIDF-LO documents generated with the value of the presentity provided by the Target. Where the Target does not have an SAML assertion with the provided presentity, the LIS does not need to accept the value provided. Where the LIS does provide a PIDF-LO with the proffered identity in the presentity field, the Target will need to ensure that their identity associated with any outbound messaging can be tied to the same value that is the presentity field of the PIDF-LO, for example, using SIP identity mechanisms. When used in this manner, fraud and false information can only be achieved easily if the Target and owner of the identity is directly involved, making him/her easily identifiable. For most applications where identity is required, this is adequate and is the recommended approach.
In some cases, a Target is able to provide information to the LIS that allows the LIS to make the association between the provided presentity value, and the actual device. HELD provides this functionality by supporting the SAML Assertion and EncryptedAssertion methods. Using these mechanisms, a Target can assert its true identity to the LIS, giving the LIS a means of determining if the assertion is true.
If the LIS is unable to validate the identity provided in the SAML assertion, then the LIS should return an error. HELD does not define how a client obtains a SAML assertion; it is assumed that best current practices are followed and a Target should only provide the LIS with a presentity representing its true identity when the Target explicitly trusts the LIS.
Setting <retention-expiry>
The <retention-expiry> field in the PIDF-LO is a date time field. It specifies the absolute date and time at which the holder of the PIDF-LO is no longer permitted to possess the location information. The profile element provides two ways in which the Target may instruct the LIS to populate the <retention-expiry> field.
The first is through the <retentionExpiry> field, which specifies an absolute date and time. Whenever the LIS creates a PIDF-LO describing the location of the Target, the <retention-expiry> element in the PIDF-LO will be set to the value that was provided in the <retentionExpiry> field.
<createContext xmlns="http://sitacs.uow.edu.au/ns/location/held"> <lifetime>PT10M</lifetime> <profile> <retentionExpiry>2006-01-01T13:00:00</retentionExpiry> </profile> <rules> <rulesetURI>https://www.example.com/~user/privacy/ruleset.xml</rulesetURI> </rules> </createContext>
The second way that the HELD protocol supports setting the <retention-expiry> value using the profile element is through the <retentionInterval> field. This field represents a duration, and is used to instruct the LIS to make holding a PIDF-LO valid for only a certain period of time after it is requested, for example, holding a PIDF-LO valid for only ten minutes. This is achieved by the LIS obtaining the time that a location request comes in, and adding the <retentionInterval> to this to obtain an absolute <retention-expiry> value for the PIDF-LO. The <retentionInterval> may be specified as an absolute in seconds (for example, 20.5) or in the XML duration format (for instance, PT10M).
<createContext xmlns="http://sitacs.uow.edu.au/ns/location/held"> <lifetime>PT10M</lifetime> <profile> <!-sets the interval to 30 minutes (1800 seconds --> <retentionInterval>1800</retentionInterval> </profile> <rules> <rulesetURI>https://www.example.com/~user/privacy/ruleset.xml</rulesetURI> </rules> </createContext>
Setting <retransmission-allowed>
The <retransmission-allowed> field in the PIDF-LO is a Boolean type. When set to "no," the PIDF-LO holder may not forward the document to any other node. When set to "yes," the holder may share the PIDF-LO with other parties. The HELD protocol allows the Target to indicate its preference for the setting of this value through the <retransmission> field in the profile element.
<createContext xmlns="http://sitacs.uow.edu.au/ns/location/held"> <lifetime>PT10M</lifetime> <profile> <retransmission>true<retransmission> </profile> <rules> <rulesetURI>https://www.example.com/~user/privacy/ruleset.xml</rulesetURI> </rules> </createContext>
Setting <external-ruleset>
In the PIDF-LO, the <external-ruleset> field contains a URI that references a complete set of rules and policies regarding the access and dissemination of the information in the PIDF-LO. The recommendation in Reference 9 is that this URI should use the HTTPS scheme and that the rule holder should authenticate the requesting node. The HELD protocol supports the Target, informing the LIS of the value to place in this field using the <rulesetURI> field in the profile element.
<createContext xmlns="http://sitacs.uow.edu.au/ns/location/held"> <lifetime>PT10M</lifetime> <profile> <rulesetURI>https://www.privacy.com/~user/ruleset.xml</rulesetURI> </profile> <rules> <rule > <conditions> <identity> <one /> </identity> </conditions> </rule> </rules> </createContext>
Updating a Context
The previous section explained how a Target can create a context on the LIS and what parameters the Target can include in the context to have the LIS customize the PIDF-LO with options that the Target would like. It stands to reason that a Target may wish to change certain aspects of their context over time-for example, who is authorized to request location information, or to extend the life-time of the context. The HELD protocol supports this functionality through the updateContext message.
In order to update a context, the Target must identify to the LIS which context is to be updated, and prove to the LIS that it is authorized to update the identifier context. The context identification and authorization mechanisms are provided to the Target when it first creates the context on the LIS. Context identification is achieved by the Target providing one of the location URIs that it received, and authorization is achieved by including the password received when the context was created.
<updateContext xmlns="http://sitacs.uow.edu.au/ns/location/held"> <context> <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o</locationURI> <password>38cdj38mjcd-0-=54821kj28mp1qms.1</password> </context> <lifetime>PT30M</lifetime> </updateContext>
To understand why context identification and authorization are necessary beyond simply the Target's IP address, we need to look at an example. Let's take a residential broadband connection to a house. A typical deployment may consist of an ADSL home router that connects to the broadband network on one side, and the home network on the other with a network address translation (NAT) agent in between. The home router includes a DHCP server providing a private IP address range to hosts inside the house, and the NAT service to support routing traffic to the public Internet. To a LIS based at the ISP, all hosts inside the house appear to be at the same location since they are all identified by the same IP address: the IP address of the home router. Suppose that the house has a typical family in it: mom, dad, and their two teenage children, Bob and Alice, each with their own computer. If a literal location is being requested by each host, this is fine; they all get the same location. When a host requests a location reference, however, each will create its own context on the LIS. This means that the LIS requires some way other than simply an IP address to be able to identify which context to update. The reason for authentication is to make sure that an untrusted third party to whom Alice has given a location URI cannot simply change her access rules.
When a Target successfully updates its context, it will receive a contextResponse message from the LIS. This contextResponse message will contain the same set of location URIs; however, the LIS as a matter of policy may elect to provide the Target with a new password. This new password takes effect immediately and any attempts to use the old password will fail.
Anything that can be set using the createContext message can be changed using the updateContext message. There are two special cases that require specific explanation. The first is changes to access rules, and the second is changes to the 1ifeTime parameter.
Changing the Rules
When a Target wishes to change its access rules, it must pass the complete new ruleset to the LIS since there is no support in the HELD protocol for ruleset compositing. For example, suppose that a Target had a ruleset allowing Bob, Alice, Fred, and Mary access to its location, and that this had been sent to the LIS.
<createContext xmlns="http://sitacs.uow.edu.au/ns/location/held"> <lifetime>PT2H</lifetime> <rules> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <rule > <conditions> <identity> <one bold">sip:Bob@example.com"/> <one BOLD">sip:Alice@example.com"/> <one BOLD">sip:Fred@example.com"/> <one BOLD">sip:Mary@example.com"/> </identity> </conditions> </rule> </ruleset> </rules> </createContext>
Suppose the Target decided that Bob was no longer its friend. The Target cannot simply say to the LIS, remove Bob from my access list; the Target must send a new access list to the LIS consisting of only Alice, Fred, and Mary.
<updateContext xmlns="http://sitacs.uow.edu.au/ns/location/held"> <context> <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o</locationURI> <password>38cdj38mjcd-0-=54821kj28mp1qms.1</password> </context> <rules> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <rule > <conditions> <identity> <one BOLD">sip:Alice@example.com"/> <one BOLD">sip:Fred@example.com"/> <one bold">sip:Mary@example.com"/> </identity> </conditions> </rule> </ruleset> </rules> </updateContext>
Similarly, if the Target wishes to add a new person to its buddy list, they must send the entire ruleset to the LIS, including the identity of the new buddy.
The Target needs to let the LIS know whenever it makes changes to the referenced rules; otherwise, the LIS will continue to apply out-of-date rules. This even applies when the Target has provided a ruleset URI, because the LIS doesn't know if the ruleset changes. The Target does this by sending the LIS a ruleset URI in an updateContext message. This may be the same ruleset URI as was sent previously, but on receipt of a ruleset URI in an updateContext message, the LIS will retrieve and reapply the ruleset.
Updating lifeTime
The Target can extend the lifetime of their context by providing a new duration or absolute value for the lifeTime parameter in an updateContext message. The only way to terminate a context on the LIS is for the context to reach its expiry time. For a Target to terminate a context, it must therefore set the lifeTime parameter to zero or to a time in the past. This will result in the LIS terminating and purging data associated with the Target's context.
Location Assertion
Location assertion is the act of the Target proffering a location the LIS. A Target may do this for a number of reasons but the two main ones are the Target asking the LIS to provide some confirmation to the Target of where it is, and the Target wanting to get the LIS to provide some dependability signature so the Target can provide a signed location to a Location Recipient.
In the first scenario, a Target may know that it is in room 23 on the second floor of building 39, but it may not know the street address. Location assertion provides the Target with the ability to say to the LIS, "I am in room 23 on the second floor of building 39." In turn, the LIS may only be able to determine location down to a building number-in this case, building 39. The result of asserting location in this case would be the LIS being provided a populated civic location with all the necessary details to identify the location of the Target down to room 23 on the second floor of building 39. This same mechanism could be used to perform civic address validation, as is necessary for the NENA-i2 solution.
In the second scenario, suppose a Target is capable of determining location to a high degree of accuracy and precision using a differential GPS system, while the LIS is only able to determine the Target's location to a more coarse level using network-based radio timing techniques. What happens if the Location Recipient needs high accuracy location and a dependability signature? In this case, the Target can use GPS to determine its location, and then proffer this location to the LIS to validate it. If the proffered location falls within the area that the LIS would have assigned to the Target, then the assertion is successful and the LIS returns a signed PIDF-LO containing the GPS determined location. In this situation, the LIS has asserted that the location provided by the Target was as good, or better, than what the LIS could provide, and so the LIS signs the location as though it had determined it.
The HELD protocol supports location assertion through the locationRequest message. When a Target wishes to assert a location, it uses the <assert> element rather than the <locationType> element that was described earlier. The following subsection will describe the options available to a Target when asserting a location.
Asserting a Location
Support is provided for asserting a civic location, a geodetic location, or both a geodetic and civic location. As indicated, if the LIS is able to assert the proffered location, then the LIS will return the same location in the resulting PIDF-LO. If the assertion fails, then the default behavior of the LIS is to return the location that it does know for the Target. There is a provision on this behavior, however, and that is that the LIS must return a location in the same form that was asserted. That is, if the Target asserted a geodetic location, then the LIS must respond either with a geodetic location or an error. Similarly, if the Target asserts a civic location, then the LIS must respond with either a civic location or an error. If the Target asserts both a geodetic location and a civic location, then the LIS may respond with either location types, both, or an error if the LIS is unable to determine the location of the Target at all (see Figure 4.10). The LIS must never respond to a geodetic assertion with a civic address or civic assertion with a geodetic location. These rules are expressed in Table 4.1.
| Target Assertion | LIS Response | ||
|---|---|---|---|
| Geodetic | Civic | Geodetic | Civic |
| X | X | ||
| X | X | ||
| X | X | X | |
| X | X | X | |
| X | X | X | X |
Figure 4.10: Location assertion using HELD.
How location is determined is often important to a user of location information, and an LIS-provided location should always include an indication of how location was determined by populating the <method> parameter of the PIDF-LO. Yet when a Target asserts its location to the LIS, the LIS has no way of knowing how the Target determined this location. To assist the LIS, the <assertion> element of the 1ocationRequest has a method attribute that should be set by the Target when the assertion is made. A civic assertion therefore might look similar to the one shown next. The full set of valid values for the method attribute is available from www.iana.org/assignments/method-tokens.
<locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held"> <assert method="Manual"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xml:lang="en-AU"> <country>AU</country> <A1> NSW </A1> <A3>Wollongong</A3> <A4>North Wollongong</A4> <PRD>Corner</PRD> <RD>Flinders</RD> <STS>Street</STS> <RDBR>Campbell Street</RDBR> <LMK>Gilligan's Island</LMK> <NAM> Video Rental Store </NAM> <PC>2500</PC> <ROOM> Westerns and Classics </ROOM> <PLC>store</PLC> <POBOX>Private Box 15</POBOX> </civicAddress> </assert> </locationRequest>
A Target asserting location should know when the location was determined, and when it will no longer be considered valid; thus, it should also tell the LIS this. The assert request supports the Target providing this information to the LIS through the timestamp and expires attributes. A geodetic assertion might therefore look similar to the following.
<locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held" signed="true"> <assert method="Device-Based_A-GPS" timestamp="2006-01-01T13:00:00" expires="2006-01-01T13:05:00"> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326" xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" xmlns:gml="http://www.opengis.net/gml"> <gml:pos> 42.5463 -73.2512 </gml:pos> <gml:radius uom="urn:ogc:def:uom:EPSG::9001"> 5.3 </gml:radius> </gs:Circle> </assert> </locationRequest>
Sometimes a Target will want the LIS to either accept the proffered location or to fail. Such a situation might occur if the Target wants the LIS to sign a location that the Target determined using GPS. The HELD protocol supports this by providing the optional exact attribute on the assert element. If the Target wants only what it has requested, it can set the exact attribute to yes, and the LIS will either return a PIDF-LO with the proffered location or an error message.
<locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held" signed="true"> <assert method="Device-Based_A-GPS" timestamp="2006-01-01T13:00:00" expires="2006-01-01T13:05:00" exact="yes"> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326" xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" xmlns:gml="http://www.opengis.net/gml"> <gml:pos> 42.5463 -73.2512 </gml:pos> <gml:radius uom="urn:ogc:def:uom:EPSG::9001"> 5.3 </gml:radius> </gs:Circle> </assert> </locationRequest>
Reporting Errors
There are three possible messages that may be sent by the LIS in response to a Target request, a PIDF-LO, an error message, or a contextResponse message. The error and contextResponse messages have specific result code and message attributes associated with them that provide guidance on how operations have completed on the LIS.
The code attribute indicates the actual outcome of the requested operation and follows a three-decimal form similar to that used in HTTP (see Reference 11) and SIP (see Reference 12). The code attribute is intended to be used more by the HELD-client software itself. The full list of defined codes is provided in the HELD protocol specification.
The message attribute contains a text-based reason describing what occurred on the LIS when the operation was processed. This attribute is intended to provide more information to a human operator.
<error xmlns="http://sitacs.uow.edu.au/ns/location/held" code="501" message="Location Unknown"/> <contextResponse xmlns="http://sitacs.uow.edu.au/ns/location/held" code="200" message="OK"> <context expires="2006-01-01T13:00:00"> <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o</locationURI> <password>38cdj38mjcd-0-=54821kj28mplqms.1</password> </context> </contextResponse>
Third-Party Interface Authentication
The Third-Party Interface (described earlier) is the interface on which the LIS services location requests come in through a location URI. The LIS will only process locationRequest messages on this interface, and all hosts making location requests through this mechanism MUST be authenticated by the LIS. The LIS will not provide location information to any requesting host unless it first passes authentication and is subsequently authorized based on Target access policy and/or local rules and regulations to possess the location of the Target. If either authentication or authorization of the requesting host fails, then the LIS will return an error message with a code of 402.
<error xmlns="http://sitacs.uow.edu.au/ns/location/held" code="402" message="Authentication Error"/>
A requesting host may identify itself to the LIS in one of two ways, either using a client-side X.509 certificate signed by a certification authority acceptable to the LIS, or by using a Security Assertions Markup Language (SAML) identity assertion. The X.509 certificate method when combined with HELD using the HTTP binding provides an advantage over the SAML assertion mechanisms. This is because presentation of a client-side certificate is already an accepted practice in TLS session establishment, as is used for HTTPS. In contrast, the SAML assertion requires an extension to the location request message to include the SAML elements.
The requesting host may use any of the options described for the locationRequest message. A LIS will ignore any values contained in the <profi1e> element when the locationRequest message is received over the Third-Party Interface. It may also choose to ignore an asserted location value provided to it in a locationRequest message received over the Third-Party Interface.
The Trusted-Party Query Interface
The need for the Trusted-Party Query Interface is best described with examples, and specific examples will be provided in subsequent chapters where we look at location determination and acquisition in specific types of network deployments. As described earlier, the Trusted-Party Query Interface supports a node other than the Target requesting the Target's location. This support extends to the trusted node being able to request the location of the Target without the trusted node having been given a specific location URI by the Target. That is, the trusted node is able to identify the Target to the LIS in some manner. The HELD protocol supports this functionality through extensions which will be described in detail in subsequent chapters.
The LIS must authenticate all nodes attempting to request location through the Trusted-Party Query Interface. The mechanism chosen for authentication is left unspecified and will be dependent upon network configuration. X.509 client-side and server-side certificates are recommended, however.
EAN: 2147483647
Pages: 129