eduTap Project Documentation#

Attention

This document is a work in progress. Structure and content may change a lot within the next days / weeks.

Version 0.0.1dev

Project and Requirement Documentation for the “eduTap” Project by the EUGLOH Work Package - Campus Life. Providing a digitized card pilot for European Higher Education Institutions - A Campus Card for Interoperable Services - and a Framework for additional digitized service cards.

Note

This project aims at specifying a new, better version of the European Student Card (ESC) idea, in such a way, that it actually provides an baseline for interoperable services and fulfils the vision of the European Student Card Initiative (ESCI).

The major differences:

  • not student exclusive –> It aims on all persons (roles) at Higher Education Institutions or even all Education Institutions as the difference in ISCED-Level 6-8 to lower level might not make a huge difference. –> Student ID, Employee ID, Affiliate ID, Alum ID, maybe also Pupil ID

  • aim to issue the cards as wallet passes into smartphones

  • not to integrate all services into one card, but provide a core card / pass and additional cards / passes for legacy services

  • it is not limited to Students at European Union Member states –> Focus on Erasmus+ Partner Institutions / Countries, but may extend to all Countries worldwide similar to other edu-Services like: eduRoam, eduGAIN, …

Hint

This Document / Documentation define requirements, therefor the key words “MUST”, “REQUIRED”, “SHALL”, “MUST NOT”, “SHALL NOT”, “SHOULD”, “RECOMMENDED”, “SHOULD NOT”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Background#

The European Commission and the Erasmus+ Program has defined a roadmap for digitalization and interoperable service provisioning within the european education system.

Within this roadmap and vision several projects have been defined and funded to standardize a European Student Card (ESC). This project has been lead by Student Unions of several member states, most notable . The defined “European Student Card” specification neither reflects the needs of the Higher Education Institutions nor does it really provide any interoperability. Additionally, the provided specification documents and implemented elements conflicts with GDPR requirements and have a lot IT-security issues.

Warning

We do NOT recommend any Higher Education Institution to implement the current European Student Card Specification of the European Student Card Project / ESC-Tension Project.

Goals of eduTap project#

The vision of the “European Student Card” is valid and great. This project group honors the vision and tries to provide an alternative specification that would provide an interoperable baseline.

Key Concepts#

Identity Documents based on plastic cards are not a good base for interoperable service provision. Chip cards and smart cards, are limited. They have a limited memory, and storing data / applications on those cards differ by the providers. Also interoperability does not reside within the cards, as almost any technology provider has different internal standards to store and secure data on the card, interoperability is done on the reader side.

Modern smartphones have Wallet functions build into the operating system and could store almost an unlimited number of cards / passes and data. Also smartphones are the essential working tool for students and most university employees.

The approach of “Integrated Chip Cards”, to store multiple service specific applications within one card is not valid anymore. Within Smartphone Wallets the approach of “one card per service” has more benefits.

Service provider on and off campus does have different needs and existing technologies, especially with legacy systems, so issuing one service card per service is a better approach.

Additionally most service providers does not provide their services to students exclusively. Multiple customer / consumer groups exists, that could uses those services. The European Campus Card does reflect this by opening the system to all roles.

A majority of service providers, especially off campus, do offer services and discounts to members of Higher Education Institutions. They often only need a affiliation status verification or prove of entitlement, sometimes scoped to certain institutions. For Higher Education Institutions themselves, their Identity Management Systems is the “point-of-truths”. Key elements of those IDM Systems are standardized with LDAP-Schemata: eduPerson and SCHema for ACademia (SCHAC). Those Schema define a common set of attributes used by almost all HEIs.

The eduPerson specification defines an enumeration of permissible values for roles: eduPersonAffiliation

  • faculty

  • student

  • staff

  • alum

  • member

  • affiliate

  • employee

  • library-walk-in

Those eight roles contain seven values for natural persons and one for technical devices. The roles have a logical structure and hierarchy:

graph TD student staff faculty member alum affiliate staff --> employee faculty --> employee student ---> member employee --> member

Within an institution most often the following four roles have a relevance for identification documents / cards:

  • student

  • employee

  • affiliate

  • alum

The problem is, a natural person could have multiple accounts for an login - connected to an Identity Management System. For each account at an institution zero to seven eduPersonAffiliation roles could be assigned. So a natural person could have multiple roles and even the same role in multiple institutions, so scoped affiliations are potentially important.

graph TD person[Natural Person] account[Account] role[Role] pass[Pass / Card] person -- 1..n --> account account -- 1..0-7 --> role person -. 1..n .-> role account -- 1..n --> pass role --. 1..n .-> pass

Linking of multiple accounts is a necessary thing.

Contents#

Appendix#