Basic Definitions and Assumptions

We present our conceptual model based on set and function formalism, algebra of sets and first order logic. The conceptual model specification is guided by conventional authorization notions and expected authorization requests.

An elementary policy statement consists of an object component, a positive or negative access right component and zero or more condition components. Thus, to represent the components, we define sets of elements called objects 5#5, positive rights 6#6, negative rights 7#7 and conditions 8#8. All existing policy statements are contained in the set 9#9. In addition, we define a set of authorization requests 10#10.

All the sets, except for 8#8 , are finite dynamic and unordered. The dynamic property means that sets are not fixed, new elements can be added and existing elements can be deleted. The finite property assumption requires that at any particular time, the sets are finite. Negation is applied only to the elements of the set 6#6 to model negative rights. We do not define negative conditions. The empty set is denoted by 11#11.

5#5 is finite dynamic non-empty unordered set of object elements:

12#12 (1)

6#6 is finite dynamic non-empty unordered set of access right elements:

13#13 (2)

7#7 is finite dynamic non-empty unordered set of negative access right elements. Set 7#7 is constructed from the set 6#6 by applying negation to each element of the set 6#6.

14#14 (3)

Note that 6#6 15#15.

8#8 is dynamic unordered set of condition elements with a special condition element 16#16, which represents an empty condition:

17#17 (4)

9#9 is finite dynamic unordered set of compound policy elements:

18#18 (5)

Each element 4#4 of the set 9#9 represents a set of three elements:

19#19 (6)

Note that a condition element can be 16#16. When 20#20 the rights are granted or denied unconditionally. An example of a practical policy with an empty condition is: ``file 1#1 can be read by anyone''.

10#10 is finite dynamic partially ordered set of compound authorization request elements:

21#21 (7)

Each element 3#3 of the set 10#10 represents a set of three elements:

22#22 (8)

The elements correspond to the target object (23#23), requested access right (24#24) and a condition constant (25#25). The condition constant 25#25 represents information which is matched to the requirements specified in the condition of the relevant policy statement. In practice, this information can be represented by a set of credentials, e.g., authenticated user identity. For example, a policy statement ``Anyone can read file 1#1 from 8am till 6pm'' specifies a time condition. The request ``read (24#24) file 1#1 (23#23) at 5pm (25#25)'' specifies current time and is matched to the time condition in the policy statement.

To make our model practical, special provisions should be made for dealing with the following situations:

• incomplete data, not known at the authorization time. During network fragmentation some data may be inaccessible.

• policy requires a certain event to happen in the future. Statements about the future do not have truth values until the event described takes place.

• the function used to evaluate conditions does not terminate for the arguments supplied. Incorrect implementation, bad parameters.

In order to properly deal with these situations we will adopt a three-valued logic [9], [13].

Three-valued logic is classical boolean (true/false) logic extended with a third truth value - undefined.

We define an auxiliary set 2#2, consisting of the three constants: true, represented by 26#26, false, represented by 27#27 and 28#28, meaning uncertainty.

29#29 (9)

Table 1 shows the truth tables, when at least one argument is equal to 28#28.

30#30


Table 1.

In addition, 31#31. Next we define functions to express an authorization process.

The 32#32 function takes a set of policy elements 9#9 and request 3#3, which contains particular object 33#33 as an argument and returns a subset 34#34 where this object appears.

35#35

36#36 (10)

The 37#37 function takes a set of policy elements 9#9 and request 3#3, which contains particular access right 38#38 as an argument and returns a subset 34#34 where this right appears.

39#39

40#40 (11)

The 41#41 is a condition evaluation function.

42#42 (12)

The function 43#43 defines positive or negative modality of the policy element. If the access right, contained in the policy element is positive or negative, the modality is positive or negative, respectively.

44#44 45#45 46#46

47#47 48#48 49#49 (13)

The 43#43 function has to be applied to all elements 34#34. The evaluated modality of each policy element will be taken with or without the negation 50#50 according to its right. After all the modalities are evaluated, we will take their disjunction. These operations are performed by the 51#51 function.

52#52

53#53

54#54 (14)

The resulting value 55#55 obeys to the 56#56 operation for three-valued logic. That is, 51#51 returns 26#26 if at least one modality gave the result 26#26, 27#27 if all results were 27#27, and 28#28 otherwise (i.e., at least one result was 28#28, possible some 27#27 but none 26#26).

The 57#57 is a composite function:

58#58

59#59

60#60 (15)

The 57#57 function takes the set of policies 9#9 and an authorization request 3#3 as arguments. It returns 27#27, 26#26 or 28#28 meaning authorized, not authorized or uncertain. Three-valued logic at the conceptual level has to be mapped to the two-valued logic at the implementation level. In the end, the access must be either granted or denied.