Condition Representation and Evaluation

Read conditions such as access identity and location appearing in the authorization request, specify a set of constants which must be matched against a corresponding set of constants found in the policy elements. These conditions are represented by a set 124#124. This set is constructed from a set of all condition constants passed in authorization requests 3#3 defined in (), a set of all condition constants contained in policy elements 4#4 defined in () and a set of operations 43#43. Condition evaluation function for this type of conditions returns 26#26 if applying operation 125#125, (126#126) to the condition constants evaluates to 26#26, otherwise it returns 27#27.

For example, a set of operations 43#43 may contain (87#87). If 127#127, condition evaluation function returns 26#26 if 128#128), otherwise it returns 27#27.

Some conditions, such as system load, can be represented numerically. These conditions are evaluated by comparing numbers (natural, integer or real). Therefore, we can define the set of operations as
129#129 130#130 ,131#131 , 132#132 , 133#133 , 134#134, 135#135.

Write conditions, such as notification and audit specify the name of a system variable, whose value must be changed, and the new value. Condition evaluation function for these conditions returns 26#26 if the updating of the system variable succeeded, and 27#27 otherwise.

Unfortunately not all conditions can be represented in this way. In practice, conditions can be application-specific and complex. The problem is how an informal specification of the condition can be transformed into a precise formal mathematical structure, within which we can actually prove things about the properties, such as computability and polynomial-time decidability.