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

From: Cuellar Jorge ^lt;Jorge.R.Cuellar@mchp.siemens.de>
Date: Wed May 22 2002 - 16:26:40 EDT

Richard Shockey writes:

> 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.

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.

> 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.
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."

> It strikes me there are two key requirements here which is
> 1. a Location Object which is the semantic expression of

You mean syntactic?

> 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.

Yes, the Location Privacy Object is what we call the "policy".
But I would also agree with the name " Location Privacy Object".

> 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).

How the Location Server indexes his Objects
may be out of our scope.

> 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.

That would be acceptable, as long as the transport protocol
obeys the rules attached to the Location and Location Privacy
(Policy) Objects.

> 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.

I know of other applications that would need this...

> 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.

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.

> 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.

Perhaps there are other ways of doing this, ...

> 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.

Yes, the document is way too long and has to be reduced to
a reasonable minimum. Many parts in it's current form
are meant only for discussion.

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

The index key, if you need one, is probably the Target ID,
which could be a telephone number. Although for the behavioral
description of the protocol it does not seem to be necessary
to specify how the Location Server manages internally
his Objects.

> TTL

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.

> Latitude Longitude

We need one format for location, but of course there are
many options: "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."

> Source

What is this exactly? (The name of the entity that provided
the Location Information in first place, that is, the
Location Sighter (LoSi) or Location Data 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.

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

> 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.

> 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.

Yes, and health records are subject to lots of privacy regulations.
Not only the patient needs to be protected, also the doctor for
instance. It is indeed an apparent contradiction that you want
on one side authentication and on the other side privacy. But
you can have both.

Regards,

Jorge
--------------------------------------------
Dr. Jorge R Cuellar T +49 89 636-47 585
Security
CT IC 3
Siemens jorge.cuellar@mchp.siemens.de
----------------------------------------------
Received on Wed May 22 16:30:44 2002

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST