Last Modifield: 06/24/2002
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 |
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. |