2.1.3 Geographic Location/Privacy (geopriv)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC 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: 2004-10-15

Chair(s):

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

Coordination:

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.
Feb 04  Submit PIDF-LO basic geopriv object draft as a PS
Feb 04  Initial Common Rules base object draft
Feb 04  Initial Common Ruels GEOPRIV object draft
Mar 04  Submit Common Rules base object draft as a PS
Mar 04  Submit Common Rules GEOPRIV object draft as a PS
Apr 04  Submit DHCP Civil draft as a PS
Jun 04  Initial Geo-tag/Geo-Header draft
Jun 04  Initial HTTP using protocol draft
Jun 04  Initial SIP using protocol draft
Jul 04  Initial Using protocol guideline
Nov 04  Submit Geo-tag/Geo-Header draft as a PS
Nov 04  Submit HTTP using protocol draft as a PS
Nov 04  Submit SIP using protocol draft as a PS
Nov 04  Submit Using protocol guidelines draft as a BCP
Nov 04  Conclude working group

Internet-Drafts:

  • draft-ietf-geopriv-dhcp-civil-04.txt
  • draft-ietf-geopriv-policy-04.txt
  • draft-ietf-geopriv-pidf-lo-03.txt
  • draft-ietf-geopriv-pres-02.txt
  • draft-ietf-geopriv-common-policy-03.txt
  • draft-ietf-geopriv-radius-lo-01.txt

    Request For Comments:

    RFCStatusTitle
    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
    GEOPRIV-minutes-IETF61 GEOPRIV Meeting notes for IETF61

    Wednesday, November 10 at 1300-1500
    ====================================

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

    Scribe: Brian Rosen

    Agenda:

    1. Agenda Bashing
    Agenda was accepted as proposed

    2. Working Group Document Status
    a. Status of documents sent to the IESG/RFC Editor
        draft-ietf-geopriv-pidf-lo approved by IESG (IANA actions completed)
        draft-ietf-geopriv-pres approved by IESG as informational

    b. Status of documents in the working group.
    -draft-ietf-geopriv-dhcp-civil-04
    WGLC ended on 11/3

    c. Solicitation of documents in working group last call.
    -draft-ietf-geopriv-common-policy-03
    In WGLC until Nov 22

    One comment was received from the floor: it was suggested that the document would be easier to read if its many acronyms were replaced with full meanings.  Henning agreed.

    d. Status of related documents
    -draft-guenther-geopriv-policy-caps-01

    The chairs asked if it was the intent of the authors to make this a working group item.  After some discussion and explanation by Jonathan Rosenberg on its relation to SIMPLE, Hannes Tschofenig signified that the authors of the draft would seek adoption by the working group at a future date.

    e. Status of related groups
    -Emergency Context Resolution with Internet Technologies (ECRIT).
    Jon Peterson explained the purpose of the ECRIT BoF and its relationship with GEOPRIV and urged meeting participants to attend.

    3. Milestone Discussion
    Andy Newton suggested the following new milestones for the group:
      Submit draft-ietf-geopriv-policy as proposed standard in Jan., 2005
      Submit draft-ietf-geopriv-radius as proposed standard in Feb., 2005
      Confer with SIP WG on SIP using protocol draft as proposed standard in Feb., 2005
      Close WG with final meeting at IETF 62 in Mar., 2005

    Brian Rosen alerted the group of the intentions of NENA to submit a requirements document for extensions to PDIF-LO, and that such a document would need a working group.  The intent is to have a requirements draft by March, 2005.

    4. Discussion of Geospatial Location issues in
    draft-ietf-geopriv-policy-04

    The chairs expressed concern that the IETF does not have enough experience in geospatial location to provide adequate peer review of
    the geospatial location algorithms in draft-ietf-geopriv-policy.  They suggest getting at least two known experts to provide written review or modify the document to use a pre-existing established standard.

    Henning Schulzrinne gave a presentation on how to simplify the geospatial location treating altitude as a separate coordinate.  The room then discussed the complexity issues involved with geospatial location and 3D coordinates.  It was suggested that geospatial and civil coordinates could be combined to provide the necessary detail.  However, many in the room believed that the geospatial location needed an altitude, and many expressed that civil coordinates are often too vague for some purposes.

    After discussion, the chairs requested a hum on the issue.  The chairs asked the room to provide hums on three proposals: 1) to drop altitude entirely, 2) decouple altitude from x,y, or 3) leave the geospatial location in the document as is [all 3 coordinates].  The consensus of the room was to keep altitude but decouple it.

    5. Discussion of draft-ietf-geopriv-radius-lo-01
    Hannes Tschofeniq gave a presentation on the newly combined radius drafts.  This version is updated to match PIDF-LO fields, splits policy into basic rules which MUST be implemented and extended rules which SHOULD be implemented, and provides a "note-well" URI.  The extended ruleset is also a reference due to space limitation in RADIUS.  And the location type list re-uses values from RPID.

    The room then discussed whether the target of the location was the user or some other related network element.  Many were concerned with privacy implications while others stated they were attempting to address requirements for accounting and taxation.  The chairs noted that this issue could not be solved in the meeting and discussions of it needed to be taken to the working group mailing list.  They asked Hannes to bring this issue to the list.

    The chairs also instructed the authors to separate the IANA registry for location types into a separate document.

    6. Any Other Business

    Henning Schulzrinne started a discussion on non-interoperability of results in PIDF-LO due to too much flexibility in GML.  It was suggested that a small BCP draft could be written to fix the problem.  It was also suggested that the problem could be fixed Authors-48 period of PIDF-LO before it becomes an RFC.  The chairs and AD expressed concern and suggested the scope of change needed to be known before such an action could even be considered.

    Slides

    None received.