RE: combination of location and identity

From: Reinaldo Penno ^lt;reinaldo_penno@nortelnetworks.com>
Date: Thu Jul 12 2001 - 20:33:21 EDT

Hi Valentin,

comment inline.

> -----Original Message-----
> From: Valentin Christoph [mailto:christoph.valentin@siemens.at]
> Sent: Thursday, July 12, 2001 6:01 AM
> To: geopriv@mail.apps.ietf.org
> Subject: RE: combination of location and identity
>
>
> Hello all,
>
> I agree with Mr. Hauser's theses and I'm also glad that I
> have found this
> WG.
>
> About the proposal to distinguish between the location and its
> "representations", I suggest to consider the following
> representations:
>
> - geographical coordinates (with or without altitude),
> maybe plus time
> coordinate
> - postal address
> - telephone number's country/city prefix etc.
> - access network specific identifier
> e.g. CGI/SAI (cell global identifier/Service Area
> Identifier of a
> GSM/UMTS network)
>

We also have to differentiate between local vs global significance. Postal
code 95345 in USA probably has several counterparts all over the world.

> I also agree with Mr.Takahashi, who wrote on July, 2nd: "I
> think, in first
> place, we need a common understanding on what are
> location-based services to
> discuss security and privacy."
>
> I suggest the following preliminary list of procedures using location
> information:
>
> 1.) Location information associated with a common resource
> Some Internet Resource (HTML document) is indexed by
> geographic coordinates
> (or another representation of location). This case is considered in
> draft-daviel-html-geo-tag-05.txt.
> Such a document could for instance, be a contract, which is
> associated with
> time and space coordinates (WHERE and WHEN did the
> contractors sign it) and
> which is made available for the public.
> It could also be a restaurant guide or something similar,
> which has only
> significance in a distinct region, but is of public interest.

I read your draft, very interesting. What we should also be aware is that if
I document is cached, the cache should update the geo tags.

>
> 2.) Request location information associated with a static
> interface/node.
> This case is considered in rfc1876, where is described, how
> to incorporate
> geographic information into the DNS.
> This information is useful for the network operator, but it should be
> accessible in a very restricted manner, because serious
> damage of network
> infrastructure could result from a wrong person getting this
> information.

This has been around for a while. Of course is some form of geo location
service, but this information is considered very risky. I do not think
people will actually implement it.

>
> 3.) Request location information associated with a mobile interface
> (notebook, mobile phone, router in an airplane...)
> This may result in a lot of nice applications, but there has to be the
> permission of the owner of the interface to reveal this location
> information.

Permission from the owner is a must. If we think about car and airplanes
bombs, kidnapping, etc we become to grasp how a geo service can really do
damage. Do you remeber some years ago during the internal russian war that
separatist which was killed based on his celular location?

>
>
> 5.) Request location dependent information from a given
> provider (server).
> This is similar to case 1., but a trustet relationship
> between the provider
> and the requestor is assumed. On the one hand the provider
> guarantees, that
> nobody else gets the information about which place the requestor is
> interested in, on the other hand the requestor is authenticated and
> authorized to get this information (and he will pay for it -
> accounting).
>
> 6.) Anonymous push services
> Depending on the change of the current location (of the
> terminal equipment),
> a user gets publicly available information in an anonymous manner.
>
> 7.) Authorized push services
> Depending on the change of the current location (of the
> terminal equipment),
> a user gets information which is provided to a specific group.

6 and 7 have great potential.

>
> Best Regards
> Christoph Valentin
> SIEMENS Austria
> Program and System Engineering
>
regards,

Reinaldo
Received on Thu Jul 12 20:33:31 2001

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