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

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
              greening@bigtribe.com +1(415)995-7151 fax 995-7155

-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: Thursday, May 16, 2002 3:00 PM
To: Richard Shockey; Allison Mankin; ietf-geopriv@mail.apps.ietf.org
Cc: ned.freed@mrochek.com; rg+ietf@qualcomm.com
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:
>
>>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.
>
>
>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.
>
>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.
>
>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.
>
>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.
>
>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.
>
>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.
>
>
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>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: rshockey@ix.netcom.com> or
><mailto: rich.shockey@neustar.biz>
><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
Received on Fri May 17 23:30:29 2002