Subject: RE: [xacml] Generalization
That is exactly the kind of generalized effect approach that I was talking about when we added "indeterminate" value as an explicit rule effect. I do not think that in this case we need to talk about obligation anymore. One just may expand the value space of effect that may be represented as a URI, with a restriction that for the purposes of access control each value needs to be castable to a special reserved "grant"/"deny" or "indeterminate" URI. Then mandatory recombination algorithms may stay the same, using the castable-to value of the effect, while an extension algorithm may do whatever it wants with the effect values. <rule> <effect castable-to="xacml:GRANT"> <value>some-uri</value> </effect> </rule> Daniel; -----Original Message----- From: Tim Moses [mailto:firstname.lastname@example.org] Sent: Monday, November 15, 2004 8:23 AM To: 'XACML' Subject: [xacml] Generalization Colleagues - Response to a couple of questions raised during our discussion of this topic in Thursday's telecon. All discussion is relative to rules combined into a policy; policies combined into a policyset behave analogously. 1. Daniel asked about non-applicable rules. These do not contribute any obligations to the combination. If none of the rules contribute obligations, then the policy value is null. 2. Polar said that an alternative approach would be to leave Effect values undefined in the core and allow extensions to define suitable values. This is definitely a possibility. I prefer the approach that I described for two reasons. a. It treats the obligation as the principal result. It is the more general concept. Effect, which is relevant only to access control, is set by an obligation. b. It simplifies combining algorithms. The obligations associated with an Indeterminate result are explicitly stated in the policy, and the combining algorithm handles obligations independent of the rule values that gave rise to them. Of course, this approach would cause us to make Obligations a mandatory part of the standard. But, nothing in this approach infringes on IBM's patent. All the best. Tim. ----------------------------------------------------------------- Tim Moses 613.270.3183 To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgro up.php.