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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Nov 2003 02:02:07 -0500

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.

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?

Thanks,
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

---

From: [email-masked]
Date: Mon, 24 Nov 2003 14:47:01 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 24.November.2003 09:02
> To: Simple WG
> Subject: [Simple] xcap/geopriv alignment issue 8: exceptions
> 
> 

I don't see why someone would compose 2 permissions for the same domain. What is a scenario for this?

> progress this just behind the main specs.

Ok.

/Hisham

---

From: [email-masked]
Date: Mon, 24 Nov 2003 14:47:01 +0200

Ok.

/Hisham

---

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

> 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:
> 
> > 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.
> > 
> > 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 
> > 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.
> > 
> > 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.
> > 
> > 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.
> 
> 
>

---

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

Hi,

My opinion on extensions is exactly similar to Ben's. I believe we need the exceptions from day one. 

I agree that in "open" systems where users can quite freely generate new IDs, blacklists don't work. However, in enterprises or even in many commercial public SIP networks, users do get authenticated and user identity allocation is an administrative process subject to authentication/authorization. In these environments exceptions are clearly valuable to users, and leaving them out might mean that SIMPLE is not considered as flexible as other systems implementing this kind of features.

Leaving external references out of the exceptions is fine, although I would prefer having them with a rule that if the resolution fails for some reason, the whole <applies-to> level statement is discarded. (Is there some reason why this proposal would not work?)

Markus

> Sent: 24 November, 2003 22:38
> To: Jonathan Rosenberg
> Cc: Simple WG

---

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

Hi,

Markus

---

From: [email-masked]
Date: Tue, 25 Nov 2003 17:35:58 +0200

> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 25.November.2003 17:21
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> [email-masked] wrote:
> > 
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>ext Ben Campbell
> >>>The current xcap-auth specification adds support for 
> >>
> >>exceptions within 
> >>
> >>>Now, a few points need to be made clear about the 
> >>
> >>exceptions processing.
> >>
> >>>is completely useless. The reason is that it is really easy 
> >>
> >>to obtain 
> >>
> >>information is not 
> >>>leaked under any failure condition.
> >>>
> >>>additive permissions. So, for example, if I have two 
> >>
> >>staements like this:
> >>
> >>><applies-to>
> >>>If you try and make except clauses carry across permission 
> >>
> >>statements, 
> >>
> > 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.
> 
> 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.

Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described.

/Hisham

> 
> 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.
> 
> > 
> > Regards,
> > Hisham
> > 
> >

---

From: [email-masked]
Date: Wed, 26 Nov 2003 09:41:02 -0500

>ext Robert Sparks
>Sent: Wednesday, November 26, 2003 1:36 AM
>To: Ben Campbell
>Cc: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
>[email-masked]
>(speaking from the floor)
>
>In the presence/IM systems I've been using on a daily basis for
>some time now, I do not have a way to say "Allow everybody in
>foo.com except bar" and I still find these systems useful.
>

Shall we conclude from this that current restrictions of systems is a useful measure to build future systems?

I do believe that exceptions would be useful, in particular in inter-domain and interoperable systems. Since I believe that's what is tried to be built, exceptions should be considered. 

Dirk