Subject: RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]

From: [email-masked]
Date: Tue, 9 Sep 2003 00:12:22 +0300

Hi,

Jonathan Rosenberg wrote:
> As such, the best we can do is avoid dependencies on encoding details 
> (such as whether placetype is put in a status or future-status 
> element). I would suggest that the best way to do this is to allow 
> filters and authorization policies to point at rpids and pidf 
> elements 
> by element name, no matter where that element appears in an XML 
> document. So, if I don't want people to know my geoloc, I would 
> specify an auth policy that blocks "placetype".

I completely agree with this. Element-level control is sometimes necessary. It would also be good if the presence server doing the authorization/filtering did not have to understand the meaning of the elements, but it could just do dumb comparisons.

What I've heard from people is that XPath allows you to do also this kind of "multi-level" matching, so you would not have to know exactly where "placetype" can occur. If this is really true, is there any reason why not to take it as the solution. It is not a major problem to define something just for this purpose, but if XPath works, why not use it. 

Markus 

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 07 September, 2003 07:53
> To: Henning Schulzrinne
> Cc: Khartabil Hisham (NMP/Helsinki); [email-masked]; 
> [email-masked]
> Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes 
> for IETF #57]
> 
> 
> 
> 
> Henning Schulzrinne wrote:
> 
> > I agree that we seem to need to ways of identifying information:
> > 
> > (1) syntactically, for fine-grained control; after all, 
> someone may well 
> > be prepared to reveal the type of place they are in, but 
> not the actual 
> > location.
> 
> Fair enough, thought I don't think I would call this "syntactic".
> 
> > 
> > (2) semantically, where we label each piece of information 
> as being part 
> > of one or more broader classes, such as "where am I" and "what am I 
> > doing" or "what device capabilities do I have" or, as another axis, 
> > "present" and "future".
> > 
> > Beyond the obvious location identification, it might be 
> useful to go 
> > through the set of PIDF and RPID (and related document) 
> items to see if 
> > they are amenable to such a grouping. If each group has one 
> element, 
> > this approach isn't too helpful.
> 
> I thought about this a bunch.
> 
> The conclusion I came to is that, in many cases, the types of 
> authorization policies that users will want are those which block the 
> ability of a watcher to deduce a specific fact. For example, 
> if I take 
> a day off, and don't want my boss or colleauges to know it, I will 
> want my presence to be structured so that no one can figure 
> out that I 
> am not working. This would mean, for example, that if I am sleeping, 
> this activity value should not be shown to watchers.
> 
> My geolocation concerns were similar. I think what users may want is 
> the ability to say "I don't want people to know where I am". Many 
> possible presence elements can reveal this - including ones like 
> activity and privacy, which reveal indirect clues about location.
> 
> Unfortunately, I don't think its practical to have authorization 
> mechanisms which require the server to figure out what rpid elements 
> are needed to deduce a specific fact.
> 
> As such, the best we can do is avoid dependencies on encoding details 
> (such as whether placetype is put in a status or future-status 
> element). I would suggest that the best way to do this is to allow 
> filters and authorization policies to point at rpids and pidf 
> elements 
> by element name, no matter where that element appears in an XML 
> document. So, if I don't want people to know my geoloc, I would 
> specify an auth policy that blocks "placetype".
> 
> 
> > 
> > Another approach (3) is to have a scale of privacy concern 
> or 'presence 
> > resolution', i.e., establish some default ordering, from 
> "OPEN/CLOSED" 
> > at the low end to "every new item that I publish" at the 
> high end, with 
> > no more than half a dozen levels. Each new element would 
> then be labeled 
> > as falling into one of these groupings.
> 
> I agree this is a great idea. In fact, I had exactly this kind of 
> thing in mind for the compound permissions.
> 
> > 
> > I think both (2) and (3) have the distinct advantage that 
> they are far 
> > easier to explain to users than dozens of checkboxes for each 
> > RPID/geoloc/PIDF element. (3) is roughly similar to the 
> privacy slider 
> > in the Internet Options menu for IE, for example. There is no 
> > requirement that everybody agrees with an ordering, just that it is 
> > plausible for the majority of use cases. Advanced users can click 
> > through to the per-element include/exclude list.
> 
> I agree that we don't want users to click on checkboxes for each rpid 
> type. I think you might have a checkbox for "don't reveal my 
> location", and when its selected, the client generates an xcap-auth 
> document which blocks a whole bunch of elements, each listed by name. 
> This may require us to produce a use case document that helps folks 
> figure out what types of facts users might want to control, and what 
> elements are involved in computing such facts.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple