Subject: RE: Geopriv WG - meeting 5-6 Jun, other news

From: "Ashitey, Daniel" <[email-masked]>
Date: Tue, 14 May 2002 00:40:53 -0400

Dear Allison,  
I applaud the effort to revive discussions in this group.  I think there are
several interesting areas this group can cover. One quick comments on the
revised milestones: In order to keep within the scope of working with
existing location technologies, may I suggest that if an example draft is
planned to be published, even for informational purposes only,  as alluded
in Jan 03 timeframe, then is should cover all existing location technology
instead of just handset-based. For user-controlled location, a similar
argument can be made for network-based solutions as well.  I will be more
than happy to contribute an example draft for network-based location
solution. I look forward to participating in the discussion .

Thanks
Daniel Ashitey
Trueposition Inc.
King of Prussia, PA

-----Original Message-----
From: Allison Mankin [mailto:[email-masked]]
Sent: Monday, May 13, 2002 11:04 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Geopriv WG - meeting 5-6 Jun, other news

With our Area Director's consent, we have just advanced all of
our milestones (and the charter page is updated).  We have also
confirmed his permission for us to have an interim meeting,
as well as the Yokohama meeting, to try to catch up.

The interim will be at Qualcomm, in San Diego, Jun 5-6.  Qualcomm
has confirmed hosting.  I don't have room and hotel info from 
Randy or John N. yet, but we will get it to you, as well as looking
into providing a phone bridge.

The basis of our discussions for now should be the requirements draft 
that Jorge Cuellar has recently announced, which represents joined efforts
from several of the folks who wrote before, and which has had 
several different groups commenting and discussing it off the list
to date.

Allison

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 16 May 2002 20:44:19 -0400

Howdy Richard.

> Now on to some particulars.
> 
> IMHO these data elements look like XML objects and the Privacy Object 
> should be an extension of the work already done in W3C on P3P.  Where as 
> P3P was designed as a PULL mechanism to define privacy policy for servers 
> running HTTP ..what we are seeing here is more of a PUSH mechanism in the 
> opposite direction.  The Rule Maker defines what they want people should 
> see not the Location Seeker defining what their policy is.

Almost.

Up until November of 2000 P3P was as described, with the state management
drafts hanging in Massinter-shutdown-mode, with Ned-and-Keith doing their 
little bit too.

At the November P3P f2f a vendor took the position that policy evaluation
was actually much more complex than advertized (true), and another vendor
took the position that policies should be expressed without reference to
a DOM tree, and be carried in-band. At the conclusion of that meeting,
compact representations on state management mechanism instances entered
the P3P spec.

This has been adopted with application of P3P to CC/PP, and Xforms, but
to be honest, although HTTP is commonly viewed as a retrieval mechanism
for HTML, it is really a retrieval mechanism for objects encoded using
MIME, and that isn't sufficiently general for the protocol, the event
model, or the data representation format.

In another protocol (onward-transport of customer profiles) developed at
roughly the same time (1999-2000) by another industry group (CPExchange),
P3P's vocabulary was adapted in DTD form.

In another protocol (onward-transport of domain registration data)
developed in 2001-2002 by another industry group (PROVREG WG), P3P's
vocabulary was adapted in schema form.

A representation format is useful. It could be in ASN.1, in XML, in BNF,
and it could even be expressed as a MIB. There are a lot of choices.

An event model is useful. It could be asymmetric. It could be symmetric.
There are a lot of choices.

A group or address-equivalence model is useful. It could be a GIPC built
on unicast, it could be multicast. There are a lot of choices.

Another bit of related tech is APPEL, spun off from P3P, November '00.

Now to take another salient para (out of order):

> Let be honest here .. though there are several applications where this 
> architecture might be useful the clear and present need is in Internet 
> Telephony and SIP in particular.

Half the time I don't know where I am. The other half the time I don't
know what time it is.

         I'd like locality representation format(s)
                            and
        I'd like temporal representation format(s)
                            and
        I'd like representation peering mechanism(s)
                            and
             I'd like convergence mechanism(s)
                            and
          I'd like interface(s) to AAA mechanism(s)

[Basically, I'd like an NLP that looks and smells like NTP, with simple and
 secure variants, having zippo to do with GPS or carrier network knowledge,
 except as one possible, non-authoritative, source of l-and/or-t data, and
 capable of supporting j-random policy requirements, as opposed to being
 just their weak pseudo-technical restatements.]

> I want this list to understand that we are laying the ground work for what 
> is perhaps a once in a generation advance in the concept of a public 
> service location protocol that if defined correctly could link not just the 
> location of an individual in distress but also provide life saving links to 
> other forms of data ...health records that could save countless 
> lives.  Think about that in the context of privacy requirements.

Maybe.

Eric

---

From: Dan Greening <[email-masked]>
Date: Fri, 17 May 2002 20:29:13 -0700

Regarding a question embedded below, US law is a little vague on how to
handle wireless privacy in general, and location privacy in specific.
Some of the material below is from Kris Anne Monteith, FCC Chief of
Wireless Telecom Policy.

In the USA, courts have declared opt-out the rule of the day. In other
words, notify participants prior to establishing a relationship, allow
people to opt-out or not participate.  FCC required opt-in in previous
regulations, but this was declared unconstitutional by US Tenth Circuit
Court of Appeals.  In the US, I don't think there are provisions
requiring consumers to be able to erase past historical data. There is
privacy legislation in the Senate (Hollings) and House (Stearns), but
these are not likely to be approved by either body in 2002.  US Chamber
of Commerce opposes both.  The House bill is more favorable to business,
Senate bill requires opt-in, and fines violators
$5000/company/violation, which can add up in a class action suit to
millions or billions, so you can imagine commercial concern about this.

Things are a little more confusing in Europe, where some claim you can't
retain information about a person's location, even if you are just
caching a previously obtained location to improve efficiency.  In fact,
I've looked through existing European law, and I THINK that you can do
this as long as you tell the user you are doing it and give them the
ability to delete cached information.

Regards,

Dan Greening, Ph.D.  CEO, BigTribe Corporation 
              330 Townsend Street, Suite 209, San Francisco, CA
94107-1662 
              [email-masked]  +1(415)995-7151  fax 995-7155

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Thursday, May 16, 2002 3:00 PM
To: Richard Shockey; Allison Mankin; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Geopriv WG - meeting 5-6 Jun, other news

Richard

I share many of your views written here. I would add a few requirements
such as altitude, velocity and vector (better than direction). TTL
should
be coupled with the Time of source sample because the LO of a Target
might
be for a stationary object (infinite TTL) vs. a Rocket (changing quite
rapidly).

I question how you determine "confidence" within the LO Requirements. Is
the policy Rule Maker going to tell me that I should only have a 50%
confidence factor of the answer I just got from some location server
when
trying to determine your location, or should that be in the background?
Shouldn't the Rule Maker (Target's Policy) determine how granular the
information is going to be based on who's asking for it?

I don't know if I agree with your PUSH preference at this time, except
in
times of emergency -- in which case I believe the LO should be part of
the
original INVITE packet in SIP.

Has anyone talked to the FCC and NENA (in the US, and counterparts in
other
countries) about their requirements regarding disclosure of information?
One good lawsuit might very well change (or obsolete) this protocol if
its
written with the constraints of these requirements and past views.

At 04:28 PM 5/16/2002 -0400, Richard Shockey wrote:
>At 11:04 AM 5/13/2002 -0400, Allison Mankin wrote:
>
>Unfortunately I will personally be unable to attend the proposed off
site 
>but I wish to make some comments on the proposed requirements draft,
which 
>IMHO is currently inadequate to the task.
>
>In the first place it is my belief that we are not dealing with a
protocol 
>here but objects and the policy surrounding those objects.
>
>The proposed draft way too long on imposing policy on the objects
without 
>actually defining any requirements for the objects.
>
>It strikes me there are two key requirements here which is 1. a
Location 
>Object which is the semantic expression of location data and other
useful 
>information ( raw or other ) of the Target that can be interpreted by 
>Location Seeker in order to act upon it and  2. A Location Privacy
Object 
>that presumably under the control Rule Maker ( perhaps the Target )
that 
>expresses what information can be transferred and under what 
>conditions.  Both of these objects reside in this "Location Server"
that 
>can be queried by some undefined and presumably out of scope
application 
>mechanism keyed on by some identifier ( phone number for instance).
>
>I submit that any discussion of transport of geopriv objects be deemed
out 
>of scope and those discussions are best left to the applications that
need 
>geopriv data ...SIP for instance.
>
>Where it MIGHT be legitimate to discuss Authentication & Authorization 
>requirements between geopriv entities it is not appropriate to impose 
>requirements on other protocols that may already have built in AA 
>methodologies. It is very easy for me see how these objects could be
easily 
>integrated into the SIP environment using all of the existing tools SIP
has 
>at its disposal without imposing any new protocol requirements on SIP.
The 
>Location Object and its Privacy object could easily be transferred to a

>Location Server integrated as part of the SIP proxy during a REGISTER 
>session for instance ...and a Location Seeker could request the
Location 
>Object in a form of INVITE where the PSAP could clearly and
unambiguously 
>authenticate its identity.
>
>Discussions on identity management is SIP is now well underway.
>
>What I'm hoping will come out of this meeting is some agreement that
the 
>requirements document is not done unless the requirements for the
Location 
>Object and Privacy Object can be sufficiently defined, other wise we
will 
>not be able to progress the work froma short, clear, concise and
reasonable 
>document. I suggest now and will continue to suggest that the scope of
the 
>requirements document reflect this generally minimalist approach to
object 
>design and leave general policy details to the applications that must
use 
>the objects.
>So What are the requirements for a Location Object?  I might suggest a
good 
>start might be ...
>
>Index key - telephone number ?
>TTL
>Latitude Longitude
>Source
>Time of source sample
>Confidence Level
>Motion & Direction if available etc.
>
>What then are the requirements for the Privacy Object ... I make no
claim 
>to be a expert on the P3P work but I think that would be a good place
to
start.
>
>Last but not least I have real problems with Identity Protection
statements 
>in REQ 12.  I've said this before and I'll say it again ..there are
serious 
>policy issues here with public safety officials if the protocol can
permit 
>the Policy Maker to override legitimate requests for identity
information. 
>This is not the wiretapping issue ... on issues involving public safety

>state and federal regulators WILL take a very very firm stand.
Therefore 
>the language should be changed from MUST to MAY be able hide real
identity.
>Richard Shockey, Senior Manager, Strategic Technology Initiatives
>NeuStar Inc.
>45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
>1120 Vermont Ave NW Suite 400 Washington DC 20005
>Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
><mailto: [email-masked]> or
><mailto: [email-masked]>
><http://www.neustar.biz>
><http://www.enum.org>
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Senior Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: Cuellar Jorge <[email-masked]>
Date: Fri, 24 May 2002 15:44:26 +0200

>>>  In the first place it is my belief that we are not dealing
>>>  with a protocol here but objects and the policy surrounding
>>>  those objects.

>> In a certain sense this is true: our main concern is a
>> Location Object. But the rules that govern the use of that
>> object, may be seen as a "protocol", what we call a "embedded
>> protocol". Besides that protocol, we could also set some
>> requirements on the transporting protocol or on the union
>> of embedded and transport protocol. But anyway it must be made
>> clear how the 2 protocols together will manage the object.

>  I dislike attempting to place requirements on other
>  protocols and working groups.  This is better left to a
>  lengthy and well reasoned Security Consideration section. I
>  have considerable faith in the ability of the IESG to impose
>  security requirements where necessary. But this is clearly
>  an issue of how / if the WG can impose specific security and
>  authentication protocols on others when .. in the case of
>  SIP for example ..there is an existing architecture in place
>  that we have no need to tamper with.
>  How would you propose to resolve this apparent conflict?

I also dislike placing requirements on other protocols and
working groups, but it is my understanding that this is our
charter:
"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
applicability and will become mandatory to implement for IETF
protocols that are location-aware."

Now if SIP is able to satisfy the security and privacy 
requirements that seem necessary, and to interoperate
with other protocols assuring the security and privacy
goals, I do not see why those requirements for SIP
imply any changes for SIP.

Privacy refers to the right of an entity, normally a
person, acting in its own behalf, to determine the degree to which
it will interact with its environment, including the degree to
which the entity is willing to share information about itself with
others. 
How does exactly SIP protect the privacy of Location Information?

To quote the International Working Group on Data Protection
in Telecommunications (Group of EU Privacy Commissioners) 
(International Working Group on Data
Protection in Telecommunications: Common Position on Privacy
and location information in mobile communications
services. Adopted at the 29th meeting of the Working Group
on 15/16 February 2001 in Bangalore
http://www.datenschutz-berlin.de/doc/int/iwgdpt/locat_en.htm):

"The enhanced precision of location information and its
availability to parties other than the operators of mobile
telecommunications networks create new unprecedented threats
to the privacy of the users of mobile devices linked to
telecommunications networks. The Working Group therefore
deems it necessary that the technology for locating mobile
devices is designed as little invasive to privacy as
possible."

>>>  The proposed draft way too long on imposing policy on the
>>>  objects without actually defining any requirements for the
>>>  objects.

>> This is true, and we want to make progress in that direction too.
>> Up to now it has not been clear what parts of the object
>> will be "opaque" from the point of view of the embedded
>> protocol, that is: uninterpreted. The requirement draft focuses
>> on the privacy, authentication and security requirements.

>  of which I submit the last two are out of scope for the
>  objects themselves .. 

The last 2 reqs are:

21.  When a Location Server accepts a policy from the Rule-
 Maker, the target MUST prove to the combined protocol that
 he owns the claimed group or role identifier that should be
 passed to the Location Recipient.

One simple way of implementing this requirements is avoiding
"role identifiers" altogether. But if the
information "A person of group A is in location X" may be
fake, what is it's value?

22.  The "generic" policies (as opposed to the policies
 created by the Rule-Maker) used by the Location Data
 Source, by the Ultimate Location Recipients and by the
 Location Server of some special scenarios to be discussed
 yet, MUST be made explicit.

The purpose of the requirement is that, if some entity
uses some kind of "generic" policies (for instance:
the location information will be only passed to the
"Home Location Server" of the user), then those
generic policies must be spelled out.
I do not see your problem with that.

>  how SIP uses these objects in its
>  transport and security framework is the business of the
>  SIPPING WG and not here. What I am hoping to see is a
>  rescope of the work plan and indeed perhaps even a recharter
>  that focuses on a minimal set of real deliverables FIRST and
>  a requirements document that narrows the scope of the
>  problem to something that can be achieved in our lifetimes.

Recharter?

I really do think that we are able to solve the problem
in our lifetimes, if we go for it.

>  I continue to submit that your proposed requirements
>  documents is insufficiently focused to be IETF WG plan. Many
>  of us have seen WG's drift into all sorts of rat holes and
>  wander in the wilderness when the requirements documents was
>  not clear on what is to be achieved.

>  I believe I have a legitimate concern that the direction you
>  propose leads down the path towards an "end world hunger"
>  solution . 

No. I know of many systems that offer authentication, confidentiality
and anonymity. Don't you?

>  Considering the legitimate need for a solution I
>  just think it makes sense to break up the problem into
>  clear, discrete problem statements that can be addressed one
>  at a time.

Please make a start.

>> As the Description of Working Group says:
>> "The primary task of this working group will be to assess
>> 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."

>  well yes but ... I still see no real discrete problem
>  statements in your draft that can be translated into
>  concrete requirements for how the WG is to express Location
>  ( though this seems to be solving itself the LIF work looks
>  most promising ) or Privacy. What is privacy ? ..how can
>  Privacy be expressed in a syntax that can be rationally
>  machine processed by applications that may or may not have
>  unlimited processing resources.  What is that syntax? What
>  elements of Privacy MUST be expressed in this proposed
>  syntax?

<snip>

>> Yes, if you can integrate the Location Object into SIP
>> in a way that the entities unambiguously authenticate
>> themselves and an identity management is on the way
>> that provides anonymity to the parties, then
>> what you are saying is basically that the requirements
>> draft is in fact easily satisfied by SIP. Those are good news.

>  yes ... which I think supports my contention
>  that the work here should be
>  compartmentalized into more manageable pieces
>  , however it would be useful
>  work to offer a security and authentication
>  framework for those OTHER
>  protocols that are not as robust 
>  and well defined as SIP

I agree. We need to do that.

>> Time to live? Is that an absolute value or relative to
>> the time of source sample? (in the first case you do not
>> necessarily need the time of source sample).
>> This could be an opaque field, from our point of view.

>  Well this goes back to the concept of Confidence. The IMHO
>  Target or Device 9source) in your definitions may wish to
>  set such a value..its probably arbitrary but I mentioned it
>  as a possible example ..however given the kinds of
>  discussion we are seeing from experts in this problem space
>  I be interested to hear their views...

Yes, me too. But this discussion on what exactly are the
"fields" (or attributes) of the Location Object is still
somewhat premature here.

>>>  What then are the requirements for the Privacy Object ... I
>>>  make no claim to be a expert on the P3P work but I think
>>>  that would be a good place to start.

>> I have looked at them in detail; we can use many ideas.

>  This IMHO is where we will need the
>  most brain power... syntactically
>  expressing a complex and often vague
>  term like privacy is going the be the
>  #1 challenge.

Although I have some ideas on that, I do not think that this
is the time for discussing those questions. For some ideas look
for instance to the IBM Privacy Institute
http://www.research.ibm.com/privacy/

>>>  Last but not least I have real problems with Identity
>>>  Protection statements in REQ 12.  I've said this before and
>>>  I'll say it again ..there are serious policy issues here
>>>  with public safety officials if the protocol can permit the
>>>  Policy Maker to override legitimate requests for identity
>>>  information.  This is not the wiretapping issue ... on
>>>  issues involving public safety state and federal regulators
>>>  WILL take a very very firm stand. Therefore the language
>>>  should be changed from MUST to MAY be able hide real
>>>  identity.

>> I agree that our specification has to comply with public safety
>> state and federal regulations, and we have to be clear on this.

>  please ... I have splinters on my rear from sitting on
>  ancient government issue chairs trying to explain these
>  kinds of things to them.

Well, on the other side public regulations will enforce us to
provide privacy. How do you want to explain that to them?

<snip>

>> It is indeed an apparent contradiction that you want
>> on one side authentication and on the other side privacy. But
>> you can have both.

>  Thank you very much !

Thank you too! Regards, 

Jorge