Re: [Geopriv] LoST features

From: Andrew Newton ^lt;>
Date: Thu Aug 31 2006 - 14:11:55 EDT

Is LoST a GEOPRIV item? My comments follow your message for the sake of
people on the ECRIT list.

Rosen, Brian wrote:
> In NENA, we're talking about using LoST as a way for a PSAP to get the
> right responders for a location. In North America, there is one number
> (in most, but not all jurisdictions), 9-1-1. If you ask for the
> sos.police service, with a location in New York City, you will be given
> the sos, 9-1-1 response.
> What we would like is if the PSAP makes the same query, it would get the
> URI for NYPD.
> It might also be used for a multilevel routing decision, where a user
> query got you to a high level (say, a state-level) ESRP, which reran the
> query itself (same service, same location) to get the actual URI of the
> This means (only) that the response depends on the identity of who is
> asking.
> I have advocated that the query could be restricted to a secure
> connection (TLS or IPSEC), and the authentication information for that
> could be used to make an authorization decision on what to return.
> Does this seem reasonable enough that the document could say the
> response MAY depend on the identity of the requestor, and the identity
> MAY be the identity supplied for a secure connection to the server? I'm
> not sure we need anything else.

I'm not to wild about the concept in general, but I'm certainly against how
you want to implement it. You are counting on the TLS stack to do client
authentication, but what this means to a lot of TLS libraries is that no
client authentication results in no query. I do not believe that is a
desirable behavior. In fact, I thought we had as a requirement that LoST
queries can come from anywhere... and as we all should know by now, there is
no universal PKI.

I'd rather an optional authentication id be passed in with the query, from
which the LoST server can make any special authorization decisions.


Geopriv mailing list
Received on Thu, 31 Aug 2006 14:11:55 -0400

This archive was generated by hypermail 2.1.8 : Thu Aug 31 2006 - 14:29:02 EDT