Scenario Analysis (was Re: Requirements Document)

I think another point to consider is whether services are location-oriented
or target (object)-oriented.

Target-oriented services: Requesters request for the location of particular
targets. "I want to know where John is". Requesters send the target
identity and service providers (maybe John or John's delegate) respond with
the target location.

Location-oriented services: Requesters request for the information about
particular places. For example, "I want to know who of my colleagues are in
the district X." Requesters send the location and Service providers (or
delegates) respond with target identities.

In either case, the important point here is to avoid disclosing
correspondencies between identities and locations. The location information
itself (e.g. a pair of longititude and latitude) is meaningless without ties
to the identities in many cases. So strong encryption of location
information (or longitude and latitude) is not neccessary, which reduces
computing costs in anonymized location-oriented services (you have to search
for psuedo-named targets using location as search-key in the database).
This is pretty different from encryption in other services - for example,
mail or music content delivery, in which content itself is valuable and
needs strong encryption.

PS. Let's use meaningfull subject titles...

Regards,

Kenji
NTT Labs.
Tokyo, Japan

----- Original Message -----
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: <ned.freed@mrochek.com>; "'John W Noerenberg II'" <jwn2@qualcomm.com>;
<geopriv@mail.apps.ietf.org>
Sent: Saturday, August 25, 2001 12:31 PM
Subject: Re: Requirements Document

> I believe that one part of the communication problem we seem to be
> having is that different people seem to have very different models as to
> where and how various pieces are to be used. As far as I can tell:
>
> - Some seem to look at objects (presumably meaning pieces of text or
> binary information) carried in existing protocols, with the location
> object injected by the requestor ("client").
>
> Here, the sender - human or its agent - primarily needs to be sure that
> it reveals the information it wants to the party it thinks it is
> revealing it to. As I tried to say before (and Brian has been arguing, I
> believe) is that this case is primarily a UI issue, once the identity of
> the object-receiving side has been verified. (I'm being very loose with
> the term identity here since it may well be the case that I don't care
> about the precise name, but rather some authorization or credential.)
>
> HTTP is only one of many such examples, with SMTP, RTSP and SIP being
> other obvious candidates, in addition to the various emerging
> presence/IM candidate protocols. (DNS is not very interesting since it's
> designed as a repository of public information, so worrying about the
> privacy of information contained in DNS seems somewhat besides the
> point.)
>
> - others think of existing protocols, with location information injected
> into these by some intermediate entity (e.g., a proxy cache in the case
> of HTTP or a MTA in the case of SMTP or a proxy in the case of SIP);
>
> - others seem to focus on entities being queried by third parties for
> their location, possibly as part of some larger exchange (e.g., HTTP
> request generates a separate query for location, rather than including
> the information in the original request).
>
> I'm sure I'm missing other scenarios that are implied in people's
> responses. We want to be model-independent in our requirements, but
> without at least some common understanding, requirements tend to be
> colored by how people see this stuff working in practice.
>
> The interesting part will be, I believe, for the first and to a lesser
> extent second case, is whether existing authentication mechanisms, for
> example, are sufficient or whether new mechanisms are needed. I don't
> think we need (or can) settle this now, but I wouldn't want to assume
> that we need new mechanisms, given that most application-layer protocols
> carry other information which also has concerns about privacy or
> authenticity.
>
> Since we seem to be talking past each other, maybe some example protocol
> scenarios (not details) might get everyone on the same page.
>
> Henning Schulzrinne http://www.cs.columbia.edu/~hgs
Received on Tue Sep 4 01:51:58 2001