European Student Identifier: Hvad skal der til?

Artiklen her kan med udbytte læses omhyggeligt af uddannelsesinstitutioners it-organisation og studieadministration i forening. Den opdateres løbende, i takt med udviklingen på området, og tåler derfor ganske jævnlig genlæsning:

Som led i digitaliseringen af Erasmus skal hver uddannelsesinstitution som deltager i programmet, snart implementere den såkaldte European Student Identifier (“ESI”) i visse af sine it-systemer. Hver ESI-værdi er en kort tegnrække som identificerer netop én studerende ved institutionen – fuldstændig ligesom det lokale brugernavn og andre identifiers man allerede måtte have i brug i institutionens systemer.

WAYF kommer til at spille en rolle som formidler af ESI gennem eduGAIN og er i dialog med Uddannelsesministeriet og GÉANT om ESI. I det følgende belyses hvilke uomgængelige krav ESI-implementeringen stiller til institutionerne.

Hver Erasmus-institution skal selv definere og udstede ESI-værdier for sine studerende. Internt kan institutionen formatere værdierne som den vil; men i det mindste ved udveksling med eksterne tjenester (Erasmus-tjenester etc.) skal hver ESI-værdi have formatet urn:schac:personalUniqueCode:int:esi:<sHO>:<code>, hvor <sHO> er institutionens SCHAC-kode (schacHomeOrganization-værdi) i WAYF. Det er helt op til den enkelte institution hvordan den vil udfylde <code> – så længe værdien aldrig vil blive genbrugt om en anden person og forbliver i aktiv brug i relevante systemer i hvert fald så længe den betegnede studerende er i udveksling fra institutionen. Hvis institutionen allerede har en identifier med den egenskab, vil den identifier muligvis kunne bruges som grundlag for <code>. Hver ESI-værdi må dog højst fylde 255 tegn alt inklusive. Bl.a derfor bør det undgås i <code> at gentage informationen i <sHO>, dvs. fx langt hellere ...esi:ku.dk:abc123 end ...esi:ku.dk:abc123@ku.dk.

Derudover gælder det at hver studerendes ESI-værdi skal kunne formidles til WAYF fra institutionens identity provider OG skal identificere den studerende i mobilitetsdata som institutionen udveksler begge veje med tjenesten Erasmus Without Paper (“EWP”). Hvilket generelt indebærer at hver studerendes ESI-værdi skal være tilgængelig både for institutionens identity provider og for dens studieadministrative systemer, i det mindste de systemer som skal udveksle data med EWP. Og de sidste (“mobilitetssystemerne”) skal altså også kunne genkende eller “afkode” institutionens egne ESI-værdier når de kommer tilbage fra EWP – altså nemt kunne henføre dem til de identifiers som institutionen i øvrigt bruger for de betegnede studerende. Til WAYF skal brugerens ESI sendes som værdi af attributten schacPersonalUniqueCode. Eksempler på alm. benyttet identity provider-software er SimpleSAMLphp, ADFS, AzureAD, NetIQ.

Hvis institutionens identity provider og dens mobilitetssystem ikke allerede kender hver studerende under samme identifier, direkte eller indirekte, bliver det formentlig institutionens største udfordring ved ESI-implementeringen at få skabt denne helt nødvendige sammenhæng mellem systemerne. Uden den kan institutionens systemer ikke producere samme ESI-værdi for samme studerende – og institutionen dermed vanskeligt deltage i Erasmus længere. Institutioner som skal kommunikere med EWP via et tredjepartssystem (fx MoveOn, EASY, Erasmus Dashboard), bør henvende sig til systemets leverandør med henblik på afklaring af hvordan systemet knyttes sammen med institutionens ESI-værdier.

ESI er tænkt som en internationalisering af den identifikation som hver institution bruger for sine studerende internt, i sine studieadministrative systemer. Derfor vil det konceptuelt bedste valg som grundlag for udfyldning af <code> være sådan noget som et internt studienummer eller studie-ID, STADS-løbenummer, ESAS-UUID (se længere nede) eller CPR-nummer. Men praktiske og andre hensyn kan bringe andre, mere it-tekniske identifiers i spil såsom lokalt brugernavn og LDAP-UUID. Eksempelvis kan det vise sig vanskeligere at gøre ESAS-UUID tilgængeligt for institutionens identity provider end at få dens mobilitetssystem til at bruge ESI-værdier baseret på et it-brugernavn som identity provider'en allerede råder over.

Hvis man vælger at basere <code> på en identifier som er genereret i et system, fx UUID fra en LDAP-brugerbase, skal man være opmærksom hvis systemet på et tidspunkt udfases. ESI-værdier som er i aktiv brug i pågående Erasmus-udvekslinger, må nemlig ikke ændre sig blot fordi institutionen skifter system – men skal fortsat kunne frigives fra institutionens identity provider og kunne fortolkes i dens mobilitetssystem også efter udfasningen af det system som har genereret <code>-delen. Skift af AD fra on-prem til cloud eller omvendt på en institution som har baseret <code> på ObjectGUID, kunne være et eksempel på en situation som kræver opmærksomhed. Udfasning af ESAS eller STADS hos institutioner som har baseret sig på ID'er fra de systemer, kunne være andre eksempler. Robusthed mod den slags udfordringer kan man opnå ved at gemme hver udstedt ESI-værdi i et nyt felt i LDAP-brugerbasen og hvor man ellers har brug for at kunne få den fra.

Om ESI hedder det i øvrigt at værdierne ikke er beregnet til manuel håndtering, men kun til maskinel behandling – dvs. udtrykket behøver ikke være nemt at huske eller taste. Det anbefales også at værdierne konstrueres sådan at man ikke ud fra dem kan gætte hvem de betegnede studerende er – dvs. som <code> skal man snarere end fx et navneafledt brugernavn eller en navneafledt institutionsmailadresse bruge fx et uigennemskueligt brugernavn, et løbenummer eller et internt studienummer (klart bedste valg hvis muligt). Muligheder kunne fx være CWIS-nummer, LDAP-UUID, ESAS-UUID (se længere nede), STADS-nummer. Hvis et mere følsomt udtryk viser sig at være det mest praktiske grundlag, kan man overveje at bruge en forvansket udgave af det som <code> og skal i det tilfælde gemme sammenhængen mellem forvanskning og udtryk for at mobilitetssystemet kan afkode egne ESI'er som modtages fra EWP. Den bedste grad af privacy opnår man naturligvis ved at bruge sådan et udtryk som kun få er i stand til at henføre til den betegnede studerende. Derfor er det måske ikke optimalt (omend muligt) at udfylde <code> med fx et brugernavn hvis sammenhæng med den studerende allerede er kendt i en bredere kreds.

Der er fra Erasmus ingen ambition om at sørge for at hver fysisk person kun får tildelt én ESI-værdi igennem sit samlede studieliv. Tværtimod vil samme person typisk få flere ESI'er hvis vedkommende skifter institution. Det er heller ikke væsentligt, omend i visse sammenhænge måske lidt ubekvemt. Det væsentlige er: at enhver udstedt ESI-værdi aldrig vil blive genbrugt som ID for en anden person og er operativ i relevante systemer i hvert fald så længe den betegnede studerende er i udveksling fra institutionen.

I nogle medlemslande, fx Sverige og Frankrig, har det været muligt at lave en national koordinering af ESI-værdirummet og dermed have kun én ESI-værdi per studerende i landet; men her i Danmark er det hidtil ikke lykkedes at identificere noget indlysende fælles værdigrundlag. CPR-nummer er et følsomt valg, selv som input til en salt'et hash. De mange institutioner som bruger det studieadministrative system ESAS, har dog mulighed for at udstede samme ESI-værdi for samme person på tværs af institutionerne, på basis af ESAS-UUID. Institutioner som ønsker at gå den vej, skal i stedet for det ovenfor skitserede blot benytte formatet urn:schac:personalUniqueCode:int:esi:esas.ufmit.dk:ESAS-UUID i hver ESI-værdi. Institutioner som ønsker koordinering af yderligere tværgående værdirum, kan henvende sig til WAYF med konkrete forslag.

Sådan er hovedtrækkene i ESI-regimet. Der kan også findes information om ESI i dokumentet her, på EUF's website generelt og i GÉANTs wiki (autoritativ kilde).