L'identifiant étudiant européen (ESI)

1. Pourquoi un identifiant étudiant européen ?

Le processus de mobilité Erasmus met en jeu plusieurs services qui interviennent à différentes étapes de la demande de mobilité d'un étudiant :

  • En amont, des échanges de données inter-établissements via le réseau Erasmus Without Paper (EWP) ;
  • Puis un accès ultérieur de l’étudiant à des services de mobilité en ligne (application mobile Erasmus+, Online Learning Agreement notamment).

Pour leurs besoins de fonctionnement, ces différents services ont par ailleurs besoin d’échanger entre eux des données sur les étudiants en mobilité. Ces différentes interactions du processus de mobilité sont illustrées de façon macroscopique dans le schéma ci-dessous :

Comment ainsi s’assurer que différents services, intervenant chacun à différents stades du processus de mobilité, reconnaissent de manière univoque un étudiant donné comme le même étudiant ?

L'identifiant étudiant européen (European Student Identifier ou ESI) se veut une réponse à cette problématique. Généré par les établissements participants, il constitue la clé de voute du processus de mobilité afin de :

  1. garantir qu'un étudiant en mobilité soit identifié de manière unique par les différents services de mobilité;
  2. faciliter l'échange de données entre ces différents services.

2. Enjeux liés à l'ESI pour les établissements participants Erasmus

Pour les établissements participants au programme Erasmus, les enjeux liés à l'introduction de l'ESI sont de :

  1. Générer un ESI dans leur système d'information local, en respectant les spécifications décrites dans ce document (voir ci-après);
  2. Transporter cet ESI lors des échanges de données Erasmus Without Paper inter-établissements (établissement d'origine <> établissement d'accueil) ;
  3. Transmettre cet ESI aux services en ligne de mobilité Erasmus via la fédération d'identités eduGAIN, lors de l'authentification de l'étudiant auprès de ces services.

3. Génération de l'ESI

La génération de l'ESI est une opération du ressort de l'établissement. Elle doit être effectuée conformément à la spécification décrite ci-dessous.

3.1 Spécification de l'ESI

La spécification originale de l'ESI (en anglais) est disponible ici.

3.1.1 Caractéristiques requises

Les exigences identifiées pour l'ESI pour répondre aux besoins du processus de mobilité Erasmus décrits ci-avant sont les suivantes :

  • Globalement unique : chaque étudiant doit être identifié de manière unique, au-delà des frontières organisationnelle (i.e. son établissement) et nationale ;
  • Persistant : l’identifiant doit suivre l’étudiant a minima tout au long de sa période de mobilité ;
  • Non ciblé : l’identifiant doit rester le même pour tous les services impliqués dans le processus de mobilité Erasmus ;
  • Indépendant du protocole : la valeur de cet identifiant ne doit pas changer quelque soit le protocole (de fédération) utilisé (i.e. SAML ou OpenID Connect) ;
  • Indépendant du mode de transport : la valeur de cet identifiant ne doit pas changer quelque soit le canal de transport utilisé (i.e. flux web pour la fédération vs flux back channel pour les échanges EWP) ;

3.1.2 Principes directeurs

Les principes directeurs à retenir pour l'ESI :

  • L'ESI est construit à partir des identifiants étudiant déjà existant dans les SI des établissements participants. Pour les établissements français, il se base ainsi sur l'identifiant national étudiant (INE).
  • L’attribut schacPersonalUniqueCode issu du standard SCHAC (SCHema for Academia) a été privilégié pour transporter l’ESI.

3.1.3 Format pour les établissements français

Les établissements français tirent directement profit de l'INE qui est un identifiant avec une portée nationale.
Ils peuvent ainsi atteindre l'exigence d'unicité globale en utilisant la forme simple de l'ESI, dont le format est décrit ci-après :

schacPersonalUniqueCode: urn:schac:personalUniqueCode:int:esi:fr:<INE>

Note :

  • <INE>: contient l'Identifiant National Étudiant (INE) sur 11 caractères. Cet identifiant a une portée nationale et est présent pour tout étudiant enregistré dans le SI Scolarité de l'établissement.

Exemple :

Ci-dessous un exemple de valeur d'ESI pour un étudiant enregistré dans un établissement français sous l'INE 1234567890G

3.2 Injection de l'ESI dans le SI local de l'établissement

La stratégie à mettre en œuvre ici est étroitement liée au contexte SI côté établissement et pourra varier d'un établissement à l'autre.
Nous nous bornerons donc ici à décrire le principe général uniquement.

Basiquement, il s'agira pour un établissement:

  1. De générer des ESI au bon format pour les étudiants concernés par la mobilité ;
  2. De mettre à disposition (provisionner) ces ESI dans les référentiels utilisateurs des briques applicatives concernées (outil de gestion des mobilités pour EWP ; fournisseur d'identités pour la brique fédération d'identités).

4. Transport de l'ESI dans les échanges de données Erasmus Without Paper

4.1 Périmètre concerné

Côté établissement, le périmètre concerné est le suivant :

4.2 Connexion d'un établissement participant Erasmus au réseau Erasmus Without Paper

Pour un établissement participant à Erasmus, la connexion au réseau Erasmus Without Paper s'effectue via un outil de gestion des mobilités.
Trois possibilités existent ainsi pour établissement :

  1. L'établissement dispose d'un outil de gestion des mobilités fourni par un tiers commercial (type MoveOn, Mobility Online, TerraDotta, etc.) ;
  2. L'établissement dispose d'un outil de gestion des mobilités interne (issu d'un développement “maison”) ;
  3. L'établissement n'a pas d'outil de gestion des mobilités et utilise le Dashboard Erasmus (outil gratuit fourni par la Commission Européenne).

4.3 Intégration de l'ESI aux outils de gestion des mobilités

Comme illustré par le schéma ci-dessous, l'ESI devra être pris en compte dans l'outil de gestion des mobilités utilisé par l'établissement afin qu'il puisse être transporté dans les échanges de données Erasmus Without Paper :

5. Transmission de l'ESI aux services Erasmus via la fédération eduGAIN

5.1 Périmètre concerné

Côté établissement, le périmètre concerné est le suivant :

5.2 Rôle de la fédération d'identités eduGAIN

Comme illustré dans le schéma au chapitre précédent, l’accès aux services en ligne de mobilité Erasmus (OLA, appli mobile Erasmus+, etc.) requiert des étudiants une authentification préalable (matérialisée par la flèche orange).

La fédération eduGAIN va permettre aux étudiants de réaliser facilement cette authentification en utilisant le compte de leur établissement d'origine. Elle va en outre permettre aux services de recevoir lors du processus d'authentification les informations essentielles liées aux étudiants en mobilité - dont l'ESI - fournies par leur établissement d'origine.

5.3 Mise en oeuvre côté établissement

La mise en œuvre côté établissement implique la réalisation des pré-requis suivants :

  • De disposer pour son établissement d'une brique technique fournisseur d'identités (appelé aussi Identity Provider ou IdP), capable de prendre en charge l'authentification des étudiants via la fédération d'identités ;
  • D'avoir enregistré cette brique fournisseur d'identités auprès de RENATER dans la fédération Education-Recherche : consulter la page dédiée pour plus de détails ;
  • D'avoir configuré cette brique fournisseur d'identités pour permette l'accès aux services Erasmus via la fédération eduGAIN : consulter la page dédiée pour plus de détails.