Date: 4th October 2019

Introduction

Licia briefly introduced MyAcademicID project.  The project which is led by EUF (European University Foundation)  aims to enable student mobility by enabling federated access for some of the Erasmus tools and services. GÉANT, SUNET and RENATER participate for the NREN/Fed-Ops community. 

Erasmus student mobility keeps growing steadily over the years, and funding has been made available to automate the process. At the moment, the online tools and services that are available to support student mobility and the exchange of the student grades are not federated. The technical aspects to enable federated access for the Erasmus tools are underway as part of MyAcademicID project; it is however important to note that universities will keep using some out of band mechanisms to exchange students grades. 

The main use-case  (and challenge) is how to enable federated access to the identified Erasmus services (via eduGAIN); at the same time we need to  ensure that a user is unequivocally identified, starting from the moment he/she logs in via eduGAIN/national federation to fill-in the online application, until his/her participation in the Erasmus program is completed. . During this lifecycle, the user will have to access numerous online services, data records will be transferred from his/her University to Erasmus and the receiving University, and the user while at the receiving University should be able to receive services, such as accessing the campus canteen etc, using his/her European Student Card. 

In order to enable this, the student will have to have an identifier that will be used to unequivocally identify him/her across service and when his/her student records are exchanged as part of the Erasmus process. The Identity Management Systems behind the Identity Providers at the campuses, do have such identifiers for each user account, but in many cases these identifiers are specific to the IT services and are not linked with identifiers used in the student records or in the university student cards.

There is an opportunity to work together to expand the reach of federated access actively contribute in enabling  the Erasmus programme and student mobility in Europe.

Aim of the call 

The aim of the call was to discuss if and how federation operators can play a role in supporting the identifier needed for the use-case highlighted above. A subset of federation operators have been invited to join the call. Christos presented the work done so far as part of MyAcademicID as well as work that happened prior to MyAcademicID.  

There are different identifiers but none of them alone would solve the challenge above. The main requirements for such an identifier are:

Looking at the existing identifiers: 

How can federations help?

Q: ESI seems to carry a lot of information, how do we keep it unique? I.e. a users start at institution A then move to B, then the identifier would changes  The identifier of the institution could be send via the federated access). 

Q: Is the organisation sent via IdP the same info that is used for Erasmus purposes? 

A: Joao noted that for some Erasmus services to work, they need to verify the institution. The users could provide that but that would generate more errors.  The proposed format was to support different situations where some countries manages the student numbers centrally, and some others do not. 

ESI contains the student number  + the organisational code - The latter needs changing as the EC will replace the current format which is used to identify institutions applying for grants. In fact it would be desirable to allow for different type of organisational codes. The student number, which is managed by the student’s home organisation,  is in most of the cases not encoded in the IDM systems of the universities. 

The Fed Ops can help by:

Leif noted that together with Victoriano they are looking at the scalable ways to uniquely identify the users’ organisations. The ideal solution would be a globally unique way of expressing the academic records of a given person in such a way that the identifiers can be resolved back to the accrediting institution in a secure way that prevents forgeries and spoofing.

There are standards being specified that could achieve the proposed solution, like DIDs (Distributed Identity Document) and VCs (Virtual Credentials), but this will require substantial changes in how things are done in the current identity and data federations in Higher Education. It was agreed however that a short term solution is needed and that an incremental approach to solving the problem should be found.

Next steps 

It was agreed to start with a practical approach before migrating to a more complex solution. 

As a first approach, current Higher Education Federations in eduGAIN could be leveraged. Federation operators could ask IdPs to add both schacHomeOrganization and schacPersonalUniqueCode to IdP metadata distributed through the federations metadata feed. 

schacHomeOrganization would be used to  carry the internet domain for the institution the IdP belongs to. And schacPersonalUniqueCode will be multivalued and carry the institution identifiers (whatever they may be).

Victoriano proposed to find a way to use an identifier that is encoded as SCHACPersonalUniqueCode and also includes the SCHACHomeOrg following this format:

urn:schac:personalUniqueCode:es:uma.es:estudiante:1234567

This proposal should be further discussed and a plan on how to test should be agreed upon as soon as possible (a new doodle will be sent soon).

Miro volunteered to test in Croatia.