2.1.4 Geographic Location/Privacy (geopriv)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. 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-02-08


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-05.txt
  • draft-ietf-geopriv-policy-05.txt
  • draft-ietf-geopriv-pidf-lo-03.txt
  • draft-ietf-geopriv-pres-02.txt
  • draft-ietf-geopriv-common-policy-04.txt
  • draft-ietf-geopriv-radius-lo-02.txt
  • draft-ietf-geopriv-location-types-registry-00.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

    Current Meeting Report

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

    Medhavi Bhatia
    Edwom Aoki

    1) Agenda
    Andrew presented an alternate agenda from the one circulated on the mailing list so that all the presentations could be reviewed with proper question and answers. His proposal was to eliminate any discussions specific to re-charter. There were no objections.

    2) Status of PIDF-LO
    Andrew noted that this specification was pending IANA clarifications. Jon Peterson informed the group that he would meet with IANA to complete the clarifications.

    3) GEOPRIV Common Policy
    Andrew noted that work on draft-ietf-geopriv-common-policy was holding on last call comments regarding the use of substitution groups vs. <any> elements in the XML Schemas. He also noted that discussion regarding unauthenticated vs. anonymous access had been moved to the SIMPLE working group.
    Regarding the direction of the XML Schemas for this draft, it was noted that one use case was offered showing the need for <any> elements and none offered for substitution groups. Andrew asked for any arguments for the use of substitution groups. None were offered so Andrew instructed the draft authors to make the necessary changes to this draft to use <any> elements.

    4) NENA Requirements
    Brian Rosen presented draft-rosen-nena-geopriv-requirements.
    Brian noted the need for integrity of location information so that emergency calls cannot dispatch emergency responders to forged locations. Questions were asked regarding end-to-end security and integrity. It was noted that the requirement may be for the location generator to provide a signature that is carried from end-to-end. There was also discussion of providing a time-to-live for location information to reduce the amount of time location data is valid.
    Brian noted that multiple locations are confusing an unnecessary for emergency calls, and there is a need for a deterministic single, unique location. For this, it was noted that rules and guidelines were needed for an algorithm on resolution.
    Rohan Mahy questioned the need for placetypes. Brian suggested that emergency responders need information regarding the surroundings of the emergency and not just a legal/postal address or coordinates.
    Jonathan Rosenberg noted that many of the problems under discussion were already addressed by the PIDF specification.

    5) PIDF-LO Profile
    James Winterbottom presented draft-winterbottom-geopriv-pidf-lo-profile.
    James noted that the GML specification used by PIDF-LO was very large and implementors needed guidance on how to use GML with PIDF-LO. A suggestion for the room was to limit the number of GML defined shapes used by PIDF-LO.
    Jon Peterson noted that this work was needed.

    6) SAML Authorization
    Hannes Tschofenig presented draft-guenther-geopriv-saml-policy.
    There were no questions from the room regarding this work. Jonathan Rosenberg noted that is was good work.

    Hannes Tschofenig gave a presentation on the latest changes in the GEOPRIV RADIUS draft. There were no questions or comments from the room. Andrew asked if the draft was ready for working group last call, and Hannes indicated it needed one more revision to address one known issue.

    8) Domain Authorization for PIDF-LO
    James Winterbottom presented draft-thomson-domain-auth.
    Jon Peterson noted that original working group discussions around PIDF-LO came to the conclusion that security was only needed for the document as a whole and not in parts. Henning Schulzerinne commented regarding the multiple signing operations and called for a need of a single signing framework, and also noted that signed data in layer 2 network elements will require a location key in every layer 2 network element. Jon Peterson stated that the threat requirement for unsigned layer 2 location information was an unknown.
    James suggested that it would be necessary for intermediate nodes to add data to PIDF-LO, such as refinement of location information or additional information, and therefore the signature scheme needed to be able to accommodate PIDF-LO modification or additions.

    9) HTTP Enabled Location Delivery
    James Winterbottom presented draft-winterbottom-http-location-delivery.
    Henning Schulzrinne asked how impersonations would be prevented without additional security measures. He also noted that the scope of DNS and access networks are not equivalent and therefore do not provide a proper match.
    Randall Gellens asked James to clarify the use case for this work. James pointed out this was about solely passing location objects and location information passed in the act of web browsing.
    Brian Rosen noted that this use of HTTP added to the overall architectural complexity of moving location information up the protocol stack. He noted that with more choices for transfer of location data, there is a higher likelihood of noninteroperability. Rohan Mahy pointed out that this was the case anyway given the number of layer 2 mechanism that provide location data.
    Jonathan Rosenberg noted that the use of source IP addresses would be problematic given the large number of NAT devices deployed on modern networks.

    10) General Architecture
    Andrew opened up the floor to a general discussion regarding architecture of conveying location information through the protocol stack. This discussion touched on the trust associated with location generators, trust issues related to regulated service networks vs. adhoc networks, and the re-use of common network configuration mechanisms to provide location information to network nodes.
    To judge the sense of the discussion, Andrew asked the room to hum if they found work on this type of architecture was needed within the IETF. The hum carried. Andrew then asked if it was necessary to have one universal architecture or if competing architectures would be reasonable. The consensus of the room was that multiple architectures would be reality.
    Jon Peterson noted that multiple architectures would develop naturally and that the IETF needed to produce requirements and descriptions of properties for network elements at each layer in relation to moving location information from one layer of the protocol stack to another. Many participants in the room agreed that this was a better use of the groups time than to define competing architectures.
    Andrew asked for draft volunteers to raise their hands if they were willing to write Internet Drafts describing these properties. Many hands were raised. Andrew suggested that as many of them collaborate as possible and to submit drafts as soon as possible.

    11) Any Other Business
    No other business was offered. Andrew closed the meeting.


    NENA geopriv Requirements
    Domain Authorization for PIDF-LO
    SAML in Authorization Policies
    Carrying Location Objects in RADIUS
    HTTP Enabled Location Delivery (HELD)