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

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

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 25.November.2003 17:21
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions
> 
> 
> [email-masked] wrote:
> > 
> >>-----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.
> 
> 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
> > 
> > 
> >>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 15:07:12 -0600

> 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 exceptio…

That assumes you know about Carol. My point is, these two cases are not 
the same thing. You might be able to simulate something like exceptions 
by doing this, if and only if you have full knowledge of the membership 
of example.com. I suspect that will commonly be false.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Nov 2003 15:07:12 -0600

---

From: Robert Sparks <[email-masked]>
Date: Wed, 26 Nov 2003 00:35:52 -0600

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

On reflection, when using future systems I think I will prefer the model
of explicitly listing those people I wish to authorize over excepting
individuals from a set I cannot control and possibly cannot know.

Thus, I don't think it is absolutely necessary to have that kind of
statement in the initial xcap-auth mechanism.

I do see the power of having such a statement to some applications
that may consume presence, and I would very much like to have such
a statement available. I think it is acceptable for this functionality
to be an extension of the base xcap-auth tool.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Wed, 26 Nov 2003 00:35:52 -0600

RjS

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Nov 2003 08:31:45 -0600

> foo.com except bar" and I still find these systems useful.

I do have to point out that most of the existing, big commercially 
deployed systems, are single-domain, non-interoperable systems. We make 
due with them because that is what exists. I did not think that is what 
we are trying to build here.

Let me back off from saying you cannot build a useful system without 
exceptions. Let me instead state that I have endured a number of 
customer requests for authorization models that cannot be implemented 
without exceptions.
> statement in the initial xcap-auth mechanism.

Out of curiosity, do you see it necessary to be able to say a rule 
applies to a domain at all? Or to generalize, to any "group" where 
membership is determined when the rule is applied, rather than when it 
is created?

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Nov 2003 08:31:45 -0600

---

From: Alex Audu <[email-masked]>
Date: Wed, 26 Nov 2003 09:52:41 -0600

Hello Robert,

Please see comments in-line.

Regards,
Alex.

> individuals from a set I cannot control and possibly cannot know.

Even if you want to authorize thousands of users but one or two?  That
is not an economical use of processing cycles that will be brought to bear
in going through that long list of authorized users every time a subscrption
is attempted (in my view).

---

From: Alex Audu <[email-masked]>
Date: Wed, 26 Nov 2003 09:52:41 -0600

Hello Robert,

Regards,
Alex.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 28 Nov 2003 10:50:27 -0600

> we are trying to build here.

No, but the question starting this thread is whether or not it would
be acceptable to have a base authorization system that didn't support
exceptions. My point is that there are environments where such a system
would be useful. (And I don't think the single-domain/non-interoperable
characteristics of the existing systems I refer to is pertainant to that
statement.)

> customer requests for authorization models that cannot be implemented 

Is there something in this set of requests that would make having
exceptions as an extension to the core protocol unacceptable?

> membership is determined when the rule is applied, rather than when it 

Useful. Useful enough that I want a system that supports the concept.
But absolutely necessary? No. A core authorization system that did not
support this concept would still be useful.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 28 Nov 2003 10:50:27 -0600