2.1.5 Geographic Location/Privacy (geopriv)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-20

Allison Mankin <mankin@psg.com>
Randall Gellens <rg+ietf@qualcomm.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.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.


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-03.txt
  • - draft-danley-geopriv-threat-analysis-00.txt
  • - draft-ietf-geopriv-dhcp-lo-option-00.txt
  • - draft-ietf-geopriv-threat-analysis-00.txt
  • No Request For Comments

    Current Meeting Report

    Minute Taker: Hannes Tschofenig
    Chairs: Randall Gellens, Allison Mankin
    Agenda Bashing
    Requirements document will be simplified a bit more (but has been quite a 
    bit already)
    Location object not ready for last call
    a number of non-working group documents to be discussed some to be 
    brought into working group.
    geopriv core as a way into
    geopriv using document
    Document status - Chairs - 5 mins -
      Make sure you have read:
    (also on our charter, but not refreshed, documents on http and html)
    Requirements draft (Jorge Cuellar)
    Brief review of WGLC changes on requirements document
    Two new authors
    New names for domain entities of the protocol; new abbreviations
    The new terms are described on the slide
    Henning Schulzrinne: The entities are logical entities.
    Jorge Cuellar: True. They might be co-located. 
    James Kempf:  Authorization is done at the Location Server
    Jorge: yes
    Q: The work is more general - there is not necessarily a 
    server-client architecture. (location intermediary)
    Henning: Some people would like to get rid of the term server
    Randall Gellens: Are the terms confusing as defined in the document?
    Henning: Less loaded term wouldn't hurt
    Jon Peterson: The term server is the only term that is not changed from the 
    previous version of the draft. It is perhaps not worth changing 
    anything anymore.
    James Polk:  The server is actually the controller. The server is the 
    appropriate term here
    Comment: This draft has greatly improved. It looks good as it is.
    Jorge: A peer-to-peer scenario does not contradict this notation here
    Several: The LS is applying most rules, and particularly filtering the 
    location information, but In the minimum requirements the Location 
    Recipient is processing also some rules (do not distribute, do not store 
    longer than ..)
    Geopriv/DHC Option (James Polk)
    - Original format proposed was presented
    - Suggestion that a datum has to be included. 3 are currently 
    - A main open issue: Based on the terms in the current requirements 
    document, DHCP may be seen not as an using protocol, but as a protocol that 
    acts before geopriv.  Thus the location information passed here is not a LO, 
    but a "LCI (location configuration information)".  Seen in this way, DHCP is 
    only gathering the location information to be used by the LG.
    Q: Is LCI an object conveying location information.
    A: Yes, but it does not contain security and policy information
    There is some confusion about the DHCP information and the location 
    object definition in the requirements document
    Henning: It might be helpful to indicate that this is not part of 
    geopriv.  Unlike the other information where the info is available to the 
    entity - they just happen to be at two different physical entities. There 
    just need to be twodifferent definitions
    Ted Hardie: Privacy and security requirements in the two cases are 
    different It might be valuable to explicitly state which are the privacy and 
    security requirements in each case
    Jon: Jorge's picture describes where the geopriv object moves. It should 
    additionally be specified where the Location Generator obtains the 
    necessary information about the location information. It might be good for 
    the scenario
    Henning: LCI ("Location Configuration Information") term should be 
    defined outside the DHCP draft since it is a useful concept
    Allison: We should add it to the scenarios draft. Additionally we need to 
    add the security and privacy issues that Ted has mentioned
    Henning: I also submitted a similar draft, but providing civil location 
    information via DHCP (instead of geo-location). It is easier to 
    generate this type of information. A street address conveys more the type of 
    location that people usually think of. It is useful (from security and 
    privacy perspective, and also for performance and simpler 
    functionality) to provide this information instead of using a 
    translator (which could translate geo-location information to civil 
    location information).
    Jon: This sounds like a good idea
    Jon: Who should do the conversion you just mentioned?
    Henning: The database to do the conversion is large - there are only a few 
    companies doing this. The server could this do internally 
    (theoretically) but in reality you don't want to do this by yourself. You 
    don't want to keep track of all street changes.  This type of 
    translation service may be expensive if you want to be always 
    Henning: Hum on the DHCP draft?
    Ted: Seems ok. The charter covers the draft of DHCP that James = 
    presented, this topic is not far from that one
    Threat Analysis (Jon Peterson)
    This work is done. We could do a WG last call
    Randall gave Jon comments (on paper) during the presentation
    Presence as a using protocol (Jon Peterson):
    Presentation about draft-peterson-geopriv-pres-00
    Describes what a using protocol is and how it is location 
    information can be used in presence protocols
    There is some similarity between presence and geopriv.
    RFC2778/RFC779 defined a framework for presence
    Presence is not the only way how location information can be 
    distributed.  Emergency calls are another example where you simply 
    provide location information to the desired entity
    Hence presence is only one example of using geopriv but not the only one 
    MIME/XML based data format: PIDF 
    (draft-ietf-impp-pidf-0x) This exact work has been done before. Hence it 
    would be good to reuse it instead of reinventing it
    Henning: The presence itself is a delivery mechanism. We should not be 
    mislead by the presentation where presence is usually used
    Jonathan Rosenberg: Rule stuff is the hardest stuff. Simple and sipping 
    working group is discussing these issues.
    James Kempf: Take a look at the Japanese Phone system.
    Jon: Jorge mentioned this usage already (codeword, token, password)
    Allison: Identifiers can be pseudonymous for the presence 
    Jon: I gave a link to a presence URI. It is very easy to get opaque URIs
    Jonathan: The principle application of anonymous URIs (proposed in SIP).  
    Call centers offer some examples where this is useful. Identity 
    independent SIP URIs. This is a private draft
    Allison: These things should be made more explicit
    Henning: Publication: Notion of an anonymous contact address. Usually all 
    have a user@domain characteristic. Hence there are no random numbers and 
    globally unique.  Hence there is a pseudonym and a domain name
    Jon: How many people think that this work is useful for geopriv WG?
    Randall: Work on security and policy (location object) has to be done
    Jon: There can be parallell activities: Work on security and policies at the 
    same time of working on an using protocol
    Allison: Area directors should decide whether this should become a 
    working group document if the IESG agrees to expand the charter
    Ted: Hum?
    Group: Acceptance
    Geopriv Elements & Fields (John Morris)
    Description what requirements document says about specific fields. Some of 
    them are optional.
    Henning: Optional might mean
    a) default value assumed
    b) not defined
    John Morris: needs to be defined
    Limited privacy rules: 
    Two different groups of rules
    Henning: A little bit confused about the human-readable rule.  This 
    causes a number of problems (e.g. internationalization problem)
    John Morris: I am not pushing this requirement or the wording. That 
    language came from discussion with others. It needs to be discussed 
    Randall: I had the same concern with the document
    John Morris: Instead of saying that some rules are only machine 
    readable, we may want to say that some rules are never presented to a 
    human, those rules are passed only between two servers
    Randall: It is appropriate to have rules to an end user. These rules do not 
    need to be formatted as human readable within the LO, but made readable 
    when presented to the human
    Jonathan: This is only about information rendering. It is misguided to 
    include any display information. This is a separate problem
    Henning: Different formulation: Specify information by value or 
    John Morris: Some rules are too complex to have it specified in the 
    location object. In this case there should be a external reference to 
    these rules then if they are not included. 
    Henning: If you cannot express all exceptions then you might want to 
    include additional things. (Because you don't want to encode all human 
    In that case however, you cannot sue someone
    Ted: How can I configure my device based on these rules?  Henning should 
    send text to the list
    John: We need these issues soon
    General discussion of protocols - Chairs and AD - up to 30 mins
    Randall: What should be included in the location object and what 
    Henning: Doing the easy things first. Make it extensible. Not delaying 
    everything until the tough problems are solved
    Jon: would like to make a first proposal (based on PIDF from IMPP)
    Allison: Do they contain security?
    Jon: yes as part of smime. more advanced stuff can be done at the XML 
    Randall: Who is going to work on a geopriv location object? Please send 
    your names to Allison and Randall.  


    Geopriv Elements & Fields
    Geopriv-Related Requirements