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.

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) ;

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

1. Générer et déployer l'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 dans les échanges de données Erasmus Without Paper (échanges de données entre établissement d'origine et établissement d'accueil), via l'outil de gestion des mobilités utilisé ;
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.

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 sur l'identifiant national étudiant ou INE (voir §2.2 ci-dessous).
• L’attribut schacPersonalUniqueCode issu du standard SCHAC (SCHema for Academia) est utilisé pour transporter l’ESI.

Conformément à sa spécification originelle, l’ESI peut prendre l’une des deux formes suivantes, en fonction de la portée requise pour faire de l’identifiant étudiant utilisé dans le SI local de l’établissement un identifiant étudiant globalement unique :

ESI avec identifiant étudiant de portée nationale (ou régionale) :

urn:schac:personalUniqueCode:int:esi:<country-code>:<studentcode>

ESI avec identifiant étudiant de portée locale à l’établissement :

urn:schac:personalUniqueCode:int:esi:<sHO>:<studentcode>

Avec :

• <country-code> est un identifiant de code pays ISO 3166 valide permettant de qualifier la portée nationale du code étudiant <studentcode> qui lui fait suite (autrement dit, le code étudiant identifie ici de manière unique l'étudiant au sein de l'État membre, ou de la région administrative le cas échéant) ;
• <sHO> désigne la valeur de l’attribut schacHomeOrganization, qui correspond au nom de domaine DNS de l’établissement. Requis si le code étudiant <studentcode> utilisé ne possède qu’une portée locale à l’établissement d’enseignement supérieur ;
• <studentcode> désigne l’identifiant étudiant utilisé par l'établissement d’enseignement supérieur, qui identifie l’étudiant de manière unique pour la portée considérée ;

Les établissements français tirent directement profit de l'INE (Identifiant National Étudiant) qui est un identifiant avec une portée nationale. Ils peuvent ainsi adopter la forme de l’ESI basée sur l’utilisation du code pays, comme illustrée ci- dessous :

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

Avec :

• en partie gauche, urn:schac:personalUniqueCode:int:esi:fr est un préfixe invariant qui s’applique à tous les établissements français ;
• en partie droite, <codeINE> contient l'Identifiant National Étudiant (INE) de l’étudiant concerné, 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.

Une valeur d'ESI pour un étudiant enregistré dans un établissement français sous l'INE 1234567890G prendrait ainsi la forme :

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).

On peut toutefois souligner que, dans la mesure où l’ESI est construit à partir de l’INE et présente une partie gauche préfixe invariante, manipuler et faire transiter l’ESI dans sa forme complète au sein du SI de l’établissement n'a que peu d'intérêt car source de complexité supplémentaire. Il est ainsi plutôt recommandé :

• de provisionner les INE des étudiants Erasmus dans les référentiels utilisateurs des briques applicatives concernées : outil de gestion des mobilités pour Erasmus Without Paper d’un côté, et fournisseur d’identités pour la fédération d’identités de l’autre ;
• au niveau de chaque brique applicative, de construire, sur la base des INE disponibles, les ESI des étudiants Erasmus au bon format, avant de les transmettre respectivement dans les échanges Erasmus Without Paper et ceux liés à la fédération d’identités.

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

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).

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 :

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

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 d'identités 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.

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.