I do hope you realize that stating 'no LCP' does not prevent a target from
discovering it's own location using identity-ext. The characteristic of
'LCP' is that the communication protocol provides assurances to the LIS the
request is from the target. Identity-ext cannot do this. So, if the LIS
can go off and verify the request is in fact from the target using some
'out-of-band' mechanism, great, the LIS can then chose the proper policy.
So, from a policy POV, identity-ext (by itself) CANNOT be a LCP.
BTW, I'm still bothered by the assumption of 'LCP Policy'. Such a policy is
still under control of the Rulemaker(s). GeoPriv does not dictate 'LCP
Policy'.
-Marc-
On 11/12/09 9:58 PM, "Winterbottom, James" <James.Winterbottom@andrew.com>
wrote:
>
>
> 4. HELD Identity Extensions
> draft-ietf-geopriv-held-identity-extensions
> Martin Thomson presented an update on this document. The primary open
> issues are around how authentication and authorization are applied.
> Cullen Jennings expressed concern that current text on authenticating
> ownership of identifiers is not implementable. The authors agreed to
> restrict usage to limited cases with pre-configured authorization
> relationships, except possibly for some cases the document can provide
> clear, implementable guidance.
>
> [AJW] Absolutely NOT TRUE! I voiced a very strong protest to this in the
> jabber room. I agree to this ONLY for the identifiers that cannot have an
> explicitly verifiable link back to the Target IP address. I have provided one
> very good example of where this is the case. I will look at the others and see
> if there are similar scenarios. But please, the comment above about the
> author's agreeing is false and what is stated was not the outcome.
>
> Cheers
> James
>
> _______________________________________________
> 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
