Download The TIES final report

TIES PROJECT REPORT
TIES has anticipated there will either be onward flow of an institution’s user data to other groups within the
organisation wishing to use it or that there will be direct access to the centrally maintained database. Whichever
method is used, a secure, authenticated, connection will be required for transfer or collection of data by the RA.
Data required by TIES
The data held on students and staff may, for organizational purposes, be slightly different. The following common
data items were used in TIES:
— Unique identifier: for example staff personnel number or student enrolment number.
— Personal name: provides an additional user-friendly identifier (though not necessarily unique) for the
user.
— Local username: used to access local services.
— Passphrase: used in conjunction with the local username.
— External username: a pseudonymous username intended for external use.
— Valid from: data for new students and staff may appear in the institution’s databases before arrival and
this may need to be reflected in the certificate validity.
— Valid until: the options regarding validity period are discussed in 11.3.2.
All of these items may be generated and stored in the institution’s master databases. Alternatively, they may be
generated and maintained by the RA. In time, it would be expected that all data would migrate to central
databases.
A simple administrative web tool for managing the RA database was developed.
Timeliness of data
The timeliness of the user data may vary between institutions. It is anticipated that an RA will process data at
least daily but may be required to do so more frequently. This frequency will need to match that used to maintain
local services to ensure consistent provision across both local and external services.
Updates and revocation
Once populated, the TIES RA uses a file containing change information to maintain the currency of its database.
These changes will reflect information about new and departing students and staff, or changes affecting the
enrollment of existing members. If there are no existing institution processes that produce this change file, then
the RA may generate one by comparing the latest presented data on staff and students against its own database. In
the event of a user departing before the natural expiry of their certificate, the RA will issue a revocation request to
the CA which will subsequently announce the revocation in the next CRL issued.
Other users
As has been noted, the processes used to support and provide services to staff and students are well developed,
since these are required for the provision of local services. An institution may also wish to offer services to users
who are neither students nor staff, but who may be categorised as visitors, such as visiting academics, honorary
academics and students from other institutions where there are joint teaching arrangements. The organisational
processes required to support visitors are likely to be informal and vary widely between institutions. As a
consequence, this category of user has not been considered in the implementation of the RA developed in the
project, although in some institutions the existing arrangements for visitors may allow them to be accommodated.
The RA disseminates institutional data as shown in figure A.1.
Audit
An audit trail is maintained by the RA. The actions that prompt an entry to be made in the audit file are:
— user registration request
— revocation request
35