I don't believe you are comparing use cases, you are comparing mechanisms.
The use cases are more simple.
1) A target discovering it's location (TDIL)
2) Third party discovering someone else's location
more in-line.......
-Marc-
On 9/17/09 10:20 AM, "Alissa Cooper" <acooper@cdt.org> wrote:
> Before we get back to the terminology question that Marc has raised
> regarding LCP, it might be useful to map out the use cases we are
> discussing to see where the real differences are. I have made an
> attempt below based on the recent discussions -- are these the
> distinctions that we should be making?
>
>
> In the rough process for an LS providing location to an LR, the LS:
>
> 1. Authenticates the LR.
> 2. Checks whether the LR is authorized to receive the location it
> requested.
> 3. Provides the location if the LR is authorized.
>
> I think we have four basic use cases that we've been comparing.
>
> I. In DHCP, the steps above are as follows:
This mechanism can only fulfill use case #1
>
> 1. Authentication: based on DHC
> 2. Authorization: implicit because LR is the Target
Authorization: Rulemaker: well-known TDIL policy
> 3. Provide LI (per 3825 or 4776) or location URI pointing to LO (per
> dhcp-lbyr-uri)
>
> II. In the base HELD protocol, the steps are:
This mechanism can only fulfill use case #1
>
> 1. Authentication: return-routeability of IP address
> 2. Authorization: based on Rule Maker rules (which may be equivalent
> to the "LCP policy" of only providing a Target with its own location,
> or may forbid even that for certain Targets, per Martin's email [1]/
> held section 9.3)
Authorization: Rulemaker policy (most cases = well-known TDIL policy)
> 3. Provide LO or location URI pointing to LO
>
> III. For a Target using a HELD identity extension to obtain its own
> location, the steps are:
>
> 1. Authentication: required, but we can't mandate anything detailed
> since it depends on the identifier presented (per Richard's email [2])
Authentication: Required, regardless how difficult
> 2. Authorization: based on Rule Maker rules (which may be equivalent
> to the "LCP policy" of only providing a Target with its own location,
> or may forbid even that for certain Targets, per Martin's email [1]/
> held section 9.3)
Authorization: Rulemaker policy
> 3. Provide LO or location URI pointing to LO
>
> IV. For an LR using a HELD identity extension to obtain some other
> Target's location, the steps are:
>
> 1. Authentication: required, but we can't mandate anything detailed
> since it depends on the identifier presented (per Richard's email [2])
Authentication: Required, regardless how difficult
> 2. Authorization: based on Rule Maker rules
Authorization: Rulemaker policy
> 3. Provide LO or location URI pointing to LO
>
> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg07874.html
> [2] http://www.ietf.org/mail-archive/web/geopriv/current/msg07880.html
>
>
>
>
>
> On Sep 17, 2009, at 8:21 AM, Marc Linsner wrote:
>
>> Martin,
>>
>> 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]
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
