Subject: RE: [SIP] Re: Location information

From: "Mark Watson" <[email-masked]>
Date: Tue, 6 Feb 2001 16:02:08 -0000

The public network will likely be trusted in the sense that it promises to
obey the user's stated privacy requirements, indeed Data Protection
legislation will usually oblige the public network provider to do this.
Also, it will likely be a requirement of the public service that terminals
identify themselves in some way.

I do not think it likely that for Emergency calls, terminals/networks will
behave differently with respect to identity information than for normal
calls except that it will probably not be considered an infringement of
privacy to deliver identity information to an Emergency call centre even
when the user has requested it be kept private.

More complex is how does the public service provider verify the identity and
location information ? In the example above, the public service provider can
only be sure of the owner of the Enterprise network from which the call
came, and this may not translate into a single geographic location. The
network would be forced to send forward only the 'unverified' location
information provided by the caller.

...Mark

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: 05 February 2001 18:48
> To: 'William Marshall'
> Cc: [email-masked]
> Subject: RE: [SIP] Re: Location information
> 
> 
> If I have an enterprise network, and it connects to a public 
> network, then
> the trust boundary may stop at the private/public boundary.  The
> "subscriber"
> is the enterprise, not the individual.  In the privacy draft, 
> if extended to
> location, there is no mechanism to:
> 	Recognize that this is an emergency call
> 	Recognize that the UAS is the emergency center
> 	Pass location information despite any of the requests 
> the UAC may
> make.
> 
> Yet, the requirement is to identify the location of the individual.
> I think the draft has some fine mechanisms in it.  I just 
> don't think they
> are 
> sufficient for emergency purposes.
> 
> Brian
> 
> > -----Original Message-----
> > From: William Marshall [mailto:[email-masked]]
> > Sent: Monday, February 05, 2001 1:31 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [SIP] Re: Location information
> > 
> > 
> > An ordinary call must yield subscriber information.  There is
> > not an option for the user to suppress this, by law (although the
> > user may request this information not be given to the destination).
> > However, the destination can always identify the caller, 
> for purposes
> > of tracing an obscene or harassing call.
> > 
> > Accuracy of location is certainly variable, and it is possible
> > the UA may permit delivery of less precise information, but suppress
> > accurate information.  Multiple levels are just like multiple 
> > identities;
> > the privacy draft as described by Mark in previous email 
> > allows separate
> > anonymity requirements to be attached to each.
> > 
> > Bill Marshall
> > [email-masked]
> > 
> > -----original message-----
> > From: "Rosen, Brian" <[email-masked]>
> > To: "'William Marshall'" <[email-masked]>
> > Cc: [email-masked]
> > Subject: RE: [SIP] Re: Location information
> > Date: Mon, 5 Feb 2001 12:01:48 -0500 
> > 
> > The problem that location presents that is different from the 
> > privacy draft (unless I missed it) is that an emergency call must
> > yield location information.  There is not an option for the user
> > to suppress this, by law.  The path by which a user might connect
> > to an emergency center cannot be pre-arranged.  I believe that it
> > will take creation of a cryptographically secure infrastructure
> > to allow such a system to have the desired property that the user
> > can control location information, but when required it can be
> > securely delivered.
> > 
> > I also think that location is not an "all or nothing" kind of
> > thing.  The privacy draft presupposes that the world is bifurcated
> > into trusted and untrusted domains, and privacy is secured
> > when venturing into an untrusted domain.  This is not the behavior
> > I really want. The desired behavior I want is:
> > 	Accuracy (precision) of location is variable
> > 		I may want to give some people precise 
> > information, others
> > 		less precise.  There will be multiple levels
> > 	Time (and motion) variability - if I am mobile, then where I
> > 		am changes over time.  I need to express this somehow,
> > 		but I also need to control it (not everyone can 
> > be told that
> > 		I am mobile)
> > What we learned in the spatial effort is that the whole 
> location thing
> > is more complex that you would like it to be, and it is hard to get
> > an implementable subset that has enough functionality to be 
> > interesting.
> > We also learned the difficulties in reaching consensus on 
> issues that
> > involve privacy.
> > 
> > Brian
> > 	
> > 	
> > 	
> > 
> > > -----Original Message-----
> > > From: William Marshall [mailto:[email-masked]]
> > > Sent: Monday, February 05, 2001 11:40 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: [SIP] Re: Location information
> > > 
> > > 
> > > Brian,
> > > 
> > > It seems that the privacy draft faces up squarely to the privacy
> > > concerns.  The draft already deals with all the regulatory 
> > > requirements
> > > about verification of identity, hiding of identity, etc.  
> > The security
> > > implications of knowing who you are are just as daunting 
> as knowing
> > > where you are.  In some places regulations already cover 
> > > location info,
> > > and the framework in the privacy draft deals with them.
> > > 
> > > As with the subscriber identity - the UA may insert it, and may
> > > demand (via a tag and a Proxy-Require) that it be kept private.
> > > The proxies may verify the identity, and mark it verified, or mark
> > > it unverified, and must delete the information if privacy was 
> > > requested.
> > > The procedures are all there in the privacy draft, and just need
> > > some minor extensions to handle multiple identity types, and 
> > > per-identity
> > > privacy requests.
> > > 
> > > The previous efforts (spatial) generated a string giving location
> > > information.  Sip uses "name-addr | addr-spec" everywhere, which
> > > includes a display-name string; however a URL format 
> would be nicer.
> > > I was sure I had heard about a URL format with this 
> information, but
> > > can't find any reference to it.
> > > 
> > > Bill Marshall
> > > [email-masked]
> > > 
> > > -----original message-----
> > > From: "Rosen, Brian" <[email-masked]>
> > > Subject: RE: Location information (was Re: [SIP] SIP 
> Privacy Draft)
> > > Date: Mon, 5 Feb 2001 10:44:54 -0500
> > > 
> > > There was an effort started several IETFs ago to define a PROTOCOL
> > > to exchange geographic location.  That was shot down.  
> > There is still
> > > a low level effort to define a format for exchanging such 
> > information.
> > > 
> > > Before starting another effort, you might want to look at 
> the prior
> > > work (spatial).  You also MUST forthrightly face up to the privacy
> > > concerns that have stymied other efforts.  The security 
> > > implications of
> > > knowing where you are can be VERY daunting, and in general 
> > discussions
> > > on the issues have yielded more problems than answers.'
> > > 
> > > Brian
> > > 
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to [email-masked] with
> > > "subscribe sip-implementors" in the body.
> > > 
> > 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to [email-masked] with
> "subscribe sip-implementors" in the body.
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 6 Feb 2001 09:23:37 -0800 (PST)

Mark Watson writes:
 > location information ? 

   In the same way that it authenticates the user so that it
   isn't subject to fraud?

 > In the example above, the public service provider can

   That's not necessarily the case. Assuming that the there
   isn't a fog box in the middle, the UA could sign the
   request which the public service provider could verify.
   Or the enterprise could vouch for the identity of the
   user and/or location much like the PSTN does now.

		Mike