Page tree
Skip to end of metadata
Go to start of metadata

The purpose of the processing operation is to enable students and faculty of Higher Education Institutions (HEIs) to identify and authenticate themselves to the Services of the European Student Card Initiative and those directly supporting the digitisation of Erasmus+. These services are operated by the European University Foundation (EUF), which supports and enable the student mobility process.

The following attributes are requested:

  • Any of Persistent NameID, eduPersonPrincipalName (if the IdP supports the R&S Enitity Category), eduPersonTargetedID, eduPersonUniqueId, eduPersonOrcid, subject-id, pairwise-id: The services requires to uniquely identify users throughout the student mobility process. Without some kind of unique identifier, it is not possible to distinguish between two different users.
  • cn and/or displayName and/or sn + givenName: The Erasmus process needs to know the name of the person participating in the student mobility process.
  • mail: The service needs to be able to contact the user regarding the status of student mobility process.
  • schacPersonalUniqueCode: Τhe student mobility processes require the use of a number of services, all of which are involved in different stages of the pipeline and which will need to be able to exchange data about the students who are in mobility. The European Student Identifier (ESI) is globally unique, persistent, non-targeted, protocol neutral and data transport neutral. In SAML, the ESI is transported in the schacPersonaUniqueCode attribute (as defined in the SCHema for Academia). Currently support for the ESI is being rolled out in Higher Education Institutions around Europe. If your HEI, already supports the ESI, you can release it to the ERASMUS SP Proxy using this attribute.
  • schacHomeOrganization: The student mobility processes need the to identify the Home Institution from which the user is coming from.
  • eduPersonScopedAffiliation: The student mobility processes rely on authorising access to users based on the affiliation of their members in their home organisation.
  • No labels


  1. Note that the SAML SP in question does already support consuming the SAML Standard Identifiers subject-id and pairwise-id (as also indicated above) but its SAML 2.0 Metadata has yet to be amended with the entity attribute to signal that to IDPs.

    Until that happens no IDP will likely release these attributes to the SP.
    Adding this is on the todo list of the service operator(s).

    1. Moreover national federations should update their attribute schemas to make schacPersonalUniqueCode recommended or mandatory at HEI to be available to use to ESI.