2.1.4 Geographic Location/Privacy (geopriv)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional GEOPRIV Web Page

Last Modified: 2005-06-27


Allison Mankin <mankin@psg.com>
Randall Gellens <rg+ietf@qualcomm.com>
Andrew Newton <andy@hxr.us>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion: geopriv@ietf.org
To Subscribe: geopriv-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/geopriv/index.html

Description of Working Group:

As more and more resources become available on the Internet, some
applications need to acquire geographic location information about
certain resources or entities. These applications include navigation,
emergency services, management of equipment in the field, and other
location-based services.

But while the formatting and transfer of such information is in some
sense a straightforward process, the implications of doing it,
especially in regards to privacy and security, are anything but.

The primary task of this working group will be to assess the the
authorization, integrity and privacy requirements that must be met in
order to transfer such information, or authorize the release or
representation of such information through an agent.

In addition, the working group will select an already standardized
format to recommend for use in representing location per se.  A key
task will be to enhance this format and protocol approaches using the
enhanced format, to ensure that the security and privacy methods are
available to diverse location-aware applications.  Approaches to be
considered will include (among others) data formats incorporating
fields directing the privacy handling of the location information and
possible methods of specifying variable precision of location.

Also to be considered will be:  authorization of requestors and
responders; authorization of proxies (for instance, the ability to
authorize a carrier to reveal what timezone one is in, but not what
city.  An approach to the taxonomy of requestors, as well as to the
resolution or precision of information given them, will be part of this

The combination of these elements should provide a service capable of
transferring geographic location information in a private and secure
fashion (including the option of denying transfer).

For reasons of both future interoperability and assurance of the
security and privacy goals, it is a goal of the working group to
deliver a specification that has broad applicablity and will become
mandatory to implement for IETF protocols that are location-aware.

Two further deliverables of the WG will be:

o An example API for application-level access to/management
  of link-based location information.  That is, for instance, the WG
  may describe an API for secure, privacy-enabling user/ application
  handling of location information specific to a 3G wireless link

o Development of i-ds that make security and privacy integral to
  location information in HTTP and HTML, based on the work in
  draft-daviel-html-geo-tag-05.txt and

Out of Scope:

This WG won't develop location-determining technology.  It will work
from existing technologies and where the technology is undeveloped,
will state that applicability may await others' developments.

This WG won't develop technology to support any particular regulatory
requirement [e.g. E.911] but will provide a framework that might be
used for private/secure definition of such technologies by other


The WG will coordinate with other WGs developing general privacy and
location-aware functions, e.g. the SIP WG, so that the WG deliverables
can be used by them.  Other coordination should include the NymIP
research community, WC3, and the Location Information Forum.

Goals and Milestones:

Done  Discuss initial geopriv scenarios and application requirements i-d's
Done  Discuss initial geographic location privacy and security requirements i-d.
Done  Initial i-d on geographic information protocol design, including privacy and security techniques.
Done  Review charter and initial i-ds with AD, and have IESG consider rechartering if necessary.
Done  Submit geopriv scenarios and application requirements to IESG for publicaiton as Informational RFCs
Done  Submit security/privacy requirements I-D to IESG for publication as Informational RFC.
Done  Submit PIDF-LO basic geopriv object draft as a PS
Done  Initial Common Rules base object draft
Done  Initial Common Ruels GEOPRIV object draft
Done  Submit DHCP Civil draft as a PS
Feb 05  Initial bis-requirements document
Feb 05  Confer with SIP WG on SIP using protocol draft as PS
Feb 05  Submit draft-ietf-geopriv-policy as PS
Feb 05  Submit draft-ietf-geopriv-common-policy as PS
Mar 05  Close or re-charter for GEOPRIV-MAINT
Mar 05  Submit draft-ietf-geopriv-radius as PS


  • draft-ietf-geopriv-dhcp-civil-06.txt
  • draft-ietf-geopriv-policy-06.txt
  • draft-ietf-geopriv-pidf-lo-03.txt
  • draft-ietf-geopriv-common-policy-05.txt
  • draft-ietf-geopriv-radius-lo-04.txt
  • draft-ietf-geopriv-location-types-registry-02.txt
  • draft-ietf-geopriv-pdif-lo-profile-01.txt

    Request For Comments:

    RFC3693 I Geopriv requirements
    RFC3694 I Threat Analysis of the geopriv Protocol
    RFC3825 Standard Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information
    RFC4079 I A Presence Architecture for the Distribution of GEOPRIV Location Objects

    Current Meeting Report

    Minutes of the GEOPRIV Working Group at the 63nd IETF
    Allison Mankin
    Randall Gellens
    Andrew Newton

    Doug Otis
    1. Agenda

    2. Andrew presented the agenda, and noted that two items had been added: a) GEOPRIV issues with SIP events, and b) draft-guenther-geopriv-saml-policy-01. No objection were given to the additions.

    3. draft-winterbottom-location-uri-00

    4. Martin Thomson presented draft-winterbottom-location-uri-00. Martin discussed the benefits of passing location information by reference vs. passing location information by value.
      Henning Schulzrinne objected to the points that pass-by-reference had superior privacy strengths, and Jon Peterson pointed out that pass-by-reference has better access control features whereby pass-by-value is limited to the use of cryptography. Hannes Tschofenig disagreed with this point and noted that in both cases access control needs to be configured. Henning Schulzrinne and Jon Peterson also discussed the differences between cost and environmental challenges between pass-by-value and pass-by-reference.
      Many participants noted that the draft seemed more like propaganda against pass-by-value and requested that it either should be toned down or provide better supporting arguments. The draft authors agreed.
      Ted Hardie noted that any pass-by-reference model needs to specify the access methods for reference, with URIs the set of schemes need to be specified. Jon Peterson then noted that this draft was only intended to describe a concept and not a concrete proposal.
      Brian Rosen noted that the description of pass-by-value being used by anybody does not correctly describe the pass-by-value deployment environments where trust is put into the channel and channel connections, especially when channel security is utilized. Jon Peterson noted that pass-by-reference does not necessarily need to rely upon cryptography, whereby pass-by-value does require cryptography. Brian Rosen noted that in the emergency case that passwords were not plausible for deployment.

    5. draft-ietf-geopriv-pdif-lo-profile-01

    6. Hannes Tshofenig presented draft-ietf-geopriv-pdif-lo-profile.
      Henning Schulzrinne noted that he did not see any productive outcome for continuing discussion on providing guidelines on precision or accuracy. He noted that he knew of no reasons why it would be dropped when it was given.

    7. draft-winterbottom-http-location-delivery-01

    8. Martin Thomson presented draft-winterbottom-http-location-delivery-01.txt. This document is known as HELD.
      John Schnizlein noted that HTTP has the capability of traversing NATs, but that HELD cannot because of its callback feature.
      Henning Schulzrinne noted that objects reference by HELD will have an object lifetime issue, at that at some point that a location object reference by HELD would be deleted. Martin Thomson suggested that retention requirements could be added but that they would vary depending on situation. Henning Schulzrinne expressed concern over variable retention requirements. Steve Norris also expressed concern for variable retention requirements. Hannes Tschofenig also stated that there was a state maintenance issue on top of the retention issue.
      Hannes Tschofenig stated that he did not understand the pseudonym in HELD and stated that there might be identity issues with HELD pseudonyms and the other identifiers in PIDF-LO.
      Ted Hardie stated that he believed that GEOPRIV does not currently have the policy rules defined for using On-Behalf-Of in HELD and that it would require a lot of work. John Schnizlein agreed and noted that On-Behalf-Of using IP addresses from the access networks will cause mistakes.
      John Schnizlein raised concerns four concerns: (a) reliance on "the" access network fails because there are often multiple ones - a tunnel for example (b) discovery using DNS unnecessarily relies on DHCP, then on a record not intended for the public use of DNS, (c) reliance on the domain returned by DHCP does not work either: e.g. the domain for the host in my hand is not here in France where the access is, and (d) the feasibility of generating a location from just an IP address is not clear. Martin Thomson mentioned that SLP could be used instead.

    9. Followup to issues from interim meeting

    10. Hannes Tschofenig led a facilitated discussion on the issues that came from the GEOPRIV/ECRIT interim meeting held in New York.
      John Schnizlein questioned the need to worry about wrong locaiton information in an emergency phone call. Steve Norris noted that it is quite common in certain jurisdictions to fake incidents that require police reaction just to give neighbors a bad reputation. Stuart Goldman noted that fake location information in an emergency call could be used by terrorists to dispatch first responders to the wrong location. Randy Gellens noted that it may be easier to trust location information from a SIP proxy than from a call originator, but sophisticated attackers can stand up a SIP proxy. Andrew Newton and John Schnizlein noted that emergency call takers usually ask callers for information in addition to what they get from the network.
      Rohan Mahy noted that once a cryptographic signature is placed over an identity, there is then an issue of coordinating identities with users and emergency call centers.
      Brian Rosen noted that PSAP operators want location information to be reliable and spoof protected, but that even if the location information is incorrect a PSAP will take a call. Correct location information may be usable for call routing in high load situations. He also noted that asserted location is more important than identity.
      Brian Rosen also noted that the access network and signaling network may be different, and therefore it is difficult to use the access network to control aspects of the signaling. And that the two networks have different identities. Hannes Tschofenig noted that the difference between the access network and the signaling network is an issue because many solutions do not take into account these differing network architectures. Ted Hardie noted that the question that needs to be asked is about the necessity of passing the location/identity binding from the access network through the signaling network and to the emergency call end point.
      Rohan Mahy asked how a PSAP distinguishes between a large number of legitimate calls and a denial-of-service attack.
      Henning Schulzrinne asked if it is helpful to provide better bindings between location and network characteristics. Such as, would the source IP address of the call help when the location passed in the call is not known to be in that location.
      Steve Norris stated that multiple pieces of information given to the PSAPs will be beneficial, and so it could be useful to provide PSAPs with both the information from a network element and a information from a client.

    11. GEOPRIV issues with SIP Events

    12. Rohan Mahy presented draft-mahy-geopriv-sip-loc-pkg-01.txt.
      Henning Schulzrinne stated that the normal PIDF-LO model uses presence subscriptions and this draft does not use presence. Rohan asked about applications that do not need presence information. Jon Peterson answered that presence requests can be filtered. Rohan noted that doing presence requests requires domain knowledge in presence even though the application is in the location domain.
      James Polk noted that this document solves a problem that is difficult to do in the SIP location conveyance document. Martin Thomson also agreed that the document was useful but noted that some of the GML bindings needed to be tightened up. Rohan noted that the use of GML with PIDF-LO is one of the reasons why he believed this document should be in GEOPRIV.
      Randy Gellens noted that the privacy requirements about location change events may be harder than anticipated because users tend to have changing needs. Rohan answered the concern by stating that such complexity could be handled by user interfaces.
      Andrew asked for a hum from the room regarding GEOPRIV accepting the work in the draft on the filter formatting. The room accepted the work.

    13. draft-guenther-geopriv-saml-policy-01

    14. Hannes Tschofenig gave a presentation on draft-guenther-geopriv-sampl-policy-01.
      Andrew asked how many participants had read the draft. Only two participants raised their hands. Andrew stated that the question of adopting this draft would have to be taken to the list since there were not enough reviewers of the draft in the room.


    Rationale for Location By-Reference
    GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations Progress Update
    HTTP Enabled Location Delivery (HELD)
    Architectural Considerations for GEOPRIV/ECRIT
    SAML in Authorization Policies