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: [email-masked]
Date: Mon, 17 May 2004 11:30:32 +0300

> Sent: 17.May.2004 10:57
> To: Isomaki Markus (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] Update to xcap authorization rules
> 
> 
> 
> > 
> > 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.

Note: There can appear more than one <note> element. Would <provide-note> provide all notes?

/Hisham

---

From: [email-masked]
Date: Fri, 21 May 2004 09:28:42 +0300

Just to be clear, I was referring to the <note> elements at the presentity level, not tuple level. There can be a multiplicity of those. <provide-note> would provide all those <note> elements at the presentity level. The ones at the tuple level need different handling.

/Hisham

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 20.May.2004 13:26
> To: Niemi Aki (Nokia-M/Espoo)
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Isomaki Markus
> (Nokia-NRC/Helsinki); [email-masked]
> Aki Niemi wrote:
> > ext [email-masked] wrote:
> > 
> >>>> 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.
> >>
> >>
> >>
> > I at least think it should, since I think the only reason 
> for having 
> > multiple notes would be to give each one their own 
> 'xml:lang' attribute 
> > value.
> 
> Yes, I also agree. Please take a look at the email I just sent on 
> presence rules issue 4, where I think these "provide-X" things should 
> not support complicated selection rules which allow you to 
> say for which 
> tuples you were talking about.
> 
> I think what we'll find is that, if I really want to control 
> information 
> differently in different tuples, this manifests itself by me simply 
> providing you with some tuples and not others, in which case 
> you'll get 
> the <note> that was in the tuples you get.
> 
> -Jonathan R.
> 
> --