Current Meeting Report
Jabber Logs

2.1.4 Geographic Location/Privacy (geopriv)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 06/24/2002

A. Mankin <>
Randall Gellens <>
Applications Area Director(s):
Ned Freed <>
Patrik Faltstrom <>
Applications Area Advisor:
Ned Freed <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe
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-00.txt
  • No Request For Comments

    Current Meeting Report

    Geographic Location / Privacy Working Group
    1930 Monday
    Reported by Pete McCann <>.
    (Reviewed by Randall Gellens, who added material from his Jabber text 
    conference notes.)
    Agenda Bashing
    Key questions:
        problems, issues with draft?
        Other important scenarios needed in the draft?
        Adopt as WG draft (with edits)?
    30 minutes
    open issues that are not protocol open issues
        any requirements missing from draft?
        ready for WG last call?
    Was going to do lots of slides, but broke his arm instead.
    This draft outlines a few use cases and message diagrams.
    Not intended to be comprehensive; rather, is a cross-section
    Is very incomplete, we will try to make it more complete
    3 different classes according to
        origin of location site
        different overlapping of geopriv roles
          sighter/server in same or different entities
    Interested in any scenarios that are significantly different from what's 
    there that we can add to.
    Allison: does anyone have a scenario they would like to see?
    Morris: we will take another crack at it, we'll work on it
    Allison: have to ask AD if he is agreeable about charter, but how does 
    group feel about working group item?
    floor: goal?
    Allison: Informational
    Hum indicates mildly positive response, no opposition hum
    Patrick Fallstrom: you will come back explicitly?
    Alison: yes.  We have a milestone related to this, but we will ask
    PF: want to make 100% sure you will ask
    Key Issues that are not protocol open issues
    Any requirements missing from draft?
    Ready for WGLC?
    All important issues are either closed or out of scope.
    Issue 25: Emergency Call Authentication (a) closed
    Requirement 14.3:
    The protocol SHOULD allow a bypass if auth fails in an emergency call
    Issue 25 (b) Open
    Even if the telephone has not logged in, it should still be possible to 
    make emergency calls/pass location information
    If user may not authenticate itself, whose policy to use?
    Cuellar: Use default policy
    Comment: Always going to be these issues. There is only so much that can be 
    done. We don't need to worry so much about it.
    Cuellar: Going over issues in order of importance:
        A: can only send location to emergency center
    But what if emergency center is not authenticable?
        Don't know this is really a problem
    Henning: realistically, this is no different than picking up a pay phone, 
    you hope when you call 911 you are talking to a real center, not some 
    mafia outfit.
    So this is not an open issue?
    Henning: what else are you going to do?  Not make the call?
    Issue 13: LO fields: closed
    MUST Implement in location object:
        target ID
        Location recipient ID
          (may be Mcast or group ID)
        Location recipient creds
        Proof-of-possession of the creds
        (One or more) Location fields each containing one or more Location
    Representations, which can be in different formats
    Issue 15: Out of scope: for privacy reasons, there is no need for 
    multiple locations
    Allison: so far, we said it was a protocol matter, we would have to do it 
    when we get to the protocol definition
    Fair statement, for privacy reasons there is no reason to have multiple 
    Henning: Still a little fuzzy about what you mean by target ID.  Could be 
    all kinds of things: SIP ID, IP address, email address.  Any 
    requirement for what a target ID has to do?
    Cuellar: will talk about domain space of IDs in a minute
    John: Still continues to be value in having multiple locations, but those 
    multiple values could be separate geopriv objects.  Reasons to put them in 
    the same object aren't compelling enough
    mic: req #2: "Eventually optional" list 2.1 - 2.14.  But first 5 
    (2.1-2.5) are mandatory?  Rest of the list is also mandatory to 
    Cuellar: understanding is yet.
    mic: don't ever remember discussion that this was mandatory to 
    implement.  From a desk phone, clearly not a field you have or need
    Cuellar: senders don't have to implement something they aren't using
    mic: but motion vectors...
    Henning: mandatory to implement is too fuzzy.  Can mean, "I don't crash if I 
    get it", can mean, "I generate it", can mean, "I do something with it".  For a 
    particular application, might be meaningless.  Mandatory to implement 
    should be things that are externally observable bits on the wire.  As for 
    features which are only visible in the application sense, don't see how we 
    can test this feature.  Should not be in protocol requirements.
    Rohan: if direction and speed are mandatory, doesn't seem a burden for desk 
    (direction=N, speed=0) is not a burden.
    Henning: don't want to send info that gets compressed away because it's not 
    Randy: this topic is a bit of a rathole, let's move forward
    Cuellar: bring it to mailing list
    Allison: when we do WGLC, you'll find that actual object contents aren't 
    there yet.
    Just trying to finish requirements
    mic: generally agree, but have never read an e-mail or discussion.
    Allison: are you reading hte right document?  WGLC would be the right 
    place to object
    mic: page 15, requirement 2, must support eventually optional
    Henning: text can be fixed
    Additional LO fields
    6 Location Data types
    7 motionand direction vectors
    8 Timing info
          When was LI accurate?  (sighting time)
          Until when considered current? (TTL)
    9 Policy field  (see also issue 17)
          MAY be a pointer, e.g., an URI
    10 Security
    11 Version number
    Issue 17: (Limited) Policy language or Core Set (closed)
    Do we want to define a simple policy language?
    Yes, but it may be very simple.
    MAY be simply: delete-by date
    In the draft replace some text
    Issue 29: Full Policy: out of scope
    Do we want to define a full policy language?
    Perhaps, but it is completely outside of scope how policies are 
    managed, how a location server has access to the privacy policies, etc.
    Issue 15: Multiple Locations Issue
    Out of scope, we already talked about it
    Allison: to clarify, when we define location object, these things
    will come back in scope.  We want to finish requirements document and move on 
    to protocol.
    Issue 8b: Accuracy Flag (closed)
    It is not useful to provide an accuracy attribute in object, i.e., a flag 
    saying "I'm not telling you the whole truth"
    But: if the LO is used for requesting a position, an accuracy level may be 
    This is an open protocol issue, out of scope for this document.
    mic: want to say something about time at which?
    Cuellar: has nothing to do with time, just +/- 1cm, 1000meters, etc.
    mic: if you have a vector, direction, speed.  If you have a timeframe for 
    which it is accurate, you know when that info is interesting.
    Issue 20: Who defines the Identities (ID mngt) Out of scope
    See draft section 9.7
    If we have a big enough namespace, perhaps we can take pseudonyms from it
    Otherwise, may need to extend it
    Issue 16: Full Integrity Issue: Closed
    Is there a provision in the protocol to prohibit the users to send false 
    Is there a provision to specify transforms to introduce errors?
    These are non-requirements.  We don't need to talk about them.
    Morris: will be scenarios where I am thinking about going to a 
    not that this is where I am.
    Henning: would have to be bigger context (legal requirements, 
    Issue 27: single packet exchange: out of scope
    Tracking a small object has several implications:
    1. small device
    2. delta format
    3. the geopriv protocol needs to be at most a single packet exchange
    Only 2 is now a requirement, but all should be possible
    Allison: since you've got the delta format... where there is a 
    requirement and it's not hard for us, do we need them here?  This 
    document is privacy and security requirement, and some protocol 
    requirements, but in some cases we don't know the shape of the protocol 
    well enough.  We could put it here, it's not binding on us.
    Cuellar: Personal opinion is we'll use XML.
    mic: we need this requirement to avoid people thinking geopriv can't meet 
    their needs.
    Henning: there are applications that are one-way only, don't want people 
    saying geopriv is not applicable because it requires two-way.
    Allison: some protocol requirements are not here because we don't 
    understand them well enough, but putting this here is not going to hurt 
    because it is not a contract signed in blood
    mic: it's not a requirement, because it isn't going to break if you don't do 
    it that way.  Therefore you shouldn't put this here.
    Jorge: problem with this requirement: we're going to define object and that 
    it can move from place to place
    mic: maybe should say the protocol should support this, but it's not the 
    only way to do things
    Allison: use some weasel words
    Henning: value is to capture discussion that has taken place.  When 
    propose things, we should capture as many good insights as we have in the 
    Jorge: ok, this is captured in the appendix anyway.
    Issues 18, 19: Generic Policies (used by LoSi, used by ULR)
    Issue 28: Multicast Issue
    Can we include the object in multicast protocol?
    Issues 21, 22: Group or role identifiers: out of scope like 
    "administrator", "member-of-club-A", etc
    Also with context dependent meaning?
    Group or role IDs are probably not somehow explciitly supported
    Allison: need to wrap up
    WGLC allows you to say you don't like some text
    Can we take this document to WGLC on the mailing list?  Hum for WGLC of 
    Hums indicate positive response, no objections.
    Allison: OK, we're ready for WG last call on Req document. Now we can 
    progress towards protocol work.
    Going to do a discussion on protocol work in the rest of meeting
    Instruction set of the privacy object
    Then threat analysis, then location object itself
    John Morris: draft-morris-geopriv-core... came out of discussions on 
    Requirements draft. We rejected the approach that no rules go in the 
    object, and also that all rules go in. Issue is do we have maybe 1 or 2, or 
    do we have 3-5 or what?
    John Morris: Jon Peterson was concerned with as many as 7 rules being 
    included or being needed.
    Entirely external
        Only a reference to external privacy rules
    Bare Bones Internal
        at most one or two rules (such as retention duration)
    Limited Internal
        A limited set of 4 to 7 rules
    Full Internal
        a full, robust set of privacy rules
    Limited Internal Proposal
    laid out by the draft
    A. Limitation on length of data retention
    B. Limitation on any retransmission or further disclosure
    C. Permission to disclose only to specified individual entity
    D. Permission to disclose only to someone presenting a specified key or a 
    special type of cred
    E. Requirement that location granularity precision of location info be 
    F. Requirement that external privacy rules be followed
    G. Instruction that location be transmitted to specified external URI with 
    specified instruction
    Back of Napkin Modification
      From Location Sighter to Location Server
        only A, B, F (human readable rules in 2 forms)
      From Location Server to Location Server
        A, B, F plus C-E (machine readable rules)
      From Location Server to Ultimate Location Recipient
        only A, B, F (human readable rules in 2 forms)
    G is a requirement but not a "privacy rule"
    Henning: basic question: if I were to replace location with some other sort 
    of personal data, have you looked at which of these requirements were 
    motivated by privacy preferences in W3C?  Typing it in vs GPS makes no 
    Morris: P3P early proposals may have contained this.  Now the spec is very 
    content-server centric.  Need for user-expressible control language (not 
    machine to machine).  Not clear W3C is the right place to do it.
    Henning: may want to have a bit of flexibility in expressing 
    Morris: yes, one of problems with P3P is that it can only set privacy 
    about information that is definable by URI.  But they will change that 
    Henning: not sure document says that, would be helpful to give 
    motivation & relationship to P3P up front.
    Morris: ok, will write separate draft
    Allison: One of questions on Morris document: what is it?  It is not 
    intended to be a WG document.  Just a help to feed into the protocol 
    document.  Threats document is one of our deliverables.
    Michele Danley
    Threats Document
    You can read the draft
    This is different from most other threats documents because of context 
    joint with john morris, john peterson, ..., would be interesting to 
    document all of threats that come up with location information.  Some 
    threats may not have technical solutions.
    1. Protocol Attacks
    2. Host attacks
          Location info is all stored in one place.
          Log of location info may be more useful
    3. Usage attacks
          How users might use geopriv
    Fair Information Practices
    Seven principles
    Allison: comments on document?
    Randy: anybody read the draft?
    Allison: this WG has been a little different all along, as 
    privacy/use threats are different.  Written in a very careful way.
    Rick: general question: is there any capability for feedback?  In US we 
    have FOIA.
    Is there any capability within requirements to get info on who has seen me 
    and to whom information has been divulged?
    John Morris: it's out of scope.  We will have a hard enough time dealing 
    with retention.  It is not going to be very comfortable for people to say 
    "destroy after 2 weeks" without articulating what destroy means & 
    defining some way to go back and check.
    Rick: more a point of philosophy about the world in which I wish to live.
    This information should be required.
    JM: geopriv deals with a number of entities (cell carrier) for which I want 
    them to delete this information as quickly as possible.  One problem might be 
    that this requirement imposes him to keep a list of everyone he gave it to.
    Henning: in many cases, information you care about is location + 
    something else
    There is a danger of solving a fairly general problem in a specific way.  
    None of this is really enforceable.
    Rick: is there consensus that there should be no philosophy on the 
    ability of clients to find to whom their location information has been 
    mic: issue of control. 
    mic: Our grandkids will have to live with this protocol.
    Randy: serious rathole issue.  "Our grandkids..." we are not defining the 
    ultimate end requirements for everything.  These are just minimal 
    for now.  Need to be kept as simple as possible.
    JM: Users prefer to have entities destroy info quickly, not retain for 
    Cuellar: In core document is proposal for flag on 
    Cuellar: should be a flag that says notify me when you give away info.
    Don't see any prohibition against putting this into the protocol.
    Michele: we do get at this within the host threats.
    DM: Rules on logging, redistribition, time-to-live
    DM: One of the principles of fair info practices is should be able to know who has info in you.
    Allison: privacy protocols can go into insane 100% intensity.  We will not 
    get to that point in the protocol design.  Michele's document clearly 
    defines threats.  We will get to some of these issues in protocl design.
    mik: Info is sometimes abused. We shouldn't facilitate evil uses.
    Rick: not advocating 100% solution, just want to note that some 
    information is abused.
    Allison: please review the threat document.
    Any more discussion before we take a hum?
    This is in the charter.
    Those in favor of Informational document geopriv-threats please hum...
    Hum is positive, no objections.
    Allison: we have been given custody of some objects from the DHC WG.
    James M. Polk
    Location Object Semantics
    A group went off and wrote two drafts
    Presented one this morning in DHC
    Specific location formats for DHCP.  Geopriv should endorse
    Purpose of ID
    Give semantic intent of the location object described in:  
    Want a root set of location fields in an IP phone.  What is mechanism to get 
    it there?
    DHCP is not a bad way to go about it
    Immediate Practical Use
    Emergency Response for wired-ethernet (IP-phone) infrastructures
    Host needs to know where it is in order to send its location to 
    emergency responder
    Simple method using host configuration protocol.
    Issues for discussion
    Presentation will cover 3 points:
        Use of "resolution" instead of "accuracy"
        Host control (modification) of Resolution
        Domain control of Resolution
    Idea of resolution vs. accuracy
    Accuracy generally describes: I'm within X number of meters from "this" 
    Resolution generally describes: I'm somewhere within a (square, 
    rectangle, trapezoid) of these dimensions
    LO Format
    DHCP option, latitude, longitude, altitude lat/long in degrees
    emergency responders use this format
    Allison: Is that a US thing or worldwide?
    JP: not limited to North America?
    Rick: decimal/ASCII?
    JP: all binary.  Integer.Fraction: 9 bits integer, last 25 are fraction 
    Altitude: 22bits integer, 8 bits fraction
    Allison: how does this fit with object in other protocols, we might need a 
    version number?
    JP: could add it, wasn't thinking about it.
    Randy/Allison: Think about version field to help in mapping with general 
    geopriv object.
    Randy: If we have a logical geopriv object, many protocols will use a 
    textual representation while others (such as DHCP) will need a binary 
    form. A version number in the binary form will help map it to the 
    textual one (which may have an easier time with optional and extension 
    Henning: in general, I'm not always convinced that a version number is 
    particularly useful, especially in protocols that have a way to 
    identify different objects
    Allison: DHC object is a member of a family.  This is a binary form.  May be 
    expressed as something else in other protocols
    Henning: almost want a format identifier that is independent of 
    namespace (DHCP, whatever)
    Allison: right.  Using protocol is sometimes DHCP, sometimes SIP or 
    something else way high up in the stack.
    Randy: something to think about
    mic: this is folded into 32 bit format, other than first 2 bytes, rest of it 
    is just a raw binary lat/long/altitude
    Allison: doesn't have any of the privacy stuff.  There will need to be 
    other material here.
    JamesPolk: I'm not trying to circumvent your efforts.  Just want to get 
    location to device.
    Allison: you are the first use case
    For emergency response, what do you want?  Is difference from mean low tide 
    really useful?  If this was used for 911, public service access point 
    would get 300 m, vs 310 m, what floor is that?  We decided 
    measurement unit 1 = meters, unit 2 = floors.
    Henning: you are mixing physical and civil descriptions.  Should be 2 
    separate descriptions.
    JP: if PSAP gets altitude of 300 m, where do they go?
    Henning: not disagreeing.  We want two different descriptions of the 
    JP: so simple mapping software is unacceptable, you need this raw in the 
    Henning: I want it both ways.
    JP: PSAP just wants one
    Henning: no, they want both.
    mic: they get phone number, then you look up location.  We will give them 
    lat/long, then they can look it up.  There is no standard way to 
    represent postal addresses.
    Rick: also should provide capability for full addresses
    JP: agree for geopriv, but for DHCP we only want 15 bytes.
    John Peterson: you're going to have to map lat/long into civil address.  We 
    can put the responsibility to lookup altitude in same lookup.
    Rick: simple use case: was out in backcountry, someone had heart attack.
    He died.
    Resolution control by endpoint
    LaRes, LoRes and AltRes are length fields for their corresponding 
    coordinate field.
    White House Example
    resolution can be used to represent minimum precision within a given 
    Resolution control by Domain
    Accomplished by DHC Reply containing xRes values which the endpoint could 
    interpret as the maximum resolution allowed for any location reply
        Perhaps except in Emergency situations where xRes fields are set to max 
    Dave Oran: can't use word "allowed" there is no enforcement mechanism
    Open Issues
    Who owns this effort?
    Allison: Internet Area director in charge of DHC passed it over.  This is 
    now a Geopriv effort. Agreed to by Internet Area AD, PAF, Ned, Allison, and 
    Randy: This is our second use case.
    Allison: Now that we are in WGLC on our requirements document, we're at 
    serious stage of working on protocol.
    JP: Possible open question: accuracy vs. resolution
    Allison: do requirement folks have a problem changing/adding to 
    Henning: have you asked the other bodies who deal in this area?
    Randy: Your definition of "Resolution" matches my understanding of what 
    we've been using "Accuracy" for.
    JP: here within radius is not accuracy as defined in this draft
    Jorge: if say accuracy is going to be the State, or Country, how do we deal 
    with this?  It is not a trapezoid, circle, is a very strange figure
    Randy: this is a terminology question, not a real disagreement
    Allison: open mic for protocol discussion
    Maybe we will shut down and head to the bar
    Henning: interest in representation of civil locations, needed in VoIP 
    context, anyone else interested?
    Rick: nods.
    Allison: WGLC will proceed, we need to discuss our other documents.
    We may need to have another interim meeting.  Location TBD, will be 
    announced on mailing list.  (Lots of bad location jokes).
    Adjournment to the bar is now administratively allowed.


    Requirements Draft Issues
    Core Privacy Policies
    Location Object Semantics