Subject: RE: [Simple] xcap/geopriv alignment issue 8: exceptions

From: [email-masked]
Date: Tue, 25 Nov 2003 10:13:11 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Ben Campbell
> Sent: 24.November.2003 22:38
> To: Jonathan Rosenberg
> Cc: Simple WG
> Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions
> 
> 
> Jonathan Rosenberg wrote:
> 
> > This issue consumed a lot of discussion during the Minneapolis IETF.
> > 
> > The current xcap-auth specification adds support for 
> exceptions within 
> > the applies-to statements. This allows for a way to say 
> that a statement 
> > applies to all the users in a domain or list EXCEPT the 
> listed set of 
> > users. This is useful for specifying things like "I want to grant 
> > permission to everyone in dynamicsoft.com except for Bob". 
> Presumably 
> > Bob is an annoying guy and I just don't want to grant him 
> permission.
> > 
> > Now, a few points need to be made clear about the 
> exceptions processing.
> > 
> > Firstly, having things like this:
> > 
> > <applies-to>
> >   <any/>
> >   <except>
> >     <uri>sip:[email-masked]</uri>
> >   </except>
> > </applies-to>
> > 
> > is completely useless. The reason is that it is really easy 
> to obtain 
> > new names from many namespace providers. As a result, you 
> may thikn you 
> > are blocking Joe, but he just goes off, gets a new URI from 
> yahoo, and 
> > your permission statement is useless.
> > Indeed, the entire notion of except clauses is only useful 
> if you assume 
> > that there are cases where it is hard to obtain new 
> identifiers. There 
> > was some dispute about whether this is a good assumnption 
> or not. I, and 
> > some others, do believe that in many enterprises, it is a good 
> > assumption that obtaining a new enterprise identifier is not easy.
> 
> While agree that outside of walled-gardens your example is not very 
> useful, I do think this is very useful when your applies-to 
> is scoped to 
> a domain.
> 
> This is not limited to enterprise deployments. It may be true 
> that some 
> providers give away identities for free, it is not the case 
> that _all_ 
> providers do this. In fact, I think the whole argument that you don't 
> need exceptions becauses identities are free is bogus.
> 
> > 
> > A second point on exceptions. If an exception represents a 
> list, and you 
> > can't dereference that list, then you have to drop the 
> entire permission 
> > statement. This is to ensure privacy-safety, so that 
> information is not 
> > leaked under any failure condition.
> > 
> > Finally, it needs to be clarified that exceptions still result in 
> > additive permissions. So, for example, if I have two 
> staements like this:
> > 
> > <applies-to>
> >   <domain>example.com</domain>
> >   <except>
> >     <uri>sip:[email-masked]</uri>
> >   </except>
> > </applies-to>
> > 
> > <accept>
> > 
> > and
> > 
> > <applies-to>
> >   <domain>example.com</domain>
> >   <except>
> >     <uri>sip:[email-masked]</uri>
> >   </except>
> > </applies-to>
> > 
> > <accept/>
> > 
> > 
> > 
> > That if EITHER Sally or Bob subscribes, they will be 
> granted permission 
> > to subscribe. Thats because, if Bob subscribes, the first policy 
> > statement applies to him, resulting in his subscription 
> being accepted. 
> > If Sally subscribes, the second applies to her, and her 
> subscription is 
> > accepted.
> > 
> > If you try and make except clauses carry across permission 
> statements, 
> > you end up in a place where these statements are no longer 
> additive, and 
> > you are not privacy safe anymore.
> > 
> > Now, even given these clarifications, the geopriv group is 
> not planning 
> > on specifying an except condition at this time. Though they 
> consider it 
> > useful, its been ruled out of scope for the initial policy 
> document. 
> > Thus, if we wish to align, we would need to also rule it 
> out of scope in 
> > the initial version of the specification.
> > 
> > That does not mean it could never be done; indeed, it would be my 
> > proposal to more or less immediately have a draft defining it, and 
> > progress this just behind the main specs.
> > 
> > IMHO, it is worth getting alignment to let this feature 
> move forward in 
> > a separate specification, behind the main one.
> > 
> > Comments and thoughts?
> 
> I personally do not think we can live without exceptions, even for a 
> little while. Since the additive approach does not allow me to 
> explicitly black-list someone and have that override any other 
> permissions, then the only way I could create a rule that allowed 
> everyone from example.com except alice would be to list every single 
> member of example.com explicitly. This is bad enough from a 
> convenience 
> perspective--but in reality it is very unlikely example.com 
> will share 
> its membership roster with me, so I could not do this even if 
> I wanted to.

The way it works today is that you have a list of presentities and a list of watchers. The list of watchers is what the issues are about. In most systems today, the list of watchers is a mirror to the list of presentities, and therefore does not include everyone is a domain. 

I think it is ok for now to give permissions to individual watchers as selected by the presentity. We are not at a stage in presence systems where we want to allow everyone at a domain to view someone's presence excepting individual x and y. But more like 15 to 20 individuals that the presentity mostly interacts with in that domain.

So, instead of allowing, for example, everyone at example.com except for Bob. I can pick john, alice, ben and adam from example.com that I interact with and want to allow to be my watchers, and create permissions for them. This leaves out bob along with everyone else at example.com. I think this is good enough.

Regards,
Hisham

> 
> I am willing to live with limiting exceptions expressions to 
> things that 
> never require external resolution.
> 
> > 
> > Thanks,
> > Jonathan R.
> 
> 
> 
> _______________________________________________
> 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: Ben Campbell <[email-masked]>
Date: Tue, 25 Nov 2003 09:21:16 -0600

> So, instead of allowing, for example, everyone at example.com except for Bob. I can pick john, alice, ben and adam from example.com that I interact with and want to allow to be my watchers, and cre…

So you have allowed John, Alice, Ben and Adam. That is _not_ the same as 
"Everyone but Bob". For example, what if Carol joins example.com 
tomorrow. The "Allow John, Alice, Ben, and Adam" rule will not include 
her, but the "Everyone but Bob rule" would.

Most of the existing systems that mirror the watcher and presentity 
lists are single-domain systems. In an interoperable, multidomain 
system, I think that policy needs will quickly outstrip the expressivity 
of the rule language if you don't have exceptions.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Nov 2003 09:21:16 -0600