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

["Thomson, Martin" <[e-mail]>]

James,

If the Geolocation header isn't linking PIDF documents into signalling, I'm at a loss to explain why it is there at all.

It's becoming more and more apparent that you don't understand how location by reference is deployed.  I believe that this says enough:

> >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...

No one but you has brought up that term.  It's not even relevant to the discussion.

--Martin

> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]]
> Sent: Sunday, 5 July 2009 7:18 AM
> To: Thomson, Martin; [e-mail]
> Subject: Re: draft-ietf-sipcore-location-conveyance-00 : identity
> binding (was: something else)
> 
> 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
> >
------------------------------------------------------------------------------------------------
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]