RE: Authentication/Authorization Issues: Re: [Geopriv] coming to termson location by reference

I think I agree with everything Brian has said here.

The fundamental point being that the LIS has a transitory relationship
with the device in the access network - it is not concerned with the
static identity of the device user.

PIDF-LO is supported by the LIS for the provision of location
information because (a) it's good reuse of the existing specification
and (b) it is complementary to the presence architecture should the user
wish to provide the PIDF-LO to it's presence server it comes pre-baked.
It is not used because the LIS is concerned with the identity the device
may have with a presence service. In fact a LIS is a
device-transient-presence service that uses its own unique,
user-independent, and anonymous identity associated with that device.

Cheers,
Martin

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Thursday, 14 September 2006 12:21 AM
> To: 'Hannes Tschofenig'
> Cc: 'Andrew Newton'; geopriv@ietf.org; Dawson, Martin
> Subject: RE: Authentication/Authorization Issues: Re: [Geopriv] coming
to
> termson location by reference
>
> > One might further detail the scenarios. I was just wondering whether
the
> > Reference Creator has the information to build a PIDF-LO. If there
is a
> > relationship between the Reference Creator and the Target then
things
> > are much simpler. There are, however, some applicability statements
/
> > assumptions around this.
> It can build a PIDF-LO. The question is what identity is provided in
the
> PIDF.
>
> >
> > To address the case where there is no relationship between the
Reference
> > Creator and the Target HELD has taken the approach to upload
identity
> > and privacy policy information to the LIS.
> I think it's essential to have the target control the policy. I think
the
> access network creating an identity that is meaningful to anyone else
is
> problematic and not helpful.
>
> ...snip...
> > > I would think in the former case that:
> > > a) The access network MUST obtain policy from its subscriber in
order
> to
> > > meet Geopriv requirements.
> > > b) The location provided would probably NOT have any identity
> > information
> >
> > entity element in the PIDF-LO = empty.
> Well, at least anonymous
>
> ...snip....
> > Do you think that the access network needs to have possession of the
> > authorization policies ? (as, for example, provided by HELD)
> Yes, I think it does
>
> ...snip...
> > > identity of the target to watch; all he needs is the URL. If the
URL
> > > contains no identity information, which in this case it should,
then I
> > think
> > > everything is okay except the "how do you tell an emergency case"
> > problem.
> > I am not sure that this works. How do you make the differentiation
> > between a PSAP and an arbitrary Location Recipient when they ask for
> > location at the LIS/presence server without authenticating them
first?
> I don't really know how to do this in a way that a protocol can
implement.
> I think you can do it in a way that a lawsuit would work.
>
> Let me point out that if you take the purpose of the location
reference to
> get location AND NOTHING ELSE, then a PIDF with the -LO and
no/anonymous
> identity serves you well. If you want an identity, then I think you
> really
> do have presence, and you should use it, and not create something that
is
> identity+location, but not presence.
>
> Basically, since I don't see how anyone will link an access network's
> notion
> of identity with any other identity (say your AoR for a phone or IM
> service), then I don't think the access network identity is useful for
> anything outside its domain.
>
> Brian
>

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 13 Sep 2006 10:17:19 -0500