2.1.2 Geographic Location/Privacy (geopriv)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

Allison Mankin <mankin@isi.edu>
Randall Gellens <rg+ietf@qualcomm.com>

Applications Area Director(s):

Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Ned Freed <ned.freed@mrochek.com>

Mailing Lists:

General Discussion:geopriv@mail.apps.ietf.org
To Subscribe: geopriv-request@mail.apps.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.

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:

Jul 01

  

Discuss initial geographic location privacy and security requirements i-d.

Aug 01

  

Discuss initial geographic information object/transport framework i-d.

Aug 01

  

Initial i-d on geographic information protocol design, including privacy and security techniques.

Aug 01

  

Review charter and initial i-ds with AD, and have IESG consider rechartering if necessary.

Sep 01

  

Use initial framework to develop an example location/privacy API that might be used in a 3G handset or other consumer application.

Sep 01

  

Submit security/privacy requirements I-D to IESG for publication as Informational RFC.

Oct 01

  

Use initial framework to restructure drafts on geographic information in HTTP and HTML so that location security and privacy are integral.

Oct 01

  

Submit geographic location/privacy framework to IESG for publication as Informational RFC.

Jan 02

  

Submit geographic location/privacy protocol to IESG for publication in standards track.

Mar 02

  

Conclude working group

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Geopriv WG Meeting Minutes, IETF 51, 9 August 2001

Reported by John Noerenberg

Notetaker's apology: While I attempted to get everyone's name as they spoke at the mike, I guessed at the spelling of many of your names, and missed some of them. Please don't take offense at errors or omissions. They are inadvertant and not intentional.

Geopriv met for an hour 9 August 2001. Co-chair Allison Mankin identified two items for the agenda of the WG's first meeting. We would review the charter, and she would give the people in attendance the opportunity to introduce themselves, and offer comments on how to accomplish the goals laid out for the WG in the charter. Intro slides are at http://www.east.isi.edu/~mankin/GEO51.html. Co-chair Randy Gellens was not able to attend.

There are many IETF WGs and groups outside the IETF who are vitally interested in the privacy implications of location. Allison described the history of the geopriv WG: the ideas for geolocation objects in IETF were explored by the Spatial BOF and mailing list, but the IESG was unable to get the Spatial group to make privacy issues primary in their charter proposal. Therefore the IESG (with the Applications area sponsoring) developed the geopriv WG charter. A key point is that the actual geolocation information structures are not the main contribution to be made by IETF: a number of organizations are devoted to GIS; the geopriv WG will add privacy-supporting networking protocol context to location formats defined outside IETF.

Drafts prepared originally in the context of Spatial are good as sources of input for geopriv, notably by Takahashi et al and Tang et al. Another draft was noted, that by Rosen and Mahy, that needs to be resubmitted to internet- drafts. Two drafts by Daviel on geolocation objects in html and http are on the charter, provided that the drafts are revised to meet privacy and security requirements developed as the WG's first milestone.

Allison then invited attendees at the meeting to offer their thoughts on how the WG should proceed toward its goals. Kenji Takahashi asked if what is developed by geopriv would be protocol independent. Allison and Ned Freed (the Area Director) answered that we anticipate that at least the initial phase of our work will be reviewed by the IESG and IAB for its utility and for its suitability for other applications and protocols. It is not certain a specific over-the-wire protocol would come out of this group. Leslie Daigle pointed out that another working group, IMPP, which she co-chairs, has deferred on location privacy issues because they realized they didn't have the necessary expertise.

Andrew Randall asked if this group was aware of the work by the WAP Forum regarding use of location information, and protocols to manage its use. He was asked if WAP Forum work was freely available to non-members. Andrew answered that once published the specifications were available, but works in progress were not published. Scott Bradner jumped in and noted that the IETF is aware that other standards bodies have different practices than the IETF, and that the IESG and IAB will work assiduously to help WGs avoid obstacles that may arise. We, as well as other standards bodies, realize there is nothing to be gained in duplicating each other's efforts. Meanwhile, he requested that at this early point in the WG's life geopriv postpone concerns regarding these matters. Allison noted that the Open GIS Forum has also been working in this area, and Scott and Allison noted that they are both in touch with the group.

Henning Schulzrinne cautioned the WG that making location information available for use is a critical path item for the wireless telephony industry. For example location information is very important for emergency response systems planned to be made available by wireless carriers. He encouraged the WG to make intermediate results that enable such systems available as early as possible. He warned that if we act too slowly, others would make decisions without the benefit of our expertise.

Angus M??? applauded the inauguration of the WG. He asked if the framework of the protocol would specify when or whether authentication would be required to obtain location information. John Noerenberg noted the answer isn't known, but this is the sort of question that WG is charged with answering.

John Loughney introduced himself as having spent a lot of effort on spatial and the documents it attempted to develop. He reminded geopriv that spatial had considerable difficulty with security and privacy considerations because the group poorly understood the scope of what they were trying to accomplish in this regard. He recommended geopriv conduct a threat analysis in order to focus their work. There was a hum of agreement amongst the attendees.

Echoing the earlier remarks concerning the WAP Forum, Shahid Shoaib noted that 3GPP and 3GPP2 were also working in this area. It would not be good if different standards bodies produced conflicting protocols. That would make establishment of a standard difficult.

Rohan Mahy asked if the Chair was looking for authors and editors for the WG's documents. Allison took this opportunity to ask anyone interested in working on the papers to be produced to contact her after the meeting or send her email (Allison Mankin <mankin@isi.edu>). Rohan identified himself as the author of a spatial requirements draft, recently expired. Allison recommended he resubmit the draft.

Dan Rothman suggested geopriv develop a cross-reference to other organizations and IETF WGs that will be affected by this WG.

Karen Sollins suggested geopriv must be explicit defining location representation, that in her experience the form of the information is entwined with the information. This led to a further discussion about the nature of the work to be produced by geopriv. James Polk, who co-chaired the spatial BOFs, agreed with Karen that geopriv must define the location payload with attendant information defining scope of use and means to prevent unintended disclosure. He felt the WG charter did not make this an explicit work item. ???? asked if geopriv would only define data objects for location. Allison replied, "No." She cited other environments that require both a definition of data objects, as well as the means to transport them. John Noerenberg noted data objects defined in one environment might be used elsewhere, citing MIME in email as a particular example. While the MIME WG concerned itself solely with defining data objects for use within email transport, MIME data objects have found applicability in other contexts. Henning noted protocols must specify both data representation and transport. (Transport is used here in a generic sense, not to mean Layer 4). Ned Freed (as Area Director) reported that as he worked on the charter with the Chairs, he had particular difficulty finding a term naming the protocol elements, or data objects, carried by the protocol. Whatever term is used to describe the information moved by the protocol, he agreed it is essential they be defined. Further, he noted geopriv's protocol elements are likely to be used in protocols where the elements move only in one direction, as well as in protocols where location data objects move bi-directonally. Greg Vaudreil asked if SASL would be a useful framework. Ned replied that was not certain, but that was certainly along the lines to be considered.

Kenji Takahashi observed it was important that geopriv define the location services offered by the protocols it defines. Dave Loren asserted the security requirements for geopriv protocols will not be orthogonal to the data requirements. He gave an example where too-specific knowledge of a party's location could compromise their privacy. There was a murmur of agreement in the meeting as attendees recognized the truth and importance of this remark.

We were nearly out of time for the meeting. Dan Rothman raised the last topic to be discussed. He returned to the scope of the work to be performed by geopriv. He said that the outputs must be defined in order to determine whether peers can interoperably exchange data objects in a geopriv session. Further, IETF rules require there be multiple implementations of peers. Ned, agreeing, noted there are various ways to achieve this. For example, the WG could define several applications that transport geopriv protocol elements. The WG may also define a single protocol that has multiple independent implementations. [Allison's query: is this last note just about multiple implementations or something else that needs expanding.]

With this, our hour was up. Allison thanked everyone for participating, and closed the meeting.

Slides

None received.