A Formal Security Model for Collaboration in Multi-agency Networks	
Salem Aljareh	
Computing Science, Newcastle University, Newcastle upon Tyne, UK NE1 7RU
Email: s.s.aljareh@ncl.ac.uk	
	
Nick Rossiter (Informatics), Michael Heather (Law)	
 University of Northumbria, Newcastle upon Tyne , UK, NE1 8ST
Email:nick.rossiter@unn.ac.uk; m.heather@unn.ac.uk	
Keywords:	Collaboration networks, security models, multi-agency service, category theory, pullback, Petri-Net
Abstract:	Security problems in collaborative work between multiple agencies are less well understood than those in the business and defence worlds. We develop a perspective for policies and models that is task-based on a need-to-know basis. These policies are represented by two protocols, the first CTCP (Collaboration Task-based Creation Protocol) dealing with negotiation, decision and agreement between the parties involved and the second CTRP (Collaboration Task-based Run-time Protocol) responsible for the operation of the policy. The two protocols and the relationship between them are defined in Petri-Nets. The overall model is formally defined using a categorical pullback construction. Each of the protocols, represented as Petri-Nets for state-transition purposes, is a category-valued functor in the pullback.  

1	INTRODUCTION
Information is naturally sharable among groups such as team, committee, organization, country and federation in a manner based on trust. However to achieve an accepted level of trust is quite a complicated issue because as the collaboration grows wider, more participants are involved with divergent policies. Although designing secure models for collaboration environments has been a target of a number of academic and commercial research bodies and several works have been done (both theoretical and practical), numerous organizations still keep their systems (especially the trusted systems) unconnected with outsiders. 
Basically security systems are built out of the available mechanisms to meet a security policy based on a selected security model [Gollmann, 1999]. A review has been made elsewhere [Aljareh & Rossiter, 2002] of the appropriateness of standard security models for collaborative multi-agency systems. Most are either targeted at a specific security requirement or are too static to represent a dynamic situation. All deal with a single policy, whereas by definition the multi-agency and collaboration environment involves more than one policy. 
A motivating example of an application that involves multi-agency services is the medical information services. The only model designed to meet the security requirements for the medical records in the UK was the BMA (British Medical Association) Security Policy Model [Anderson, 1996]. This model was recently examined [Aljareh & Rossiter, 2001] against the multi-agency security requirements and it was found that the issue of sharing clinical information including collaboration activities with other agencies such as police, social services or the education authority was not clearly considered. For instance the need-to-know problem was not addressed in the BMA model, as the BMA does not accept that need-to-know is an acceptable basis for access control decisions. However there might be a case where need-to-know cannot be avoided. For instance a service provider such as an insurance company offers its services conditioned by some information about the patient who applies for such services. An example is given in [Aljareh & Rossiter, 2001]. 
In this paper, we propose a security model that we argue will alleviate the security difficulties that may arise in attempts to build a collaboration network. The model is constructed from a task-based perspective, as this approach seems to offer the best way forward, as discussed later. An example of a prototype for informal collaboration, handled using the model, is given elsewhere [Aljareh & Rossiter, 2002]. The general principles of the model are discussed and a diagrammatic notation is devised. Two task-based collaboration protocols, expressed in this paper in the form of Petri-Nets, represent the permitted states and transitions. The choice of Petri-Nets as the notation is discussed. Finally the overall model is constructed formally as categorical pullbacks to illustrate its foundation on established logical principles. 
2	A TASK-BASED PERSPECTIVE FOR COLLABORATION NETWORKS
A collaboration business, by definition, is based on the needs of the collaborators from each other. Each side needs information or a service from the other participants. The obvious question that someone will immediately ask before he/she releases any confidential information or responds to an enquiry is: what for? For what purpose is the information required? Usually the expected answer will be the naming of a task for which the information required is essential, sometimes with a further explanation of the benefit of this task for the two sides (collaboration proposal). The information owner may like to restrict the use of this information by some conditions (security policy). If they reach initial agreement a detailed negotiation will then take place until they reach a considered level of trust, which leads to a collaboration agreement to perform the task. One reasonable condition might be to limit the use of the information by other tasks. For instance it could be specified that the information should not be used outside the task for any purpose.
We have decided to construct our model as a task-oriented model for the following reasons: 
1.	Fundamentally any collaboration scheme is based on specific tasks: there is no collaboration without a task. 
2.	The task-based approach is promising to address the need-to-know problem, satisfying a user requirement in any multi-agency services environment.
3.	The collaboration task is the common object between the collaborators. 
4.	Shared information ownership can be granted to the collaboration task. 
5.	The task is scalable, flexible and dynamic. 
6.	Explicit responsibility is recognized in the task-based approach. 
Overall the basis for any collaboration is an aim to share resources in order to achieve common benefits by performing shared operations. Other task-based approaches to security are discussed later.

3	GENERAL PRINCIPLES FOR OUR MODEL
Collaboration: In our model we consider any deal/trade between individuals or groups, which aims to benefit the sides involved as a kind of collaboration. The following are some forms of collaboration:
·	Trading between customers and service providers.
·	Joint operation projects
·	Research group collaboration.
·	The clinician and the patient trade/relationship: the clinician's job exists because of the patient, and the patient needs the clinician for treatment. So both need each other and benefit each other. The clinician may need to know some information from the patient as part of the course of treatment. The relationship is in general based on trust. In this example there are two sides trading benefits through the task called treatment
Ownership: In this model an item of information is owned initially by its natural owner that is the person to whom the information relates. For instance information about the baby is owned by the baby although this information is controlled by guardian/parents. In computer security terms this is called grant access or delegation. Once this information is required to be shared among collaboration parties, an access will be granted to what we call the collaboration-task, controlled by the task-policy. The information owner and/or the access controller will be part of the negotiation that results in the task policy.
Authorization: A participant in a collaboration network, called task-participant, will be authorised to gain access to a collaboration-task. This authority will be limited by what we call task-policy.
Responsibilities: All responsibilities should be explicitly defined in the task policy. This way each individual collaborator (task-participant) knows their responsibilities such as the required duties, the rules to follow (including ethical codes), the limitations (e.g. time, use of material and information) and the penalties.

4	COLLABORATIVE TASK CHARACTERISTICS
The characteristics of collaborative tasks are considered to be:
1.	Flexible:  can be a single activity or group of activities sharing same policy, each of which can be selected as the need arises. 
2.	Dynamic: can be updated even while it is running (supporting post-hoc justification). For instance a nurse can be replaced by another one if he/she is not, for any reason, able to complete his/her duty in a surgical operation. However any change in the task elements should be fully and carefully documented.
3.	Secure: should be fully protected using all the available mechanisms.
4.	Scalable: can be upgraded, for instance to fill some gaps in the original task. A new collaboration task can be built starting from default tasks. 
5.	Accountable: all collaboration protocol states and all task run-time events of the collaboration must be well documented.

5 	DIAGRAMMATIC REPRESENTATION OF MODEL 

Task-based Collaboration protocols

Collaboration Task-based Creation Protocol (CTCP)

Collaboration Task-based Runtime Protocol (CTRP)

Figure 1: General Architecture for secure Collaboration Environment

Policy

Material

Requirements

The architecture in Figure 1 illustrates the general components of our model. The main component is the collaborators (two or more), each of which will need to define three elements: requirements (what does he/she/it/they aim to gain from the other side), 

policy (rules that need to be obeyed) and material (e.g. information to release or services to offer). The second component is a pair of task-based collaboration protocols -- the Collaboration Task Creation Protocol (CTCP) and the Collaboration Task Runtime Protocol (CTRP) -- both detailed later in the following sections. 
CTCP includes a negotiation between all collaborators where the proposed task will be discussed including all collaborators’ policies and requirements. This process (negotiation) continues until a decision is taken either by rejecting the proposal or by accepting it. The acceptance of a proposal will lead to a formal agreement/contract, which will produce the proposed collaboration task in its final stage including all of the policies and requirements.  Negotiation can of course be a very complex task [Chu-Carroll & Carberry, 2000]. The work described here could be extended later to include such aspects as conflict resolution. CTRP will start after a successful compilation of CTCP and as scheduled .in the task_policy (not necessarily immediately after the end of CTCP).
The main function of CTRP is to process the task that was previously created by the CTCP protocol and ensure that the task_policy is obeyed, the collaborators are aware of the circumstances and the right action is taken. 

(Requirements, offer, policy) * No of Collaborators

Rethinking

Dismiss

Introduction

Negotiation

Decision

Mistrust

Discard

Trust

Agreement

Create
Col-task

Figure 2: Petri-Net Graph representing the Collaboration Task-based Creation Protocol (CTCP)

6	REPRESENTATION OF PROTOCOLS IN PETRI-NET NOTATION
We use the Petri-Nets model to represent our collaboration protocols to provide a formal basis and a more applicable medium for computer scientists. Flow charts lack a formal basis and can be ambiguous in representing states and transitions. Data flow diagrams emphasise flows of data, not states, which are considered critical in security systems. 
Net theory was originally introduced in a PhD thesis of C. A. Petri. Later Reisig [1985] introduced it to the software engineering area. More recent advances in this formalism are described in [Reisig & Rozenberg, 1998]. The usefulness of Petri-Nets in providing a theoretical basis for handling object life cycles has been demonstrated by van der Aalst and Basten  [2001]. In collaboration networks, similar to the multi-agency services investigated here, Furuta and Stotts [1994] presented an evolution of the Trellis model by providing a formal Petri net basis for prototyping the control of such a network. 
In the security area an industrial use of Coloured Petri-Nets was developed by Rasmussen and Singh, [1996] making it possible to perform simulations. The nets were debugged by constructing reachability graphs. Joshi and Ghafoor [2000] specified a multi-level security model for multimedia using a time- augmented coloured Petri-Net model. For cryptographic protocols Crazzolara and Winskel [2001] use Petri-Nets to illustrate how their semantics can be used to prove security properties. Ryan [2003] notes that causality, critical in the analysis of security protocols, is closely related to information flow and that causal structures are rather more explicit in Petri-Nets than in many other areas.
In general Petri-Nets have been widely used for the modelling and analysis of systems that are characterized as being concurrent, asynchronous, distributed, parallel and non-deterministic [Jensen, 1996].   All these features apply in the collaborative, multi-agency systems studied here. Activities in the systems: a) overlap in timing; b) are run independently rather than according to some common time signal; c) are run over many different servers; d) involve the splitting of tasks into subtasks which run in parallel until some common join point is reached; and e) may not give the same result in negotiation each time the protocols are run. 
The Petri-Net in Figure 2 represents the CTCP protocol. The initial state represents for each collaborator their requirements, policies and offers. For instance, in the patient-doctor collaboration, the patient’s requirements are treatments, the patient’s policy is to keep personal information secret, the doctor’s requirements may include information about the patient and the doctor’s offer is a treatment course. Following discussion of this initial state the task, at first an offer from one side or a requirement from another, is accepted as an offer for further negotiation or rejected without any further details. Policy considerations are normally omitted during the introduction transition. 
If the proposed task is found to be reasonable then all collaborators will enter into a detailed negotiation in which all aspects including requirements, services and polices will be clarified for all collaborators. After that one of three decisions will be taken: the first option could be one of the collaborators needs more time to think about the task/offer; the second option could be that the expected level of trust could not be ensured so the task is simply dismissed; the third option is that all collaborators trust each others so that an agreement between all collaborators will take place. This agreement at the end will be formulated in what we call the collaboration task. 

Init Process

Preparation

Task process

Log

Assessment

Abort

End

Update

CTCP

Figure 3: Petri-Net Graph representing the Collaboration Task-based Run-time Protocol (CTRP)

Task process

Task process

Init Process

Init Process

Preparation

Preparation

Log

Log

Assessment

Assessment

End

End

Abort

Abort

CTCP

CTCP

Update

Update

Figure 4: Exception occurring during CTRP, followed by an abort and a return to CTCP  (see section 6 for notation)

Figure 4: Exception occurring during CTRP, followed by an abort and a return to CTCP 

This task will be limited in scope by the task policy, which is a composition of all collaborators' policies, meeting all sides’ requirements.
The Collaboration Task Runtime protocol (CTRP), illustrated in Figure 3, starts after the task has been completely created by the CTCP protocol and when its schedule time, according to the task-policy, is due. Before starting the process of the task some tasks need some preparations. Then the task process starts following the policy that has been approved in the CTCP stage. Each state of this process is monitored, assessed (verified against the task-policy) and then documented. The task assessment may result in one of the following:
1.	The task is proceeding satisfactorily, following the policy and the plan and has not finished yet, so the task should persist. 
2.	The task needs an update to meet its requirements. Depending on how the updates affect the process: the task may restart or continue from the last state of the process. 
3.	The task reaches its scheduled end, hence the task terminates normally. 
4.	There might be a case where the task abnormally terminates, for instance the task-policy has been violated, or the task exceeds the scheduled time without valid reasons. The abnormal termination could lead either to the end of the task and then the collaboration or to a new session of the CTCP. An exception is raised when the policy has been violated as in Figure 4.

In our model exceptions are divided into three types according to the handling process:
1.	Exceptions with which the task can still continue to its normal end. Exceptions of this type are handled within the CTRP protocol by the task update component.  Figure 4 shows the path of the exception type as a double line =.. 
2.	Exceptions with which the task must be terminated and another task is required to complete the planned function. Such cases are handled partially in the CTRP protocol. The task in such cases is aborted and the process log (task history) used by the CTCP protocol to create another task to redo the function that could not be done by the terminated task in view of the exceptions that have arisen.  The exception handling path for this type is shown as a thick line in Figure 4.
3.	Exceptions with which the task must be terminated and there is no need for any further actions. There are cases where the task immediately terminated and no further actions are possible. Exceptions from this type are handled within the CTRP protocol through the ABORT component. The exception handling path for this type is shown as a dotted line in Figure 4. 

7	FORMALISATION WITH CATEGORICAL PULLBACKS

The relationship between the protocols CTCP and CTRP can be represented rigorously by the categorical pullback shown in Figure 5. Pullbacks are examples of cartesian closed categories [Mac Lane, 1998].

									C
									
			c				c x a				c	

C XB A														C/B		

					c x a							a

									A

Figure 5: Categorical Pullback of System (A) over Environment (C) in the context of Purpose/View (C/B)

This figure shows the relationship between four categories (denoted in bold font). C is the complete environment, A is a particular system to which a user may require access, C/B is a slice category or subcategory of C and C XB A is a limit, representing the relationship between C and A in the context of B. The limit can be viewed as a subcategory of the product C X A over B. Three functors map between C XB A and C/B.  is the existential quantifier selecting some C/B for a particular C XB A,  is the universal quantifier selecting C/B that satisfy all the rules determined by  as the diagonal functor selecting a limit C XB A for a particular subcategory C/B.  is right adjoint to  and left adjoint to , written  -|  -| .  Two natural transformations are shown. c is the unit of adjunction comparing objects C with objects C XB A and cxa is the counit of adjunction comparing objects C XB A with objects A. c is an inverse projection (*) and c x a is a projection (). 
In terms of our CTCP/CTRP model given above:
The diagonal functor  corresponds to the protocol CTCP whereby a limit C XB A is selected for a particular purpose C/B through negotiation. CTCP selects a relationship between C and A for a particular purpose such that the diagram in Figure 5 commutes, that is c o c x a = a o c x a. As a Petri-Net CTCP can be represented as a monoidal category [Asperti, Ferrari & Gorrieri, 1990]. CTCP is therefore a category-valued functor. C XB A corresponds to the policy rules derived through the negotiation in CTCP. 
The existential functor  is a type constraint: there must exist for all policy rules in C XB A an entry in the system C/B. 
The universal quantifier functor  corresponds to the protocol CTRP: all the rules held in the negotiated policy (the limit C XB A) are applied for a particular purpose (C/B). Like CTCP, CTRP is a category-valued functor with its Petri-Net defined as a monoidal category. 
Overall CTCP is right-adjoint to  and left-adjoint to CTRP. CTRP is right-adjoint to CTCP. 
Exceptions are much less likely to occur in the strongly typed categorical model than in a set model. If they did occur they would be handled at the natural transformation level. The unit of adjunction c is given as 1c  CTRP o CTCP(c) and the counit of adjunction as CTCP o CTRP(c x a)  1c x a . The former measures the change in c as the functors CTCP and CTRP are applied in turn. The latter measures the change in (c x a) as the functors CTRP and CTCP are applied in turn. The unit and counit both give a measure of consistency as the application is run with the possibility of exceptions being raised if divergence is noted. 

8	DISCUSSION
We consider two aspects of our work. Firstly the extent to which task-based approaches have been used before in security systems; secondly the prospects for formal approaches in the security area.
The idea of task-based has been introduced before in a number of models [Fischer-Hübner & Ott, 1998; Steinke, 1997; Thomas & Sandhu, 1994].  All were at the basic level of this approach. The focus by the last two (Steinke; Thomas & Sandhu) was on whether a task-based security model could be an alternative authorisation and access control model to the subject-object traditional authorisation models. The first paper (Fischer-Hübner & Ott) tried to address the privacy problem using the task-based approach.  We have intended in our model to use all of the power of this idea (task-based approach) to address the security problem of the collaboration networks and the multi-agency services environment. In more detail:
1.	Steinke [1997] outlines the general features and characteristics of the task-based approaches such as:
·	The need-to-know is related to the operation, which needs to be performed.
·	Any information needs can be related to a task.
·	Tasks are common entities that exist and relate directly to both users and to information.
·	Tasks limit the access to the information from the start to the termination of the tasks.
·	Tasks already exist, and are identifiable, flexible and dynamic.
The Group Security model (GSM) by Steinke was described as a security model, which provides access to information on the base of a user's task.
However some features of GSM are already rather obvious in existing information systems infrastructure. For instance in any relational database, it is always possible to grant users/roles to functions, procedures, and packages rather than grant them to the information objects (e.g. tables, views). These functions, procedures and packages are in fact tasks and group of tasks and also can be functionally minimized. GSM considers the discretionary security approach to deal with ownership. Overall GSM is more suitable for hierarchical systems, where the responsibilities are visible. 
2.	Thomas & Sandhu [1994] introduced the task-based approach initially as an approach to address integrity issues in computerized information systems from an enterprise perspective. Subsequently Thomas & Sandhu [1997] developed their approach to produce a paradigm for access control and authorisation management. The developed model is called Task-based authorisation control (TBAC).  
3.	Fischer-Hübner & Ott [1998] in their model attempted to address the privacy aspect using the task-based approach. The nature of the task-based approach eases the handling of the main privacy requirements such as:
·	Purpose binding: personal data obtained for one purpose should not be used for another purpose without informed consent.
·	Necessity of data collection and processing: the collection and processing of personal data shall only be allowed, if it is necessary for tasks falling within the responsibility of the data processing agency. 
In contrast to the models of Steinke and of Thomas & Sandhu, this model takes a forward step to de-centralise the authorisation using a 4-eyes principle. However there were no end-user requirements supporting this model and the 4-eyes principle is not enough to ensure de-centralisation. The set theory which was used to represent this model is not proven, nor is it in a framework (Petri-Nets, Category theory, LaSCO, Ponder, VDM, Z, ...) where proof is done by following constructive principles or through a guaranteed mechanism. Finally the Fischer-Hübner & Ott model does not include collaboration ventures. 
4.	Mahling, Coury & Croft [1990] tried to build a task-based collaboration model. However this work starts from a relatively late stage in the negotiation where the plan, agreement and tasks are relatively clear. In addition their work does not consider the case of the multi-agency environments where the policies of the collaborators are different. 
We argue that the real challenge for the task-based approach is the multi-agency services environment, where responsibilities are distributed and the ownership is dynamic.  None of the existing approaches have considered the multi-agency aspects in detail.  
Formalising security models is an important matter as this a way in which guarantees can be secured about the reliability of a model. Security rules for multi-agency systems need to be formulated at the policy level. At this level, category theory seems to be appropriate as it provides not only appropriate abstractions for this level but also, in a multi-level architecture, mappings to lower levels such as mechanisms. For interoperability a multi-level approach constructed in category theory has already proved very promising [Rossiter, Nelson & Heather, 2003]. The use of Petri-Nets, for detailed state transitions, within a categorical framework, for control of types and levels, looks to be a way forward for formalising security in information systems. More advanced techniques such as Timed Petri-Nets and Stochastic Petri-Nets should be useful in gaining greater expressibility. Validation techniques in Petri-Nets could also be used for verifying the model.  The benefits of using Petri-Nets will be highest where collaboration occurs between multiple agencies. This is a natural area for applying Petri Nets with its concurrency, asynchronicity, distribution, parallelism and non-determinism. 
9	CONCLUSIONS
This paper has introduced a task-based model to facilitate collaboration in trusted multi-agency networks. Our model is based on the fundamental aspect of the collaboration environment, which is the task-based perspective. Two task-based collaboration protocols (CTCP and CTRP), expressed in this paper in the form of Petri-Nets, are used to represent the permitted states and transitions. The extent to which task-based approaches have been used before in security systems has also been discussed.
The two protocols and the relationship between them are defined in Petri-Nets. The overall model is formally defined using a categorical pullback construction. Each of the protocols, represented as Petri-Nets for state-transition purposes, is a category-valued functor in the pullback.  The use of Petri-Nets within a categorical framework looks to be a promising way forward for security problems. 
REFERENCES
Aljareh, S., & Rossiter N., 2001, Toward security in multi-agency clinical information services, Proceedings Workshop on Dependability in Healthcare Informatics, Edinburgh, 22nd-23rd March 2001, 33-41. 
Aljareh, S., & Rossiter, N., 2002, A Task-based Security Model to facilitate Collaboration in Trusted Multi-agency Networks, ACM Symposium on Applied Computing (SAC) 2002, Madrid, 744-749.
Anderson, R., 1996, A Security Policy Model for clinical Information Systems, Proc. IEEE Symposium on Research in Security and Privacy, 30–43. 
Asperti, A., Ferrari, G. L., & Gorrieri, R., 1990, Implicative formulae in the `Proofs as Computations' analogy, Proc 17th ACM SIGPLAN-SIGACT Symp Principles Programming Languages, 59-71. 
Chu-Carroll, J., and Carberry, S., 2000, Conflict Resolution in Collaborative Planning Dialogues, International Journal of Human-Computer Studies, 53(6) 969-1015.
Crazzolara, F., & G. Winskel, G., 2001, Petri-Nets in cryptographic protocols, Proc. 6th International Workshop on Formal methods for Parallel Programming: Theory and Practice, San Francisco
Fischer-Hübner, S., & Ott, A., 1998, From a Formal Privacy Model to its Implementation, Proc. 21st National Information Systems Security Conference, Arlington, VA. 
Furuta, R, & Stotts, P D, 1994, Interpreted collaboration protocols and their use in groupware prototyping, Proceedings of the 1994 ACM conference on Computer supported cooperative work, Chapel Hill, North Carolina, United States, 121 – 131.
Gollmann, D., 1999, Computer Security. ISBN: 0 471 97844 2, John Wiley and Sons.  
Jensen, K., 1996, Colored Petri-Nets - Basic concepts, analysis methods and practical use, Springer, second edition 1.
Joshi, J., & Ghafoor, A., 2000, A Petri-Net Based Multilevel Security Specification Model for Multimedia Documents, ICME2000, IEEE International Conference on Multimedia and Expo, MP10.12 533, Purdue University, USA. 
Mac Lane, S, 1998, Categories for the Working Mathematician, 2nd ed, Springer-Verlag, New York.
 Mahling, D.E., Coury, B. G., & Croft, W. B., 1990, User Models in Cooperative Task-oriented environment. Proc. 23rd Annual Hawaii IEEE International Conference on System Science, 94-99.
Rasmussen, J. L., & Singh, M., 1996, Designing a Security System by Means of Coloured Petri-Nets. Proc. 17th International Conference in Application and Theory of Petri-Nets (ICATPN'96), Osaka, Japan, Lecture Notes in Computer Science, 1091 400-419. 
Reisig, W., 1985, Petri-Nets: an Introduction. Berlin; New York: Springer-Verlag. 
Reisig, W., & Rozenberg G., 1998, Lectures on Petri-Nets: Advances in Petri-Nets. Lecture Notes in Computer Science, no. 1491.
Rossiter, N., Nelson, D. A., & Heather, M. A., 2003, Formalizing Types with Ultimate Closure for Middleware Tools in Information Systems Engineering, 5th International Conference on Enterprise Information Systems (ICEIS), Angers, France 366-373. 
Ryan, P, 2003, Theoretical Challenges Raised by Information Security, Workshop on Issues in Security and Petri-Nets (WISP), ICATPN.  
Steinke, G., 1997, A Task-based Approach to Implementing Computer Security, Journal of Computer Information Systems, 47-54.
Thomas, R. K., & Sandhu, R. S., 1994, Conceptual Foundation for a Model of Task-Based Authorization, Proc. 7th IEEE Computer Security Foundations Workshop, Franconia, NH, 66-79.
Thomas, R. K., & Sandhu, R. S., 1997, Task-based Authorization Controls (TBAC): A Family of Models for Active and Enterprise-oriented Authorization Management. Proc. IFIP WG11.3 Workshop on Database Security, Lake Tahoe, California pp. 
Van der Aalst, W. M. P., & Basten, D., 2001, Identifying Commonalities and differences in Object Life Cycles using Behavioral Inheritance, Application and Theory of Petri-Nets 2001, 22nd International Conference ICATPN, Newcastle, 32-52.