An Architecture for Supporting Vicarious Learning in a Distributed Environment Julian Newman Xiaofeng Gong
Steve Neely Helen Lowe
David Eyers Jean Bacon
Department of Computer and Information Sciences University of Strathclyde Glasgow G1 1XH UK
University of Cambridge Computer Laboratory Cambridge CB2 3QG UK
[email protected] [email protected]
[email protected] [email protected]
School of Computing and Mathematical Sciences Glasgow Caledonian University UK
[email protected] [email protected]
ABSTRACT
1.
Existing software systems designed to support learning do not adequately provide for vicarious learning in a crossinstitutional collaborative environment. We have developed an architecture based on role-based access control, which provides the necessary security, robustness, flexibility, and explicit formulation of policy. Such an architecture is general enough to be used in a variety of educational institutions and settings, yet flexible enough to allow a wide range of policies within a single system.
Software systems that support teaching and learning in a multi-university consortium often fall short because they are not integrated and provide little access control or privacy of data, are not designed specifically to meet the needs of users in an educational environment, and do not adequately support different types of learning and reuse of materials. [20] concluded that these problems are very closely interlinked — for example the available security models inhibit the management of learning and learning materials because insufficient support is given to the kinds of activities of different roles in different phases of the academic process. The RAED project is based on the belief that higher education involves inducting the student into a community of learners in which learning results not only from studentstudent and student-tutor interaction, but also via vicarious learning from observed interactions amongst other community members. RAED uses a model known as Atoms and Trails, developed in a predecessor project, MANTCHI [20]. Our aim in RAED is to provide an improved management environment for the Atoms and Trails model, particularly attending to related security issues.
Acknowledgements This work is supported in part by Grant GR/R52237/01 under the Distributed Information Management programme of the EPSRC. We are grateful to our colleagues in Cambridge and Glasgow for helpful discussions and to the members of the MANTCHI project for sharing their teaching material. We would particularly like to thank David Benyon, Phil Gray, Alastair Kilgour, John Lowe, Dave Moffat, and Ken Moody.
Categories and Subject Descriptors C.2.4 [Computer-Communication Networks]: Distributed Systems—distributed applications; D.4.7 [Operating Systems]: Organization and Design—distributed systems
General Terms Security, design, management
Keywords OASIS, role-based access control, policy
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC ’04, March 14-17, 2004, Nicosia, Cyprus Copyright 2004 ACM 1-58113-812-1/03/04 ...$5.00.
INTRODUCTION
2.
BACKGROUND
2.1
Pedagogy
The pedagogy of this project derives from the work of [12] and [15] and relates to the concept of constructive learning. The teacher plays a supportive role; the student learns principally through the performance of tasks: usually problems to solve, or “constructions” where the student produces an output — a design, a paper, a report, a program, or a presentation. The tutor gives the student feedback, ranging from informal comments or constructive criticism through to a formal assessment. The whole process is a structured dialogue. [15] has described a three stage-model of this process, distinguishing three types of courseware that support the phases: • Primary Courseware is intended mainly to present new subject matter. • Secondary Courseware describes the environment and
Secondary courseware (exercise)
Secondary courseware (exercise) Walkman specific material
Radio alarm specific material
Hy pe rl i
nk
(t r
ail
)
Invariants
Tertiary courseware
Walkman solutions
Feedback & discussion
Work in progress
tutorial discussion about solutions and feedback. The subject expert captures these discussions and packages selected solutions and discussion segments (including anonymizing where appropriate) as an additional resource for vicarious learning – the trail. A new variant of the atom is then developed for the next cohort of students, with links to the trail. In the variant, the task details are changed (e.g. from modelling the user interface of a radio alarm to modelling that of a mobile phone). Thus students can benefit from “overhearing” tutorial discussions of previous solutions, while still being challenged by a new problem. The solutions and discussion of the new variant atom can again be packaged as another trail.
2.2 Figure 1: The Atoms and Trails Model (statecharts example)
set of tools by which the learner performs learning tasks, and the tasks (and task materials) themselves. • Tertiary courseware is a new conception of courseware which is gradually gaining recognition ([13]; [17]; [19]; [20]). Its defining characteristic is the “re-use” of the learning activities of other students. Tertiary courseware is constructed from all or any of: – outputs from assessment, – dialogues between learners and tutors, – peer discussions. Its effectiveness depends on the phenomenon of vicarious learning, i.e. learning by overhearing or observation rather than by direct participation ([16]; [18]; [23]). Collaborating tutors in different universities export and import web-based courseware elements (atoms). An atom describes a tutorial problem, with links to other learning resources. In the Atoms-and-Trails model (illustrated in Figure 1), an Atom consists of an invariant part (for example, materials for an exercise on interface modelling using Statecharts) together with parts specific to an instantiation. For example, in Figure 1 we see that there are two instantiations: the initial version relates to a Walkman, and the second version relates to a Radio Alarm. As students work on one version of the atom, they may learn vicariously from past students, by the provision of tertiary learning material from other versions. For example, students engaged in carrying out the radio alarm exercise may see past student solutions to the Walkman exercise, together with tutorial feedback and discussion about these solutions. These tertiary courseware elements are known as the trail. We call the exporting tutor the subject expert of the atom, and we call the importing tutor the local organizer. Note that local organizers and students will commonly be in different administrative domains from the subject expert, and that the whole process will be supported by a federation of interworking services. Students submit problem solutions, receive feedback from the subject expert, and participate in
Role-Based Access Control
[10] compares the merits of different access control models in an inter-university collaborative tutoring context. With owner based discretionary access control it is impossible to enforce consistent organizational policies and determine what access is granted to a user. Such policies will be an important factor where the materials to be protected or accessed are involved in student assessment, as is often the case where course work by groups as well as by individuals forms part of the requirements for passing a course or module. Lattice-based mandatory access control is better than discretionary for enforcing organizational policies, but can only control information flow between levels, so it lacks flexibility. In the case of collaborative cross-university tutoring such as the MANTCHI experiment, or where a university is collaborating with a company to deliver workplace or work-based learning, there is simply no single organizational hierarchy within which permissible flow of information can be defined. Role-Based Access Control (RBAC), described below, promises to provide the necessary combination of flexibility and rigour. Large-scale organizations have an increasingly strong need for secure inter-operation across organizational networks and internet-based services. Facilitating this requires flexible and adaptable authentication and authorization approaches. Role-based Access Control has emerged as a promising technology to meet this need. It reduces administrative complexity by adding the concept of a role as an abstraction between the security principals (i.e. users) and the privileges associated with them. This allows the particular principals performing in some organizational or task-based role to change without the need to modify access rights other than to update the user-role assignment mapping. An area of rapidly emerging research is in how to federate independent, secure services both in terms of the sharing of credentials and the access control policy over them. The NIST reference models [21], pioneered by [22], specifies four fundamental RBAC models. The first model defines the basic user-role and role-privilege mappings. Later models are extended to introduce role-hierarchies and predicateguarded (i.e. non-automatic) role transitions. Some RBAC systems treat roles as long-lived attributes associated with particular principals. In other RBAC architectures, a user’s right to perform in a given role may change depending on their environment, and they thus treat role membership as transient, usually within some sort of user session. See [2] for a comparison of such persistent and dynamic role membership schemes. Many research groups are investigating RBAC, some from
the perspective of theoretical modelling ([1]; [7]), and others with respect to the practical deployment ([5]; [6]; [8]; [9]; [14]) of RBAC into security systems. A combination of both approaches is necessary to derive role structures to suit the behaviour of existing organizations. The Open Architecture for Secure Interworking Services (OASIS: see [3]; [4]; [11]) has developed into a distributed RBAC implementation supporting parameterized policy elements, rule-based policy definition and session-based, distributed operation. Parameterized RBAC systems augment a given role credential with attributes. In the case of OASIS, its role activation and privilege authorization rules are also parameterized, and can perform environmental interaction for the sake of operations such as database lookup, or temporal checks. Mathematically these policy rules are specified in a simplified horn-clause logic; they are currently implemented in XML format. Whereas many RBAC models include a notion of privilege delegation, the OASIS architecture employs the more expressive and secure notion of appointment. Through a tree hierarchy of roles, RBAC delegation often results in principals near the top of the tree having large numbers of unnecessary privileges, violating the principle of least privilege. OASIS appointment models the intuition that principals are often in the position of indirectly authorizing other principals to do tasks they themselves do not have the privileges to perform. The current implementation of OASIS uses Enterprise JavaBeans to maintain role state within sessions over a secure OASIS network. Users authenticate with OASISaware portals using appointments, in this case X.509 certificates containing OASIS extension fields. Distributed OASIS services can communicate with each other using SOAP over HTTPS connections — within such a network it can offer fast revocation of credentials. One aim was to test the appropriateness of RBAC for elearning, particularly when distributed sites are cooperating. Our experience to date confirms that separating system and application administration simplifies the overall task and minimises the risk of errors, particularly when distributed sites are cooperating. System administration includes registering individuals and recording in a database, or certifying, their employment or group memberships. Application administration includes the expression and enforcement of role activation and authorisation policies, including service-level agreements between distributed institutions. For example, if GCU students are accessing material at Strathclyde, it is sufficient for the Strathclyde system to accept a GCU certified student certificate as a credential for activating a student-on-course role. One institution need never be involved with details of the individuals involved at the other. The fact that OASIS defines service-specific roles which are activated within sessions, as opposed to generic, persistent roles which are used for a wide variety of purposes, allows access control to be defined precisely, according to the principle of least privilege.
3. 3.1
ARCHITECTURE The RAED System
We now describe a web-based architecture for the system we have implemented, known as RAED (Role-Based Access Control for the Evolution of Distributed Courseware, referring to secondary tertiary courseware which grows or
evolves over time). In §3.2 we explain the layout for standard database driven web sites and how OASIS may be incorporated into such sites. In §3.3 and §3.4 we describe the RAED architecture itself. The RAED system provides a role-based access secured infrastructure for globally distributed electronic courseware. Specifically the RBAC middleware employed is an implementation of the OASIS architecture. The client-side presentation of the RAED system is manifested as a set of pages on the web. The pages are dynamically generated, based on a set of rules for each role coupled with results from database queries. For example, students logged in to the system will be presented with pages tailored according to which course they are enrolled in, and any related material to which they are allowed access as specified by a local tutor. RAED course material is logically separated into units termed atoms as explained in §2.1. Each atom is individually authored by an atom expert. These atoms include secondary courseware such as exercises, plus a form of tertiary courseware called trails. A trail is a conceptual path from a task specification to solutions followed by previous students. The visibility of trails is specified by the local tutor for each group of students in the system. A pleasing feature of this system is its transparency to the user: the complexities induced by combining material from several distributed sources are completely masked so that students see a single unified web site, although often even a single page combines information from distributed sources across two or more domains.
3.2
Standard database driven web sites
A database driven web site is a dynamically generated web site built by a server to handle requests from browsers. The HTML code is compiled by a server-side set of programs. Example server-side technologies for doing this are PHP, JSP, ASP, or servlet code using some database access technology such as JDBC onto MySQL or Postgres databases. Figure 2 shows an architecture for a database driven web site. When a web browser sends an HTTP request to the server for a page of a database driven web site the server queries the database and generates HTML presentation code based on the results of the queries. This has the advantages that new content may be added to the web site without changing the presentation code; it is simply added to the database. Further advantages include the benefits of handling data with a database (advanced content management), separation of presentation and data, and protection of data through the database schema.
3.3
OASIS protected web sites
Standard database driven web sites do not include a fine grained data access model. Complementary technologies for protecting data need to be employed if users are to be given different levels of authority. OASIS is a middleware security technology that allows the definition of roles in the system that users may enter in order to view different parts of the data. Figure 3 shows the architecture of an OASIS privilege checked web site. An OASIS protected web site includes an additional layer of access control over the data. This layer is executed along-
Web server HTTP/ HTML
HTTP/ HTML
Internet HTTP
HTTP
SQL / DATA
data
base
Figure 2: Architecture for a database driven web site
Web Server HTTPS/ HTML
HTTPS/ HTML
Internet HTTP
HTTP
yes/no
grant request?
CBCL OASIS Server SQL / Application data SQL / OASIS data
data
base
Figure 3: OASIS checking client privileges for a web site side the web server and the data in use. In Figure 3 the OASIS server is dealing with requests from the web server; OASIS automatically checks whether the connected client has sufficient privileges for accessing database data according to the policy specified (see §3.4 and §3.6). The client is authenticated at the browser using an X.509 certificate. This is client-side authentication, which happens once a session, as a bootstrap into the system.
3.4
RAED Architecture
The RAED system architecture defines a mechanism for globally distributing electronic courseware using OASIS and database governed information. Figure 4 shows the RAED architecture with two domains, one at the University of Strathclyde and one at Glasgow Caledonian University. Both the University of Strathclyde and Glasgow Caledonian University (GCU) domains are running individual instances of web servers, OASIS servers and databases. In our current implementation the courseware is delivered via web pages generated from from JavaServer Pages (JSP), populated from a PostgreSQL database through the J2EE application server’s JDBC connection pool. A client wishing to access the Strathclyde system must present a valid X.509 certificate. Our current certificate issuing service ensures all X.509 certificates are password-protected. A secure session is then set up between the client and the server (using TLS-based HTTPS). This sets up a secure session over HTTP between the client and server. When a client tries to access a secured resource the web
server passes the request onto the OASIS server, which checks the local database to see whether the client has the appropriate privileges. This is indicated by the arrows between the sides of the OASIS servers and the databases. The OASIS server checks an XML policy file and performs environmental lookups. An XML policy file defines the OASIS rules governing which operations an entity in a given role may execute. Environmental lookups are checks in the system for external factors affecting a policy; for example the system may access a database to check whether a student is enrolled in a given course. If the client request is authorized the OASIS server informs a server-side script in the web server which will dynamically generate the appropriate web pages for the client. When a client connected to Glasgow Caledonian University wishes to access data governed by the University of Strathclyde domain the request propagates from the Glasgow Caledonian University OASIS server to the University of Strathclyde OASIS server. For this to occur a shared policy must be agreed between the two institutions. The Strathclyde OASIS server will check the policy file plus any environmental constraints and decide whether to allow the access to the local data.
3.5
Atoms in the RAED system
Two example atoms in the RAED system are web design and state charts. Atoms may be used in a variety of different courses and are shared across institutions. Atoms are authored by atom experts and published in the local domain. The expert registers the atom details in the
GCU domain
Strathclyde domain OASIS server
data
OASIS server
SOAP comms
base
data
Web server
DB comms of app data
base
Web server
HTTP
HTTPS/ HTML
HTTP
HTTPS/ HTML
HTTP
HTTPS/ HTML
Figure 4: RAED system architecture local database and advertises it through some other mechanism (email, word of mouth, or via a virtual learning environment (VLE) such as Blackboard or Spider1 ). Experts may edit any of the web pages of the atom or update the database if its location changes. The web interface allows the experts to update locations and add new exercises or trails. All this information is stored in the local database and used when tutors access their RAED web pages. Local tutors indicate which course material the students may access. The web interface allows them to set exercises with due dates and visibility of trails. This information is stored in the local database and used by OASIS as an environmental lookup when students access their RAED pages.
3.6
Roles and policies in the RAED system
We have started with two atoms, statecharts and webdesign; and two domains, univStrath and univGCU. We hope to add more atoms during our initial live evaluation this coming semester, and possibly more domains. For each atom, we identify the following roles: • subject-expert • local-organizer • tutor • student The participants’ view (for any role) is that of a graph of web pages, each node being a web page, and each arc a directed link. 1 Spider is a VLE which has been developed at the University of Strathclyde
For the purposes of defining roles and privileges in RAED, we need to split atoms into five sections: 1. atom-core. The background material (prerequisites, links to supporting material, reading list — whatever the subject-expert chooses; 2. atom-ex(n). The exercise, set by the subject-expert — in general there is a choice of exercises and it is this which leads to there being different instances (or versions) n of an atom. Usually it will be local-organizers who choose which instance their students will do. 3. trail(atom-ex(n)). The trail; this will consist of all tertiary material except that belonging to the current exercise. 4. atom-local(d). The local arrangements for submitting the atom, written by each local-organizer at domain d for their own students. 5. atom-notes(n). Teaching notes for the atom (or a particular instance of it), which could include a variety of materials such as tutor guidance notes and model answers. All roles except that of student have read access to this: it is a matter of local policy as to what access students have (none; access subject to constraints such as the submission deadline having passed, etc.) An extract from an example policy file is shown in Figure 5. The XML representation is equivalent to the formal representation discussed in [4]. Policies may also be described graphically as in Figure 6.
Figure 6: Graphical representation of part of a RAED policy
4. DISCUSSION
exercise after the submission date for the exercise”,
We are planning to evaluate our system in use by students and tutors in October, 2003. We are already evaluating it as regards its suitability from the point of view of staff members in their roles as subject experts, tutors, and local organizers. So far we have identified a number of attractive features:
where the exercises chosen and corresponding submission dates are accessed from a database. This gives a clean separation of data from policy and automates much of the tedious (and potentially error-prone) process which users of VLEs must go through.
• The transparency of the system. Users can access the different components of the various atoms, wherever they are physically located, and read them as if they were a single web site. Links to material to which users are not allowed access to simply do not appear in their browsers.
• Dynamic qualities: the privileges of a role commonly change over time and in response to events, for example a student’s access rights to material before or after a certain date, or according to whether they have submitted work. These are naturally handled in OASIS by environmental predicates. OASIS with its parameterized roles as described in §2.2 can also readily handle exceptions. In this application we may have: students who hand in work late due to special circumstances such as illness; the need sometimes to allow different handing in times for (say) full-time and part-time students; and so forth.
• The flexibility of the system. The logic is sufficiently expressive as to allow a wide variety of policies. The design of the system also means that different local organizers can decide different policies for the same objects — for example, one might allow their students sight of the marking scheme at all times, another might allow it after the submission or other date, while a third might not allow this at all. • The generality, explicitness, and relative simplicity with which policy is expressed. Clearly, most operating systems (for example, UNIX) allow users to set permissions for groups and in general; Blackboard and other VLEs allow users to lock files or set activation dates. However, the policy thereby expressed is implicit, and can only be deduced, possibly imperfectly, by examining all the objects and their access rights. For the practitioner, these access rights must be set by selecting objects and setting permissions individually. Our system uses an explicit representation of policy, whereby a policy is expressed in high level terms as, for example “Students may access the trail to the current
5.
EVALUATION
During the academic year of 2003–2004 we plan the following usage: • One atom, web design, owned by a lecturer at the University of Strathclyde, used by the owner at Strathclyde and also by another lecturer acting as localorganizer at GCU. This atom already has two exercises and a trail for one of these. • A new atom, AI search techniques, owned and used by a lecturer at Glasgow Caledonian University, to be created from an existing exercise and run twice, with two different groups of students, once during semester one with no trail, and again using a second exercise
in semester two with the second cohort allowed access to the trail of the first exercise. This atom can also be used at Strathclyde in the second semester with a third cohort of students.
• The development of a web site for lecturers, to allow creation, publication, and advertising of atoms in the local academic community.
6.
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Figure 5: XML representation of part of a RAED policy
CONCLUSIONS AND FURTHER WORK
We have tested the OASIS system in a novel domain. It proved relatively straightforward to adapt OASIS for the new application and we are happy with the security of the system which is as secure as current e-commerce systems. Role-based access control is well-suited to an environment in which roles rather than identities better describe a person’s access rights. For example, it is entirely possible that a fourth-year student taking the AI search techniques atom could act in a tutoring role on the web design atom. We have already seen that most lecturers will have two roles: that of subject-expert on some atoms, and local organizer on others. We do plan to improve tool support for writing policies, in particular the development of the user interface and some validation procedures. Presently we anticipate no problem in users selecting one of the policies which we have already formulated or in our being able to express any policy which is likely to be requested. However, a possible weakness of the system, without better tool support, is that users wishing to use a completely new policy need to be able to write XML files, or at least be able to customize existing ones.
7.
REFERENCES
[1] G. J. Ahn and R. Sandhu. Role Based Authorization Constraints Specification. ACM Transaction on Information and System Security, 3(4), November 2000. [2] J. Bacon, K. Moody, D. Chadwick, and O. Otenko. Persistent versus Dynamic Role Membership. In IFIP WG 11.3 Working Conference on Database and Applications Security, Estes Park, Colorado, August 2003. [3] J. Bacon, K. Moody, and W. Yao. Access Control and Trust in the Use of Widely Distributed Services. In Proceedings of the 3rd International Conference on Middleware, volume 2218 of Lecture Notes in Computer Science, pages 295–310, Heidelberg, November 2001. Springer. [4] J. Bacon, K. Moody, and W. Yao. A model of OASIS role-based access control and its support for active security. ACM Transactions on Information and System Security, 5(4):492–540, November 2002. [5] J. F. Barkley. Implementing Role Based Access Control using Object Technology. In First ACM Workshop on Role Based Access Control, November 1995. [6] J. F. Barkley, A. V. Cincotta, D. F. Ferraiolo, S. Gavrilla, and R. D. Kuhn. Role Based Access Control for the World Wide Web. In 20th National Information System Security Conference. NIST/NSA, 1997.
[7] E. P. Bertino, P. A. Bonatti, and E. Ferrari. TRABC: A Temporal Role-Based Access Control Model. In 5th ACM Workshop on Role-based Access Control, Berlin, 2000. [8] R. Chandramouli. Application of XML Tools for Enterprise-Wide RBAC Implementation Task. In 5th ACM Workshop on Role-based Access Control, Berlin, 2000. [9] D. Ferraiolo and J. Barkley. Specifying and managing Role-Based Access Control within a Corporate Intranet. In 2nd ACM Workshop on Role-based Access Control, Berlin, 1997. [10] X. Gong and J. Newman. Selecting a Security Architecture for a New Model of Distributed Tutorial Support. In Proceedings of 11th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, pages 89–94, Los Alamitos, CA, June 2002. Computer Society Press. [11] R. Hayton, J. Bacon, and K. Moody. OASIS: Access Control in an Open, Distributed Environment. In Proceedings IEEE Symposium on Security and Privacy, pages 3–14, Oakland CA, May 1998. [12] D. Laurillard. Rethinking University Teaching : A Framework for the Effective Use of Educational Technology. Routledge, 1993. [13] J. Lee, F. Dineen, and J. McKendree. Supporting Student Discussions: It Isn’t Just Talk. Education and Information Technologies, 3:217–229, 1998. [14] V. M., R. Govaerts, and J. Vandewalle. How Role Based Access Control is implemented in SESAME. In IEEE 6th WETICE, 1997. [15] J. Mayes. Learning Technology and Groundhog Day. In W. Strang, V. Simpson, and D. E. Slater, editors, Proceedings of Hypermedia at Work: Practice and Theory in Higher Education. University of Kent at Canterbury, 1995. [16] J. T. Mayes and I. Neilson. Learning from other people’s dialogues: questions about computer-based
[17]
[18]
[19]
[20]
[21]
[22]
[23]
answers. In B. B. Collis and G. Davies, editors, Innovative Adult Learning with Innovative Technologies, volume 1, pages 31–47. Elsevier Science B.V., Amsterdam, 1995. T. Mayes and F. Dineen. Developing Tertiary Courseware through capturing Task Directed Discussions. In Proceedings of ED-MEDIA, Seattle, USA, 1999. J. McKendree, K. Stenning, T. Mayes, J. Lee, and R. Cox. Why observing a dialogue may benefit learning. Journal of Computer Assisted Learning, 14:110–119, 1998. R. Monthienvichienchai and M. A. Sasse. Learning from Others’ Mistakes Through Computer Supported Vicarious Learning. In Proceedings of the 4th LTSN Conference, Galway, Ireland, August 2003. J. Newman, T. Mayes, D. Benyon, S. Draper, P. Gray, A. Kilgour, and L. Mackinnon. Lessons from a Multi-university Remote Tutoring Community — MANTCHI. In Proceedings of the 3rd International Conference on the Role of Universities in the Future Information Society: The Virtual University. Flagstaff, Arizona, 1999. R. Sandhu, D. Ferraiolo, and R. Kuhn. The NIST model for role-based access control: towards a unified standard. In Proceedings of the fifth ACM workshop on Role-based access control, pages 47–63, 2000. R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman. Role Based Access Control Models. IEEE Computer, 29(2):38–47, 1996. K. Stenning, J. McKendree, J. Lee, R. Cox, F. Dineen, and T. Mayes. Vicarious Learning from Educational Dialogue. In C. Hoadley and J. Roschelle, editors, Proceedings of Computer Support for Co-operative Learning: Designing New Media for a New Millenium, pages 341–347, Stanford University, Palo Alto, CA, December 1999.
