2.1.6 Geographic Location/Privacy (geopriv)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-20

Allison Mankin <mankin@psg.com>
Randall Gellens <rg+ietf@qualcomm.com>
andrew newton <anewton@ecotroph.net>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
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: ftp://ftp.ietf.org/ietf-mail-archive/geopriv
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 deliverable.

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 technology.

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 draft-daviel-http-geo-header-03.txt.

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 bodies.


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:
Jun 02  Discuss initial geopriv scenarios and application requirements i-d's
Jun 02  Discuss initial geographic location privacy and security requirements i-d.
Aug 02  Initial i-d on geographic information protocol design, including privacy and security techniques.
Aug 02  Review charter and initial i-ds with AD, and have IESG consider rechartering if necessary.
Aug 02  Submit geopriv scenarios and application requirements to IESG for publicaiton as Informational RFCs
Sep 02  Submit security/privacy requirements I-D to IESG for publication as Informational RFC.
Sep 02  Use initial framework to restructure drafts on geographic information in HTTP and HTML so that location security and privacy are integral.
Dec 02  Use initial framework to develop an example location/privacy API that might be used in a 3G handset or other consumer application.
Jan 03  Submit geopriv protocol, geopriv http, geopriv html, and handset example draft to IESG for publication as standards track RFCs (except for example draft, submitted as Informational)
Mar 03  Conclude working group, unless ADs determine added work is needed
  • - draft-ietf-geopriv-reqs-04.txt
  • - draft-ietf-geopriv-dhcp-lo-option-00.txt
  • - draft-ietf-geopriv-dhcp-lci-option-02.txt
  • - draft-ietf-geopriv-dhcp-civil-00.txt
  • - draft-ietf-geopriv-policy-00.txt
  • No Request For Comments

    Current Meeting Report

    Meeting Minutes of the Geographic
    Location/Privacy (GEOPRIV) Working Group
    Monday, November 10, 2003, 1930-2200
    Allison Mankin
    Randall Gellens
    Andrew Newton
    Ashir Ahmed
    Published Agenda:
    1) Agenda Bashing
    2) WG Administrativia
    3) LO and GML Issues (Hannes Tschofenig)
    4) PIDF-LO (Jon Peterson)
    5) POLICY
       Permissions and Rules (Henning Schulzrinne)
       Changes and Open Issues (Hannes Tschofenig)
    6) Any Other Business
    1) Agenda Bashing
       No agenda modifications requested
    2) WG Administrativia
       Two drafts in RFC Editor queue
       One draft under review of IESG
       No additional comments.
    3) LO and GML Issues
    Presentation given by Hannes Tschofenig
    Concerns expressed from the room ranged from size of the documents, 
    performance issues, and usage details for implementors.
    4) PIDF-LO
    Presentation by Jon Peterson on 
    It was asked that the permission flags be separated out of the PIDF-LO 
    schema for use in other applications.  After a minor discussion on the 
    merits of using a new namespace vs. global scoped elements in the 
    current schema, the draft author indicated he would create a separate 
    namespace and schema for the flags.
    The issue of the indicating the device source of the presentity was 
    raised.  There was no decision that this was needed.
    The room discussed avoidance of interoperability issues by declaring a MIME 
    type for the location object.  It was noted that using protocols will know 
    the format anyway.
    Concern was raised regarding the "must understand" requirement in PIDF. 
     This was proceeded by a discussion of XML validation.
    The room then discussed civil location in PIDF-LO.  The chair noted the 
    working group's consensus regarding the desire for civil location in 
    PIDF-LO vs. just POLICY.  A question was put to the floor:  should 
    PIDF-LO incorporate the civil location elements from POLICY. The 
    consensus of the room was positive.
    It was noted that the X.509 certificates for S/MIME would require a 
    subject alternative name of URI type of a pres: URI.
    4) POLICY
    Presentation by Henning Schzulrinne regarding permissions and rules 
    philosophy for draft-ietf-geopriv-policy.
    An issue was raised by Jonathon Rosenberg, but he and Henning decided to 
    take the issue to the list for detailed discussion.
    There were no other questions for this presentation.
    Hannes Tschofenig gave a presentation on changes and open issues in 
    The issue of logging was raised.  It was noted that the service 
    provider will be doing logging of the using protocol and that this issue 
    could not be solved by the working group.
    It was mentioned that the current draft did not address identities and 
    authentication types.  One of the co-authors indicated that this would be 
    placed back in the next version of the draft.
    The room discussed notifications and the level of detail and size of 
    information involved.  A question regarding authorization in the using 
    protocol was asked.  Hannes indicated that the authors were working 
    through those details.
    A question was asked of the room:  should the POLICY document contain a 
    section regarding the using profiles.  The room consented.
    The next issue raised involved the URI's for authentication and 
    identity.  Henning noted that there are two ways to proceed: using an 
    opaque string or declaring using protocol specific elements.  This led into 
    the discussion about domains and individuals and the convergence with 
    XCAP.  It was noted that XCAP has notion of domain match and that not all 
    authentication schemes have the notion of "user@domain".
    This next led to a discussion on exception lists to rule targets.  After 
    much discussion, the room was asked the following question: are 
    exceptions NOT needed.  The room did not consent.  It was then asked of the 
    room if only additive permissions without exceptions were 
    acceptable.  The room was evenly split and not consensus was found.
    Convergence with XCAP and the work of the SIMPLE working group was then 
    raised again.  The desire to avoid divergence was expressed.  After much 
    discussion on how to proceed, the following proposal was presnted on a 
    method to go forward: if the SIMPLE working group agrees to retain 
    domain-based authorization but exclude exception-based rules in XCAP, then 
    the GEOPRIV working group agrees to use XCAP.  This proposal noted that 
    exception-based rules would not be included in version 1 of the 
    specification, but would be considered in subsequent versions with the 
    hind-sight of deployment experience.  The room consented.
    6) Any Other Business
    Brian Rosen (and Jon Morris) presented a topic on Emergency 911.  He noted 
    the danger in not specifying rules for crypto with regard to emergency call 
    routing.  He proposed supporting TLS (or IPSEC) as normal security 
    mechanism for emergency calls.  While the room was not formally asked to 
    indicate approval, many participants favored the idea.  The chairs asked for 
    more discussion of the topic on the working group mailing list.
    Geopriv mailing list


    Location Object and GML Issues
    Policy Rules for Disclosure and Modification of Geographic Information
    Policy Changes/Open Issues