Re: [sipcore] draft-ietf-sipcore-location-conveyance-00 : identity binding (was: something else)

["James M. Polk" <[e-mail]>]

At 01:14 AM 7/3/2009, Thomson, Martin wrote:
>I can sympathize with your desire to keep everything within the 
>PIDF, but it's just not practical.

That's the way presence it built, and I'm not going to try and change 
that model - not because of a single header value.


>If this were a file transfer protocol, then I can see the sense in 
>being able to ship arbitrary PIDF documents around.

I'm missing how shipping around message bodies isn't just like 
shipping files around...?

Whether it be in an INVITE or a NOTIFY based on a subscription that 
was accepted. A PIDF is something that signaling cannot remain a part 
of (i.e., these are decomposed).

>However, we're talking about attaching semantics to these documents 
>in the context of signalling.

no, we really aren't. The information in the signaling doesn't have 
to be in the message body, and visa versa. For example, if Alice has 
Carol's PIDF-LO, and understands that Alice is allowed to retransmit 
that information and the retention timer hasn't expired, there is 
nothing in the RFC 4119 (or any update) that declares Alice cannot 
tell Bob where Carol is. How Bob determines who is identified within 
a or each document is by the "entity=" attribute within that document.

>The Geolocation header makes a binding between the request and the document.

no, the Geolocation header determines *where* the LO is (local in the 
SIP request, or remote via a dereferencable URI).  The Geolocation 
header also says which SIP entity inserted each location value and 
whether or not that value can be used for routing. It doesn't 
bind  an entity, for 1 reason, because is just isn't that easy to 
accomplish the equivalent of an unlinkable pseudonym - which is a 
requirement for PIDF-LOs based on the rules within RFC 3693. 
Anonymity is just hard in SIP, and not practiced very much (outside 
of gov agencies  ;-)

>That binding had better have some well-understood meaning or this all fails.

It's the binding that's the problem for something that is meant to be 
decomposed.


>If you want to pass around unrelated information, you're free to do 
>so without a Geolocation header.

I do not agree with this on several counts.  a presence document MUST 
NOT be forced to be linked to signaling, is the most important one.


>There are two use cases that make what you propose very difficult 
>from a practical standpoint.  One is a very real problem; the other 
>can be argued to be less so, but continues to plague us, so it's 
>probably still important.
>
>1) If we use your interpretation, then location URIs need to be 
>dereferenced before anyone can even be sure that they are relevant.

Firstly, they shouldn't be if the "routing-allowed" is set to no, 
therefore these entities shouldn't be looking at location at all.

Secondly, if a presence document's entity isn't understood, this is a 
security measure, and maybe the entity owner doesn't want you looking 
at it in the first place (and figuring out how it's about).


>1b) Furthermore, your LS - especially if it is a LIS - might not use 
>the identity that you want.

you define a LIS as a sender of LI (location Information), which has, 
by definition, no identity information -- so there's no "might" at 
all about identity from a LIS. A PIDF-LO has identity information, 
which is why we've gone to great lengths to make the information in 
it secure and private.

>It probably can't.  It is unlikely that a LIS is able to assert that 
>sips:[e-mail] was present at the given location and time.

wow (said sarcastically) -- now you are seeing why I don't believe in OBO...

seriously, a LIS, which you define as a LI provider via an LCP 
(location configuration protocol) such as DHCP or LLDP-MED cannot 
provide identity information, so no, it is the LI recipient - the UA 
- that attaches the identity information to the LI to form a LO 
(Location Object). A PIDF-LO is the one example that's standardized 
now for this. It contains an entity= attribute that the UA places 
it's identity information that is the *binder* of identity to the 
accompanying location information.

I agree that putting unlinked pseudonyms in this attribute can cause 
problems, especially when a SIP request that contains a PIDF-LO wants 
to have that message routed based on the contained location. I am 
going to add text saying this scenario is to be avoided in the next 
rev (-01) of the doc. It isn't there now, and that's a mistake.

>It's going to say that the entity that requested location 
>information at that time was at that location and give them a 
>name...an unlinked pseudonym.

LI doesn't provide identity because LCPs do not provide 
identity.  It's the identity of the UA that attaches identity (even 
unlinkable) to the LI when it forms an LO.


>2) The other is digital signing and integrity.  The binding between 
>location and identity is often made in a context that is unaware of 
>SIP identities.  Therefore, a signed PIDF document might not include 
>an identity that is meaningful in the signalling context.

But what's signed? It's the PIDF-LO *after* the entity= attribute is 
populated. It's the UA that chooses to bind it's identity (i.e., the 
currently registered user to that UA) to the presence document that 
happens to carry a location object.  Remember, RFC 4119 created the 
LO in the existing PIDF, and the entity= attribute was already 
defined in every PIDF (and it's not optional BTW).


>There's no reason that you can't assign meaning to the Geolocation 
>header that says: whomever inserted this header asserts that the UAC 
>is at the indicated location.

The text has always said location can only be conveyed in a PIDF-LO 
(which is part of PIDF -- i.e., presence). In resolving the idea that 
servers can insert location just as UACs can, the text then included 
the inserter= indication is included by the entity that inserted 
*this* locationValue (i.e., location URI by-value or by-reference).

The target identity has always had to be part of the presence 
document. The Location Generator (that's also a Location Server) 
creates the PIDF-LO. In that, is this entity= attribute that can be a 
linkable or unlinkable identity.

>That doesn't necessarily imply that the entity identified in the 
>document is the same as the UAC, or vice versa, all it does is 
>provide a binding between identity in one context (the UAC) and 
>another (the Target of the PIDF).

this means you want to through out the whole idea of unlinkable 
pseudonyms and their beneficial use, because that's what you are 
doing. In order for an unlinkable pseudonyms to still be useful in 
your usage - the SIP signaling will also have to be anonymous.  Have 
you looked at how hard that is? Have you looked at how many header 
values contain linkage to the owner and/or owner's domain? Look at 
RFC 3323 and ask how many have implemented it...


>(In your example, the semantic web folks would assert that a URI 
>tells you nothing, only the context where it appears gives you the 
>information necessary to put it into context.

>Maybe Alice can tell Carol that the location she just received was 
>Bob's location; or it can identify Bob directly.)

err, that's what I've been saying. The Alice to Carol SIP request 
that contains the PIDF that is associated with Bob will have to have 
an entity= attribute that says "this is Bob's document", likely by 
his AOR or Contact address. If Carol doesn't understand that entity= 
indicator, then the document is useless, just as an unlinkable 
pseudonym would be...


>--Martin
>
> > -----Original Message-----
> > From: James M. Polk [mailto:[e-mail]]
> > Sent: Friday, 3 July 2009 3:42 PM
> > To: Thomson, Martin; Elwell, John; [e-mail]
> > Subject: RE: [sipcore] Review of draft-ietf-sipcore-location-
> > conveyance-00 sections 1 to 3
> >
> > >...
> > > > >Then again, the Target-UAC connection still isn't made.
> > > >
> > > > that has been going on in the background, offlist
> > >
> > >Please let me know what the outcome is.  I'm sure we're all
> > interested.
> >
> > actually - I said this below already, and verified this with Mr.
> > Peterson this week.
> >
> >
> > > > >Are we assuming this still?
> > > >
> > > > we can't.
> > >
> > >You'll have to justify that.  I don't only think it's possible, I
> > >think that it's necessary.
> > >
> > > > signaling is easily decomposed from a presence document.
> > >
> > >Sure, but when you remove the presence document it loses any meaning
> > >it might have gained from being attached to the signalling.
> >
> > exactly, and what's the problem with this?  a presence document is
> > intended to be useful on its own, without signaling.
> >
> >
> > > > the target is identified as the "entity=" attribute within the
> > > > <presence> element. Check section 5 of conveyance (i.e., my LbyV
> > > > example) to see.
> > >
> > >The Target is "identified" by the entity attribute, but there's no
> > >guarantee that the recipient can make use of that identifier.
> >
> > exactly
> >
> > >An unlinked pseudonym wouldn't offer any clues.
> >
> > but at this point, this is the advantage. There is no identity
> > information revealed to who doesn't know the pseudonym (which is the
> > point, right?)
> >
> > If Alice doesn't use an unlinknable pseudonym, and uses something
> > that is readable to her identity (like an AOR or contact address),
> > the this presence document is linkable to her identity with or
> > without signaling information.
> >
> >
> > > > Therefore, the target identifier is found there, even if it is an
> > > > unlinkable pseudonym to intermediary entities. If it is not
> > > > understood by the location recipient, then it is ignored because it
> > > > cannot attach identity to it.
> > >
> > >So you are saying that if the presence document contains an
> > >identifier that cannot be linked to the UAC by a recipient, then
> > >that document possibly refers to another entity.
> >
> > not exactly.
> >
> > I'm saying regardless of who signaled the document (for example,
> > whether from Bob to Alice, or Alice to Carol), the entity= attribute
> > identifies to who hte target is for this document without the
> > signaling. If this is Bob's location, he is the target. If it can be
> > linked to him, then both Alice and Carol know this is Bob's target
> > location (no matter who sent it to Alice or Carol).  If this is
> > unlinkable, even if Bob sent it to Alice *and* Carol, neither know
> > this is Bob's target location. They cannot assume this is Bob's
> > location, because they can't verify the identity within the document
> > (which is necessary).
> >
> > Furthering the Alice, Bob and Carol example, let's say Bob told Alice
> > his location, and Alice passed this on to Carol, along with Alice's
> > location. This is possible because the entity= attribute in both
> > PIDF-LO documents that Carol received identify which location goes to
> > which entity (Alice and Bob respectfully). This assumes that Bob set
> > his retransmission-allowed to "yes" or true, and the retention-expiry
> > hasn't elapsed.
> >
> > >A proxy performing location-based routing would ignore the request,
> > >or regard location information as absent.
> >
> > yes
> >
> > this would necessitate a 424 (bad location) response, with a error
> > code set to 100 (cannot process location).
> >
> > I would normally want to add a new error code specifically in the 1XX
> > range indicating the problem specifically is (to the effect of)
> > "received *a* location, but couldn't link this to your location to
> > use for location based routing -- please provide your linkable
> > identity and try again". However, a few of you want me to remove the
> > error section entirely, so adding a new one doesn't make much sense,
> > right? (***even though it would address THIS EXACT PROBLEM***)...
> >
> > <mumble>
> >
> >
> > >I offer a different possibility: that the location information
> > >pertains to the entity that makes the request, regardless of the
> > >identifier used within the document.
> >
> > that links the identity to the SIP request, even if the use doesn't
> > want this link. That doesn't seem right.
> >
> >
> > > > I will take your advice (based on reading RFC 4479) and delete -
> > and
> > > > not mention - the <deviceID> as this is providing too much
> > > > information that might reveal a link to the target's identity.
> > >
> > >Thanks.
> >
> > no problem.
> >
> >
> > >--Martin
> > >
> > >----------------------------------------------------------------------
> > --------------------------
> > >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]
> >
>
>------------------------------------------------------------------------------------------------
>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]