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: Ben Campbell <[email-masked]>
Date: Mon, 24 Nov 2003 14:37:46 -0600

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 
> leaked under any failure condition.
> 
> 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.

I am willing to live with limiting exceptions expressions to things that 
never require external resolution.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Nov 2003 14:37:46 -0600