Geographic Location / Privacy Working Group
1930 Monday

Reported by Pete McCann <mccap@lucent.com>.
(Reviewed by Randall Gellens, who added material from his Jabber text conference notes.)

Agenda Bashing
draft-cuellar-geopriv-scenarios-01.txt
(Morris)
Key questions:
    problems, issues with draft?
    Other important scenarios needed in the draft?
    Adopt as WG draft (with edits)?

draft-ietf-geopriv-reqs-01.txt
(Cuellar)
30 minutes
open issues that are not protocol open issues
    any requirements missing from draft?
    ready for WG last call?


Morris
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
    push/pull
    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?
(silence)
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


Requirements
Cuellar
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 locations
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 implement?
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 phone.
(direction=N, speed=0) is not a burden.
Henning: don't want to send info that gets compressed away because it's not useful.
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 requested
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 information?
NO
Is there a provision to specify transforms to introduce errors?
NO
These are non-requirements.  We don't need to talk about them.

Morris: will be scenarios where I am thinking about going to a location,
not that this is where I am.
Henning: would have to be bigger context (legal requirements, contracts)

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 people
propose things, we should capture as many good insights as we have in the document.
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?
Yes.

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 geopriv-reqs?
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


draft-morris-geopriv-core-00.txt
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 reduced
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 difference.
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 preference
Morris: yes, one of problems with P3P is that it can only set privacy preferences
about information that is definable by URI.  But they will change that soon.
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.

Threats
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

Countermeasures

Fair Information Practices
Seven principles

Questions?

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 divulged?
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 requirements
for now.  Need to be kept as simple as possible.
JM: Users prefer to have entities destroy info quickly, not retain for queries.
Cuellar: In core document is proposal for flag on redistribution.
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 openness...you 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
draft-polk-geopriv-loc-object-semantics-00

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:  draft-polk-dhcp-geo-loc-option-00.txt
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" point
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 part.
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 fields).
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 location.
JP: so simple mapping software is unacceptable, you need this raw in the packet
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 jurisdiction

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 values
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.
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 terminology?
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.