- Open Access
Conflict detection in obligation with deadline policies
© Essaouini et al.; licensee Springer. 2014
Received: 21 March 2014
Accepted: 8 August 2014
Published: 10 September 2014
Many papers have already provided models to formally specify security policies. In this paper, security policies are modeled using deontic concepts of permission and obligation. Permission rules are used to specify access control policies, while obligation rules are useful to specify other security requirements corresponding to usage control policies as the availability of information in its allotted time. However, when both permission and obligation concepts are used to express security policies, several different types of conflict can be raised and should be detected and managed. We are interested in this work in managing conflicts between obligations with deadlines and permissions. Thus, we first begin by formally defining the conflicting situations using the situation calculus. Afterwards, we provide an algorithm for searching a plan of actions, when it exists, which fulfills all the active obligations in a given situation in their deadlines with respect to the permission rules. The length of the plan is set in advance and can be calculated in the case where the sets of actions and fluents are finite to ensure the decidability of the solution search. Furthermore, in the plan search, the choice of the execution time of the elected actions obeys to equations and inequalities which need to be solved. For this purpose, we need a component allowing these equations and inequalities resolution. To illustrate our approach, we take an example inspired from existing laws in hospitals regulating deadlines for completion of patient medical records. The example is formally specified in our language and implemented in ECRC Common Logic Programming System ECLIPSE 3.5.2, which is equipped with Simplex algorithm for solving linear equations and inequalities over the reals. In the implementation, we show how the plan search can be optimized through the use of some heuristics and make some evaluation tests.
A security policy is often defined as permission, prohibition, obligation, and exemption rules. Permission and prohibition rules are used to specify access control policies. Obligation and exemption rules are useful to specify other security requirements corresponding to usage control policies ,. In the usage control literature, two different types of obligation are generally considered called system obligation and user obligation . When the security policy includes user obligation, these obligations should be associated with deadlines. When these obligations are activated, these deadlines provide the user with some time to enforce the obligation before violation occurs.
The application of these rules to the same object may lead to conflicting situations. Preliminary work on the classification of conflicts are reported in , where several types of conflicts have been defined (see also ,). Benferhat et al.  presents an approach based on possibilistic logic to deal with conflicts in prioritized security policies. However, there is another type of conflict which is not managed yet, namely, the conflict between obligations with deadlines. This kind of conflict could happen in the case of overlapping deadlines. For example: (i) The doctor is obliged to fill in the summary sheet within 1 h after the patient leaves. (ii) The surgeon must be vigilant in the operating room. If the doctor is a surgeon and he is in the operating room during a patient’s leaving, and if the duration of the surgery ends 2 h after the patient’s leaving, the surgeon cannot fill in the summary sheet of the patient because the surgery could end after the deadline associated with filling the summary sheet. Thus, there may be situations where it is impossible to meet certain obligation requirements of the security policy before their deadlines.
Temporal projection problem : asks whether a formula holds after a sequence of actions is performed in the initial situation. This is useful to decide which rule can be applied to a given situation and detect violation.
Planning : given a goal formula, planning consists in finding a sequence of actions so that the goal is satisfied after executing this sequence of actions. We show how to detect, using planning task, if there is conflict between obligation with deadline rules. Then, we introduce the concept of legal plan to detect conflict between obligation and permission rules.
To illustrate our approach, we take the example of completion of medical records inspired from existing laws in hospitals . This completion is regulated by obligation rules with deadline. Each rule specifies the associated deadline to complete each document in the patient record. Any latency on writing patient record could affect the information availability time for each patient which negatively impacts the quality of provided care. This has led some hospitals to specify sanctions when these deadlines are not respected, see for example the Ontario regulations . The example shows a real need to have obligations with deadline in security policy and a real need to manage the conflicts between them.
The initial proposed formalism is extended with two new modalities for expressing permissions and system obligations.
Managing permissions induces a new type of conflict which occurs when it is impossible to find a sequence of permitted actions which leads to a situation where obligations are fulfilled in their deadlines. We formally define the situations which correspond to such conflicts by introducing the concept of a legal plan.
The algorithm for detection of conflict between obligations with deadline initially proposed in the previous paper is extended to allow the detection of conflicts between permissions and obligations with deadlines.
The previous implementation is extended to support the search for a legal plan. And finally, we made some evaluation tests and propose some optimization tools using heuristics.
This article is organized as follows. In Section 1, we give a motivation example. Section 2 presents the situation calculus. Section 3 explains how to define security policies that include obligations with deadline. This model is based on deontic logic, and a security policy is viewed as a set of deontic norms. Section 5 extends situation calculus to formally derive which actual norms apply in a given situation. In this section, we also formally define when an obligation with deadline is violated. Section 5 shows how to detect the presence of conflicting norms in the policy. In Section 6, we give the specification of the motivation example. In Section 7, we make the implementation of our model using the programming language GOLOG . In this section, we make assessment on different situations that we built to simulate our model on the use case and discuss some performance evaluation. The related work is presented in Section 8. Finally, we present the conclusion and perspectives.
1 Motivation example
In the medical community, patient’s record contains information about care provided to the patient during his stay in the hospital. The medical records are regulated by hospitals through legal texts . These laws specify, in particular, the time given to doctors to complete patient records assigned to them. In hospitals where medical records are digitally stored, these rules may be expressed as obligations with deadlines. These rules aim to ensure the availability of medical information in expected time. In this section, we describe the impact of availability of medical information in expected time on the quality of patient care, and we give an example of obligations with deadline concerning completion of medical records.
1.1 Impact of deadlines to complete medical records on the availability of information
Studies have shown that patient care can be improved by timely sending a complete and accurate information on patient hospitalization to the practitioner -. In contrast, a breakdown of communication, due to delays in the transfer of information or incomplete information, can have serious consequences. For example, the physician who does not have access to the summary sheet of a patient hospitalization prepared by acute care services is in an uncomfortable situation when the patient’s life is in danger. Despite what has been raised by these studies on the importance of time when transferring patient information, other studies have noticed that in practice, there is a lag in the transfer of this information. Some of these studies noticed a significant delay between the time when the patient receives his leave and when the generalist physician received the advice ,. Therefore, the hospitals are required to establish regulations so that the medical records are filled timely to ensure continuity of patient care. In what follows, we give some examples of rules concerning the deadline assigned to doctors to complete certain elements of patient’s records.
1.2 Rules regarding the completion of patient’s medical record
The medical summary/summary sheet: When a doctor authorizes the patient assigned to him to leave the hospital, he must complete the medical summary of this patient before this latter leaves the hospital.
Admission note: The doctor must complete the admission note of the patient assigned to him when he is admitted in the hospital within 30 min following his admission.
Medical observation: The doctor must complete the medical observation of the patient assigned to him when he is admitted in the hospital within 40 min following his admission.
Operating Protocol: The doctor who did a surgery for a patient assigned to him must complete the operating protocol of this patient within 100 min following the intervention.
Discharge note: If a doctor authorizes the patient assigned to him to leave the hospital, he must complete his discharge note. The discharge note must be completed before the patient’s leaving.
2 Situation calculus
The situation calculus  is a second-order logic language specially designed to represent the change in dynamic worlds. The ontology and axiomatization of the sequential situation calculus was extended to include time , concurrency, and natural actions . However, in all cases, the basic elements of language are actions, situations, and fluents. The situation language used in this paper is described below.
2.1 The language
All changes in the world are the results of actions. They are designated by terms of first-order logic. To represent the time in the situation calculus, we add a time argument in all instantaneous actions which is used to specify the exact time or time range in which the actions occur in world history. For example, sign(Jean, dischargeNote(Mary), 100) is the instantaneous action of signing the discharge note of Mary by Jean at the moment 100. The actions are instantaneous, but we can express actions with duration. For example, consider the following two instantaneous actions, startConsultation(d, p, t), meaning d starts consultation of p at time t, and endConsultation (d,p,t′), meaning d ends consultation of p at time t′. The fluent inConsultation(p, s), expressing the patient p is in consultation in the situation s, turns from false to true if there exists a time t and doctor d when the action startConsultation(d, p, t) is performed, and turns to false if there exists a time t′ when the action endConsultation (d,p,t′) is performed. Thus, in situations where fluent inConsultation(p, s) is true, we can describe the properties of the world, such as the heartbeat of p per unit time, as a function of time that must be true during advancement of consultation.
A possible history of the world, which is a sequence of actions is represented by the first-order terms denoted situation. The constant S0 is the initial situation.
There is a binary function symbol do; do(α,s) denotes the situation resulting from the execution of the action α in the situation s. For example, do(write(Jean, dischargeNote(Mary), 5), do(write(Jean, consultationReport(Mary), 8), do(write(Jean, admissionNote(Mary), 10), S0))) is the situation indicating the history of the world which consists of the execution of the sequence of actions [write(Jean, admissionNote(Mary), 10), write(Jean, consultationReport(Mary), 8), write(Jean, dischargeNote(Mary), 5)].
Fluents describing the facts of a state. There are two types of fluents: relational fluents and functional fluents. Relational fluents are symbols of predicates which take a term of type situation as the last argument, which their truth values may vary from one situation to another. For example, inConsultation(Mary, s), means that Mary is in consultation at situation s. Functional fluents are denoted by function symbols that take a situation as the last argument, which the truth of their function values changes from one situation to another. For example, heartbeat(Mary, s) denotes the number of heartbeats of Mary in situation s.
There are also symbols of predicates and functions (including constants) denoting relations and functions independent of situations.
A particular binary predicate symbol <, defines a strict order relation on situations; s<s′ means that we can reach s′ by a sequence of actions starting from s. For instance, do(a2, do(a1, S0)) < do(a4, do(a3, do(a2, do(a1, S0)))).
A second particular binary predicate symbol Poss, defines when an action is possible. Poss(a,s) means that the action a can be executed in the situation s.
A function symbol time: time(a) denotes the time when the action a occurs.
A function symbol start: start(s) denotes the start time of the situation s.
2.2 Fundamental axioms
The second-order induction axiom:
The induction axiom says that to prove that property P is true in all situations, it is sufficient to prove that P is true in the initial situation S0 (initialization step) and for all actions a and situations σ, if P is true in the situation σ, then P is still true in the situation do(a,σ) (induction step). The axiom is necessary to prove properties true in all situations .
The unique name axioms:
Axioms that define an order relation < on situations:
The axiom: start(do(a,s))=time(a).
Action precondition axioms, one for each action:
where characterizes the preconditions of the action A, it is any first-order formula with free variables among , t, and whose only term of sort of situation is s.For example, a patient can leave the hospital if he is in the hospital.Using predicate poss(a), we can then recursively specify that a given situation s is executable.
Successor state axioms, one for each fluent. These axioms characterize the effects of actions on fluents and they embody a solution to the frame problema for deterministic actions .The syntactic form of successor state axiom for a relational fluent F is
where and indicate the conditions under which if the action a is executed in situation s, becomes true and false, respectively.For example, the succession state axiom of fluent assigned(p,d,s), meaning a patient p is assigned to a doctor d can be defined as follows:
Here, corresponds to the formula: (∃t)a=assign(p,d,t) and is the formula: (∃t)a=revokeAssignment(p,d,t)∨(∃t)a=leave(p,t). The action assign makes the fluent assigned true, and the actions revokeAssignment and leave turn the fluent assigned to false.
It is assumed that no action can turn F to be both true and false in a situation, i.e., .For a functional fluent, the syntactic form of successor state axiom is
where, is any first-order formula with free variables among , y, a, t, and whose only term of sort of situation is s.
Axioms describing the initial situation.
In each application involving a particular action , an axiom that gives the time of the action A: .
Σ is the foundational axiomatic of the situation calculus.
Ass is a set of successor state axioms.
Aap is a set of action precondition axioms.
is a set of initial situation axioms. is a set of sentences with the property that S0 is the only term of sort situation mentioned by the fluents of a sentence of . Thus, no fluent of a formula of mentions a variable of sort situation or the function symbol do.
where do([a1,…,a n ],s) is an abbreviation for do(a n ,do(an−1,…,do(a1,s)…)).
3 Security policy specification
The language we define to specify permissions and obligations in security policies is based on deontic logic of actions. We consider two modalities: permissions and obligations with deadline. They are called normative modalities in the following. Normative modalities are represented as dyadic conditional modalities. Permissions are specified using dyadic modality P(α|p), where α is an action of and p is the condition of the permission. The condition is any formula built using fluents of without situation. P(α|p) means that the action α is permitted when condition p holds. Obligations with deadline are specified using modality O(α<d|p) which intuitively means that when formula p starts to hold, there is an obligation to execute action α before the deadline condition d starts to hold. In the following, we assume that the deadline condition must be an atomic fluent predicate of . If the action α is executed before the deadline condition d starts to hold, then we shall say that the obligation is fulfilled. Else, we shall consider that the obligation is violated. We call norm a formula corresponding to a conditional permission or obligation with deadline. A security policy, is a finite set of norms. We shall now use the situation calculus to formally define the semantics of these different modalities.
4 Actual norm derivation and violation detection
This axiom specifies that the permission to do an action becomes effective after the action that activates the context of the permission rule is executed. This permission remains effective until an action that turns the activation context to false is executed.
Using permitted situations, we introduce a notion of legal plan. Given a goal formula G, a legal plan consists of finding a permitted situation that satisfies G.
This axiom says that the obligation to do α before deadline d is activated when starts to be true. This obligation is deactivated when it is fulfilled (i.e., action α is done) or it is violated (i.e., deadline d starts to be true) or condition ends to be true (i.e., it is no longer relevant to do α).
Notice that if in a given situation σ, it simultaneously happens that the obligatory action is executed and the associated deadline is activated, then the decision is to consider that the obligation is violated and not fulfilled. This is called obligation with strict deadline. We can also define O(α≤d|p) so that in the same situation, the obligation is fulfilled and not violated.
This axiom specifies that an obligation to do α is violated, when the associated deadline comes true when it was still active, and it was never executed. The axiom also specifies that in a given situation σ, if it simultaneously happens that the obligatory action is executed and the associated deadline is activated, then the decision is to consider that the obligation is violated.
5 Policy conflict detection
conflict between obligation with deadline rules
conflict between permission and obligation with deadline rules
situation locally enforceable is defined in relation with a particular obligation and characterizes the fact that this obligation can be fulfilled by following the executable plan.
situation globally enforceable characterizes the fact that all the active obligations can be enforced in an executable plan without violating the associated deadlines.
situation legal locally enforceable is defined in relation with a particular obligation and characterizes the fact that this obligation can be fulfilled by following an executable plan constituted of permitted actions (legal plan).
situation legal globally enforceable characterizes the fact that all the active obligations can be enforced in an executable and legal plan without violating the associated deadlines.
5.1 Obligation conflicts
Proving that a given situation σ is globally enforceable, amounts to proving the existence of an executable situation where all the active obligations in σ are fulfilled. If such a situation does not exist, we say that the policy is feasibility conflictual in σ. If the set of actions and the set of fluents are finite, we can prove that the existence of such a situation is decidable and can be solved in NEXPTIME complexity. This complexity of planning in the situation calculus is high but is similar to other planners, like Strips for example .
5.2 Conflict between permission and obligation rules
In what follows, we assume the existence of a temporal reasoning component that allows us to infer, for example, that T1=T2 when T1≤T1 and T2≤T2, and we are able to solve linear equations and inequalities over the reals using the Simplex algorithm . Algorithm 1 detects the different types of conflict we have defined using recursive search as defined in Algorithm 2. Note that in Algorithm 2, we allow the execution of parallel actions; otherwise, we can use constraints to specify the actions which cannot be done in parallel. These constraints can be compiled into precondition axioms of these actions . In this work and to simplify, we omit the use of constraints. Note that we suppose that if a situation we check is globally enforceable (respectively legally globally enforceable), then this situation must be executable (respectively permitted). Proving that a situation is executable (respectively permitted) can be done using regression , where testing is reduced to proving first-order theorem in the initial situation.
6 Formal specification of the case study’s security policy
Rule 1: The doctor must complete the admission note of the patient assigned to him within 30 units of time following his admission to the hospital.
Rule 2: The doctor must complete the medical observation of the patient assigned to him within 30 units of time following his admission to the hospital.
Rule 3: End deadline for completing the admission note of a patient must occur after 30 units of time of his admission to the hospital.
Rule 4: End deadline for completing the medical observation of a patient must occur after 40 units of time of his admission to the hospital.
Rule 5: The doctor is permitted to start writing observation or admission note of an inpatient assigned to him when he is not writing another document.
Rule 6: The doctor is permitted to complete observation or admission note at least 5 units of time after he began to write it.
Normally, we should specify a permission rule for each action in . But for simplicity, we quote just one permission rule regarding the action of writing documents.
Set of fluents:
assigned(p,d,s). The patient p is assigned to a doctor d in situation s.
inpatient(p,t,s). The patient p is admitted to the hospital at time t in the situation s.
leaving(p,s). The patient p leaves the hospital in s.
deadline(t y p e,p,t,s). The deadline to write document of type type concerning patient p created at time t is elapsed in s.
writingDoc(d,type,p,t,t′,s). d is writing the document of type type concerning patient p created at time t and began to be written at t′ in s.
writtenDoc(d,type,p,t,s). The document of type type concerning patient p and created at time t has been written in s by d.
doctor(d). d is a doctor.
Set of actions:
assign(p,d,t). The action to assign at time t the patient p to the doctor d.
revokeAssignment(p,d,t). The action to revoke at time t assignment of the patient p to the doctor d.
patientAdmission(p,t). The action to admit at time t the patient p at the hospital.
leave(p,t). The patient p leaves the hospital at time t.
EndDeadline(t y p e,p,t,t′): The action to warn at time t′ that the accorded deadline for writing document of patient p expires.
StartWrite(d,type,p,t), EndWrite(d,type,p,t): d starts (respectively ends) to write document of type corresponding to patient p at time t; type is one of the following elements: Observation or AdmssionNote.
Fluent succession state axioms: Patient p will be assigned to doctor d when the action of assignment is executed, since then p remains assigned to d unless there is a revocation of assignment or the patient leaves the hospital.(6)Patient p is hospitalized if he was admitted to the hospital and did not leave.(7)Action EndDeadline is executed to denote that the delay accorded to write documents is elapsed. When the deadline is considered expired, it remains expired forever.(8)A document is in a writing process if its writing began before and is not completed yet.(9)A document is considered written if the writing process is completed.(10)
Action precondition axioms: In what follows, all action precondition axioms are written using equivalent conditions except startWrite action. This is because we consider that all these actions are always permitted (even if we did not mention the permission rules associated with them for simplicity). In contrast, precondition axiom of actions startWrite and endWrite will be rewritten later to take into account the permission rule associated with them.It is assumed that a patient can be assigned at any time to a doctor except if the patient is already assigned to him.
We implement our model using the logic programming language Golog ,, based on the situation calculus. Regarding our need to solve linear equations and inequalities, we use the Common Logic Programming System ECLIPSE 3.5.2, which provides a built-in Simplex algorithm for solving linear equations and inequalities over the reals.
The point of departure for the implementation is to get the list of all active obligations in a given situation S. This is given using the predicate activeObligations(ActiveObligationsList,S):
Given the list of active obligations, seeking the situation where all these obligations are fulfilled is made using the procedure plan.
Here, primitiveAction is a predicate characterizing all the actions of the domain. If N=0, the execution of the procedure ends. If N>0, a primitive action a is selected. The Golog interpreter checks if the selected action a is possible and verifies that start(s)≤time(a), where s is the current situation. If so, a is executed and do(a,s) becomes the new current executable situation.
We can change the following instruction of Golog:
and replace it with the following statement for searching a legal plan:
In our implementation, we make no change in the Golog interpreter, but every precondition axiom of an action includes the fact that this action is permitted using the fluent perm. Thus, we test whether a situation is strongly enforceable or not using the predicate sEnforceable(N,S1).
Let us start by seeing how we can write some axioms of our example using Golog. The complete description of axioms is described in Additional file 1.
7.1 Examples of succession state axioms
7.2 Examples of action precondition axioms
In addition to the succession state axioms and precondition axioms of actions, we suppose having the following axioms in the initial situation s0.
7.3 Description of bad situations
The badSituation test is used to remove partial plans which are known in advance to be unsuccessful. For example, a branch resulting from the execution of an action that disables an active obligation can be eliminated. A branch resulting from the execution of an action that activates the deadline corresponding to an active obligation may also be removed. We will see in the following how this can be done in the implementation of our example.
If a violation of an active obligation occurs after the execution of an action, it is no longer necessary to continue searching a solution from the resulting situation.
If an active obligation is deactivated after the execution of an action, it is no longer necessary to continue searching a solution from the resulting situation.
The construction of these bad situations can be done using the succession state axioms of fluent Ob and Fulfil. Thus, these optimizations can be generalized to any policy without losing the completeness of the planning search. In our example, the execution of actions patientAdmission and assign activates other obligations and have no impact on the fulfillment of obligations which are already active. Therefore, the path resulting from their execution can be eliminated in the solution search.
This optimization is closely related to our example because there is nothing that prevents to have actions in the policy that are necessary to fulfill obligations, but their execution leads to activate other obligations simultaneously.
We have performed tests that check the strongly enforceability of situations constructed as follows: the first situation checked by the first test, denoted s 1 is the result of the assignment of a single patient p 1 to the doctor jean at time 4 followed by his admission in the hospital at time 5.
The next situation s 2 is the assignment of another patient p 2 to jean at time 6 from the situation s 1 followed by the admission of p 2 in the hospital at time 7.
We build 20 tests. Their complete description is in Additional file 2. The planning depth research is calculated as follows. In our application domain, there are seven actions, four of them are removed from the planning through the specification of badSituation. The remainder actions are startWrite, endWrite, and endDeadline. In the database, there is one doctor Jean and two types of documents, so for each patient, these actions are possible twice, one for each type of document. When one of these actions is executed, it is not possible to execute it again according to their precondition axioms. Thus, when all these actions are performed one after the other, it is no longer possible to perform other actions except those which are discarded from the planning search. Thereby, whenever a patient is added, the minimum depth ensuring the decidability of solution research is increased by six.
We conducted two series of tests depending on the deadlines associated with the obligations to write documents. The experiment was run on a machine equipped with an Intel 32 bit, 2.60 GHz, x4 processor, and 3.8 GB RAM, running ECLIPSE 3.5.2 on ubuntu Linux (v.13.04).
7.4 The first series of tests
The deadline for writing admission note is 30 units of time, and the observation is 40 units of time (see Additional file 3). In this series of tests, the maximum number of patients, who can be admitted in the hospital and assigned to jean, without causing conflict between the obligations is 4. Indeed, the policy is not conflictual in the first four situations. As example, the following legal plan generates a situation when all the active obligations in the situation s 1 are fulfilled which means that s 1 is strongly globally enforceable.
The above plan contains uninstantiated temporal variables. The value of these variables is just constrained by the inequalities in ECLIPSE’s linear constraint store, although there may be cases when plans are fully specified like the following third test which proves that the policy remains consistent after the admission of three patients.
Finally, the fifth test shows how the admission of a fifth patient produces a conflict.
7.5 The second series of tests
The deadline for writing admission note is 1,000 units of time, and the observation is 1,100 units of time (see Additional file 4).
The summary of second series of tests
CPU time (s)
8 Related work
Most traditional security models are static and respond to access requests just by yes (accept) or no (deny). Recently, there are more and more works on security models that model obligations ,-. Formalization of obligations differs from one model to another. In XACML , obligations are all operations that must be met in conjunction with the application of the authorization decision. In ,,, distinction is made between provisions and obligations. Provisions are actions or conditions that must be met before authorizing access. Obligations are actions that must be executed by users or system after the access is given. The ABC model (authorization, obligation, and condition)  was specifically designed to express security policies including usage control constraints. The expression of a constraint to be satisfied before the use of an object can be expressed as contextual authorization. However, constraints to meet during or after the use of an object relate to obligations that the user must follow. The NOMAD model  is based on a formalization in temporal and deontic logic to express contextual obligations which should be met before, during, or after the execution of an action. It is also possible to specify a deadline after which some obligation will be considered violated if the action was not performed. Authors in , define a core language to specify the access and usage control requirements and then give a formalism based on the logic of temporary actions (TLA)  to specify the behavior of the policy controller in charge of evaluating such policy. In this approach, a permission is associated with two conditions, the first must be true at the time of query evaluation, and the second must always be true as long as access is in progress. The authors also introduce a concept to reset a current access. Regarding obligations, they are associated with two conditions. Once the first condition is satisfied, the obligation is triggered, then the controller sends a notification to the user to perform the appropriate obligation, the second condition determines when the obligation should be considered violated. If the user does not satisfy the obligation before the second condition becomes true, a penalty is applied to him. The authors in  talk about what they called deontic conflicts. The types of conflict that the authors have classified in this category are those that occur between permission and prohibition and those which occurs between obligation and obligation waiver. As in the used formalism, the authors do not use prohibition and obligation waiver modalities, they do not deal with these conflicts in their work. But in this category, there is another kind of conflict which is the conflict between the obligations with deadlines and permissions. In our work, this conflict is detected when there is no plan consisting of permitted actions that lead to fulfilling an obligation requirement in its deadline. In other words, it is possible that in a given situation, a mandatory action is permitted and it can be fulfilled in its deadline, but it is not possible to execute because it is necessary to first execute other actions which are not permitted. Certainly, the authors define another type of conflict called temporal conflicts which occur when two deontic assignments at the same time initiate and terminate obligation. This is a particular case of what we detect in what we call the global conflict between the obligations with deadlines. Indeed, in a given situation, it may be possible to fulfill an active obligation in its deadline but given that there are other active obligations, at the same time it is not possible to fulfill them together without violating one of them. The conflict in the temporal constraints is actually a special case of a ‘logical’ conflict which we detect with the concept of executable plan.
In this paper, we use deontic modalities to specify close security policies including obligations with deadline. Then, we use the temporal sequential situations calculus to derive concrete permissions and obligations. Furthermore, we show how the situation calculus allows us to detect if there is a policy conflict in a given situation using the planning task. Moreover, we have illustrated our approach by using a case study from the health care community. Specifically, we are interested in obligations with deadlines concerning completion of the patients’ medical records. We show how we can use our language to express the obligations of this example. In addition, we present the implementation that we did, using the logic programming language based on Golog.
On the other hand, obligations are generally associated with penalties when their violation occurs. The regulation of a hospital may specify the penalties triggered when medical records are not completed on due time. For example, if medical folders are not completed on time, the medical records department can establish for the president of the Executive Committee of the Medical Council of doctors the list of doctors and the number of folders that remain incomplete for each of them. While receiving this list, the director of professional services can inform by warning all doctors of the list that their privileges are automatically suspended until they complete their late folders. Our ongoing work along these lines consists, when we have a conflict, to specify whether the subject is accountable for this conflict. Furthermore, when we have several subjects, it is important to specify whether the violation of an obligation is not due to a violation of another subject obligation that has indirectly delayed fulfillment of the first obligation.
Our future work also includes conflict resolution. A conflicting situation means that there are subjects who cannot accomplish their active obligations one after another without violation. In such a situation, it will be interesting to know if there are active obligations of another subject in the same situation that could solve this conflict and then derive if this subject has enough free time to perform some active obligations of the first subject. This is one of the possible solutions to solve the conflict. We can also detect the rules responsible for the conflict and then update the policy with new deadlines for these rules.
a The difficulty in logic of expressing the dynamics of a situation without explicitly specifying everything that is not affected by the actions.
This work is supported by the ITEA2 Predykot project (Grant agreement no.10035).
- F Cuppens, N Cuppens-Boulahia, T Sans, in CSFW. Nomad: a security model with non atomic actions and deadlines, (2005), pp. 186–196.Google Scholar
- Elrakaiby Y, Cuppens F, Cuppens-Boulahia N: Formal enforcement and management of obligation policies. Data Knowl. Eng 2012, 71(1):127-147. 10.1016/j.datak.2011.09.001View ArticleGoogle Scholar
- Hilty M, Pretschner A, Basin D, Schaefer C, Walter T: A policy language for distributed usage control. In Proceedings of the 12th European Conference on Research in Computer Security (ESORICS’07). Springer-Verlag, Berlin; 2007:531-546.Google Scholar
- Moffett JD, Sloman MS: Policy conflict analysis in distributed system management. J. Organ. Comput 1994, 4(1):1-22.Google Scholar
- Bertino E, Jajodia S, Samarati P: Supporting multiple access control policies in database systems. In Proceedings of the 1996 IEEE Symposium on Security and Privacy. IEEE Computer Society, Washington, D.C.; 1996:94-94.View ArticleGoogle Scholar
- G Dinolt, L Benzinger, M Yatabe, in Proceedings of the Computer Security Foundations Workshop VII. Combining components and policies (Franconia, USA, 1994).View ArticleGoogle Scholar
- Benferhat S, El Baida R, Cuppens F: A stratification-based approach for handling conflicts in access control. In SACMAT 2003, Proceedings of the 8th ACM Symposium on Access Control Models and Technologies, Como, Italy. ACM, New York; 2003:189-195. ISBN:1-58113-681-1Google Scholar
- R Reiter, in Principles of Knowledge Representation and Reasoning: Proceedings of the 6th International Conference (KR’ 98). Sequential, temporal Golog (Morgan Kaufmann, San Francisco, 1998), pp. 547–556.Google Scholar
- S Hanks, D McDermott, in Readings in Nonmonotonic Reasoning, ed. by ML Ginsberg. Default reasoning, nonmonotonic logics, and the frame problem (Morgan Kaufmann, San Francisco, 1987), pp. 390–395.Google Scholar
- C Green, in Proceedings of the 1st International Joint Conference on Artificial Intelligence (IJCAI’69). Application of theorem proving to problem solving (Morgan Kaufmann, San Francisco, 1969), pp. 219–239.Google Scholar
- RRO, Règlement 965. Gestion Hospitalière. Dossiers de renseigments personnels sur la santé (1990).Google Scholar
- Essaouini N, Cuppens F, Cuppens-Boulahia N, Kalam AAE: Proceedings of the eighth International Conference on Availability, Reliability and Security. IEEE Computer Society, Los Alamitos; 2013.Google Scholar
- Levesque HJ, Reiter R, Lesperance Y, Lin F, Scherl RB: GOLOG: a logic programming language for dynamic do- mains. J. Logic Program 1997, 31(1–3):59-83. 10.1016/S0743-1066(96)00121-5MATHMathSciNetView ArticleGoogle Scholar
- Balla JI, Jamieson WE: Improving the continuity of care between general practitioners and public hospitals. Med. J. Aust 1994, 161(11–12):656-659.Google Scholar
- Bolton P: A quality assurance activity to improve discharge communication with general practice. J. Qual. Clin. Pract 2001, 21: 69-70. 10.1046/j.1440-1762.2001.00416.xView ArticleGoogle Scholar
- Adams DC, Bristol JB, Poskitt KR: Surgical discharge summaries: improving the record. Ann. R. Coll. Surg. Engl 1993, 75(2):96-99.Google Scholar
- Embi PJ: Perceived Impact of Computerized Physician Documentation on Education and Clinical Practice in a Teaching Hospital. Oregon Health & Science University, Portland; 2002.Google Scholar
- Mageean RJ: Study of “discharge communications” from hospital. Br. Med. J 1986, 293(6557):1283-1284. 10.1136/bmj.293.6557.1283View ArticleGoogle Scholar
- Raval AN, Marchioriz GE, Arnold JM: Improving the continuity of care following discharge of patients hospitalized with heart failure: is the discharge summary adequate? Can. J. Cardiol 2003, 19(4):365-370.Google Scholar
- Situations, Actions and Causal Laws. MIT Press, Cambridge; 1968.Google Scholar
- R Reiter, in Principles of Knowledge Representation and Reasoning: Proceedings of the Fifth International Conference, ed. by L Aiello, J Doyle, and S Shapiro. Natural actions, concurrency and continuous time in the situation calculus (Morgan Kaufmann, San Francisco, 1996), pp. 2–13.Google Scholar
- Lin F, Reiter R: State constraints revisited. J. Logic Comput 1994, 4: 655-678. Special issue on actions and processes 10.1093/logcom/4.5.655MATHMathSciNetView ArticleGoogle Scholar
- Reiter R: The frame problem in the situation calculus: a simple solution (sometimes) and a completeness result for goal regression. In Artificial Intelligence and Mathematical Theory of Computation: Papers in Honor of John McCarthy. Edited by: Lifschitz V. Academic Press, San Diego; 1991:359-380.View ArticleGoogle Scholar
- Reiter R: Proving properties of states in the situation calculus. Artif. Intell 1993, 64(2):337-351. 10.1016/0004-3702(93)90109-OMATHMathSciNetView ArticleGoogle Scholar
- Green CC: Theorem proving by resolution as a basis for question-answering systems. In Machine Intelligence, volume 4. Edited by: Meltzer B, Michie D. American Elsevier, New York; 1969:183-205.Google Scholar
- Fikes R, Nilsson NJ: STRIPS: a new approach to the application of theorem proving to problem solving. Artif. Intell 1971, 2(3/4):189-208. 10.1016/0004-3702(71)90010-5MATHView ArticleGoogle Scholar
- Frühwirth TW, Herold A, Küchenhoff V, Le Provost T, Lim P, Monfroy E, Wallace M: Contraint logic programming - an informal introduction. In Proceedings of the Second International Logic Programming Summer School on Logic Programming in Action (LPSS ’92). Edited by: Comyn G, Fuchs NE, Ratcliffe M. Springer-Verlag, London; :3-35.Google Scholar
- Bettini C, Jajodia S, Wang XS, Wijesekera D: Obligation monitoring in policy management. In 3rd International Workshop on Policies for Distributed Systems and Networks (POLICY 2002), 5–7 June 2002. (IEEE Computer Society, Monterey; 2002.Google Scholar
- N Damianou, N Dulay, E Lupu, M Sloman, The ponder policy specification language. Proceedings of the International Workshop on Policies for Distributed Systems and Networks (POLICY ’01), 18–38 (2001).View ArticleGoogle Scholar
- Ni Q, Bertino E, Lobo J: An obligation model bridging access control policies and privacy policies. In Proceedings of the 13th ACM Symposium on Access Control Models and Technologies (SACMAT ’08). ACM, New York; 2008:133-142.View ArticleGoogle Scholar
- Craven R, Lobo J, Ma J, Russo A, Lupu E, Bandara A: Expressive policy analysis with enhanced system dynamicity. In Proceedings of the 4th International Symposium on Information, Computer, and Communications Security (ASIACCS ’09). ACM, New York; 2009:239-250.Google Scholar
- Oasis, Extensible access control markup language tc v2.0, normative xacml 2.0 documents. OASIS Standard. . Accessed 1 Feb 2005., [http://www.oasis-open.org/specs/index.php]
- Hilty M, Basin D, Pretschner A: On obligations. In Computer Security-ESORICS 2005, Lecture Notes in Computer Science. Edited by: di Vimercati S, Syverson P, Gollmann D. Springer, Berlin; 2005:98-117.View ArticleGoogle Scholar
- Park J, Sandhu R: The UCONABC usage control model. ACM Trans. Inf. Syst. Secur 2004, 7(1):128-174. 10.1145/984334.984339View ArticleGoogle Scholar
- F Cuppens, N Cuppens-Boulahia, T Sans, in 18th IEEE Computer Security Foundations Workshop (CSFW). Nomad: a security model with non atomic actions and deadlines (Aix en Provence, France, 2005).Google Scholar
- Sans T, Cuppens F, Cuppens-Boulahia N: A framework to enforce access control, usage control and obligations. Ann. Telecomm 2007, 62(11–12):1329-1352.Google Scholar
- Lamport L: The temporal logic of actions. ACM Trans. Program. Lang. Syst 1994, 16(3):872-923. 10.1145/177492.177726View ArticleGoogle Scholar
- Goedertier S, Vanthienen J: Designing compliant business processes with obligations and permissions. In Business Process Management Workshops, Lecture Notes in Computer Science. Edited by: Eder J, Dustdar S. Springer, Berlin; 2006:5-14.View ArticleGoogle Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly credited.