In-line....
On 9/20/09 9:11 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
>> What am I missing?
>
> Nothing.
>
> We might have a different view of what is necessary for this group to produce
> though.
agree
>
> I think that you are obliquely suggesting that we need to establish a baseline
> for what identity can be used, how it is used, references to the mechanisms to
> employ, etc... All that would be necessary for a Rule Maker to identify and
> authorize arbitrary Location Recipients.
Agree, I believe that is our task at hand.
>
> That's really great if you think that third party requesting is part of the
> end-game architecture. Third parties from all over request location
> information I don't think that. In fact, we'd be wasting our time if we
> pursued that. It's a big problem that isn't worth solving. Not because it
> wouldn't be useful, but because it isn't necessary.
>
> Location by reference solves much of this problem by allowing us to move from
> location configuration (local) to presence (global) where all those sorts of
> problems are in the process of being solved. That's the end-game I'm thinking
> about.
>
> Third party requests don't really figure in this end-game. Third party
> requests exist because we have an immediate need that cannot be addressed by
> the end-game solution. That need has very specific requirements that
> held-identity-extensions addresses.
First, I consider 'third party' to include other contexts than what you are
inferring here. My spouse asking my presence server for my location is a
'third party' request from a RuleMaker pov.
Hence, I have to assume that your use of 'third party' in this context is
probably closer to the previous term used, OBO. So, I assume we are talking
about the need to discover a location on behalf of a location unaware
device, which seems to coincide with what others are asking to solve.
>
> Let me suggest an alternative then. We state the following: the means by
> which authentication of requesters is established is a matter for local
> policy. Tools that are provided include TLS (authentication by shared private
> key, PKI, etc...) and HTTP authentication. If you like, you can authenticate
> based on the source IP of the request if that suits you.
>
> It's all up to the discretion of the Rule Maker.
Before we can agree to the above, we have to agree that HELD identity
extensions is strictly for the use-case described (further) above,
third-party/OBO (we need to pick one term), and can not be used by a target
discovering it's own location from a Rulemaker pov. Hence, HELD identity
extensions is not an LCP. Obviously a target could request a location
associated with an identity that happens to be it's own identity from a
different obscure layer, but since there is no way for the Rulemaker to
ascertain the request is from a target, the only possible policy that can be
applied in this use case, is a third-party/OBO policy.
Let's establish this before continuing.
-Marc-
>
> --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]
> _______________________________________________
> 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
