Subject: RE: Back to terminology

From: Cuellar Jorge <[email-masked]>
Date: Sun, 17 Feb 2002 23:43:53 +0100

Kenji, Axel,

thank you both very much for your remarks, they are very helpful.  I was
expecting to see some more discussion, particularly on "target", not being
necessarily a device, and on "owner of the privacy rights".  Perhaps this
discussion will still come...

In the next couple of days I will present a revised terminology proposal,
but this mail first some comments on your remarks: 

Axel wrote:

>  Whether or not a "(private) location recipient" is "ultimate" or a
>  "location server" (it has to be one of these two) seems to be mainly
>  a question of roles and business models.  From a technical point of
>  view, what we should focus on is _policies_.  Using policies, the
>  "owner" could specify whether or not it allows a "(private) location
>  recipient" to further pass on the location information to third
>  parties, or not.

In principle, I do agree.  In an abstract view, there is no difference
between ultimate location recipients or location servers: they just react to
the policies of the owner.  But when you look more concretely and you are
worried about how things will be implemented, a difference appears.  You may
argue that the difference I am making is not at the abstract requirements
level, but is biased towards an implementation.  Yes, perhaps I would agree,
but still I think we need to do this.  It all depends on your abstraction
level.  As soon as the requirements are concrete enough that to the point
where you say: "the location recipient has to verify the authenticity of the
policies of the owner", this distinction becomes important.

The point is that some entities, if they do not forward the information
directly or indirectly, then perhaps they do not have to be aware of the
full privacy policies of the owner.  All they have to do is to comply with a
set of "standard" policies, namely: they will not pass the information, or
save it, or link it, and they will delete it after a rather short period of
time (max. some hours), etc.  Those "standard" policies, which still have to
be stated in detail, are independent of the target or owner, in the sense
that they apply to _all_ targets (in the case of an ultimate location
recipient).

From an informational-theoretic point of view, the "standard" policy I am
referring to is very much like the "least" or "bottom" policy: it allows the
least.  (Roughly, information location is ordered: the better the accuracy,
the more information you have.  Policies may be written as assertions, each
one telling that a set of receivers under some conditions, may obtain
location information.  Thus policies are also ordered.) 

> An entity that acts as a "location server" by your definition always
> takes on the role of a "(private) location recipient" at the same
> time (otherwise it wouldn't possess any location information to
> begin with).  An "ultimate location recipient" is an entity that
> assumes the role of a "(private) location recipient", but not the
> role of a "location server".  Therefore, one of these three terms
> seems to be redundant.

My intention was to have Location Receivers to be exactly the disjoint union
of Location Servers and Ultimate Location Receivers.  (I do not think that
one of the three terms is redundant). 

Kenji wrote:

> I think the entire description, especially Location server,
> is based on the pull scenario (I hate this word...). Don't
> we need to consider the scenario in which the owners take
> initiative to send their location to trusted parties, for
> example, sending the location to family, in case of
> emergency?

Yes. There are still other scenarios.

> In the terminlogy, one target has only one owner. That
> means that, in case of group ownership, a person represents
> others.  This may be a big design decision but I think there
> should be a work around in implementation.

> I agree with Axel on Item 5.  To me, the police and others
> are just Recipient with special authorization class.

Axel wrote:

> Number 6 is completely obsolete, IMHO.
> Why would you want to treat an access network operator
> differently from any other entity?

Kenji wrote:
> - Could you explain Item 6 in further detail?  It does not
> seem to be carriers, since you mentioned them in the
> Location Data Source description.  Then what are they?

OK.  My distinction between the different types of Location Recipients
("private", "lawful" (= "regulatory") and "operational") is quite premature.
At some point or other we will have to consider that not all types of
recipients will be subject to the same laws or policies (as Axel writes: ...
these [policies] would specify that certain properly authenticated "lawful
location recipients" are always authorized to get any location information
they ask for.  These policies would have a higher priority than those of the
"owner", i.e. the owner cannot override them.).  I anticipate that not only
"lawful" (= "regulatory") location recipients but also "operational" ones
will be treated differently than ordinary ones.  In this case I agree, this
distinctions do not have to be made yet, (and perhaps are not the correct
ones).

Kenji wrote:
> Just to cofirm...  When asking my carrier for my location
> with my cell phone:
>      + I am the Owner and (private and ultimate) Location Recipient
>      + The cell phone is the Target
>      + The carrier is Location Data Source and Location Server

Yes, you are right. But also you (not your cell phone) _could_ be
the target.

Best regards,

Jorge

---

From: Randall Gellens <[email-masked]>
Date: Tue, 19 Feb 2002 14:19:55 -0800

At 11:43 PM +0100 2/17/02, Cuellar Jorge wrote:

>"the location recipient has to verify the authenticity of the

I'm not sure that we need to get involved in the policies themselves, 
including how they are authenticated.  Maybe at a later stage, after 
the initial work is done.  As long as our work allows policies to be 
specified and enforced, in a way that meets our requirements for 
security and privacy, I think that may be enough to start with.  In 
fact, we must (per our charter) start with the requirements.

>("private", "lawful" (= "regulatory") and "operational") is quite premature.

I especially do not want to get into any awareness within our work of 
legal or regulatory issues.  I think that can easily become a rat 
hole.  This is one reason to avoid getting into policy details.

>recipients will be subject to the same laws or policies

I'd like to avoid doing that.  If an operational entity is forced by 
law or regulation or contract to impose constraints on the policies 
of its users, that's their business.  As long as our work permits 
this to occur, it needn't concern us.

>certain properly authenticated "lawful
>they ask for.

This is a detail of a policy.  If we stay out of such matters, we 
avoid a great deal of complexity.