EUNIS97, Grenoble (France) 9-11 September 1997

Ref: 022813

Ping: an electronic interface for the Swedish universities

Peter Lundberg, Staffan Gustafsson

In this document we describe the "Ping"-system, a public interface to the Swedish University admittance system using WWW-technology and smart cards, enabling us to perform various services both to our regular users, current students and applicants. Examples of current services are an ability to check ones results, changing addresses in the system and ordering certificates of merits. The system is being developed in three stages, currently the first stage is under installation. This, of course, is a very brief description.

Originally the name Ping was derived from the UNIX-command "ping" which is used to check if a host on a network is available for communication or not.

The purpose of the Ping-project:
Starting out from an initial, experimental system, at the Royal Institute of technology (KTH), the LADOK-group is currently developing a general-purpose transaction handler. The transaction handler will be able to "pass along" transactions to its peers at other LADOK-installations. With this ability we will be able to implicitly "join" together all the databases at the different universities in Sweden, thereby simplifying local admission, improving the support for administrators and students, and providing information for applicants.

Short description of LADOK:

LADOK is a computer based student admission and documentation system for a university or university college. It focuses on administration of undergraduate and graduate students. The system is locally deployed and managed by the institutions

The LADOK system has a mutual core, identical for all LADOK system installations in Sweden. The core consists of a structure of database tables, computer programs and terminal screen routines. Every institution decides what parts of the core to be used at the institution and it is also possible to use locally developed addendum's. The LADOK-system can therefore be viewed upon as a large "smorgasbord" where the institution can choose which parts to use.

The LADOK-system consists of two major parts, the admission system and the documentation system. They are integrated and share data, e.g. name, address and other facts about applicants and students. A third part, handling documentation of graduate students, is newly added to the LADOK system core. Undergraduate studies are handled within two major concepts, courses and study programs. The first has its focus on students and single courses and the second of students following a specified study program, normally 3- 4 years study.

The system files contain information for student identification, general eligibility for university studies, admission to courses and study programs, registration on courses per semester, course data, credit points from courses, awarded degrees and international studies.

The LADOK system mainly focuses on student admission and documentation, planning and follow-up. The system is designed to be used by all Swedish state financed institutions of higher education and has its focus on the departmental level. Users of the LADOK system at an institution can be found at all levels:

Data from LADOK are exported to the ministry of education and other agencies for follow-up purposes. An important objective of LADOK is to prepare the annual invoice to the government for studies on the undergraduate level at an institution.

The LADOK system is owned by a consortium of 49 institutions in higher education in Sweden. Software maintenance for the LADOK system core is conducted by a maintenance group at the University of Umeå. Local system usage is the responsibility of the institution, who pays for servers, networking, terminal equipment and local support.

The system is currently facing a major revision that aims for easier user interface and new functionality including a strong focus on security issues. Today, the system is used by approx. 2.000 simultaneously on-line users but it has to be prepared for a large growth in number of users inside institutions and, of course, there are more than 300.000 students waiting for better service with WWW, touch-tone telephone systems and explicit student applications.

The IDOL-project:

The IDOL-project (Swedish for ID-Oriented solutions) is an ongoing project where several Swedish organizations gathered around a common specification of a smart card which is to be used as a means of identification in Sweden. Some of these are:
- The national telephone company (Telia)
- The national mail company (Posten) who issues the smart cards.
- The national railway company (SJ)

The card consists of both a chip and a picture, which means that it can be used as both an electronic and a visual means of identification.

On behalf of The Royal institute of technology in Stockholm the LADOK-group was asked to design and construct one part of an application enabling student access for approximately 6000 students.

The application consisted of three parts;
One part handling the direct interface to the student and his/her smart card (Telia's responsibility
One part handling the catalogue services for the identification process (Posten's responsibility)
One part handling the transactions between the student and the database (our responsibility)

The services currently provided to the students are;
1: checking registrations to courses
2: checking results
3: checking and changing ones addresses
4: ordering certificates.

The system has been in action for nearly seven months and has been the source of much knowledge. During this period we have had approximately 45000 database accesses. The "slow" periods during weekends and Christmas makes an average of 300 accesses per weekday.

In summary:
The most popular service is the possibility to check registrations, and we feel that we have evidence to say that the students have a strong interest to check their status in the system and use the services provided. It is still to early to say in which extent they will use the system to obtain certificates since the system has not been working across the summer.

The project provided us with a possibility to build a transaction-handler that operates with a secure protocol. The security in the system is high enough for us to let the students make changes on their own data. We therefore feel that we can use the model to evolve the system into a more general mechanism where students can take part in a large administrative system both for retrieving their own data and feeding the system with changes and (for example) applications.

Advantages of an electronic interface:
The advantages of an electronic interface to the admittance-system are not as obvious as they might seem.
Possible advantages might be expressed in the following terms;

Savings: The possible economical savings that the system can result in are at present marginal at best. The organization must keep the same kind of record of their students no matter if the system exists or not, and must be ready to provide the same kind of service. If we were able to develop the system to handle more student input the savings would probably be large, mostly because the time from application to acceptance / rejection could be shortened and the cost of personnel could be reduced.

Public-relations / service: As the system works today the only service that is completely new to the organization is the possibility to change addresses, I think that we can see an increased openness in the admittance- system as beneficial in terms of public-relations but measuring the benefit in good service against a possible cost in bad student service is difficult at best. One service that we think would be greatly appreciated is a possibility for applicants to feed the systems with high-school grades to find out weather the are qualified for taking a certain course/courses or not.

Record-keeping: From the technician's point of view, using the system should result in a more correct database since students will be able to check and in some extent change the data describing them.

Problems with an electronic interface:
Technically we have had few problems in designing and constructing the application. There are, however some indisputable problems concerning the installing of a system like the one in KTH in a larger scale. This has to do with the general infrastructure situation.

The cost per student in a system like this is at present very much to high to make it realistic to escalate the system to extend the entire nation. At present the cost per student is approximately $150.

My estimation is that it will take three to five years before we have an infrastructure within the Swedish Universities that is so developed that we can use it to develop services that will force the students to use smart cards. Of course "Stand alone" solutions will be developed just like in KTH bot not in a national perspective. However, until then we still have to provide service to the students and must find secure ways to authenticate users across the Internet.

Principal changes evolving from IDOL to PING:

Working within IDOL we learned that the system can handle input to the database in a secure way and that this is where the real benefits of an electronic interface are. A request that arose during the development was that the system should be able to forward questions to its peers. Therefore we have these main issues that will be addressed in the Ping-system.

The system shall;
* Be able to use several ways to authenticate users.
* Provide the same services as the system being used at KTH.
* Develop services focused on student input.
* Provide services to high-school students by testing their grades.
* Provide a seamless interface between different universities by being able to retrieve information from several LADOK-installations.

The last item on the list is by far the most important. An example on this is the typical scenario of a student administrator asking LADOK for the results of a student. With the help of the Ping-system the same kind of question could be put to all LADOK-installations thereby providing the administrator with a complete picture of a students situation. In Sweden it is not uncommon for students to change university within their education and so we expect this function to be of great value.

Some strategic design-decisions

The first and most important design decision we had to make was that if information is to be retrieved from various locations later to be used in decisions we have to be able to save the data locally together with an electronic seal describing where they came from and when they were retrieved. This is done by creating duplicate tables for certain data expanded with the information described above. The idea is that if we have a table "courses" which describes the local results of a student we also have a table "Xcourses" which describes Xternal results at a certain point in time. At present this concerns six tables in LADOK, and yes, the association to the X-files are obvious.

The second important design d is that we must take responsibility for all the three parts of the application except from the basic catalogue-services, which we hope, will be provided by several companies in Sweden. This is necessary since we want to be able to use several schemas to authenticate users.

This decision has meant that we must develop our own ID-server, as well as our own client-application. The ID-server is currently (may 31) in a stage of rapid development. The target platform is Windows NT.

For the client-application the obvious user interface today is WWW / JAVA. This is not because JAVA is the "hip" language of today, but because it gives us three certain obvious advantages.
1: The awesome problem of distributing software to 300 000 students is almost eliminated if we can use a JAVA applet.
2: Handling the problem of different versions is also more or less solved since there will not be any old software installed anywhere.
3: There are some problems with JAVA running in different browsers on different platforms. Using JAVA does not solve the problems, but they are minimized.
4: Internet gives us the widest possible exposure of the system, providing us with the possibility to use the system towards high-school graduates.

Technical premises:

It is beyond the scope of this document to give a precise technical specification of the system, some basic issues however are these:
* The system is prepared to authenticate users through smart cards, a tacacs functionality (userid / password) and internal LADOK-id's / passwords.
* Information will be passed between client and server using DES- encryption.
* A University authenticating itself to another installation will use a public/secret key pair.
* A student authenticating itself to an installation will receive a RSA-generated key to pass an encrypted session key between client and server.
* The client will not contain any secrets, if anyone would go through the problems of writing an own client so be it, the protocol will be public.
* The time for a single transaction is approximately 0.5 seconds and we aim to be able to scan all installations within 30 seconds.
* The local ID-server will have functionality to exclude specific transactions, for example those that means that changes will be done to the database.

The development process:

The system will be developed / launched in three stages:
Stage 1:
The first stage will contain basic functionality to facilitate the admission of students. We intend to focus on the possibility to exchange high-school grades, and previous university merits. This will be performed as batch operations with a very low level of interaction. This service is more a step in preparing the applications before the final admission can be performed.

This stage is currently under final testing

Stage 2: The second stage will focus upon improving the support to the student administrators. We intend to provide the student administrators with functionality to check and confirm merits between different universities thereby giving a more complete picture of a student's current status.

This stage will go into a testing phase at the end of the summer.

Stage 3: The third stage will focus upon student services, the services that will be provided will first of all be the same that are being used at KTH and later extend to more Input-oriented functions.

In which extent student services can be of the same "inter-university" kind as those of the administrator's remains to be seen, this has to do with how the security problems are solved.

This basic student functionality will be tested at the University of Umeå during the autumn of -97.

During the autumn we will also develop a public service which will provide high-school students the possibility of testing their grades for general and specific qualification. We also aim to provide a service that will answer the question, "would these grade have qualified me for a specific course last year?" These two services are perhaps the most exciting of all, still we are only at the beginning of what we can achieve with a general-purpose transaction handler like Ping.


LADOK-gruppen,
University of Umeå
901 87 Umeå, Sweden
E-mail:
peter.lundberg@ladok.umu.se
staffan.gustavsson@ladok.umu.se

Copyright EUNIS 1997 Y.E.