Subject: Re: [XCON] Authorization in conference policy

From: Alan Johnston <[email-masked]>
Date: Tue, 11 May 2004 15:45:24 -0500

Hi Aki,

Thanks for bringing this up.

I do think it would be worthwhile to do a comparison of presence and 
location policy and the conference policy that we are developing in 
XCON.  If there are major differences or divergences, it would be good to 
know what they are (such as the all-except construct you mention below).

Having said that, I'm not so certain that conference policy needs to 
formally be aligned with the common policy framework, as the differences 
between it and the other policies seem to be greater than the similarities.

However, if there are some concrete advantages to doing so, I think the 
working group should consider this approach.

Thanks,
Alan Johnston
co-chair XCON

At 02:46 PM 4/28/2004 +0300, Aki Niemi wrote:
>Hi All,
>
>Currently, XCAP-CPCP [1] includes the definition of data elements for
>implementing authorization rules and permission rules (privileges) for
>conferences. Along with the definition of those elements, it defines its
>own rule syntax.
>
>Common-policy [2] defines an authorization policy framework, intended
>for use in different applications to control access to data. It includes
>a syntax for common policy rules that are currently being used to
>describe authorization policies in location and SIP presence
>applications. Also, the common policy framework can be extended to
>accomodate other application needs.
>
>In short, this framework defines policy as a set of rules where the
>respective ordering of rules does not matter. Each rule consists of a
>condition for matching some property (e.g., identity of the requestor of
>data); and permissions that are to be applied in case the "condition"
>part has evaluated to true.
>
>It seems natural that the conference policy work would also benefit from
>adopting the common-policy framework.
>
>However, one of the intended usages of conference policy is to control
>the participation to a conference. To expel a participant from an
>ongoing conference, the conference policy would be manipulated in such a
>way that the participant is no longer allowed to participate, effecting
>a removal of that participant from the conference. The need for
>expelling users is also independent of the original admittance policy.
>Even in conferences that have open admittance (i.e. anyone can join), a
>moderator would need to be able to expel users who are disturbing the
>conference, e.g., expel a participant from a chat room for using
>explicit language.
>
>In common-policy point of view, the above would require an "all-except"
>construct, which I believe currently is not allowed in common-policy.
>Question is, can this be worked around, if we were to adopt
>common-policy in the conference policy work?
>
>And if yes, would XCON be willing to see common-policy adopted in the
>conference policy work?
>
>The advantages would include having a unified syntax for policy rules in
>these different applications, including a clear extension model etc.
>
>Disadvantages (pending the resolution of the above issue) would be
>having to rewrite the authorization policy parts of XCAP-CPCP, causing a
>delay.
>
>Thoughts?
>
>Cheers,
>Aki
>
>[1]
>http://www.ietf.org/internet-drafts/draft-koskelainen-xcon-xcap-cpcp-usage-02.txt
>
>[2]
>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-00.txt
>
>
>_______________________________________________
>XCON mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/xcon

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

---

From: Alex Audu <[email-masked]>
Date: Wed, 12 May 2004 13:49:45 -0500

It is true that  common-policy does not support "all-except" 
conditions.  But its <identity> element
does support  <except> which can be used to implement a form of 
blacklist, as exemplified in 
seciotn 7.1 of  common-policy  as follows:

   The next example shows how exceptions are implemented. A request MUST
   match the domain part and all three exceptions parts in an atomic
   fashion to be a successful match.

   <identity>
     <domain>example.com</domain>
     <except>[email-masked]</except>
     <except>[email-masked]</except>
     <except>[email-masked]</except>
   </identity>

I guess the question is, would this be enough in a conferencing scenario?
It is beneficial to unify cpcp policy under the common-policy paradigm.

Regards,
Alex.

Alan Johnston wrote:

> XCON.  If there are major differences or divergences, it would be good 
> to know what they are (such as the all-except construct you mention 
> below).
>
> formally be aligned with the common policy framework, as the 
> differences between it and the other policies seem to be greater than 
> the similarities.
>
> However, if there are some concrete advantages to doing so, I think 
> the working group should consider this approach.
>
> Thanks,
> Alan Johnston
> co-chair XCON
>