Subject: RE: [Simple] New xcap authorization documents - unions vs. intersections?

From: [email-masked]
Date: Tue, 2 Mar 2004 03:14:16 +0200

Hi,

After reading the documents I must admit I have a fundamental problem in understanding how the common policy permission combination is meant to work.

In Chapter 4 it says that permissions are additive: "If several rules match, then the overall permissions granted to the WR are the union of those permissions."

This makes sense to me. If one rule gives certain user rights to {A,B,C} and another rule to {C,D} it seems intuitive that the overall rigths are to {A,B,C,D}; or if one rule gives rights to accuracy "low" and another to "high", "high" would be the end-result.

However, Chapter 10 explains in detail how permissions are combined and that does not seem at all additive to me. For instance combining rule CR3 states that if the permission is of a "set" type, the overall permission should be _intersection_ of all given permissions. In the above case this would mean that only {C} is granted. Why is this? Shouldn't it be a union?

More precisely about the concrete presence authorization rules: Let's assume I have a rule that allows tuples of class X and Y to be shown to domain example.com, and another rule that allows tuple Z to be shown to [email-masked]. If the permissions were additive, I expected bob to get X, Y and Z - while according to the current logic I think nothing is given, as the intersection is an empty set.

Please clarify what is wrong in my interpretation.

Markus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 09 February, 2004 21:46
> To: Simple WG
> Subject: [Simple] New xcap authorization documents
> 
> 
> Folks,
> 
> We've completed the major first step of integrating the geopriv and 
> simple authorization specifications. -00 drafts have been 
> submitted to 
> both geopriv and simple supporting this unification.
> 
> In geopriv, the main draft to look at is this one (available in the 
> archives shortly:)
> http://ecotroph.net/~anewton/resources/geopriv/draft-ietf-geop
> riv-common-policy-00.txt
> 
> This is the common policy specification. It outlines the 
> framework for 
> representing policies, and defines some basic elements, such as 
> confirming subscriptions and identifying watchers. At this time, it 
> includes support for the "exception" clause against domains.
> 
> This specification is extended (and in particular, the abstract 
> condition, action, and transformation elements are made 
> concrete) with 
> presence specific data in:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-simple-rules-00.txt
> 
> which should also appear in the archives shortly. This draft will 
> replace draft-ietf-simple-xcap-auth-usage-01.txt once the 
> group is happy 
> with the approach.
> 
> Another change is the removal of "supported permissions" from 
> xcap-auth-usage. That, like authorization rules, is now broken into a 
> common core document and a presence specific one.
> 
> http://www.jdrosen.net/papers/draft-rosenberg-simple-common-po
> licy-caps-00.txt
> 
> specifies the common document, and:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-simple-pres-poli
> cy-caps-00.txt
> 
> contains the capabilities specific to presence.
> 
> These are both very simple specifications.
> 
> I think the resulting document set is much cleaner and easier to 
> understand than before. Put together, beyond a split, here 
> are the major 
> changes:
> 
> * all conditions are part of a rule-wide selector (the conditions 
> element) rather than specific to permissions. As such, the accept-if 
> condition is gone.
> 
> * only domain's have except clauses. There is no longer an "any" 
> condition or the ability to reference a list.
> 
> * The "sphere" element is now present as a condition
> 
> * There is a "validity" condition which allows you to 
> temproally scope 
> the validity of a document
> 
> * Removed "can-encrypt" condition - trying to keep things minimal.
> 
> * You can now explicitly ask for subscription confirmation using the 
> confirmation action from the common document
> 
> * You can explicitly accept or reject subscriptions with the 
> accept-subscription action in the presence specific document.
> 
> * You can now explicitly polite block. The behavior of the 
> server when 
> the user requests polite blocking is not defined - its implementation 
> specific.
> 
> * There is no longer an "encrypt" action for requesting the server to 
> send encrypted notifications.
> 
> * There is now an "anonymous" condition which allows you to specify 
> policies based on whether the subscription was anonymous
> 
> * Specific treatment for identity matching is defined for SIP digest 
> authentication, P-asserted-ID and sip-identity
> 
> * There are three content transformations defined - show-tuple, 
> show-namespace and show-element. Each of these is applied 
> INDEPENDENTLY, 
> so if an item is filtered by any one of these, its filtered 
> out of the 
> document.
> 
> * show-note and show-contact have been removed to simplify
> 
> * defaults were established for the above three transformations
> 
> * The documents are much less xcap-centric. They talk about document 
> formats, and have a small section at the end which defines 
> the usage for 
> xcap. The title and filenames have also changed to reflect this. This 
> clarifies that these documents can be used outside of xcap.
> 
> 
> 
> Please take a look and send comments.
> 
> 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
> 

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

---

From: [email-masked]
Date: Tue, 2 Mar 2004 03:14:16 +0200

Hi,

Markus