Subject: [Simple] Presence Authorization Rules

From: Goeman Stefan <[email-masked]>
Date: Thu, 23 Sep 2004 17:57:37 +0200

Hello All,

I have been reading the draft on Presence Authorization Rules, and also the
draft draft-ietf-geopriv-common-policy.
I have some remarks (otherwise I would not mail of course).

First of all, the draft on Presence Authorization Rules contracts the
geopriv draft, at least in one place.
In Section 3.2 on Actions, values are given to block, confirm, ... . If you
have two rules for the same entity and you combine them according to the
combining rules as explained in the geopriv draft you end up with the
highest value. Yet, in this case the highest value is the least privacy
preserving. This is in contradiction with the statement on page 21 of the
geopriv draft:
"Furthermore, permissions and the meaning of their values MUST be defined in
such a way that the usage of combining rules CR1, CR2, and CR3 always
preserves or increases the level of privacy protection for the PT". 

One can argue what is wrong here. Personally, I think the statement in the
geopriv draft will not really work well (see also below).

Additionally, wouldn't it also be nice if one could group people into a
class of people and define a rule for that class of people. For example, you
could have a class of friends, family, colleagues and define a rule each of
this class. The problem know arises that one person could belong to
different groups. Then again, the statement in the geopriv draft will not
work well. 
But, the best example I could think of would be the following. Suppose you
have a rule for your friends ([email-masked] belong to this group) and an
separate rule for [email-masked]. Now, why would you create a separate rule
for [email-masked]. I would say to grant him more privileges, not less. I
believe it will be easier to provide limited privileges to groups, and more
privileges to "the happy few". Certainly in this case, the geopriv statement
will not work; it has the opposite effect.

So, In general I would say that the combining rules should be formulated in
a way that it decreases the privacy of the presentity. This comes also from
the fact that it was chosen to use positive rules! The same functionality
could be reached by using negative rules. 

Greetings,
Stefan.

Stefan Goeman 
SIEMENS ICM/ICN
ICM N D SE 
[email-masked]  <mailto:[email-masked]> 
phone:   +32 14 253020 
mobile:  
Fax:       +32 14 22 29 94 

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

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 23 Sep 2004 19:16:09 +0200

# hi stefan, 
 
# please see my comments inline.

Hello All, 

highest value.
# to be more precise the combining permissions algorithms is applicable if
two or more rules fire. 

 Yet, in this case the highest value is the least privacy preserving. This
is in contradiction with the statement on page 21 of the geopriv draft:

# what would happen if jonathan changes the values corresponding to the
listed actions from

Block (0)
Confirm (1)
Polite-block (2)
Allow (3)

# to the following values: 

Block (3)
Confirm (2)
Polite-block (1)
Allow (0)

# now assume that one rule with allow(0) and another one with block(3)
fires. the combining permissions algorithm would result in a block(3)
action. 

# are you more happy with this result? 

Additionally, wouldn't it also be nice if one could group people into a
class of people and define a rule for that class of people. For example, you
could have a class of friends, family, colleagues and define a rule each of
this class. The problem know arises that one person could belong to
different groups. Then again, the statement in the geopriv draft will not
work well. 
# grouping people together can be solved on a user interface basis. There is
not necessarily a need to specify groups in the policies itself (except if
you want to reduce the bandwidth consumption). 

~snip~

# ciao
# hannes

---

From: Goeman Stefan <[email-masked]>
Date: Fri, 24 Sep 2004 11:25:45 +0200

Hello,

Comments inline.

Greetings,
Stefan.

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email-masked]] 
> Sent: donderdag 23 september 2004 19:16
> To: Goeman Stefan; [email-masked]'
> Subject: RE: [Simple] Presence Authorization Rules
> 
> 
> # hi stefan, 
>  

Yes, I understand that, and indeed you need to do something to resolve
conflicts.
 
> # are you more happy with this result? 
In theory, this would be OK. However, I am afraid it is a little bit
counter-intuitive. Suppose you have to groups (and groups make sense,
certainly on the terminal), friends and colleagues, and one person would be
in both groups. In this case you would have two rules for this person.
Suppose that when "not at work" you block everything for colleagues, and you
still allow some things to be seen for friends. In this case, with the
changes proposed above, would be blocked. This I find counter-intuitive. 

I still believe that it comes from combining positive (permit) rules, while
the end result will be less than the origination rules. That is what the
statement in geopriv says; and that is what I find counter-intuitive.
Or, to put it simpler, suppose you have no rules. Then nothing is visible to
other users. Then, you introduce one rule for one person, and something
becomes visible for that person. You introduce a second rule for the same
person, which results in decreasing the visibility again.  

> you want to reduce the bandwidth consumption). 
I don't think that is completely true. It goes further than just the user
interface. Suppose you have your buddy list, which also resides in the
network (see draft on resource lists). The buddy list is partitioned in
several groups, i.e. friends, family, ... . In your authorization policies,
you would have a rule for friends, family, ... . In this case, when a
subscribe arrives, the policy server should resolve the friends, family, and
other groups, by contacting the buddy list server, into the real entities
before you can find matching rules. I can understand that you have
objections to this practice, but it has advantages. If I add an entry in one
of my groups (friends, family, ...), I don't have to change my policy rules.
I don't see how you could solve that only based on grouping people on the
user interface; in this case, I believe you also have to change you policy
rules.

---

From: Goeman Stefan <[email-masked]>
Date: Fri, 24 Sep 2004 11:38:52 +0200

Hello All,

I forgot to mention something. We are talking about policies, but we are not
talking about policy enforcement (or maybe I missed that), which I believe
is also important. 
It does not make sense to block certain forms of communication from
watchers, that when they try that form of communication anyhow, that they
would succeed. This would be very annoying for the presentity.

Greetings,
Stefan.