We still have a disconnect.
LCP is one mechanism that assists the function whereby a ‘targets discovers it location’ (TDIL)
The LCP mechanism is specific to the action of the communication protocol ensuring the requester of location is the target. That is/was the agreed to definition by the GeoPriv community.
Identity Extensions does not/can not employ the LCP mechanism.
The policy you want is the ‘TDIL policy’.
I suggest you divorce the term LCP from the Identity Extensions draft. I earlier suggested that LCP be mentioned in the draft as a comparison such to draw functional parallels. Now I’m wondering if that’s even necessary.
-Marc-
On 9/16/09 8:05 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
I wouldn’t go so far to label LCP as an aberration (more below), but I agree with the basic message.
I hope that HELD makes Marc’s point absolutely clear:
The LIS MUST
verify that the client is the target of the returned location, i.e.,
the LIS MUST NOT provide location to other entities than the target.
Note that this is a necessary, but not sufficient criterion for
authorization. A LIS MAY deny requests according to any local
policy.
There is no such ‘right’. Besides, we’re not in any position to assign any ‘rights’.
I think that the concept of ‘LCP policy’ is a good way to address these concerns. This actually provides a way that we can treat an LCP as part of the architecture.
This is the policy under which we imagine that a LCP server might operate. LCP has all of the functions that are required (requester authentication, privacy protections, rule makers, etc…), it’s just that most of these are hard-coded. However, we need to be absolutely clear when we are making statements that depend on this policy.
And like Marc says, we should never assume that this policy exists; that wouldn’t be right.
--Martin
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Marc Linsner
Sent: Thursday, 17 September 2009 6:52 AM
To: GEOPRIV
Subject: [Geopriv] LCP & Arch....
To add more to my rant about LCP on the interim meeting call yesterday.....
LCP is an aberration of the GeoPriv architecture. Early on, the GeoPriv work group agreed to allow LCP based on the fact the underlying communication protocol would ensure the LCI provided belonged to the recipient. Hence, no work required at the LS/LIS to verify that the requester is the target. It was never agreed that LCP was a ‘function’ that GeoPriv would provide, but LCP is simply an aberration that shares the baggage associated with the GeoPriv Privacy architecture with a communication protocol that can provide the guarantees as described.
Hence, we have created 2 LCP solutions, DHCP and (baseline) HELD. Both these mechanisms protect the privacy of the location data as they guarantee that the target is the recipient. Any mechanism where the communication protocol cannot provide this guarantee MUST be considered ‘not an LCP’ and follow the whole GeoPriv privacy/security architecture (policy set by rulemaker, enforced by LS/LIS, etc.).
My hope is to dispel the myth that LCP is a ‘right’ that target has to gain access to it’s own location data and GeoPriv must deliver on this ‘right’ at all costs. The overall privacy/security architecture must still be followed when a target is discovering it’s own location (trust relationships, identity verification, rule-based policy, etc.).
-Marc-
------------------------------------------------------------------------------------------------
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]
