Last Modified: 2003-10-20
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.
| 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 |
Meeting Minutes of the Geographic Location/Privacy (GEOPRIV) Working Group ----------------------------------------- Monday, November 10, 2003, 1930-2200 Chairs: Allison Mankin Randall Gellens Andrew Newton Scribe: 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 draft-peterson-geopriv-pidf-lo 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 draft-ietf-geopriv-policy. 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 Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/g |