Subject: draft minutes of geopriv interim meeting

From: Allison Mankin <[email-masked]>
Date: Mon, 24 Jun 2002 12:03:46 -0400

Those who participated should send any corrections to the people cc'd
in the next day or so.   We'll send the participants' list out later
today - it's wandered off somewhere...

Draft Minutes from geopriv WG Interim Meeting

June 5-6, 2002

San Diego, CA
Reported by Aaron Burstein
Samuelson Law, Technology and Public Policy Clinic.

Chairs:
Allison Mankin, USC/ISI
Randall Gellens, Qualcomm

Chairs' Note:
A small number of chair-like edits were made to Aaron's
excellent and detailed notes - many thanks to Aaron for
taking such detailed minutes, much needed for a 1.5 day meeting.

Many thanks too to Qualcomm and John Noerenberg for hosting, 
with excellent facilities and hospitality.

There were both in person and phone bridge attendees.
Viewgraphs were online for the phone attendees.  

Allison and Randy

**********************************************************************
**                                                                  **
**                                                                  **
**                      JUNE 5, 2002                                **
**                                                                  **
**                                                                  **
**********************************************************************

Preliminaries
-------------

There have been no changes to our charter language,
but our dates have been updated.  Notice:

- Jun 02: privacy and security requirements i-d.
- Initial geopriv scenarios and application requirements.

Goal for this interim meeting: to go through privacy and security 
requirements so thoroughly that we feel comfortable with finishing
the draft by Yokohama.

Agenda for June 5, 2002: to discuss issues raised with the most 
recent requirements draft (draft-cuellar-geopriv-reqs-02.txt).

Slides for this are at:

http://www.east.isi.edu/~mankin/geopriv-Interim-Meeting-Issues-2002-06-05-short.ppt

Agenda for June 6, 2002: grounding discussion on protocols that 
will carry the geopriv object, as well as technologies that will 
use the object.

Other goals: a consensus statement on concerns about HTML and HTTP
tags in draft-daviel-html-geo-tag-05.txt.

A new document, draft-gogic-geopriv-concepts-00.txt, explores 
location information concepts and privacy concerns, but was 
submitted to late to be discussed in detail here.  We will try
to identify how it differs from draft-cuellar.

Discussion of the Cuellar-02 Requirement Draft
----------------------------------------------

NOTE: The first day of the meeting tracked the of issues raised 
in Jorge Cuellar's email of June 2, 2002 to the WG mailing list.
The discussion did depart from the exact format of this email, 
in that additional issues were introduced by the chairs and others,
but these departures should be clear from the headings in this 
document.

Issue 1
-------
In the early paragraphs of the draft, "user" is used in an informal
sense. "Rule maker" is what is meant.

Issue 2
-------
A small typo in paragraph 4. "LIF" should read "FLI."

Issue 3
-------
Does the Computational Location Server (CLServ) belong in the draft?
IETF (and geopriv) is not in the business of processing raw location 
information, so why is this mentioned? The charter does not even
speak of computation.

It looks like the actual computation is done at a lower level, 
filtered and passed on in a header, payload, etc.

CLServ may be mentioned in order to set it aside as a 
black box. It belongs in picture of components, but not in 
something geopriv will actually use.

Still, there are privacy concerns in the change from computation 
to distribution. It may be sufficient to require that data shouldn't 
be shipped in plain text. Computation server can use the protocol of 
its own choice to ship data en masse, etc.

Issue 4
-------
This section is ``unnecessarily long.''

This information is relevant to the geopriv object and/or
combined protocol, but is not logically arranged in the draft. 
Overall, the document needs more coherent grouping.

Material in 3.5.1 relevant to protocol and should be kept.

Section 3.4.2 (data flows, scenario 1): acts like closed system, no
interface with the internet at all. Might be useful as background,
but does not have clear application to geopriv, unless the 
information is being sent upstream. 

This is a scenario in which device is self-contained,
and the owner/target requests information to be sent to itself.

Relevance may depend on  whether device only gets and displays 
displays location (such as a handheld GPS device),
or whether part of more general purpose device capable of further 
processing and transmission.

Contrast to using cell phone -- use this scenario as a foil to 
illustrate differences in other uses, aspects of the protocol.

Issue 6
-------
``Initial access provider'': Is it necessarily
the same as a location sighter? E.g. 802.11b signal may be 
provided by an entity distinct from the location sighter.

But then does geopriv come into play? It must, if the user 
does not have a choice of initial access provider. But in 
that case, LoSi = IAP. In the 802.11 case, the IAP would never
get the LI. 

 -> Could say that IAP is a special case of a LoSi.

Back to Issue 4: identity management.
-------------------------------------
Is it necessary to talk about identities, roles? (Section 3.5.2) 
Or is this issue something for a using protocol (IM, SIP) to handle?

There may be many cases in which identities are used for many
purposes, need global ID (IM, SIP), and there are cases when 
the target does not need any identifying information from the 
requester.

For example, the query: ``Where is the nearest Pizza Hut?'' 
Requester contacts 
Pizza Hut server, gives location. The transaction can be
anonymous -- the business target has no
business knowing who is requesting information.

There may be cases where businesses and people may be identified
in the same way.

3.5 is important in getting multiple identification options supported
in geopriv. That should remain even if GUID idea is dropped.

Raises issues of authentication, entity identifier, role identifier,
etc. that can be handled in standard ways. 

A sub-issue: "transport protocol" terminology
--------------------------------------------
``Transport protocol'' may not be the right description for 
what geopriv interfaces with; should refer to whatever is
USING geopriv, for example, the use of geopriv by another 
protocol.

The name "using protocol" may be more accurate.

(End of this sub-issue).

Geopriv must not assume that the relationship
between roles and identities/entities/handles is anything
but m-to-n. Less general assumptions (n-to-1, 1-to-n, 1-to-1)
would not be realizable across geopriv uses.

Suggestion: separate roles from identities.

2 types of identities: well-known and anonymous.
Shall geopriv know of identities? E.g., ``My wife
wants to know where I am.'' Are these identities part of
geopriv or are they part of the using protocol?
Does this mean there is some sort of UID assumed in geopriv?

 - Understand this to mean that geopriv is not aware of any identities
   at all. These are part of the using protocol.

 - May not have ability to express in using protocol.

The identity of requester is a fundamental question. But geopriv
needs to identify simplest possible way to manage identities.

There is also a problem with security associations at different layers.
E.g., in SIP, problem with end-to-end authentication -- dealing with
spam voice calls. At some layers, you know who your peers
are, at others you don't. Thus, suggest using identities 
at an object level, not using protocol level.

Trouble with understanding mapping  of roles and identities:
  A supplement to the discussion immediately
  above.
------------------------------------------------------------
 ---> Switch to "short" slide set. <---
 (Available at 
http://www.east.isi.edu/~mankin/geopriv-Interim-Meeting-2002-06-05-short.ppt)

Either leave it to using protocols to handle identities, or
require that using protocol inherit identity information from 
geopriv.

1st scenario
------------
``Entities, Data Flow'': Client C seeks the location of target T.
LServ reveals this information. C NEEDS to request target T, ie.,
C must specify a target.

Next scenario: 
--------------
Rule Maker makes a policy: C may access certain data type
DT, using identity A_T. E.g., ``My wife may know what part
of the city I'm in, but anyone may know what time zone I'm in.''

C requests A_T, DT(l).

If geopriv will support this for any protocol,
identifiers must be included in geopriv -- for requests, and 
for Rule Maker to supply policy.

Other scenarios that have more general queries: e.g., ``Where are the 
cars in our fleet?''

Old BOF: URI solved this. Ask for the URI of a device. Does
geopriv inherit this URI? Or does this create a location
query protocol?

Is this IETF "presence?" Not necessarily.

An argument for including security in the geopriv object itself:
a geopriv object may traverse many layers that can't be counted 
on to respect security. An object without identity poses security 
problems.

Suppose SIP uses ID; geopriv could recognize  it as a SIP ID
(or a URI or a text field or whatever). This is not simply an
instance of an opaque ID, merely handled by geopriv; geopriv
may DO something to the ID.

How can we put together anonymous identifiers, identifiers, etc.
into a generalizable geopriv representation? May need to begin
with SIP, 802.11 ID, etc. and allow geopriv to anonymize it.

Even in SIP, there is no bright-line identity. Why does 
proliferation of IDs in SIP present a problem in geopriv.

There is no universal way of asserting identity, but there is
a way of saying who is requesting, who is sending.

Proposed closure:
-----------------
 ID must be in the object.

Reaction:
---------
1. There is a difference between REQUIRING and ALLOWING ID 
   to be in the object.
2. There are always 2 IDs: the requestor and the target.
3. Analogy to Pizza Hut: don't want to reveal ID when
   requesting location, no need for target to know
   ID of requestor. In other cases, request and response
   IDs may be known.
4. Why can't I just ask my ISA to locate the nearest 
   Pizza Hut?
5. Very good reasons for staging security in the 
   object may also have application value, e.g. in 
   ensuring that identity specified in the request is
   the identity returned in the response.
6. Don't want to require huge amount of infrastructure
   to pass IDs between consenting parties.
7. Certain cases require identities.
8. C needs to know how to identify T. 
9. Different protocols requesting ID strongly suggests 
   that there should be a generalizable ID structure in 
   geopriv. Geopriv should therefore avoid wholesale importation
   SIP or URL-centric ID.
10. How then to encrypt, authenticate IDs?
11. So there should at least be an option to have 1 or
    more IDs in geopriv.

A new case: 3GPP context. 
-------------------------
Need not only C, T IDs but also 
intermediary ID -- would like to ask brokers for information,
e.g., in foreign countries where you don't know how to request.

This could reduce to dealing with a broker, which makes its
own request in behalf of the requester.

New case: 
---------
C creates (pub key, priv key) and passes to Rule Maker or
T. But C does not know how to address T. T replies that C 
can use A_T for T's identity, and can use pub key P_C to 
identify itself.
This may be useful when C has no security relationship to LS.
T can then tell LS that C can request its information.

This would allow security even if there are eavesdroppers.

Many reasons to hide identities: T doesn't want C to know, 
or C, T not relating in service provider situation in which
they have security relationships with the IAP.

(pub key, priv key) not the only method. Could use Lamport's 
sequence of hashes, 1-time passwords. Also, don't need certificates
(they pose their own privacy problems -- can track owner of the 
certificates. Costly to make privacy-friendly PKI, certificates.
This is a cheaper way of doing the same thing.)

Would this mean eliminating certs between S and LS? No. 
There may be more fixed security associations appropriate to certs.

****************************************
REQUIREMENT
****************************************
 There was agreement that geopriv MUST implement, but not 
 always use, identities. 

 The geopriv Object MUST be able to carry identities, but geopriv
 does not necessarily specify the namespace.
****************************************

Use of identities will be context-specific, depend on 
specification of messaging syntax.

Is there a risk that this will allow some implementations to
prohibit anonymous access?

This should keep geopriv from going into blind alley that 
"anonymous" = "no identity." Pseudonymity is often
useful.

The (un)linkability question: a pseudonym that can be stored 
for a long period of time is different from transaction-duration
pseudonyms.

********************************************************
===> Discussion returned to the main set of slides. <===
********************************************************

Issue 5
-------
Should geopriv talk about location storage ``LStor?'' Isn't
this just a part of LS, location seeker, etc.? Or is it part
of geopriv?

From a privacy standpoint, data storage is crucial. Knowing storage
policy may affect what kind of information is revealed. This may
mean that there has to be some recognition of data retention.

This could be answered if there is an unlinkable ID. Saying
more than this may go beyond the geopriv charter.

It is not only the ID of T that must be concealed, but also 
identity of C, if T's privacy is to be considered.

===> There was a strong feeling that this kind of use of aggregation is 
necessary.

This need not reach HOW data is stored, or some sort of 
enforcement, but just the expression that ``You may not 
have my location if you will store it for more than 2 days.''

A policy  should somehow cover use, disclosure, and 
retention.

All based on RM? Probably.

May need to settle for good enough -- truly unlinkable 
IDs may not be possible.

What is the damage of introducing this to geopriv?

### What is this??

Issue 7
-------
Figure 1 data flows -- discuss later. Delay until scenarios draft
discussion.

Issue 8
-------
Is it necessary to distinguish FLI and LI? NO -- it's all LI.

"Filtering" in this case was meant to mean translation from 
coordinates to e.g., time zone.

But others thought this was a way of manipulating ACCURACY of
location.

Filtering (in the sense of accuracy manipulations) 
may be addressed in Gogic draft. Can think of  it as 
LI lat/long with another attribute associated with it.

Is there a FLI field in the object? Which would allow someone 
to hack the object, see cleartext position information? 

One view -- LS should apply policy (and the requisite imprecision) 
before serving it.

Could handle this in the policy -- person A may know exact 
location, person B may know location +/- 1 km, etc. This is the 
reference to ``data type.'' 

This issue is distinct from the "full integrity" issue (Issue 16,
below), which discusses the introduction of explicit 
errors; obfuscation.

Is there a convenient or useful distinction to be 
maintained between LI and FLI?

The distinction may be useful only to discover the intent in 
degraded location information.

Should inaccuracy be introduced in the LS/proxy, or elsewhere?
This question raised 2 sub-issues: 
  providing (1) filtering vs. (2) providing an accuracy attribute in 
  object, i.e., a flag saying
  "I'm not telling you the whole truth."

Creating levels of vagueness is one way of degrading information;
there are other ways of obfuscation that may be used.

Responses to these sub-issues
-----------------------------
C doesn't need to know that the information has been degraded.
It should just get an answer, preferably in lat/long.

Geopriv should not allow location seeker to know the degree of 
precision specified by the Target.

It is possible to be more vague with string locations rather 
than just lat/long. "North America" may be more vague than an 
inaccurate lat/long.

There was basic agreement that geopriv must allow the target to 
insert vagueness or inaccuracy.

Full Integrity
--------------
But a separate issue was the "full integrity" issue:
Should geopriv permit some form of "obfuscation"? There seemed to 
be a consensus that it would always be possible to mislead as to
one's location; the question was whether geopriv should facilitate
this obfuscation.

This "obfuscation" could take several forms, including (1) a 
deliberately false, but potentially exact, location; or 
(2) a true location mixed in with
a number of false locations; or (3) (2) a position
that is so vague as to reveal no useful information.

(2) could be effected either by including multiple locations within a 
single object, or by providing some attribute in the object to 
link multiple objects together.

Objection:  giving a false location may do damage, whereas a 
vague answer may give safer information. E.g., an assassination
target is in a bus whose location is transported with the locations
of 4 other buses. Potential result: all 5 buses are blown up.

===> But are there risks that are created by multiple queries that 
aren't present if object has multiple representations.

Also, multiple locations in one object may be useful: (1) for other 
obfuscation/cloaking scenarios; (2) to specify location as 
a trigger for certain events, e.g., ``When I'm at Company X,
do Y;'' (3) ``I'm going to be at these 5 locations and 
want to know which one has the closest coffee shop.''

Clarification
-------------
Having multiple REPRESENTATIONS of a device in object is different
from multiple location representation FORMATS. 
But having both creates a multiplication problem -- multiple 
formats with multiple locations could create semantic problems.

Semantics could be left to the using protocol, or the application that
handles geopriv data. More complicated things (like translating 
lat/long into street addresses, etc.) should be left 
to applications.
===> This could create interoperability issues: if a client 
has a private schema, will it need to get LI in this format? 
Will geopriv mandate 3rd party conversion engine.

Is there anything we couldn't do with multiple queries 
that we could do with multiple representations?

But should leave open possibility that application can 
request LI in a certain representation, if it has a reason
to believe it can get a reply from the target in that format.

Could have client make a conversion to lat/long; server doesn't
need to know how to do this.

Consensus on multiple locations
-------------------------------
I.e., repeating a single schema vs. multiple schemas:
- Geopriv needs multiple representations of a single 
  location. Only one is mandatory, 
  but there must be an option to have more than one.
- Still unclear  what multiple locations will mean.
- Concern: leaving semantics entirely to applications 
  introduces hand-waving, may put a lot of security and privacy
  beyond the reach of geopriv.

Implementation issues
---------------------
Is it easier to deal with multiple objects or multiple
representations within an object, from an implementation
perspective? This provoked several responses.

1. Expression of location -- ``I'm on a golf course'' -- may not 
   be something that needs to be represented in multiple locations.
   This deals with categories, not necessarily best 
   conceptualized as multiple locations.

2. Geopriv need not go into representation of boundaries. 

3. There was interest in having multiple precise locations.
   Must be able, semantically, to distinguish 10 locations in
   one message; 10 messages each with 1 location but all related 
   to 1 query. 

4. From an implementation point of view, it may be easier to 
   send 5 different requests.

5. But privacy may suffer -- sending separate objects may create 
   a risk that a single object may be intercepted, understood
   as an  exact location, and cause damage. Sending all locations
   together may create "bigger picture" that there is ambiguity.

6. But that may be security by obscurity. Cannot rely on
   that ambiguity to provide security; may discover the right answer
   or cause damage nonetheless. It is better to handle this
   problem by securing the object and the relationships
   between target and clients.

7. Reputability concerns. Explicit meaning of multiple locations
   may be that multiple locations --> they are dummies. But it
   isn't clear that this is what people are asking for.

8. Putting multiple locations in one object allows
   them to be interpreted together with less metadata. 

Should geopriv therefore explicitly specify that multiple related
objects, or multiple locations within an object, signify that some of
the locations are dummies?

Response: May need to provide intent flags -- can specify that 
multiple locations represent an attempt to specify the
same location but are done so by different technologies
(GPS, dead reckoning, etc.) 

There are different risks -- making and linking multiple queries can 
reveal a lot of information.

Consensus: 
----------
If geopriv needs to express multiple locations,
it is probably simpler to do it by expressing multiple 
locations in one object, rather than linking multiple 
objects.
----------

Further discussion of false information and multiple locations.
---------------------------------------------------------------
Geopriv needs to ensure that false information is not 
returned in any predictable fashion.

There was concern about forcing owner/rule maker to have secure external
location, rather than expressing this in the object.

Three general possibilities 
for the meaning of multiple 
locations:
---------------------------
(1) Multiple locations can mean only 1 thing.
(2) Geopriv specifies a complicated way to express
    semantics of multiple locations.
(3) Leave to application policy.

There are 2 problems: who is making the request, or who will
use it later on.

Policies should control who can access a certain kind of information.
May allow, e.g., a certain set of people to know "I am either 
at home or at work."

But this involves heavy user configuration, something 
that the average 
user would probably not take the time to do.

Another possible limit to LI access: time-stamping/time-limiting 
objects.

Agreed:
-------
Jorge Cuellar, John Morris, and Alex Gogic would post
discussions of:
- Multiple location, single object vs. multiple
location, multiple objects;
- Expressing meaning of multiple locations.
- This is a fundamental issue; is there a reason to 
  require that, in the first release, there must be the 
  ability to link multiple locations in some way. Or 
  can it be deferred to a later release?
- How far could we get with geopriv if we just settle on
  one location for the present time?
- The feasibility of  requiring that the geopriv 
  object have a bit to signify that the object does not 
  give the "whole picture."

Issue 9
-------
Trusted vs. untrusted data flows.
Trusted means that there is a contract that governs privacy between
the two parties.

Is "trusted" different from "security? YES: trust in this sense 
involves a legal relationship.

Does this affect the design of the object? 

As long as security is taken care of, if there is a 
contractual relationship, then there may not be a need for 
special treatment within the geopriv object.

The idea behind this distinction is to "thin" the policies that
need to be written, and thus reduces the emphasis that is placed
on privacy NOTICES (see P3P discussion below). 
By allowing multiple identities, etc.
there is a way of building in a sense of trust, and there need
not be a complex policy when information is exchanged between 
trusted identities.

E.g., in restaurant location case, a client may need to give very 
specific location information but no identifying information.
This is taken care of by multiple identities, rather than
an explicit expression of ``trust.''

Aside:
------
This raises a NEW QUESTION about the design of the protocol:

How is this information about trust being conveyed? Does
the object carry the policy?

This is an open question. There is a sense that there should 
be some policy in the object, but this is not a consensus.

Concern about the footprint of attaching policy to the object -- 
both bandwidth and processing power may limit how fully rules
can be expressed.

E.g., cell phone in a different carrier's area. How much information
should carrier be able to get from device, and how much will 
be referred to policy held by the home provider?

(End of aside)

Issue 10
--------
Scenario 2 billing data -- is this location data in the geopriv
sense? Or is it application layer information?

Distinction between "accounting" and "billing" -- "accounting"
is what was meant here.

Issue 11
--------
This presents a basic scope question: is geopriv dealing with 
a protocol, or objects and policy surrounding the objects. 

Seems to be consensus that we are specifying not only objects
but also how they are to be used.

Suggestion: Look at CMS (RFC 2630) to see how to blend object and protocol
language into a document that everyone can accept.

Does the LO include "commands" or "requests"? YES.

Embedded protocol/combined protocol -- security has to be 
standalone, but use is something that can be specified as a 
feature of the combined protocol.

Issue 12
--------
MUST implement vs. MUST use.

Policies must be able to say that, e.g., identification
MUST BE USED. IETF Security Area will require certain minimum 
algorithms for cryptographic authentication, etc.

Issue 13
--------
Contents of LO: these are things the LO MUST implement/MUST
support.

Location Data: YES
Location Data Type: YES
Target identity: YES
Version number: YES
Policies: **** Use, disclose, retain **** 
policies should travel with the object.
Policy Format: ?
Negotiation parameters: e.g., specifying 
format (postal address, etc.)
for returned LI.
- Cryptographic suites, etc.

Issue 14
--------
The protocol MUST define one LO (syntax and semantics) that 
must be understood by all geopriv implementations; the LO
cannot be opaque.

Issue 15
--------
The multiple locations issue was discussed above.

Issue 16
--------
Should geopriv help users to lie? What is an example of this?

It may be better to be vague. Giving multiple false locations
could allow averaging in order to give a better location.

May want to be able to send rule to LS to lie for the target.

Also, may want to be able to find out locations that will be useful
in the future, or locations that do not rely upon accurate 
location information.

Agreed:
-------
The user should be able to hand a rule to the server,
to reply ``I am always in location X.'' User MUST be able to 
do this in the rules; otherwise geopriv would have to be able
to decide what response a user can or cannot specify.
-------

But is "lying" the correct way to describe the capability? Could it 
create legal problems? Doubtful, but could create perception
problems -- go with a more general description, other than
"geopriv allows you to lie."

Is deliberately false information more protective than
vague information? A poorly designed algorithm could reveal
more than the user intended to be revealed.

On the other hand, some request contexts may render low precision
inadequate -- there is a separate interest in telling someone
you are somewhere other than where you actually are, 
rather than just giving a low precision response.

There is generally a mixed bag of uses for lying, some good, some
bad. So geopriv shouldn't decide whether user can lie; legal
norms and regulations will probably develop around false LI.

Room Consensus:
---------------
The protocol will not assume that the location is provided
represents where the user or target is situated at the 
moment of transmission.
----------

But this consensus does not settle the issue of whether a user
can provide a false location.

Some ideas:
-----------
Would like to ensure that obfuscation MUST be a capability of 
the protocol. However, this will not prevent an implementer
from disabling obfuscation. But the protocol should not be 
silent on this point.

Geopriv should protect users who cannot trust a carrier/sighter.
The protocol can be designed to give privacy-concerned 
users as much leverage as possible with carriers who are 
not willing to allow obfuscation.

This assumes carriers will follow the protocol, a big
assumption, and there is no way to ensure that carriers will
implement the full protocol.

But from privacy advocacy perspective, this at least gives some
way of making a company responsive to concerns that they are not 
implementing full privacy capabilities of the protocol.

The underlying idea is to push carriers to do as much as 
possible to implement privacy protection, with the realization
that one cannot expect complete compliance with geopriv.

====> THIS ISSUE NEEDS TO GO TO THE LIST. <====
[Note from co-chair - the issue to the list is the provision
 of conscious falsification feature by the protocol]

**********************************************************************
**                                                                  **
**                                                                  **
**                      JUNE 6, 2002                                **
**                                                                  **
**                                                                  **
**********************************************************************

Wrap-up of Issue 16
-------------------
Consequences of allowing user to provide false information:
1. Cannot make an assumption about the truth of information.
2. Other protocols (e.g., Diameter) might want to assume that
   the information is true; if it cannot do this, the protocol
   may need to look into the policies. Messy.

There is a distinction between
a. giving a deliberately vague position  (changing
   GRANULARITY; accuracy) and
b. giving a false but perhaps precise location.

Agreed:
-------
Activity (b) immediately above needs a new term -- obfuscation 
is too broad a term.

**************
    NOTE:
**************
The following issue will be summarized and presented to 
the WG for discussion in an Internet-Draft being prepared by Jorge 
Cuellar/Alex Gogin/John Morris. 

[It seems now it will be an email/viewgraphs.  Allison]
**************

Three questions:
----------------
a. Can you have mutliple locations in a single object,
   one use of which might be obfuscation?
b. Is it OK to blur your location by increasing radius?
c. Can you provide a false location (i.e., ``I'm in
   Europe,'' when you are actually in N. America)?

Cuellar, Gogic and Morris will post short draft requirement to the 
list.

Issue 17
--------
Is it out of scope to specify a policy language for geopriv?

Analogies to presence work. This may be inadequate -- geopriv
would like to have at least some pieces of policy traveling
with the object to control disposition after initial
access authorization.

Presence does allow watcher info (SIP-specific) -- a list of
identities that can be updated or will update a user upon
change in presence.

An outstanding question:
-----------------------
Is there an existing system that can be reused for this purpose?
SIP, IMPP are logical protocol options. Is P3P or a subset 
thereof suited to the task?

Geopriv should have the simplest possible relationship
to the internal maintenance of policy servers, policy retention, etc.

Issue 18
--------
Do LoSi, ULR need explicit knowledge of rule maker policies,
or can they follow a set of policies established by other means?

(1) LoSi in examples yesterday did not seem to interact with rules;
    LoSi is a ``dumb'' piece of hardware.

(2) Policy may specify: a group of people may know my location
    with certain granularity. Does the ULR need to receive the 
    full statement of rules? Probably not. But ULR does need to 
    receive a statement of the terms on which it is receiving the LI, 
    e.g., ``You must destroy this information within 24 hours.''

But (2) may not be enforceable -- a consumer of data may not 
abide by the terms. This is always a risk; not addressable by
technology. In such cases, the owner of the data may have 
recourse to some legal action, such as damages arising from breach
of contract. 

Geopriv doesn't have much to say about what ULRs do; is this moot?
NO; if ULR receives terms, it creates a relationship that may 
provide legal redress if the trust is violated.

This may be the most protection that geopriv can offer.

Further protections available within geopriv
--------------------------------------------
(1) There may be self-enforcing technology to help: expiration
dates on the LI, for example. Making this part of the protocol
will facilitate the building of hardware that will be built
that will enforce these rules.

But won't there always be people who will capture momentarily
decrypted information, copy it, etc.? YES; this is always a 
problem, but there should be some sort of RISK MANAGEMENT 
built into the protocol, so such an effort is not moot.

(2) Does ALL LI pass policy to ALL ULR? Or is it sufficient to 
pass a do-not-distribute bit and perhaps a timestamp? 
Requiring more would constrain how dumb the receiving device
can be, if it is to follow the rules of distribution.

Could be a question of whether recipients MUST process the 
instructions, or recipients MAY follow it (rendering the 
instructions optional).

Possibilities for passing policy to ULR:
----------------------------------------
(1) ULR receives no policy on LI use.
(2) Object MAY/SHOULD/MUST contain arbitrarily complex 
    LI use policy.
(3) Object MAY/SHOULD/MUST implement some information --
    a ``do not distribute bit'' and a timestamp.

It may not always be the case that the target device needs to carry
all policies -- there may be a policy server that fills in 
information before LI is sent back to policy.

There was a feeling that (3) would deal with  a lot of privacy issues;
there could be another bit that tells ULR to look to another
location/application to get more detailed policy, but that 
policy would not be part of geopriv.

Leakage/disregarding this policy specification could grounds for 
LEGAL ACTION.

More about the timestamp in (3):
--------------------------------
Need more than 1 timestamp: 
(1) When was the LI accurate? 
(2) Until when should the LI be considered current? TTL, in essence.
(3) Until when are you permitted to retain the LI?

Possible analogy with a web browser -- do-not-cache bit only
works to flag information for expiration, but does not create
requirement to actively purge caches, and applications do not
do this.

Should there be something more affirmative to signal permissibility
of redistribution?

==> ASIDE <== : There should be something in the requirements about 
    capability negotiations.

Identity requirements issues were discussed yesterday; issues 25 and
26 should go to the list.

Issue 19
--------
Generic policies MUST be made explicit. 

E.g. you are roaming in
a geopriv-compliant environment that is not a trusted environment.
Target/Owner/Device must be able to know what the LoSi, LDS, etc. does
with LI.

It was agreed yesterday that there is not always a rule maker
between the device and the LoSi. There is no way, in that case, to tell
LoSi what it may do with LI.

Does this create a requirement that all LoSi must have a certain
amount of intelligence? 
NO. This is what the policy server is supposed to do; 
but in order to be geopriv-compliant, the 
LoSi MUST NOT disclose LI to anyone but the Location Server.

LServ enforces the rules, and if LI goes anywhere else, there is 
a total circumvention of geopriv. So this is the only explicit 
rule (and it assumes secure communication between LoSi and 
LServ).

****************************************
* END OF REQUIREMENTS DRAFT DISCUSSION *
****************************************

****************************************
*       DISCUSSION OF SOME             *
*    PROTOCOLS/MECHANISMS/ISSUES       *
****************************************

II. PGP - discussion led by John Noerenberg

a. General background.
----------------------
- Mechanism for defining enc, auth protocols.
- Defines mechanism for putting these things together.
- Set of packets, each with value that specifies 
  function (e.g., priv key, enc data). 
- Geopriv could use PGP to exchange data; it is
  truly end-to-end. Parties exchange keys via web of
  trust; there is no other key distrib mechanism.

b. Questions/comments.
----------------------
1. Will PGP work for geopriv? 

 PGP is a vehicle for 
 client/server relations, but it assumes that parties have
 exchanged keys. This may not be possible in geopriv
applications.

2. Does the lack of key distribution break models like 
   "Where is the nearest Pizza Hut?" 

   Not necessarily;
   parties can specify where their public key is.

3. Should there be a mandatory key distribution model?
   This is a very difficult problem (PKI) that does not
   have a general, easily implemented solution.
   Kerberos distributes keys to communities, something
   like that might work. Requires trusted 3rd party to 
   authenticate the parties.

4. Within geopriv, many different models may work -- PGP,
   message digests (giving weaker forms of shared secrets), 
   Kerberos.

5. Authentication based on identities is problematic;
   want authentication based on pseudonym. 

6. Geopriv should be able to support exchange of keys, 
   pseudonyms for discrete transactions between parties.
   This is a requirement for a 3rd security association -- between
   the Client and the LServ (in addition to Object and 
   LServ, Client and Object).

7. But if want to use key distribution, you can't do 
   this because authentication of keys is based on knowing
   true identities.

8. (f) may not be practical; privacy and pseudonymity
   are antithetical. INTEGRITY is an agreement over keys to be
   used for information exchange. CONFIDENTIALITY ...
   PRIVACY has more to do 
   with the linkability of information to an entity's identity.

Next topic:
-----------
II. (Probable) Security requirements for geopriv. -
    Discussion led by Jon Peterson

a. Mutual auth of the generator of the object and the 
   consumer.

- Anonymity/pseudonymity. --> PGP is OK here.
But web of trust model is weak for ultimate assurance
that the other party can be trusted. (GnuPG may
also work, avoid potential IP rights 
problems with PGP.)
- Shared secret may suffice.
- Certs may be needed in other cases.

b. Integrity of the object (perhaps optional).
c. Optional confidentiality.
d. Replay protection.
e. Though we do need some actual threat models.

Next topic:
-----------
III. An Example of a Geopriv-Using Protocol - SIP -
     Discussion led by Jon Peterson

a. SIP: security mechanisms. TLS (SSL successor). Layer 4
cert-based or key-based confidentiality.
Doesn't work for UDP.

- SIP Digest. Challenge-based 1-way or mutual
authentication. Can provide some hash-based 
signatures for confidentiality. 
*** Hop-by-hop only.

-S/MIME. Provides security at MIME level.
Reuses CMS (Cryptographic Message Syntax; RFC 2630; ASN.1
based system; relatively heavyweight.)

Can provide integrity/1-way authentication 
via signatures and optional confidentiality.
*** End-to-end security protocol; security lives 
as long as the object does.

b. SIP could be seen as providing basis for 
inheritable security characteristics.

c. Encourage development of several interoperable security 
protocols, rather than one monolith that MUST be used.

d. PGP and S/MIME may provide a better model for geopriv
than TLS. Geopriv object could be transported by SIP and
SMTP; would want to allow geopriv security to survive
this.

e. But this is a heavier-weight solution and may not 
limit the kinds of implementations that can support
geopriv. Therefore need to examine further the requirements
before settling on something too heavyweight.

f. On the other hand, there may be an argument for 
hop-by-hop security only, because of the policies governing
the use and distribution of LI.

Next topic:
-----------
IV. SOAP and XML - Models for the GEOPRIV object?
    Discussion led by Jon Peterson

a. XML has standard signature and encryption.

b. XML-staged signatures and encryption allow one to 
   assign different security properties to different groups
   of elements.

- Different parties can sign different elements,
  or a single party can control access to data at 
  a fine level of granularity.

- Signature with a certificate for authentication properties.

- *** Argument for staging security inside the object ***:
  Not only can there be fine-grained control over security 
  policy, but also different levels of security for location 
  added/handled by different
  entities along the way. 

- It is important for the WG to record the kinds of THREATS 
  that require this kind of granularity.

c. SAML (authent/authorization)

d. Web services can still rely on underlying HTTP or BEEP
   security properties like SSL/TLS, SASL.

e. GML may have some interest for geopriv.

f. Need to develop threat scenarios.

g. Need to analyze the computational cost effects of 
   an XML-based approach.

Next topic:
-----------
V. HTML/HTTP
   Discussion led by Andrew Daviel, including discussion of
   whether the HTML part is pre-geopriv.

   Putting LI into legacy HTML documents. The related HTTP draft was 
   meant to make queries easier.

a. HTML draft: intended to add machine-readable location
   info to legacy pages, to make more accessible to search
   engines. NOT intended to insert personally identifying 
   information about authors.

3 attributes:
- Position (lat/long).
- Region (country code + state/province).
- Placename.

Implemented in the HTML ``meta'' element.

Privacy risks: same as search engines. It is possible to 
collect history, track requests/published information.

This becomes a concern if there is a web server on a mobile
device, continually  broadcasting its position.

The concern may not be so great because:
- User has to go out its way to do this.
- Most people do not run their own servers; assume
  those that do so know what they're doing.
- Current internet architecture can reveal a certain
  amount of geographic information (i.e., by IP address).

b. HTTP draft: embedding position information in HTTP 
   headers.

Purpose: CONVENIENCE. E.g., going to map site,
you wouldn't have to type in your location all the time.
- Client side: simplify location-based search;
  location-based browsing.
- Server side: location-based search of non-HTML
  objects.

Objectives: targeted information (weather,
traffic); less irrelevant advertising.
- Would be easily accommodated in existing
  web servers.
- Could be sent directly by client or added
  by client's proxy.
- Privacy risks: prior risks include IP-based 
  resolution.

Outstanding question: 
---------------------
Does the HTML draft create information
that should be protected by something like geopriv?
- Or would HTML authoring tools end up putting this 
  information in HTML pages?
- This may be the way to go for HTML ONLY; there is a 
  risk in introducing this too soon and having other people
  use it as a model for all sorts of location information.

Next topic:
-----------
6. P3P and its applicability to geopriv. Also other privacy
   technology components.

   Discussion led by John Morris and Deirdre Mulligan

a. A THREAT MODEL will be  more useful than a
   DESCRIPTIVE MODEL for analyzing privacy risks.
- Identities (anonymity tools directed toward 
  dealing with this problem).
- Onion routing/crowds/freedom: traffic analysis
  as well as hiding who you are.
- Identity and information management tools: ways 
  to exchange information about policies that 
  govern use of information.

b. PRESENCE is a privacy risk; is there a way to "cloak"
   yourself, hide the fact that you are there?

c. The closer information is to the underlying entity,
   the stronger the (legal) privacy protections on the information.
   E.g., information residing on one's computer is much more
   strongly guarded than the same information residing
   on someone else's server.

d. P3P implementations: Microsoft has a "compact"
   implementation dealing mostly with cookies. 
   More complete implementations would describe uses of information
   more fully, and allow identity management. 
- P3P does not allow policy negotiation, in the sense 
  of back-and-forth negotiation.

e. Reaction to the idea of using P3P in geopriv.
- It may be overly complex for geopriv, given the 
  limited set of data and ability to set defaults.

- P3P DOES NOT HAVE ANY PRIVACY DEFAULTS.
  ===> It does not start with ANY privacy protection,
       but merely provides for the expression of 
       certain preferences.

- The complexity is in part a function of the lack
of defaults. If there are no defaults, the protocol
has to provide for the expression of many,
many preferences.

- P3P ended up this way because (i) there are 
many contexts in which information is shared, 
e.g., between doctor and patient; (ii) the web is 
general purpose and relatively open to competition.
There is no structural barrier to competition, and
sites could actually compete in marketplace for
privacy.

- Factor (ii) will very likely be quite different in
contexts where geopriv is used. There are only
a handful of wireless carriers in a region, etc.

- P3P placed a heavy burden on NOTICE, which will
not meet the requirements for geopriv.

Next topic:
-----------
7. Emergency Services.
Discussion led by James Polk
   a. The Rub: jurisdictions have made or are making location of
   a caller to an emergency center mandatory (e.g., FCC 
   regulations in US).

- There is some pressure here: FCC has taken one wireless
company to court for failure to comply with 
regulation to supply 911 location information.

- It is not desirable to have wireless companies their own
protocols for FCC compliance.

- Policy engines could refuse to allow users
to specify ``Do not give my location to any person
whatsoever.''

- Dangers with this: (i) Efforts to co-opt the 
emergency location information. (ii) Carriers
could decide whether to set policy about E911.
(iii) If 911 provider is not required to be 
authenticated (perhaps it takes too long), 
then LI is subject to attack by someone impersonating
a 911 provider. (iv) (iii) might be handled by 
use of certificates, rather than high-level 
requirements in the object.

- Introducing 911 exception to authentication, 
authorization, encryption creates a path that 
could be exploited. 

- Concern: failed authorization could prevent
a call from being completed.

- Geopriv does not require that all communications
be encrypted. 

- "Group key" idea: public key that could be
shared by all emergency services in a state, for example.
This would allow communication with emergency 
services regardless of whether it is in an area
where the user has contemplated authorizing
access by emergency services to location information.

- Could have a short-term solution: encryption
and authentication are MUST implement items.

- Problem: it may politically untenable to 
require implementation of encryption; people will
want to build devices that do not do encryption.

- Could say that encryption MUST be implemented but
its control is part of policy. 

- Another concern: failure to authenticate on 
the client/caller side could leave emergency 
system vulnerable to attack by a flood of bogus
emergency calls.

- It may be possible to take a two-tiered approach: a 
"Yugo" challenge and a "Cadillac" challenge.

911 might be able to use Yugo challenge, to 
prevent emergency calls from being dropped due
to failure to authenticate. But then attackers will be able
send Yugo challenges.

- But in this context the phone will always be 
initiating, and will expect something back. If a 
response comes back from some entity that is not

- LServ will likely have the legal duty to provide the 
location information.

- Assertion: geopriv CANNOT allow emergency centers to query locations;
this would open up a huge exception.

- Objection: there may be situations in which emergency
center may need to call someone back. 

- Response: there are many reasons not
to allow emergency centers to query people --
this power is subject to abuse by the people who work in the 
centers.

- Sense of the Meeting:
----------------------
We need to solve this first in IP; worry about
gateway to other worlds later. Bridging is 
out of scope, for now, but could become a later
requirement.
------------

- Sense of the Meeting:
-----------------------
Geopriv needs to develop a list of MUST, 
SHOULD, MAY requirements. 

This is a list of 
features that all geopriv implementations 
must have, for security and interoperability.

Geopriv must arrive a minimum set of security requirements that
all geopriv implementations MUST support.

SHOULDs, MAYs to follow.
--------------

********************************
**                            **
** INTERIM MEETING ADJOURNED. **
**                            **
********************************

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 25 Jun 2002 07:35:41 -0400

>    Discussion led by John Morris and Deirdre Mulligan
...
>   implementation dealing mostly with cookies. 

See section 4 of the specification.

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 25 Jun 2002 11:46:02 -0400

More comments on Aaron's notes from the IM. Specific to mention of P3P
in the requirements portion of the IM notes. Inline, with elipses (...)

...
...
> on privacy NOTICES (see P3P discussion below). 

Meta-comment: The P3P discussion in a subsequent section of the IM
notes seemed odd. Perhaps this is my problem, one of over-familiarity.
Perhaps this is a problem of the note taker, one of reducing to writing
a complex oral narrative. In any event, p3p is a mechanism for the
announcement (not negociation, not enforcement, not ...) of data collection
practices, with a vocabulary that appears to afford a mechanism to express
the three major dc policies (EU, OEDC, US), that isn't restricted to http{s},
and has an XML syntactic representation, and a similar compact representation.

It does not address the problem space of onward-transport, which the CPEX
(non-W3C) standard attempts, and which is mentioned obliquely in the SOAP
and XML discussion.

Someone asked me earlier why I mentioned APPEL as potentially relevent to
this WG. I mentioned APPEL because that is where expression of user
preferences for subsets of all possible data collection practice policy
statements finds any of several "default" values.

	Compare: Eric's (or Randy's) default _disclosure_ rules (APPEL),
	and DoubleClick's (or USG's) default _collection_ policies (P3P).

End Meta-comment.
...
> the object carry the policy?

This was the point of adding Section 4 to the P3P Specification.

As an implmentation issue, the evaluation of a policy provided by
other means that is necessary to determine if the data collection
practices associated with a cookie are non-trivial. Self-policied
objects are simpler to evaluate.

As a protocol design issue, forcing arbitrary evaluation and policy
fetch by some other means precludes scaling policy to high-volume
non-trivially policed objects (English: kills cookies, may have the
same effect on other species of pastry).

> be some policy in the object, but this is not a consensus.

Well, this is better than a consensus that no policy may be carried
on a geo-blob.

> both bandwidth and processing power may limit how fully rules

The controlling issue here is syntax. In draft-jaye-http-trust-state-mgt
we figured we could easily shove all the policy bits remotely applicable
to cookies into 8 bits, but the PILC constraint for wireline browsers is
hardly this limiting, particularly when you look at the other junk that
is beinging sent to the browser.

I thought I raised the issue earlier, but I could be mistaken and this
really is a NEW QUESTION.

> identities that can be updated or will update a user upon

Ignoring for the moment the syntactic form of a P3P 1.0 data collection
policy statement (XML pasted on URIs, with exceptions), or the semantic
problem of evaluation (within a DOM tree, with exceptions) --

	what part of the vocabulary (purpose, recipient, retention, ...)
	are applicable?
	
	what part are not?

> to the internal maintenance of policy servers, policy retention, etc.

Heads Up (which everyone is free to ignore)

The temporal properties of policies (duration, renewal, expiry, non-uniqueness)
are more complex than they appear.

Thanks for the IM notes.

Cheers,
Eric