Geopriv                                                  J. Winterbottom
Internet-Draft                                                M. Thomson
Intended status: Standards Track                      Andrew Corporation
Expires: August 29, 2009                                   H. Tschofenig
                                                  Nokia Siemens Networks
                                                               R. Barnes
                                                        BBN Technologies
                                                       February 25, 2009

    Use of Target Identity in HTTP-Enabled Location Delivery (HELD)

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 29, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Winterbottom, et al.     Expires August 29, 2009                [Page 1]

Internet-Draft                HELD Identity                February 2009


   When a Location Information Server receives a request for location
   information (using the locationRequest message), described in the
   base HTTP Enabled Location Delivery (HELD) specification, it uses the
   source IP address of arriving message as a pointer to the location
   determination process.  This is sufficient in environments where a
   Target's location can be determined based on its IP address.

   Two additional use cases are addresses by this document.  In the
   first, location configuration requires additional or alternative
   identifiers from the source IP address provided in the request.  In
   the second, an entity other than the Target requests the Target's

   This document extends the HELD protocol to allow the location request
   message to carry Target identifiers.  Privacy and security
   considerations describe the conditions where requests containing
   identifiers are permitted.

Winterbottom, et al.     Expires August 29, 2009                [Page 2]

Internet-Draft                HELD Identity                February 2009

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Applications . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Target Identity  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Identifier Format and Protocol Details . . . . . . . . . .  6
     3.2.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  IP Address . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.2.  MAC Address  . . . . . . . . . . . . . . . . . . . . .  7
       3.2.3.  TCP or UDP Port Number . . . . . . . . . . . . . . . .  8
       3.2.4.  Network Access Identifier  . . . . . . . . . . . . . .  8
       3.2.5.  URI  . . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.6.  Hostname . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.7.  Directory Number . . . . . . . . . . . . . . . . . . .  9
       3.2.8.  Cellular Telephony Identifiers . . . . . . . . . . . .  9
       3.2.9.  DHCP Unique Identifier . . . . . . . . . . . . . . . . 10
   4.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
     6.1.  Location Configuration Protocol Requests . . . . . . . . . 14
     6.2.  Third Party Requests . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 14
     7.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 15
     7.3.  Registration of HELD 'badIdentifier' Error Code  . . . . . 15
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative references . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 17

Winterbottom, et al.     Expires August 29, 2009                [Page 3]

Internet-Draft                HELD Identity                February 2009

1.  Introduction

   Protocols for requesting and providing location information require a
   way for the requestor to specify the location that should be
   returned.  In a location configuration protocol (LCP), the location
   being requested is the requestor's location.  This fact can make the
   problem of identifying the Device simpler for LCPs, since IP
   datagrams that carry the request already carry an identifier for the
   Device, namely the source IP address of an incoming request.
   Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery]
   and DHCP ([RFC3825], [RFC4776]) rely on the source IP address, and
   possibly lower-layer identifiers to identify a Device.

   Aside from the datagrams that form a request, a location information
   server (LIS) does not necessarily have access to information that
   could further identify the Target.  In some circumstances, as shown
   in [I-D.ietf-geopriv-l7-lcp-ps], additional identification
   information can be included in a request to identify a Target.

   This document extends the HELD protocol to support the inclusion of
   additional identifiers for the Target in HELD location requests.  An
   XML schema is defined that provides a structure for including these
   identifiers in HELD requests.

   An important characteristic of this addition to the HELD protocol is
   that is also expands the potential scope of HELD beyond that of an
   LCP.  The scope of an LCP is limited to the interaction between a
   Device and a LIS.  That is, an LCP is limited to the Device
   retrieving information about their own location.  With this addition,
   third party location recipients (LRs) are able to make requests that
   include identifiers to retrieve location information about a
   particular Target.

   The usage of HELD for purposes beyond the Device-LIS interaction
   obviously introduces a new set of privacy concerns.  In an LCP, the
   requester is implicitly authorized to access the requested location
   information, because it is their own location.  In contrast, when a
   third party LR requests a Target's location, the LR MUST be
   explicitly authorized.  Establishing appropriate authorization and
   other related privacy concerns are discussed in Section 5.

1.1.  Applications

   The use of additional identifiers in HELD falls into two categories.
   A Device can use these parameters to provide additional
   identification information to a LIS.  Identification such as the
   hardware address of the Device can be used to reduce the time
   required to determine the location of the Device.  In other cases, a

Winterbottom, et al.     Expires August 29, 2009                [Page 4]

Internet-Draft                HELD Identity                February 2009

   LIS might require Device identification before any location
   information can be generated.

   A third party LR can be granted authorization to make requests for a
   given Target.  In particular, network services can be permitted to
   retrieve location for a Device that is unable to acquire location
   information for itself (see Section 6.3 of
   [I-D.ietf-ecrit-phonebcp]).  This allows use of location-dependent
   applications--particularly essential services like emergency
   calling--where Devices do not support a location configuration
   protocol (LCP) or they are unable to successfully retrieve location

2.  Terminology

   This document uses the term Location Information Server (LIS) and
   location configuration protocol (LCP) as described in

   This document reuses the term Target to refer to the subject of any
   request for location information.  The term Device is used
   specifically as the subject of an LCP, consistent with
   [I-D.ietf-geopriv-http-location-delivery].  Both these terms are
   defined in [RFC3693].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Target Identity

   Identifiers are used as the starting point in location determination.
   They should not be confused with measurement information
   ([I-D.thomson-geopriv-held-measurements]).  Measurement information
   is information about a Device and the time varying details of its
   network attachment.  Identifiers might be associated with a different
   Target over time, but the their purpose is to identify the Target,
   not to describe its environment or network attachment.

   Use of any identifier MUST only be allowed if it uniquely identifies
   a single Target.  In some circumstances, certain of these identifiers
   are either temporary or could potentially identify multiple devices.
   Identifiers that are transient or ambiguous could be exploited by an
   attacker to either gain information about another device or to obtain
   misleading information.

   The identifiers described in this section SHOULD only be used where
   that identifier is used as the basis for location determination.  It

Winterbottom, et al.     Expires August 29, 2009                [Page 5]

Internet-Draft                HELD Identity                February 2009

   is tempting for a LIS implementation to allow alternative identifiers
   for convenience or some other perceived benefit.  However, care needs
   to be taken to ensure that the binding between the indicated
   identifier and the identifier that is used for location determination
   is unique and not subject to attacks.

3.1.  Identifier Format and Protocol Details

   XML elements are used to express the Target identity.  The "target"
   element is used as a general container for identity information.
   This document defines a basic set of identifiers.  An example HELD
   request, shown in Figure 1, includes an IP version 4 address.

     <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
       <locationType exact="true">geodetic</locationType>
       <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
         <ip v="4"></ip>

                                 Figure 1

   A LIS that supports this specification echoes the "target" element in
   a successful HELD response, including the identifiers that were used
   as the basis for location determination.  Absence of this indication
   means that the location information was generated using the source IP
   address in the request.

   If an identifier is invalid, not supported by the LIS, or the
   requester is not authorized to use that identifier, a HELD error
   response of "badIdentifier".  This code is registered in Section 7.3.

   If the LIS requires an identifier that is not provided in the
   request, the desired identifiers MAY be identified in the HELD error
   response, using the "requiredIdentifiers" element.  This element
   contains a list of XML qualified names [W3C.REC-xml-names11-20060816]
   that identify the identifier elements required by the LIS.  Namespace
   prefix bindings for the qualified names are taken from document
   context.  Figure 2 shows an example error indicating that the
   requester needs to include a MAC address (Section 3.2.2) if the
   request is to succeed.

Winterbottom, et al.     Expires August 29, 2009                [Page 6]

Internet-Draft                HELD Identity                February 2009

     <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
            code="badIdentifier" message="MAC address required"

                                 Figure 2

3.2.  Identifiers

   A limited selection of identifiers are included in this document.
   The basic Target identity schema allows for the inclusion of elements
   from any namespace, therefore additional elements can be defined
   using different XML namespaces.

3.2.1.  IP Address

   The "ip" element can express a Target identity as an IP address.  An
   optional "v" attribute identifies the IP version.  The element uses
   the textual format specific to the indicated IP version.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <ip v="6">2001:DB8::1:ea7:fee1:d1e</ip>

   In situations where location configuration does not require
   additional identifiers, using IP address as an identifier enables
   third party requests.

3.2.2.  MAC Address

   The media access control (MAC) address used by the IEEE 802 family of
   access technologies is an identifier that is assigned to a particular
   network device.  A MAC address is a unique sequence that is either
   assigned at the time of manufacture of a device, or assigned by a
   local administrator.  A MAC address rarely changes; therefore, a MAC
   address is an appropriate identifier for a Device.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

Winterbottom, et al.     Expires August 29, 2009                [Page 7]

Internet-Draft                HELD Identity                February 2009

3.2.3.  TCP or UDP Port Number

   On its own, a TCP or UDP port number is insufficient to uniquely
   identify a single host, but in combination with an IP address, it can
   be used to identify a Target.

   Use of a particular port number can be transient; often significantly
   more than use of any given IP address.  However, widespread use of
   network address translation (NAT) means that some Targets cannot be
   uniquely identified by IP address alone.  An individual Target might
   be identified by a flow of packets that it generates.  Providing that
   a LIS has sufficient knowledge of the mappings used by the NAT, an
   individual target on the remote side of the NAT might be able to be
   identified uniquely.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <ip v="6">2001:DB8::1:ea7:fee1:d1e</ip>

   As with any identifier, use of port numbers is contingent on the
   value remaining consistent over time.  Use of port numbers is not
   suitable if port numbers cannot be deterministically attributed to a
   unique Target over a sufficient period of time.

3.2.4.  Network Access Identifier

   A Network Access Identifier (NAI) [RFC4282] is an identifier used in
   network authentication in a range of networks.  The identifier
   establishes a user identity within a particular domain.  Often,
   network services use an NAI in relation to location records, tying
   network access to user authentication and authorization.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

   Note:  The formal grammar for NAI permits invalid Unicode, which
      cannot be expressed using XML.  This is a known problem with that
      grammar.  Any NAI that contains invalid character sequences cannot
      be used as a Target identifier.

3.2.5.  URI

   A Target can be identified by a URI.  Any URI can be used providing
   that the requester and LIS have a common understanding of the
   semantics implied by use of the URI.

Winterbottom, et al.     Expires August 29, 2009                [Page 8]

Internet-Draft                HELD Identity                February 2009

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

3.2.6.  Hostname

   A domain name can be used as the basis for identification using the
   "hostname" element.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

3.2.7.  Directory Number

   Telephony devices are typically identified by the number that is used
   to reach them.  Within enterprises, where globally accessible
   telephone numbers might not be used, a directory number is the usual
   form of identification.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

3.2.8.  Cellular Telephony Identifiers

   A range of different forms of mobile station identifiers are used for
   different cellular telephony systems.  Elements are defined for these
   identifiers.  The following identifiers are defined:

   msisdn:  The Mobile Subscriber Integrated Services Digital Network
      Number (MSISDN) is an E.164 number between 6 and 15 digits long.

   imsi:  The International Mobile Subscriber Identity (IMSI) an
      identifier associated with all GSM and UMTS mobile subscribers.

   imei:  The International Mobile Equipment Identifier (IMEI) is a
      unique device serial number up to 15 digits long.

   min:  The Mobile Identification Number (MIN) is a unique number
      assigned to CDMA handsets.

   mdn:  The Mobile Directory Number (MDN) is an E.164 number, with
      usage similar to MSISDN.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

Winterbottom, et al.     Expires August 29, 2009                [Page 9]

Internet-Draft                HELD Identity                February 2009


3.2.9.  DHCP Unique Identifier

   The Dynamic Host Configuration Protocol (DHCP) uses a binary
   identifier for its clients.  The DHCP Unique Identifier (DUID) is
   expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of
   DHCPv6 and follows the format defined in Section 9 of [RFC3315].  The
   "duid" element includes the binary value of the DUID expressed in

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

4.  XML Schema

  <?xml version="1.0"?>
      elementFormDefault="qualified" attributeFormDefault="unqualified">

    <!-- Target Identity -->
    <xs:element name="target" type="id:targetIdentity"/>
    <xs:complexType name="targetIdentity">
        <xs:any namespace="##any" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>

    <xs:element name="requiredIdentifiers" type="id:qnameList"/>
    <xs:simpleType name="qnameList">
      <xs:list itemType="xs:QName"/>

    <xs:element name="ip" type="id:ipAddress"/>
    <xs:complexType name="ipAddress">
        <xs:extension base="xs:token">
          <xs:attribute name="v" use="optional">
              <xs:restriction base="xs:token">
                <xs:pattern value="[\da-fA-F]"/>

Winterbottom, et al.     Expires August 29, 2009               [Page 10]

Internet-Draft                HELD Identity                February 2009


    <xs:element name="mac" type="id:macAddress"/>
    <xs:simpleType name="macAddress">
      <xs:restriction base="xs:token">
        <xs:pattern value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}"/>

    <xs:element name="udpport" type="id:portNumber"/>
    <xs:element name="tcpport" type="id:portNumber"/>
    <xs:simpleType name="portNumber">
      <xs:restriction base="xs:nonNegativeInteger">
        <xs:maxInclusive value="65535"/>

    <xs:element name="nai" type="xs:token"/>

    <xs:element name="uri" type="xs:anyURI"/>

    <xs:element name="dn" type="id:digits"/>
    <xs:simpleType name="digits">
      <xs:restriction base="xs:token">
        <xs:pattern value="[\d]+"/>

    <xs:element name="hostname" type="id:domainName"/>
    <xs:simpleType name="domainName">
      <xs:restriction base="xs:token">
        <!-- the following pattern does not include whitespace;
             whitespace is added only to conform to document
             formatting restrictions -->
        <xs:pattern value="([A-Za-z\d]([A-Za-z\d-]*[A-Za-z\d])*\.)*

    <xs:element name="duid" type="xs:hexBinary"/>

    <xs:element name="msisdn" type="id:e164"/>
    <xs:element name="imsi" type="id:e164"/>
    <xs:element name="imei" type="id:digit15"/>
    <xs:element name="min" type="id:digit10"/>

Winterbottom, et al.     Expires August 29, 2009               [Page 11]

Internet-Draft                HELD Identity                February 2009

    <xs:element name="mdn" type="id:e164"/>
    <xs:simpleType name="e164">
      <xs:restriction base="id:digit15">
        <xs:minLength value="6"/>
    <xs:simpleType name="digit15">
      <xs:restriction base="id:digits">
        <xs:maxLength value="15"/>
    <xs:simpleType name="digit10">
      <xs:restriction base="id:digits">
        <xs:length value="10"/>


5.  Privacy Considerations

   A location configuration protocol has a very simple privacy model.
   Because the requester is also the Target, it can be assumed that
   providing that requester with location information is allowed.  This
   "LCP policy" makes the simple assumption that as the subject of the
   location information, the Target is also permitted access to that
   information.  In effect, an LCP server (that is, the LIS) follows a
   single rule policy that states that the Target is the only authorized
   Location Recipient.

   Note:  HELD explicitly takes the position that the Target is a Device
      and not a person.  For the purpose of discussion related to
      privacy, this distinction is not important.  In this section,
      Target refers equally to Device and person.

   When Target identity is used, the "LCP policy" is only applicable if
   the identity of requester and Target are identical.  If the
   authenticated identity of the requester and the Target are the same,
   the security and privacy considerations of the base HELD protocol
   [I-D.ietf-geopriv-http-location-delivery] MAY be applied by a LIS.
   The LIS MUST NOT use LCP policy unless it can authenticate the
   requester identity is the same as the requested identity.  Requester
   and target identities MUST be identical, related identities are not

      For example, it is not appropriate to apply LCP policy where a
      requester is authenticated by NAI and the supplied Target identity
      is a MAC address, even if that MAC address is currently registered

Winterbottom, et al.     Expires August 29, 2009               [Page 12]

Internet-Draft                HELD Identity                February 2009

      with the network under the given NAI.  In this case, the requester
      might be requesting from a different MAC address registered under
      the same NAI.  The correct way of gaining authorization is to
      establish a policy that permits this particular request as a third
      party request.

   The LCP policy does not allow requests made by third parties.  If a
   LIS permits requests from third parties using identity extensions, it
   assumes the rule of a Location Server (LS).  HELD becomes a more
   general location request protocol--a "using protocol" by the
   definitions in [RFC3693]--and the privacy considerations for using
   protocols apply.  As a Location Server, the LIS MUST explicitly
   authorize requests according to the policies that are provided by
   Rule Makers, including the Target.  This includes authentication of
   requesters where required by the authorization policies.

   An organization that provides a LIS that allows third party requests
   SHOULD provide a means for a Rule Maker to specify authorization
   policies before allowing third party requests for that Target's
   location.  Until an authorization policy is established, the LIS MUST
   reject requests by third parties.

   When the LIS is operated by the Target's access network, the
   relationship between the Target and the LIS can be transient.
   However, the process of establishing network access usually results
   in a form of agreement between the Target and the network provider.
   This process offers a natural vehicle for establishing location
   privacy policies.  Establishing authorization policy might be a
   manual process, an explicit part of the terms of service for the
   network, or an automated system that accepts formal authorization
   policies (see [RFC4745], [RFC4825]).  This document does not mandate
   any particular mechanism for establishing an authorization policy.

6.  Security Considerations

   The security considerations in
   [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for
   server authentication, confidentiality and protection from
   modification.  These protections apply to both LCP requests and the
   requests made by third parties.

   All HELD requests MUST be authenticated by the LIS.  How
   authentication is accomplished and what assurances are desired is a
   matter for policy.  The base HELD protocol uses return reachability--
   the proof of ownership of an IP address implied by the requester
   being able to successfully complete a TCP handshake.  It is
   RECOMMENDED that any means of authentication provide at least this
   degree of assurance.  [[MT: last sentence too subjective?]]  For

Winterbottom, et al.     Expires August 29, 2009               [Page 13]

Internet-Draft                HELD Identity                February 2009

   requests that include Target identity, the LIS MUST support
   authentication of TLS clients.

6.1.  Location Configuration Protocol Requests

   Requests made by a Device in the context of a location configuration
   protocol are covered by the same set of protections offered by HELD.
   LCP requests are authorized under an "LCP policy" that permits a
   Target access to location information about itself.

   Identity information provided by the Device is private data that
   might be sensitive.  The Device provides this information in the
   expectation that it assists the LIS in providing the Device a
   service.  The LIS MUST NOT use identity information for any other
   purpose other than serving the request that includes that

6.2.  Third Party Requests

   Requests from third parties have the same requirements for server
   authentication, confidentiality and protection from modification as
   LCP requests.  However, because the third party needs to be
   authorized, the requester MUST be authenticated by the LIS.  In
   addition, third party requests MUST be explicitly authorized by a
   policy that is established by a Rule Maker.

   More detail on the privacy implications of third party requests are
   covered in Section 5.

7.  IANA Considerations

   This document registers an XML namespace and schema with IANA in
   accordance with guidelines in [RFC3688].  It also creates a new
   registry for device identity types, and stipulates how new types are
   to be added.

7.1.  URN Sub-Namespace Registration for

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in

      URI: urn:ietf:params:xml:ns:geopriv:held:id

      Registrant Contact: IETF, GEOPRIV working group,
      (, James Winterbottom

Winterbottom, et al.     Expires August 29, 2009               [Page 14]

Internet-Draft                HELD Identity                February 2009


         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
         <html xmlns="" xml:lang="en">
             <title>HELD Target Identity Parameters</title>
             <h1>Namespace for HELD Target Identity Parameters</h1>
   [[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>

7.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in

   URI:  urn:ietf:params:xml:schema:geopriv:held:id

   Registrant Contact:  IETF, GEOPRIV working group, (,
      James Winterbottom (

   Schema:  The XML for this schema can be found as the entirety of
      Section 4 of this document.

7.3.  Registration of HELD 'badIdentifier' Error Code

   This section registers the "badIdentifier" error code in the "Geopriv
   HELD Registries, Error codes for HELD" IANA registry.

   badIdentifier  This error code indicates that the Target identifiers
      used in the HELD request were either: not supported by the LIS,
      badly formatted, or that the requester was not authorized to make
      a erquest for that identifier.

8.  Acknowledgements

   The authors wish to thank the NENA VoIP location working group for
   their assistance in the definition of the schema used in this
   document.  Special thanks go to Barbara Stark, Guy Caron, Nadine

Winterbottom, et al.     Expires August 29, 2009               [Page 15]

Internet-Draft                HELD Identity                February 2009

   Abbott, Jerome Grenier and Martin Dawson.  Bob Sherry provided input
   on use of URIs.  Thanks to Adam Muhlbauer and Eddy Corbett for
   providing further corrections.  Bernard Aboba provided extensive
   feedback on use cases and the security model; Bernard, along with
   Alan DeKok, also helped resolve an issue with NAIs.  Ray Bellis
   provided motivation for the protocol port parameters.

9.  References

9.1.  Normative references

   [RFC2119]                                  Bradner, S., "Key words
                                              for use in RFCs to
                                              Indicate Requirement
                                              Levels", BCP 14, RFC 2119,
                                              March 1997.

   [RFC3315]                                  Droms, R., Bound, J.,
                                              Volz, B., Lemon, T.,
                                              Perkins, C., and M.
                                              Carney, "Dynamic Host
                                              Configuration Protocol for
                                              IPv6 (DHCPv6)", RFC 3315,
                                              July 2003.

   [RFC3688]                                  Mealling, M., "The IETF
                                              XML Registry", BCP 81,
                                              RFC 3688, January 2004.

   [RFC4282]                                  Aboba, B., Beadles, M.,
                                              Arkko, J., and P. Eronen,
                                              "The Network Access
                                              Identifier", RFC 4282,
                                              December 2005.

   [RFC4361]                                  Lemon, T. and B.
                                              Sommerfeld, "Node-specific
                                              Client Identifiers for
                                              Dynamic Host Configuration
                                              Protocol Version Four
                                              (DHCPv4)", RFC 4361,
                                              February 2006.

   [I-D.ietf-geopriv-http-location-delivery]  Barnes, M., Winterbottom,
                                              J., Thomson, M., and B.
                                              Stark, "HTTP Enabled
                                              Location Delivery (HELD)",

Winterbottom, et al.     Expires August 29, 2009               [Page 16]

Internet-Draft                HELD Identity                February 2009

                                              location-delivery-12 (work
                                              in progress),
                                              January 2009.

   [I-D.ietf-geopriv-l7-lcp-ps]               Tschofenig, H. and H.
                                              Schulzrinne, "GEOPRIV
                                              Layer 7 Location
                                              Configuration Protocol;
                                              Problem Statement and
                                              Requirements", draft-ietf-
                                              geopriv-l7-lcp-ps-09 (work
                                              in progress),
                                              February 2009.

   [W3C.REC-xml-names11-20060816]             Tobin, R., Layman, A.,
                                              Bray, T., and D.
                                              Hollander, "Namespaces in
                                              XML 1.1 (Second Edition)",
                                              World Wide Web Consortium
                                              Recommendation REC-xml-
                                              August 2006, <http://

9.2.  Informative references

   [RFC3693]                                  Cuellar, J., Morris, J.,
                                              Mulligan, D., Peterson,
                                              J., and J. Polk, "Geopriv
                                              Requirements", RFC 3693,
                                              February 2004.

   [RFC3825]                                  Polk, J., Schnizlein, J.,
                                              and M. Linsner, "Dynamic
                                              Host Configuration
                                              Protocol Option for
                                              Coordinate-based Location
                                              Information", RFC 3825,
                                              July 2004.

   [RFC4388]                                  Woundy, R. and K. Kinnear,
                                              "Dynamic Host
                                              Configuration Protocol
                                              (DHCP) Leasequery",
                                              RFC 4388, February 2006.

Winterbottom, et al.     Expires August 29, 2009               [Page 17]

Internet-Draft                HELD Identity                February 2009

   [RFC4745]                                  Schulzrinne, H.,
                                              Tschofenig, H., Morris,
                                              J., Cuellar, J., Polk, J.,
                                              and J. Rosenberg, "Common
                                              Policy: A Document Format
                                              for Expressing Privacy
                                              Preferences", RFC 4745,
                                              February 2007.

   [RFC4776]                                  Schulzrinne, H., "Dynamic
                                              Host Configuration
                                              Protocol (DHCPv4 and
                                              DHCPv6) Option for Civic
                                              Addresses Configuration
                                              Information", RFC 4776,
                                              November 2006.

   [RFC4825]                                  Rosenberg, J., "The
                                              Extensible Markup Language
                                              (XML) Configuration Access
                                              Protocol (XCAP)",
                                              RFC 4825, May 2007.

   [I-D.ietf-ecrit-phonebcp]                  Rosen, B. and J. Polk,
                                              "Best Current Practice for
                                              Communications Services in
                                              support of Emergency
                                              Calling", draft-ietf-
                                              ecrit-phonebcp-07 (work in
                                              progress), January 2009.

   [I-D.thomson-geopriv-held-measurements]    Thomson, M. and J.
                                              Winterbottom, "Using
                                              Device-provided Location-
                                              Related Measurements in
                                              Location  Configuration
                                              Protocols", draft-thomson-
                                              03 (work in progress),
                                              October 2008.

   [LLDP]                                     IEEE, "802.1AB, IEEE
                                              Standard for Local and
                                              Metropolitan area
                                              networks, Station and
                                              Media Access Control
                                              Connectivity Discovery",
                                              June 2005.

Winterbottom, et al.     Expires August 29, 2009               [Page 18]

Internet-Draft                HELD Identity                February 2009

Authors' Addresses

   James Winterbottom
   Andrew Corporation
   PO Box U40
   University of Wollongong, NSW  2500


   Martin Thomson
   Andrew Corporation
   PO Box U40
   University of Wollongong, NSW  2500


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600

   Phone: +358 (50) 4871445

   Richard Barnes
   BBN Technologies
   9861 Broken Land Pkwy, Suite 400
   Columbia, MD  21046

   Phone: +1 410 290 6169

Winterbottom, et al.     Expires August 29, 2009               [Page 19]