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