I-D ACTION:draft-peterson-geopriv-pidf-lo-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: A Presence-based GEOPRIV Location Object Format
	Author(s)	: J. Peterson
	Filename	: draft-peterson-geopriv-pidf-lo-01.txt
	Pages		: 16
	Date		: 2003-9-2
	
This document describes an object format for carrying geographical
information on the Internet.  This location object extends the
Presence Information Data Format (PIDF), which was designed for
communicating privacy-sensitive presence information and which has
similar properties.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-peterson-geopriv-pidf-lo-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-peterson-geopriv-pidf-lo-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

I-D ACTION:draft-tschofenig-geopriv-authz-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Location Object Authorization Policies
	Author(s)	: H. Tschofenig
	Filename	: draft-tschofenig-geopriv-authz-00.txt
	Pages		: 18
	Date		: 2003-9-2
	
This document describes a set of policy rules to satisfy Element E
through L of the 'Core Privacy Protections for Geopriv Location
Object' draft. The draft uses XCAP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-tschofenig-geopriv-authz-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-tschofenig-geopriv-authz-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:

Georpiv and actively lying

comments below

** I've added the Geopriv list to this discussion because this thread has 
whittled down to the one issue (lying) and it hasn't been commented on yet 
there, and if a previous WG agreement is being called into question (which 
is OK) - more people should see this discussion

At 05:48 PM 9/17/2003 -0400, Jonathan Rosenberg wrote:

>James M. Polk wrote:
>
>>At 04:02 AM 9/17/2003 -0400, Jonathan Rosenberg wrote:
>>
>>>Henning,
>>>
>>>Also, how does this handle lying? I raised this question on the list as 
>>>well.
>>
>>We had this discussion over two meetings last year and the consensus was 
>>that in Geopriv, we shouldn't explicitly allow lying (as in, defining how 
>>to do it - yet knowing we can't prevent it). That was resolved in the POV 
>>that one can always give "less precise" location information (replying 
>>that I'm in North America (only) when I know I'm at 123 Main St., Dallas, 
>>TX, USA).
>>This is where permissions can be mapped to a template or table that 
>>equates to the level of resolution of the target's location a particular 
>>requester can learn.
>
>That works for geoloc, and can be mapped nicely into the model Henning is 
>proposing. "resolution" can be considered an integer, such that the 

Re: Georpiv and actively lying

Re: Georpiv and actively lying

> >That works for geoloc, and can be mapped nicely into the model Henning is 
> >proposing. "resolution" can be considered an integer, such that the 
> >maximum resolution is the value that is communicated.
> >
> >It doesnt work for presence, and it won't work for geoloc later on when 
> >you do decide to lie. It seems lying is really crucial there too. THe 
> >classic "mistress" problem applies here - if your wife only sees "I'm in 
> >North America" as opposed to "I'm at the office in Parsippany, NJ", the 
> >mere fact that the information has been made less precise conveys that 
> >there is a problem. You need to be able to say "I'm in Parsippany" when 
> >you are really in Las Vegas.

	why is this a need?

	prior work, with roughly the same issues, was debated and
	discussed in the definition of the DNS LOCation RR.
	Then it was deemed ok to specify location with a degree of
	vagueness, e.g. somewhere inside a sphere w/ a radius of 
	100Km vs somewhere inside a sphere w/ a radius of 10cm.
	
	Now w/ geopriv, there has been some historical concern over 
	being able to respond w/ different degrees of accuracy, depending
	on whom is making the request, but I'm not convivnced there is
	a need to build in the capacity to outright lie.

> cheers,
> James
> 
>                  Truth is not to be argued... it is to be presented

--bill

Re: Georpiv and actively lying

James M. Polk wrote:

> Why should we design for permissible lying in an IETF effort?
> 
> If your server or service is configured to give out misinformation, 
> that's one thing - but to build it into the protocol as a requirement 
> lacks technical justification at this point. A compliant protocol 
> implementation shouldn't be required to be able to lie just to be 
> compliant. A protocol that chooses not to be compliant can always 
> misbehave.

No particular protocol effort is required to build a lying 
implementation. In a presence model, I can have my 'alibi publisher' 
publish any Munchhausen location information that I like and then select 
to only propagate that information, rather than my GPS information. (For 
example, using my earlier sphere proposal, designate myself in the 
"mistress" sphere, which automatically only selects data from that 
source, presumably without including the label.) This is functionally no 
different than considering my calendar as an approximate location source.

I would think that in most real implementation, the published location 
information is actually an aggregate of various sources, as they all 
have different strengths and applicability (GPS outdoor vs. 802.11 
indoors, etc.). The current model doesn't support this particularly 
well, but I think it would be helpful to solve that, more generic, 
problem and then treat lying as a special case that people can address 
based on their needs.

This has the great advantage that it is far more powerful than any 
simple, static transformation could be. You can emulate a whole 
schedule, with varying meetings, road trips and what have you, rather 
than pretending to be in your office all day.

To some extent, this functionality already exists with the 'class' 
attribute in RPID. With appropriate selectors, as being discussed right 
now, you can easily include just 'class=madeup-from-whole-cloth' elements.

With this, there is no need to take a moral stand on whether the IETF 
should endorse violation of truthfulness.

Henning

Fwd: Georpiv and actively lying

Forgive (simple) - I didn't include simple in my original response to 
Jonathan's email.

Forgive (geopriv) - for sending a redundant message

just trying to get everyone in sync

>Date: Wed, 17 Sep 2003 17:29:25 -0500
>From: "James M. Polk" <jmpolk <at> cisco.com>
>Subject: Georpiv and actively lying
>X-Sender: jmpolk <at> localhost
>To: Jonathan Rosenberg <jdrosen <at> dynamicsoft.com>
>Cc: Henning Schulzrinne <hgs <at> cs.columbia.edu>,
>         Tschofenig Hannes <hannes.tschofenig <at> siemens.com>,
>         John Morris <jmorris <at> cdt.org>, geopriv <at> mail.apps.ietf.org,
>         geopriv-admin <at> ietf.org
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>List-Owner: <mailto:ietf-geopriv-owner <at> mail.apps.ietf.org>
>List-Subscribe:
>  <mailto:mailserv <at> mail.apps.ietf.org?subject=subscribe%20ietf-geopriv>
>List-Unsubscribe:
>  <mailto:mailserv <at> mail.apps.ietf.org?subject=unsubscribe%20ietf-geopriv>
>List-Id: <ietf-geopriv <at> mail.apps.ietf.org>
>Spam-test: False ; -1.5 / 4.5
>
>comments below
>
>** I've added the Geopriv list to this discussion because this thread has 
>whittled down to the one issue (lying) and it hasn't been commented on yet 
>there, and if a previous WG agreement is being called into question (which 
>is OK) - more people should see this discussion
>
>At 05:48 PM 9/17/2003 -0400, Jonathan Rosenberg wrote:
>
>
>>James M. Polk wrote:
>>
>>>At 04:02 AM 9/17/2003 -0400, Jonathan Rosenberg wrote:
>>>
>>>>Henning,
>>>>
>>>>Also, how does this handle lying? I raised this question on the list as 
>>>>well.
>>>
>>>We had this discussion over two meetings last year and the consensus was 
>>>that in Geopriv, we shouldn't explicitly allow lying (as in, defining 
>>>how to do it - yet knowing we can't prevent it). That was resolved in 
>>>the POV that one can always give "less precise" location information 
>>>(replying that I'm in North America (only) when I know I'm at 123 Main 
>>>St., Dallas, TX, USA).
>>>This is where permissions can be mapped to a template or table that 
>>>equates to the level of resolution of the target's location a particular 
>>>requester can learn.
>>
>>That works for geoloc, and can be mapped nicely into the model Henning is 
>>proposing. "resolution" can be considered an integer, such that the 
>>maximum resolution is the value that is communicated.
>>
>>It doesnt work for presence, and it won't work for geoloc later on when 
>>you do decide to lie. It seems lying is really crucial there too. THe 
>>classic "mistress" problem applies here - if your wife only sees "I'm in 
>>North America" as opposed to "I'm at the office in Parsippany, NJ", the 
>>mere fact that the information has been made less precise conveys that 
>>there is a problem. You need to be able to say "I'm in Parsippany" when 
>>you are really in Las Vegas.
>
>Why should we design for permissible lying in an IETF effort?
>
>If your server or service is configured to give out misinformation, that's 
>one thing - but to build it into the protocol as a requirement lacks 
>technical justification at this point. A compliant protocol implementation 
>shouldn't be required to be able to lie just to be compliant. A protocol 
>that chooses not to be compliant can always misbehave.
>
>
>>As such, I am somewhat surprised this was dismissed.
>
>One argument for this dismissal was that if this were built into Geopriv, 
>the IETF would be actively, explicitly endorsing (through functionality of 
>the base protocol) the ability to lie.
>
>Doesn't seem like something to be proud of, when all is said and done
>
>>I understand its hard, but it seems crucial, no?
>
>There just hasn't been a good technical reason for allowing this into the 
>protocol as a requirement of compliance yet. What I believe you are 
>pointing to is a (debatable) societal reason for this
>
>
>>-Jonathan R.
>>--
>>Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>>Chief Technology Officer                    Parsippany, NJ 07054-2711
>>dynamicsoft
>>jdrosen <at> dynamicsoft.com                     FAX:   (973) 952-5050
>>http://www.jdrosen.net                      PHONE: (973) 952-5000
>>http://www.dynamicsoft.com
>
>
>cheers,
>James
>
>                                *******************
>                 Truth is not to be argued... it is to be presented
>

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

Re: Georpiv and actively lying

inline.

James M. Polk wrote:

> comments below
> 
> ** I've added the Geopriv list to this discussion because this thread 
> has whittled down to the one issue (lying) and it hasn't been commented 
> on yet there, and if a previous WG agreement is being called into 
> question (which is OK) - more people should see this discussion
> 
> At 05:48 PM 9/17/2003 -0400, Jonathan Rosenberg wrote:
> 
> 
>> James M. Polk wrote:
>>
>>> At 04:02 AM 9/17/2003 -0400, Jonathan Rosenberg wrote:
>>>
>>>> Henning,
>>>>
>>>> Also, how does this handle lying? I raised this question on the list 
>>>> as well.
>>>
>>>
>>> We had this discussion over two meetings last year and the consensus 
>>> was that in Geopriv, we shouldn't explicitly allow lying (as in, 
>>> defining how to do it - yet knowing we can't prevent it). That was 
>>> resolved in the POV that one can always give "less precise" location 
>>> information (replying that I'm in North America (only) when I know 
>>> I'm at 123 Main St., Dallas, TX, USA).
>>> This is where permissions can be mapped to a template or table that 
>>> equates to the level of resolution of the target's location a 
>>> particular requester can learn.
>>
>>
>> That works for geoloc, and can be mapped nicely into the model Henning 
>> is proposing. "resolution" can be considered an integer, such that the 
>> maximum resolution is the value that is communicated.
>>
>> It doesnt work for presence, and it won't work for geoloc later on 
>> when you do decide to lie. It seems lying is really crucial there too. 
>> THe classic "mistress" problem applies here - if your wife only sees 
>> "I'm in North America" as opposed to "I'm at the office in Parsippany, 
>> NJ", the mere fact that the information has been made less precise 
>> conveys that there is a problem. You need to be able to say "I'm in 
>> Parsippany" when you are really in Las Vegas.
> 
> 
> Why should we design for permissible lying in an IETF effort?

Privacy, of course.

My concern is that, if the only capability of the system is to dilute 
the accuracy of data, and the level of this accuracy is known to the 
recipients of the data, the mere FACT that the data is not as accurate 
as it could be divulges sensitive information.

Its equivalent to the need for "polite blocking" as we call it, in 
presence. If I don't want you, James, to see my presence at all, 
instead of outright rejecting your subscription, the system accepts 
your subscription and then provides you with false data. If the only 
option were to outright reject your subscription, then this reveals 
senstivite data to you - namely, that I don't want you to see my presence.

Polite blocking is discussed as part of the SIMPLE specifications, and 
we have agreed that the mechanisms for setting authorization and 
privacy policies must allow for a client to tell the system to use 
polite blocking.

Do we need to mandate support for authorization and privacy mechanisms 
that facilitate lying? No. Mandatory-to-implement stuff should always 
be bare minimum, and need not include this. But that doesnt mean that 
the system shouldn't support the capability.

> 
> If your server or service is configured to give out misinformation, 
> that's one thing - but to build it into the protocol as a requirement 
> lacks technical justification at this point. A compliant protocol 
> implementation shouldn't be required to be able to lie just to be 
> compliant. A protocol that chooses not to be compliant can always 
> misbehave.

If it can be done without protocol support, thats great. But, I don't 
see how. In the case where (using geopriv terminology), the rule 
holder and location server are not co-located, there needs to be some 
way to convey that this particular data transformation is desired.

> 
> 
>> As such, I am somewhat surprised this was dismissed.
> 
> 
> One argument for this dismissal was that if this were built into 
> Geopriv, the IETF would be actively, explicitly endorsing (through 
> functionality of the base protocol) the ability to lie.

We have already done that. Quoting from rfc2779 on presence requirements:

  5.1.15. It MUST be possible for B to configure the PRESENCE SERVICE
    to deny A's subscription while appearing to A as if the subscription
    has been granted (this is sometimes called "polite blocking").  The
    protocol MUST NOT mandate the PRESENCE SERVICE to service
    subscriptions that are treated in this manner.

In what way is this not lying?

> 
> Doesn't seem like something to be proud of, when all is said and done

Privacy is about masking or misrepresntation of information in some 
way. I thought geopriv was all about privacy?

-Jonathan R.

--

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen <at> dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

Re: Georpiv and actively lying

Henning Schulzrinne wrote:

> James M. Polk wrote:
> 
> 
>> Why should we design for permissible lying in an IETF effort?
>>
>> If your server or service is configured to give out misinformation, 
>> that's one thing - but to build it into the protocol as a requirement 
>> lacks technical justification at this point. A compliant protocol 
>> implementation shouldn't be required to be able to lie just to be 
>> compliant. A protocol that chooses not to be compliant can always 
>> misbehave.
> 
> 
> No particular protocol effort is required to build a lying 
> implementation. In a presence model, I can have my 'alibi publisher' 
> publish any Munchhausen location information that I like and then select 
> to only propagate that information, rather than my GPS information. (For 
> example, using my earlier sphere proposal, designate myself in the 
> "mistress" sphere, which automatically only selects data from that 
> source, presumably without including the label.) This is functionally no 
> different than considering my calendar as an approximate location source.

We have discussed this in the past as part of the facet header 
discussion in Aki's publication work, and I believe Aki also suggest 
it again somewhere in this thread.

I believe it can work. It has the benefit that it can have lots of 
flexibility. If this transformation is done on the server, you need to 
specify particular transformations that are possible so that the user 
can set them as it desires. THe drawback is that it now requires two 
publishers for a single user just to support this capability. It also 
introduces the need to coordination between those publications, either 
by havign them co-resident, or through some other means. When 
co-resident, say, on a wireless handset, it may increase bandwidth 
usage by sending information which could have been algorithmically 
derived at the server.

> 
> I would think that in most real implementation, the published location 
> information is actually an aggregate of various sources, as they all 
> have different strengths and applicability (GPS outdoor vs. 802.11 
> indoors, etc.). The current model doesn't support this particularly 
> well, but I think it would be helpful to solve that, more generic, 
> problem and then treat lying as a special case that people can address 
> based on their needs.

I think thats a great idea. In particular, the current diagram in the 
requirements document has only a single source of information. Is 
there a desire to change the model to allow multiple sources, and then 
introduce a composition concept in the location server? This is (for 
geopriv folks), exactly the presence model we have in simple.

> 
> This has the great advantage that it is far more powerful than any 
> simple, static transformation could be. You can emulate a whole 
> schedule, with varying meetings, road trips and what have you, rather 
> than pretending to be in your office all day.
> 
> To some extent, this functionality already exists with the 'class' 
> attribute in RPID. With appropriate selectors, as being discussed right 
> now, you can easily include just 'class=madeup-from-whole-cloth' elements.
> 
> With this, there is no need to take a moral stand on whether the IETF 
> should endorse violation of truthfulness.

This is another advantage of this approach, yes.

The fundamental problem, however, has only been masked. Recall that, 
my original concern was that I didn't see how to apply Ted's "Venn 
diagram" style permission model to transformational policies. It 
seemed that you would need to assign a preference to them, so they 
would be applied in a speific order. It wasn't just set arithmetic.

Now, what we have done here is basically take alternative versions of 
the presence/geolocation for a user, compose them together, and then 
allow the permissions to select which pieces go to various watchers. 
However, we are now faced with a case where the presence/geolocation 
object, after composition, contains conflicting information. Lets say 
it contains (now using simple terms) two tuples, one associated with 
my work sphere, and one associated with my home sphere. These tuples 
present conflicting information. The tuple for my home sphere says I 
am not available for calls on my cell, and the tuple on my work sphere 
says I am.

What happens if someone is associated with both home and work spheres? 
They will now receive conflicting information. Is that the result we 
want? You might argue thats ok, since a user in both spheres should be 
allowed to see both perspectives. However, it reveals additional 
information - namely, that the user is explicitly given out 
conflicting information depending on the sphere - and this may not be 
desirable.

-Jonathan R.

--

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen <at> dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

Re: Georpiv and actively lying

At 4:50 PM -0400 09/19/2003, Jonathan Rosenberg wrote:
>Henning Schulzrinne wrote:
>
>>James M. Polk wrote:
>>
>>>Why should we design for permissible lying in an IETF effort?
>>>
>>>If your server or service is configured to give out 
>>>misinformation, that's one thing - but to build it into the 
>>>protocol as a requirement lacks technical justification at this 
>>>point. A compliant protocol implementation shouldn't be required 
>>>to be able to lie just to be compliant. A protocol that chooses 
>>>not to be compliant can always misbehave.
>>
>>
>>No particular protocol effort is required to build a lying 
>>implementation. In a presence model, I can have my 'alibi 
>>publisher' publish any Munchhausen location information that I like 
>>and then select to only propagate that information, rather than my 
>>GPS information. (For example, using my earlier sphere proposal, 
>>designate myself in the "mistress" sphere, which automatically only 
>>selects data from that source, presumably without including the 
>>label.) This is functionally no different than considering my 
>>calendar as an approximate location source.

I'm not sure I follow this.  Does this imply that you use an "alibi 
publisher" to change
your location under certain circumstances and that this location is 
held to be valid
for all watchers?  If so, this requires no special processing in the 
GeoPriv sense; it
simply implies that you can adjust location provider by 
configuration.  If you do intend
it to apply only to certain watchers, then we're back to a serious 
set of issues, including
how to do in-the-moment updates of the rules, how to apply 
transformative rules,
and so on.

>We have discussed this in the past as part of the facet header 
>discussion in Aki's publication work, and I believe Aki also suggest 
>it again somewhere in this thread.
>
>I believe it can work. It has the benefit that it can have lots of 
>flexibility. If this transformation is done on the server, you need 
>to specify particular transformations that are possible so that the 
>user can set them as it desires. THe drawback is that it now 
>requires two publishers for a single user just to support this 
>capability. It also introduces the need to coordination between 
>those publications, either by havign them co-resident, or through 
>some other means. When co-resident, say, on a wireless handset, it 
>may increase bandwidth usage by sending information which could have 
>been algorithmically derived at the server.

This seems to me to be more flexibility than GeoPriv can handle at 
the moment.  The bang for
this buck seems awfully small, and the delay larger than is 
warranted.  Just my opinion, of
course,
			regards,
				Ted