Subject: RE: [XCON] Authorization in conference policy

From: [email-masked]
Date: Thu, 13 May 2004 00:30:20 +0300

Ted,

I guess I agree with all what you say below, but I wasn't able to conclude whether you think that
a) common policy should not be used in CPCP
b) common policy could be used but defining all-except for CPCP makes no sense
c) common policy could be used and defining all-except for CPCP might be OK

(I'm not trying to make a mess with the all-except stuff in all possible cases. I actually like the common policy work a lot, I just think that many conferencing use cases make c) a reasonable approach.)

Some comments also inline. 

Ted Hardie wrote:
> 
> At 11:41 PM +0300 05/12/2004, <[email-masked]> wrote:
> >
> >However, I think the conferencing case is still different. There we 
> >could not really live without the all-except construct. In 
> >conference you don't just protect some data, but you also protect 
> >the conference participants from a misbehaving participant. So 
> >blocking and kicking out a single identity is important and useful, 
> >even if the same person could join later with another identity.
> 
> And I think that is the crux of the question.  In previous 
> discussions,
> the idea that a misbehaving individual could mint an identity at
> essentially no cost meant that creating an "any except" construct
> didn't actually prevent much.  

Well, I still think that in most cases I have in mind getting a new identity with no cost is not possible, so I would surely have use for all-except in general. But I guess that was discussed separately already.

> Your argument seems to say
> that even though it doesn't prevent them from accessing the
> conference, the *act* of kicking them out and blocking them
> has some value in and of itself.
> 

Obviously not if the participants that are kicked out always appear 1 second later again with a new disguise ;) However, I assume that there still would be non-zero cost for getting the new identity, especially measured in time - so even if the person is persistent it maybe possible for the moderator to do _something_ about him.  

> Speaking personally, it seems most likely to be valuable only
> in cases where 1) the individual must mint a new identity (i.e. cannot
> easily use a different, existing identity) and 2) this takes 
> sufficient
> time that the conference proceeds without disruption either to its
> conclusion or for some significant period of time.  I'm not sure about
> the percentage of cases likely to meet both 1 and 2.
> 

OK, I guess we agree here. I certainly have no exact figures, but I believe, and have seen in chat systems such as IRC, that these conditions are in many cases fulfilled. And what is the alternative? Not being able to do anything in any case (than to close the conference for new entries)?

> I guess one question that follows from this is a use case question:
> how often will a conference organizer be able to close a conference
> *completely* to new participants at some point in the conference?
> That would provide a pretty obvious counter to newly minted 
> identities,
> but it seems like it might be a small subset of likely cases. 
>  Any data
> on that?
> 		regards,
> 				Ted Hardie
> 
> 
> 

Markus

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 May 2004 02:20:11 -0400

I think its worth taking a step back and seeing what problems are being 
solved here.

Both geopriv and simple are interested in defining authorization 
policies that are fundamentally related to privacy systems - that is, 
systems which give out information to individuals, where a user needs to 
give permission for information to be seen. The strong need for privacy 
has driven the entire model in common-policy which is based on the 
concept of privacy safety, whereby, in case of some error, less 
information is divuldged rather than more.

In xcon, we want authorization policies that define who is allowed and 
not allowed to join a conference. I do not think these constitute 
privacy systems, and as such, I dont think that privacy safety is a 
consideration here. As Ted points out, there are some commonalities in 
probelm space (dealing with the ease with which a user can mint 
identities), but its still a different problem.

In terms of differences, there are many. For example, the notion of 
transformations in common policy doesnt make a lot of sense in xcon.

As such, I dont think it makes sense to directly reuse common policy so 
much as learn from it and borrow parts of its schema and design where 
appropriate.

-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

---

From: Aki Niemi <[email-masked]>
Date: Mon, 17 May 2004 09:50:42 +0300

Inline.

> information is divuldged rather than more.

True, and conferencing as such is a different application in that a 
participant is usually not merely consuming data, but also providing it 
into a conference. But common policy does also include this mode of 
operation ("active request-response"). And I would argue that privacy 
safety in conference authorization is as important as in presence or 
location.

> identities), but its still a different problem.

I don't think authorization policies in a conference are simply about 
who is allowed and who is in not allowed to join. In fact, I think this 
is simply a precursor to "true" geopriv-style rules where privacy-safety 
is of importance. For example, who can subscribe to conference 
information events or see floor control events. Who, in addition to 
seeing the floors, can request/grant them, etc.

> transformations in common policy doesnt make a lot of sense in xcon.

This also puzzled me at first, but let me give you an example of what 
transformations could look like in conferencing:

<rule id="7aa7c"
   <condition>
     <identity>
       <uri>[email-masked]</uri>
     </identity>
   </condition>
   <action>
     <join-handling>accept</join-handling>
   </action>
   <transformations>
     <key-participant>true</key-participant>
   </transformations>
</rule>

In essence, this would grant joe access to the conference, and tag him 
as a "key-participant", allowing for example the focus to perform a 
dial-out.

This is very well aligned with common policy, since this particular 
transformation is also a positive grant of permission - it specifies how 
the "join" needs to be modified before joe is given access to the 
conference.

It is not about how to modify the information before passing it to joe, 
simply because that isn't what joe is requesting here.

However, were we constructing a rule about whether joe is able to 
subscribe tio conference-info events, the transformations could be 
something very similar to e.g. presence authorization.

> much as learn from it and borrow parts of its schema and design where 

This is also a good approach. My guess at this point is though, that we 
would end up with something very closely resembling common-policy anyway.

Cheers,
Aki