OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] attribute references and indeterminate results


On 18 July, bill parducci writes: Re: [xacml] attribute references and indeterminate results
 > i don't see a problem with the proposed verbage. however, maybe you can
 > help explain something to me. 
 > 
 > this may be an incredibly dumb question, but is OR allowed in the
 > predicate of a rule? (other than being encapsulated within an external
 > function). in reading through the schema it seems that the most granular
 > combinator is that to combine *rules*. since conditions are a subset of
 > rules,  it would seem that the initial statement would is correct, as
 > any undetermed attribute of a condition would render it Ind. (making the
 > rule Ind.) with both actions occuring below scope of the OR operator.

OR only exists as an external function, or internally to the
semantics of a combining algorithm.

On further reflection, I think the definition of the semantics of
the function being used for OR should determine whether all
attribute references must be resolved or not.  Since retrieving
attributes can be very expensive, I propose the following
semantics for the two "standard" OR functions:

urn:oasis:names:tc:XACML:0.15g:operators:or

   Operands may be evaluated in any order.  Evaluation continues
   until either one operand returns TRUE, or until all operands
   have been evaluated.  Once any operand has been evaluated
   TRUE, no additional operands are evaluated.

   If any evaluated operand returns TRUE, then the result of the
   function is TRUE.

   If all operands are evaluated, and none of them evaluates to
   TRUE, then, if ANY operand evaluated to INDETERMINATE, the
   function returns INDETERMINATE.  If ALL operands evaluated to
   FALSE, then the function returns FALSE.

urn:oasis:names:tc:XACML:0.15g:operators:or

   Operands must be evaluated in the order specified.  As long as
   evaluated operands return a result of FALSE, evaluation
   continues.

   If an evaluated operand returns TRUE, then the function
   returns TRUE and no additional operand evaluations are done.

   If an evaluated operand returns INDETERMINATE, then the
   function returns INDETERMINATE.  In this case, additional
   operands MAY be evaluated in order to provide information for
   inclusion in Advice, but such additional evaluations do not
   affect the result of the function.

Similarly, combining algorithms must specify any requirements
regarding the order in which rules/policies/sets are evaluated,
whether all rules/policies/sets MUST be evaluated, and the
semantics of any evaluated rule/policy/set returning
INDETERMINATE.

 > Anne Anderson wrote:
 > > 
 > > v14 of the spec, right under the rule evaluation table, on page
 > > 20 (in my copy) the last paragraph ends:
 > > 
 > >   "If any attribute value referenced in the condition cannot be
 > >    obtained, then the condition evaluates Indeterminate."
 > > 
 > > Shouldn't this be something like:
 > > 
 > >   "If any attribute value that must be obtained in order to
 > >    evaluate a condition cannot be obtained, then the condition
 > >    evaluates Indeterminate."
 > > 
 > > This allows for an OR function to be based on an attribute value
 > > that can be obtained, even some attribute values for other
 > > elements in the OR can not be obtained.
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC