Subject: RE: [Simple] Update to xcap authorization rules

From: [email-masked]
Date: Wed, 12 May 2004 23:50:11 +0300

Hi,

Some comments inline. I've tried to read all the discussion in separate threads related to this, but may have missed some, so apologies if I propose or ask something that has been covered already.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 30 April, 2004 22:22
> To: Simple WG
> Subject: [Simple] Update to xcap authorization rules
> 
> 
> Folks,
> 
> I've just submitted an update to the presence authorization policies
> specification. Until it appears in the archives, you can grab a copy
> at:
> 
> http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-00.txt
> 
> There are a number of changes, based primarily on list discussions on
> this document. If you have comments on any of these, please 
> do each in a 
> separate thread and change the subject:
> 
> * The new semantic based transformations I had proposed on the list,
> and which were discussed, are now in the document and replace the
> previous syntactic based transformations. I believe we had good
> consensus to do this, but there were open issues around several
> points; see below.
> 
> * Markus had raised some issues about how "view" transformation would
> work (recall that this transformation allowed the presentity to say
> whether or not the document that is produced provides a presentity
> view, service view, or device view). The issue was whether there was
> really a strict privacy order; could I possibly have permissions that
> allow more than one of these? I think that Markus is right, that there
> is not really a strict privacy ordering here. Given that, and given
> that we still have work to do in order to agree on what these views
> mean, I've removed this feature entirely for now. I'd like to try to
> do something here, and will send a separate note on this issue.
> 

I agree with this and it seems that the discussion has already started in more detail about the relationship of authorization policies and composition policies.

> * The names of the permissions were changed to "provide-X" where X is
> the corresponding RPID element whose permission is granted. Its not
> strictly needed, since the namespace qualifier will differentiate, but
> it helps during the discussions in the text.
> 
> * Formerly, each of the permissions granted access to an rpid type,
> and allowed you to indicate which tuple, identified by class, it was
> included in. There were several problems here. One, identified by
> Markus, is the lack of a short-hand for saying "tuples of all
> classes". Another problem is that it only allowed usage of the "class"
> attribute as a means for selecting which tuples to include it in. I
> have figured out how to extend this to a bunch of different selectors,
> and have included ones for class, placetype, privacy, relationship,
> sphere and contact-type. This is done by defining all of the
> provide-foo elements as sets, rather than boolean, and the set members
> identify the tuple-selector criteria by RIPD element name/value. So,
> for example, to include the placetype attribute in all tuples where
> placetype has a value of home OR the class is friend:
> 
> <provide-placetype>
>    <tuples-whose>
>      <placetype>home</placetype>
>      <class>friend</class>
>    </tuples-whose>
> </provide-placetype>
> 
> Since, according to the common-policy rules, composition of sets is
> done by union, the above is identical to:
> 
> <provide-placetype>
>    <tuples-whose>
>      <class>friend</class>
>    </tuples-whose>
> </provide-placetype>
> 
> <provide-placetype>
>    <tuples-whose>
>      <placetype>home</placetype>
>    </tuples-whose>
> </provide-placetype>
> 
> which could appear in the same or separate permission documents.
> 
> Its also possible to explicitly say "all-tuples". I don't have
> qualifiers for things like "all tuples that include any class", but
> these can easily be added under the set definition. If folks want to
> explicitly see something added, please comment.
> 

One issue still about the current "semantic" model vs. the old "syntactic model". Now it seems that if I want to provide all RPID elements, I have to make a rule for each of them. In the old version it was possible to provide all elements with one rule by using the "show-namespace" element. I think it would still be useful to have something like "provide-rpid-all" just to make expressing some common cases more efficient.

Another thing that currently there seems to be no way of controlling child elements of <presence>, e.g. <note>, which is not within any tuple. This is allowed by PIDF, so maybe there should be a "provide-..." element explicitely for it.

> * A big concern raised by Markus and others was on supporting unknown
> presence attributes in the semantic model. The problem with doing that
> was overlap and intersection with other rules. I've addressed
> that. The spec now includes an "provide-unknown-status" element that
> has, as an attirbute, the qualified name of the unknown element for
> whom permissions are being defined. The spec explicitly says that
> these permissions apply only to elements for whom there is not
> otherwise a schema understood by the server which defines
> permissions. That eliminates the overlap problem, and allows us to
> define better authorization permissions for such things down the road,
> as needed.
> 

Yes, this looks good. However, is the intention that only elements under <status> can be provided using this mechanism? What is the reason for that? I think we need to be able to control access to unknown elements directly under <tuple> as well.

> * I combined the various presence actions into one action -
> sub-handling, with values of allow, block, confirm and polite-block,
> as I proposed on the list. The default is "block". The spec is clear
> that this is always the lowest value, and the default, so inclusion of
> an action with the value of block is not needed in a document - its
> assumed. Its included only for completeness, since people like to see
> a formal "NO" I think.
> 
> * Markus had raised an open issue around external lists as a means for
> identifying a group of users that would be referenced in an identity
> element. We concluded, I believe, to do this as a follow-on
> specification. I have not written that up right now, I'm focusing on
> getting the main document done.
> 

Yes, this seems like the right priority order.

> * Markus had raised an open issue around blacklisting, and the desired
> to say things like "allow everyone but Joe". We came to agreement that
> what Markus really meant was "allow subscriptions from domains in my
> trusted group of domains except for Joe". I had pointed out that you
> could achieve this by enumerating those domains. Given the ill-defined
> notion of "trusted group of domains" and the potential for information
> leakage that this entails, for now, I'd rather stick with what we
> have, which allows enumerated domains.
> 

OK, even though I see some practical problems with this approach (such as that migrating from current systems, e.g. wireless village, to SIMPLE will be less straightforward), I see the merit of the common policy approach, and can cope with that.

> * Markus had raised an open issue about providing different
> information to different groups of watchers, and how would that be
> supported. We had some interesting discussions on the fundamental
> model we were working with. I believe consensus was to not change the
> model, and as a result, you can provide different infomration to
> different watchers by having the "raw" presence document include both
> sets of information, and defining permissions that grant access to
> different parts of that document for different watchers. If you should
> mess up, it is possible that a user gets conflicting information. I
> have argued that this can happen in many cases, and there is not much
> we can do about it. As such, I have not changed anything to address
> this issue. Please comment if there are still concerns.
> 

I still hope something could be done about this. I guess the simplest thing would be this (hopefully I'm not stepping too far into the composer policy territory): Provide a possibility to define a rule which can say: If tuples with class A and B are to be provided, only provide A. In this way I can give tuple B to group X, and tuple A to group Y. If Y is a subset of X, watchers in group Y only get tuple A. 

> * Added a section on schema extensibility, and how that is done. This
> has come up as an IESG concern on other XML drafts I'm involved in, so
> I figure we should address it up front. Please take a look.
> 
> * removed usage and references to draft-ietf-sip-identiy and aib-body;
> replaced with some generic text on extracting username and host parts
> in future specifications. I'm concerned about the normative dependency
> that more specific text would introduce.
> 
> -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
> 

Markus

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 May 2004 03:56:33 -0400

inline.

[email-masked] wrote:

> Hi,
> 
> Some comments inline. I've tried to read all the discussion in
> separate threads related to this, but may have missed some, so
> apologies if I propose or ask something that has been covered
> already.
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of ext Jonathan Rosenberg 
>> Sent: 30 April, 2004 22:22 To: Simple WG Subject: [Simple] Update
>> to xcap authorization rules
>> 
>> 
>> Folks,
>> 
>> I've just submitted an update to the presence authorization
>> policies specification. Until it appears in the archives, you can
>> grab a copy at:
>> 
>> There are a number of changes, based primarily on list discussions
>> on this document. If you have comments on any of these, please do
>> each in a separate thread and change the subject:
>> 
>> * The new semantic based transformations I had proposed on the
>> list, and which were discussed, are now in the document and replace
>> the previous syntactic based transformations. I believe we had good
>> * Markus had raised some issues about how "view" transformation
>> would work (recall that this transformation allowed the presentity
>> to say whether or not the document that is produced provides a
>> presentity view, service view, or device view). The issue was
>> whether there was really a strict privacy order; could I possibly
>> have permissions that allow more than one of these? I think that
>> Markus is right, that there is not really a strict privacy ordering
>> here. Given that, and given that we still have work to do in order
>> to agree on what these views mean, I've removed this feature
>> entirely for now. I'd like to try to do something here, and will
>> send a separate note on this issue.
>> 
> 
> 
> I agree with this and it seems that the discussion has already
> started in more detail about the relationship of authorization
> policies and composition policies.
> 
> 
>> * The names of the permissions were changed to "provide-X" where X
>> is the corresponding RPID element whose permission is granted. Its
>> not strictly needed, since the namespace qualifier will
>> differentiate, but it helps during the discussions in the text.
>> 
>>  and allowed you to indicate which tuple, identified by class, it
>> was included in. There were several problems here. One, identified
>> by Markus, is the lack of a short-hand for saying "tuples of all 
>> classes". Another problem is that it only allowed usage of the
>> "class" attribute as a means for selecting which tuples to include
>> it in. I have figured out how to extend this to a bunch of
>> different selectors, and have included ones for class, placetype,
>> privacy, relationship, sphere and contact-type. This is done by
>> defining all of the provide-foo elements as sets, rather than
>> boolean, and the set members identify the tuple-selector criteria
>> by RIPD element name/value. So, for example, to include the
>> placetype attribute in all tuples where placetype has a value of
>> home OR the class is friend:
>> 
>> <provide-placetype> <tuples-whose> <placetype>home</placetype> 
>> <class>friend</class> </tuples-whose> </provide-placetype>
>> 
>> <provide-placetype> <tuples-whose> <class>friend</class> 
>> </tuples-whose> </provide-placetype>
>> 
>> <provide-placetype> <tuples-whose> <placetype>home</placetype> 
>> </tuples-whose> </provide-placetype>
>> 
>>  these can easily be added under the set definition. If folks want
>> to explicitly see something added, please comment.
>> 
> 
> 
> One issue still about the current "semantic" model vs. the old
> "syntactic model". Now it seems that if I want to provide all RPID
> elements, I have to make a rule for each of them. In the old version
> it was possible to provide all elements with one rule by using the
> "show-namespace" element. 

Right.

> I think it would still be useful to have
> something like "provide-rpid-all" just to make expressing some common
> cases more efficient.

I'm glad you raise this, it relates to a more general topic, which is 
how to support future extensions that define more abstract permissions, 
like "high privacy" and "medium privacy". My suggestion is that these 
such things be defined down the road as macros which expand into a set 
of basic permissions defined here.

Thus, we could later on define something like "provide-rpid-all" and map 
it into the set of defined rpid elemnets.

I would rather define this, and any other more abstract permissions, 
down the road. In particular, if any permission can be expressed as a 
union of other permissions, we don't define it at this time.

> 
> Another thing that currently there seems to be no way of controlling
> child elements of <presence>, e.g. <note>, which is not within any
> tuple. This is allowed by PIDF, so maybe there should be a
> "provide-..." element explicitely for it.

I think the only thing is actually note, since basic status has to be 
included I think. I can add a provide-note.

> 
> 
>> * A big concern raised by Markus and others was on supporting
>> unknown presence attributes in the semantic model. The problem with
>> doing that was overlap and intersection with other rules. I've
>> addressed that. The spec now includes an "provide-unknown-status"
>> element that has, as an attirbute, the qualified name of the
>> unknown element for whom permissions are being defined. The spec
>> explicitly says that these permissions apply only to elements for
>> whom there is not otherwise a schema understood by the server which
>> defines permissions. That eliminates the overlap problem, and
>> allows us to define better authorization permissions for such
>> things down the road, as needed.
>> 
> 
> 
> Yes, this looks good. However, is the intention that only elements
> under <status> can be provided using this mechanism? What is the
> reason for that? I think we need to be able to control access to
> unknown elements directly under <tuple> as well.

I can add a separate <provide-unknown-tuple-data>.

>> sub-handling, with values of allow, block, confirm and
>> polite-block, as I proposed on the list. The default is "block".
>> The spec is clear that this is always the lowest value, and the
>> default, so inclusion of an action with the value of block is not
>> needed in a document - its assumed. Its included only for
>> completeness, since people like to see a formal "NO" I think.
>> 
>> * Markus had raised an open issue around external lists as a means
>> for identifying a group of users that would be referenced in an
>> identity element. We concluded, I believe, to do this as a
>> follow-on specification. I have not written that up right now, I'm
>> focusing on getting the main document done.
>> 
> 
> 
>> * Markus had raised an open issue around blacklisting, and the
>> desired to say things like "allow everyone but Joe". We came to
>> agreement that what Markus really meant was "allow subscriptions
>> from domains in my trusted group of domains except for Joe". I had
>> pointed out that you could achieve this by enumerating those
>> domains. Given the ill-defined notion of "trusted group of domains"
>> and the potential for information leakage that this entails, for
>> now, I'd rather stick with what we have, which allows enumerated
>> domains.
>> 
> 
> 
> OK, even though I see some practical problems with this approach
> (such as that migrating from current systems, e.g. wireless village,
> to SIMPLE will be less straightforward), I see the merit of the
> common policy approach, and can cope with that.
> 
> 
>> model we were working with. I believe consensus was to not change
>> the model, and as a result, you can provide different infomration
>> to different watchers by having the "raw" presence document include
>> both sets of information, and defining permissions that grant
>> access to different parts of that document for different watchers.
>> If you should mess up, it is possible that a user gets conflicting
>> information. I have argued that this can happen in many cases, and
>> there is not much we can do about it. As such, I have not changed
>> anything to address this issue. Please comment if there are still
>> concerns.
>> 
> 
> 
> I still hope something could be done about this. I guess the simplest
> thing would be this (hopefully I'm not stepping too far into the
> composer policy territory): Provide a possibility to define a rule
> which can say: If tuples with class A and B are to be provided, only
> provide A. In this way I can give tuple B to group X, and tuple A to
> group Y. If Y is a subset of X, watchers in group Y only get tuple A.

It can be done by some downstream composition controls, and I'd rather 
leave that for later.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 May 2004 03:56:33 -0400

inline.

Right.

Thanks,
Jonathan R.