Subject: RE: [Simple] Questions on XCAP Usage for Authorization

From: [email-masked]
Date: Sun, 9 Nov 2003 20:14:04 +0200

Hi,

Jonathan Rosenberg replies to Naoko Ito:
> > - Is there any way to reject a watcher who is given permissions by
> >   other statements?
> >   ex) Give a permission to any user whose domain is 
> "example.com" but
> >       Joe.
> 
> Yes, now that is possible in -01. You would define a statement that 
> allows anyone but Joe:
> 
> <statement>
>    <applies-to>
>      <domain>example.com</domain>
>      <except>
>        <uri>sip:[email-masked]</uri>
>      <except>
>    </applies-to>
> 
>    <accept/>
> </statement>
> 
> and to reject Joe, there would be this statement:
> 
> <statement>
>    <applies-to>
>      <uri>sip:[email-masked]</uri>
>    </applies-to>
> </statement>
> 
> Note how, in the second statement, there is an applies-to, but *no* 
> permissions. I.e., the way to reject someone is that they are granted 
> no permissions.

If the default is that no-one is granted no permissions, what is the difference the second statement makes?

Markus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 31 October, 2003 22:00
> To: Naoko ITO
> Cc: [email-masked]
> Subject: Re: [Simple] Questions on XCAP Usage for Authorization
> 
> 
> Sorry for the delay in responding. Answers inline.
> 
> Naoko ITO wrote:
> 
> > Hello,
> > 
> > I have some questions on XCAP Usage for Authorization.
> > 
> > The draft says,
> >    The overall authorization for a watcher is represented 
> by the union
> >    of the permissions granted to that watcher.
> >  and
> >    In that case, the union of the permissions across those 
> statements
> >    is applied to the subscription.
> > 
> > Am I correctly understanding that the overall authorization is
> > determined by simply putting together every permission related to a
> > specific watcher?
> 
> Yes.
> 
> > 
> > Then, some questions occur to me.
> > 
> > - Is there any way to reject a watcher who is given permissions by
> >   other statements?
> >   ex) Give a permission to any user whose domain is 
> "example.com" but
> >       Joe.
> 
> Yes, now that is possible in -01. You would define a statement that 
> allows anyone but Joe:
> 
> <statement>
>    <applies-to>
>      <domain>example.com</domain>
>      <except>
>        <uri>sip:[email-masked]</uri>
>      <except>
>    </applies-to>
> 
>    <accept/>
> </statement>
> 
> and to reject Joe, there would be this statement:
> 
> <statement>
>    <applies-to>
>      <uri>sip:[email-masked]</uri>
>    </applies-to>
> </statement>
> 
> Note how, in the second statement, there is an applies-to, but *no* 
> permissions. I.e., the way to reject someone is that they are granted 
> no permissions.
> 
> 
> > - Is there a way to have a default policy which can be overridden by
> >   other statements? It seems possible to reject, or not to give a
> >   permission to all the watchers by default and add permisions to
> >   specific users only. But it does not seem possible to accept every
> >   user by default unless listed on a black list.
> 
> Sure, you can do that. You would have two-statements:
> 
> <statement>
>    <applies-to>
>      <any/>
>      <except>
>        <on-list>http://xcap.example.com/resource-lists/users/joe/
>            black-list</on-list>
>      </except>
>    </applies-to>
> 
>    <accept/>
> </statement>
> 
> <statement>
>    <applies-to>
>      <on-list>http://xcap.example.com/resource-lists/users/joe/
>            black-list</on-list>
>    </applies-to>
> </statement>
> 
> This is now possible because of the except clause which I 
> added in -01.
> 
> 
> > - How to solve the conflicts between two or more 
> permissions related to
> >   one watcher?
> 
> Ahh, thats the whole idea.
> 
> There *can't* be conflicts. By defining the permissions as additive 
> always, you never have conflicts. Geopriv has taken the exact same 
> approach.
> 
> 
> > 
> > I understand this is still under discussion, as it says,
> > 
> >       OPEN ISSUE: Another model is that you take permissions for the
> >       most specific match. I think union makes more sense 
> in the model
> >       where the entries in the statement are permissions.
> > 
> > but it'd be greatful if I can be provided any idea on this.
> 
> I think we've concluded here. I believe that the appropriate model is 
> as specified. With the addition of the except clause, I am confident 
> that we can easily specify a wide range of things, and furthermore, 
> have a model which always maximizes privacy. You never have to worry 
> about information being given out by accident because some blocking 
> rule was overriden with a permission rule. People only get 
> information 
> when they are granted an explicit permission.
> 
> Given that geopriv has also chosen this model, its clear to me that 
> its the right way to go.
> 
> -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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 04:33:04 -0500

inline.

> If the default is that no-one is granted no permissions, what is the difference the second statement makes?

The difference is whether or not reactive authorization needs to be 
used. In the current draft, lack of any statements that apply to a 
watcher means that they are pending, and so winfo would indicate to 
the presentity that a permission needs to be applied. If I want to 
deny them, I would go and add the above statement.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 04:33:04 -0500

inline.

-Jonathan R.