that it sets up a set of criteria that are ideologically driven and sees
them eroded under the pressure of pragmatism; a pressure that ultimately
wins out.
I'm not sure if you missed my point on the analogies. Your concern
appeared to be that the provision of the "identities" shouldn't be
regarded as trustable for the release of the location information. i.e:
<TED> "I still believe that if we wouldn't buy most of these identifiers
as valid credentials for the release of data in a common security
context, then their use here is symptomatic of the application of a
model that doesn't actually fit here."
My point is that there are plenty of practical situations where the LIS
doesn't need to care whether the device is providing data related to
itself or not. OBO (the term seems to be sticking) isn't an example of
this because the LIS explicitly authenticates the trust relationship
with the third party requester. The specific example is where the
population of devices in the network and the LIS that serves them simply
have no trust issues as far as whether they are providing their own
identity values or not. This is, in fact, a trust relationship between
the LIS and the devices. As with the web pages in the analogy, you can
characterize it as a "We don't care" trust relationship or as a "It's up
to the device what it wants" trust relationship but, nevertheless, the
LIS implementer can be in a position to make that judgement. An
enterprise network is a reasonable example.
Obviously an environment where a LIS cannot but should trust the
identity extensions is not a good environment in which to implement
those identity extensions in the LIS. Obviously a HELD client that
doesn't have an a-priori trust relationship with the LIS shouldn't send
identity information that is considered sensitive. I don't think this is
any different to typical security advice; it's similarly not a good idea
to send genuine authentication details to an FTP server if you're not
sure it's the FTP server to which those details apply.
Cheers,
Martin
-----Original Message-----
From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Thursday, 17 September 2009 12:43 AM
To: Dawson, Martin; Alissa Cooper; GEOPRIV
Subject: RE: [Geopriv] WG2LC:
draft-ietf-geopriv-held-identity-extensions-00.txt
At 1:52 AM -0500 9/16/09, Dawson, Martin wrote:
>Hi Ted,
>
>Just to test the water by analogy... if there's a web page wherein you
>type in your home address and it gives you the location of the
>nearest... say... Ikea, is it a security problem that the web site
>doesn't really know if that's your address?
>
>Maybe that's a bad example because it involves "location"; that's not
>the salient point. If it's a web page where I can type in my age,
>weight, dietary habits etc and obtain an estimate of the probability of
>having a heart attack; is it a security problem if the web site doesn't
>really know if I'm typing in details that are applicable to me?
>
I think the critical point is "doesn't really know". A web page,
obviously,
doesn't know anything. But it's pretty telling that we use the term
identifiers
(or identity extensions) for these bits. They can be long term
identifiers
and they can be used to associate other identities with the information
passed.
How that association might work is opaque to the end user up until the
point
all their google ad words are about blood thinners and their life
insurance rates
go up.
To take a simple example, the geo URI draft has a location example. The
geo URI has no identity associated with the location--yet the draft
notes
in the text that it is the address of one of the authors. The number of
times
it may be possible to bind location to identity is higher than the end
user might think,
and it is particularly important to recognize that it happens more
easily when
you are keying the location off a long-lived identifier (or identity).
I think that means we would be safer making those distributions pidf-lo,
rather than lci; we'd have the opportunity to use the tools pidf-lo has.
Having made one exception, though, the group seems inclined to make
more.
When we made the first one for DHCP, Jon bet me a drink that it would be
the thin edge of the wedge on this issue; I paid off long ago, but it's
probably
time to pay up again. He's been shown to be right on this one again and
again.
regards,
Ted
------------------------------------------------------------------------------------------------
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
