Valentin Christoph writes:
> I really like the approach, that the
> transformation from location data (LD) to location
> information (LI) is always done in the domain of
> the owner of the target. This because I - or
> better - the operating system of my mobile device
> always knows about the LI currently available on
> the location server, so I have full control about
> my location information.
> On the other hand, there is always an amout of LD
> available in the domain of my access network
> provider - be it my address including the
> "building" and "floor" in the case of an IDSN or
> normal telephone service provider or be it the CGI
> (global cell identification) in the case of a
> mobile network operator.- So I have to have a
> certain amount of trust into my access network
> provider anyway.
> If now the Location Server is run by the access
> network provider, there might be a more efficient
> way to provide the LD via a proprietary interface
> to the Location Server, which then has to
> transform the LD directly into FLI.
> To support this approach, another arrow "LD *****>
> Location Server" in figure 1 would be enough.
This is only the case for certain types of accounts
on certain types of access networks. But indeed, this
case will probably be even more important in the future.
The intention of the draft (perhaps not
sufficiently explained and discussed) is that
besides the target or the owner of the target,
another part of the network may send location data
(call it location information at this point) to
the Location Server. This may be within the the network
access provider or elsewhere. A few paragraphs
before Figure 1 it reads:
Also some network entity, properly authenticated and authorized
by the network, may send the Location Information to the
Location Server. This could be some location detection function
in the access network. The authentication /authorization
requirements for this case are for further discussion. This
case is different from the owner of the target, since there is
no close relationship between this network entity and this
particular target.
Now, there are two small problems with the whole
construction: yes, you have some degree of trust
on your access network provider (or, more
generally on some "properly authenticated and
authorized network entity" that is able somehow
to read your position), but this does not
necessarily cover the privacy expectations that
you have. This network entity (say, in the the
network provider domain) is authorized "somehow"
to know your location, (de facto he knows your
location) but you do not want in general that he
decides on his own to whom he wants to send your
current location. This is why you do not want this
network entity to decide which policy applies to
your location information. Thus this problem is
easily solved.
The second problem is: how do you know that the
network entity in question is indeed authorized to
send the location information to the location
server? Since the location server (if it complies
with the geopriv protocol) is not going to misuse
the data, the question amounts to: how does the
location server know that the location data is
correct? In the case of the owner of a target the
solution may be simple: the owner knows the
credentials that are needed to impersonate the
target. But in the case of a "network entity"
totally outside of the domain of the target, this
has to be more carefully studied.
In the case that both, the "network entity" and
the location server are run both by one single
access provider, there may be a solution based on
their close relationship, via a propietary interface
as you say, but this does not seem
to be the general case.
This is why this topic is left in the draft as
"for further discussion".
Best regards,
Jorge
Received on Tue Nov 27 18:08:29 2001
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:22 EST