Subject: [Simple] Update to xcap authorization rules

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Apr 2004 15:21:52 -0400

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.

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

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

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

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

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

* 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

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