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.
| 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 |
Current Meeting Report
Minutes of Geopriv, IETF 52
Minute-taker: John Noerenberg
-----
Many thanks to John Noerenberg for his superb notes.
The chairs made but a few edits.
Intro
Geopriv met on 9am Monday, December 10, 2001. Chairs Allison Mankin and Randy Gellens conducted the meeting. There was no initial agenda bashing, but as the meeting proceeded, the agenda took a beating anyway.
(Chairs's note: The IETF Way...)
Documents discussed in the meeting:
draft-morris-geopriv-scenarios-00.txt
draft-gellens-geopriv-obj-req-00.txt
Charter discussion
Allison briefly noted that milestone dates need revision. There were no suggestions made for more appropriate dates.
Scenarios
Carl Reed from the Open GIS Forum http://www.opengis.org/ gave a brief presentation outlining the work conducted by the Forum to foster development of protocols to incorporate location data into applications.
The Open GIS Forum is a membership organization with over 200 members. One of their goals is to develop a testbed for interoperable location services.
A subgroup of Open GIS, the Location Interoperability Forum (LIF), has written a Mobile Location Protocol (MLP). This work is being done by the Privacy WG of the LIF. It's currently not available to non-members. When John Noerenberg asked if anyone in the room had implemented it, no one responded. (Note-taker's comment: if anyone on the list is implementing it, it would be nice to hear about it). Carl didn't know what it would take to get it published publicly. He promised to investigate further. (Subsequent to the meeting, Kenji Takahashi notified the list where MLP could be found). It is based on http. Carl noted that much of the work of the Privacy WG overlaps what Geopriv is attempting. One of their significant influences has been the "Fair Information Practices Guideline" published by the Information Industry Association. More about that can be found at <http://www.infolit.org/members/iia.htm>.
Carl ended his presentation with a short discussion about how LIF has defined different privacy scenarios. They have broken this down into a number of cases. More complete discussion is in the document. However, it is not publicly available.
John Morris was then invited to discuss his scenarios draft. This provoked a discussion that occupied nearly all of the remainder of the meeting. There was a brief discussion at the end of the meeting of a requirement document for a location object. Most of the notes that follow are from the discussion provoked by John's document. Notes on the discussion of Randy's proposal conclude these minutes.
John's draft attempts to characterize the privacy considerations in the creation and use of location information by defining three entities that produce or consume location information. It enumerates the possible relationships between the entities. The relationships are termed "scenarios." The draft goes on to makes some observations about the privacy considerations for different scenarios. During the meeting he used a figure from his draft to explain his terminology.
This sparked comments from Brian Rosen that he fundamentally disagreed with the entities defined in the draft, leading him to question how these relationships advance the understanding the WG needs to proceed in defining location objects and protocols. Co-chair Allison Mankin interjected it was important to create the WG's lexicon. Brian agreed this was necessary. Co-chair Randy Gellens added the Morris draft is a first cut at defining terms.
Brian expanded on his objections noting the Morris draft presupposes definitions for basic terms that must be defined. Once basic terms are defined then relationships can be explored. The Chairs cautioned the group against attempting to make a too-specific definition of "location." For the purposes of this group, the location object is largely opaque.
This prompted Christian Huitema to question the opacity of a "location object". If it is truly opaque, in what way does it differ from any other information considered to be private? If there is no difference, it follows that geopriv would be defining rules for the use of any private information. He concluded this was far too broad. Unless there was a means of distinguishing location information for which privacy implications are different than for other kinds of information, geopriv could not succeed.
Henning Schulzrinne agreed with Christian's assessment adding that LIF documents do contain definitions that would be relevant.
Rohan Mahy expanded on this idea by giving examples of how location may be defined. He offered that it could either be characterized as descriptive ("7th floor, Rm 711, Grand America Hotel, Salt Lake City Utah") or coordinates in space (lat, long, altitude). He observed that both have utility depending on the application. The WG should deal with both forms, noting that location based on coordinate systems would likely be easier to describe and implement. However, ease of implementation doesn't detract from the importance of descriptive location methods.
John Noerenberg suggested we concentrate on coordinate location systems because they are more accessible. However, others commented this may be too simplistic. Brian reiterated we should pick something so we can advance. Insisting the location object is opaque is getting in the way of settling on terminology, because we must know some things about the structure of the location object in order to define operators on the object specific to managing location privacy.
Brian went on to ask whether services that transform or translate the data are within the scope of our discussion. He believes they are. Kenji Takahashi suggested that calculation engines are included among the translators. He noted that DTPS is a position calculation scheme that uses a 3rd party to assist the calculation and this has privacy implications.
Rohan Mahy returned to the idea of examining use scenarios and prioritizing them. This might enable the group to tease out the privacy problems and articulate them so they can be addressed. There was a general murmur of agreement in the room.
James Polk asked if the WG had a clear idea where it was headed. The Chairs responded, Randy saying, the first step is to establish the simplest tasks we can accomplish. Allison added our overall goal is to define how maintenance of privacy mediates access to location. James asked has the WG determined how the requestor validates himself to the owner of the data. The requestor may be seeking the data and needing to transform it for its use. The hum amongst attendees is this is something which much be determined, but it's too early to require specific schemes. Moreover, Allison asserted that translation is out of scope for the group, in the sense that it is not in our charter.
James Morris resumed to the question, "How does location data differ in import than other kinds of personal data?" He noted that perhaps the mobile device's capability is partly what sets location data apart. Henning noted this refers back to our earlier discussion, and Christian's point that if there is no distinction, geopriv is attacking a problem of much broader scope than intended in our charter. Brian agrees a more specific description of how location data is unique is needed.
Andrew MacGregor disagreed with Allison's assertion that translators are out of scope. For example, if a 3rd party performs translation, the access required raises privacy issues. The privacy policy would control whether a translation is possible. Rohan amplified this point saying that high level privacy policy for coordinate systems is complex. How the privacy policy is expressed will affect how representations are chosen. Thus, the specifics of the policy will drive the need for transformations. Carl Reed added that OpenGIS has struggled with this same issue.
This exchange prompted John Wroclawski to echo the point that without a definition of location, a protocol operating on location objects can't be defined. Rohan observed that four personal drafts the WG is considering adopting have unique definitions of location. Allison reminded the group it needs to concentrate on privacy issues affecting the use of location data, not the a detailed description of location coordinates. John Wroclawski responded that spatial coordinates are not the only useful representation of location. Different representation will affect the semantics of privacy policy. Henning agreed that a quantitative representation of location does require some understanding, hence specification, of the location representation. Hilarie Orman asked why is this not a generic privacy discussion, if location representation doesn't have unique aspects? Allison responded the WG believes location data has unique attributes. However, we haven't identified what those attributes are. Jonathan Rosenberg recommended that an abstract model of location would be helpful. An abstract model would permit the definition of privacy operators. He cited RFC2779 as an example of an abstract model. Someone familiar with P3P work within W3C noted they have also developed a location model.
Having thoroughly exhausted the possibilities for controversy in the Morris scenarios, we moved on to Randy's object requirements. Randy introduced his draft saying it is a first attempt at object requirements. John Noerenberg recalled Rohan's observation that each of the drafts offered to the WG had different definitions of location. He suggested they be enumerated and compared.
Rohan began describing them. He then asked if it was reasonable to consider different families of location definitions. Further, are the privacy requirements for each family different? There were differing opinions. Brian Rosen noted that while the answer wasn't clear as yet, he didn't believe there would be differences. John Wroclawski, on the other hand, observed that location defined by geometric coordinates imply a measurement within some precision, while the accuracy of a descriptive location specification can't be evaluated the same way. Rohan Mahey agreed with John's assessment. Henning suggested a possible privacy operator would be truncation of geometric coordinates. Jonathan Rosenberg cautioned the group about getting too specific at this stage, suggesting we should just assume they are different and proceed along those lines. The last question Rohan posed to the group is which location description, geometric or descriptive, should be treated first?
Brian encouraged that we pursue both.
Our time expired at this point. The meeting adjourned, and thus my minutes end.
Slides
None received.