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

The 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. In order to enable these processes, we require a student identifier that can be made available by the institution and which can be used by all the services to uniquely identify the user.

Requirements for a European Student Identifier

The ESI should be:

  • Globally Unique: Each student should be uniquely identified across organizational and national boundaries
  • Persistent: The identifier should follow the student during her/his time of studies
  • Non-targeted: The identifier should be the same for all services involved in the student mobility processes
  • Protocol neutral: The identifier should not change value depending on the propocal used. For example, it should be the same regardless is SAML or OpenID Connect is used
  • data transport neural: The identifier should not change value depending on how it is transported. For example, the students should be identified by the same identifier regardless if the it is through a federated authentication flow or a back-channel transfer of records.

In the next period, the project will engage with key stakeholders from the EC, the Identity Federations and the European Student Card initiative in order to decide on a solution that meets all requirements.

For a summary overview of how existing identifiers map please refer to this diagram. For more detailed explanation please refer to the text below.

Identifiers from the Identity Federation and eduGAIN

In the Identity Federation in eduGAIN there are a number of identifiers that are being used:

  • eduPersonTargetedID is a persistent, non-reassigned, opaque identifier for a principal. In abstract terms, an eduPersonTargetedID value is a tuple consisting of an opaque identifier for the principal, a name for the source of the identifier, and a name for the intended audience of the identifier. The source of the identifier is termed an identity provider and the name of the source takes the form of a SAML V2.0 entityID, which is an absolute URI. The name of the intended audience also takes the form of an absolute URI, and may refer to a single service provider or a collection of service providers, although the latter is not commonly used
  • eduPersonPrincipalName is a scoped identifier for a person. It should be represented in the form "user@scope" where 'user' is a name-based identifier for the person and where the "scope" portion MUST be the administrative domain of the identity system where the identifier was created and assigned. Each value of 'scope' defines a namespace within which the assigned identifiers MUST be unique. Given this rule, if two eduPersonPrincipalName (ePPN) values are the same at a given point in time, they refer to the same person. There must be one and only one "@" sign in valid values of eduPersonPrincipalName. Syntactically, ePPN looks like an email address but is not intended to be a person's published email address or be used as an email address. In general, name-based identifiers tend to be subject to some degree of expected change and/or reassignment. Values of eduPersonPrincipalName are often, but not required to be, human-friendly, and may change as a result of various business processes. They may also be reassigned after a locally defined period of dormancy. Applications that require a guarantee of non-reassignment and more stability, but can tolerate values unfriendly (and unknown) to humans should refer to the eduPersonTargetedID attribute
  • schacPersonalUniqueCode specifies a “unique code” for the subject it is associated with. Its value does not necessarily correspond to any identifier outside the scope of the directories using this schema. The <country-code> must be a valid two-letter ISO 3166 country code identifier or the string “int”, and assigned by the SCHAC URN Registry for this attribute; <iNSS> is a Namespace Specific String as defined in RFC 2141 but case insensitive, from a nationally controlled vocabulary, published through the URI identified at the above mentioned SCHAC URN registry.
  • schacPersonUniqueID specifies a "legal unique identifier" for the subject it is associated with. The <country-code> must be a valid two-letter ISO 3166 country code identifier or the string “int”, and assigned by the SCHAC URN Registry for this attribute; <idType>: Acceptable values must be declared per each country code through the URI identified at the above mentioned SCHAC URN registry.
  • subject-id: This is a new identifier that is long-lived, non-reassignable, omni-directional identifier suitable for use as a globally-unique external key. Its value for a given subject is independent of the relying party to whom it is given. A value (the unique ID and scope together) MUST be bound to one and only one subject, but the same unique ID given a different scope may refer to the same or (far more likely) a different subject. The relationship between an asserting party and a scope is an arbitrary one and does not reflect any assumed relationship between a scope in the form of a domain name and a domain found in a given SAML entity identifier. A value MUST NOT be assigned to more than a single subject over its lifetime of use under any circumstances. The unique ID should therefore be constructed in a fashion that reduces the probability of non-technical or political considerations leading to a violation of this requirement, and any such violation should be treated as a potential security risk to the relying parties to which the value may have been given. Relying parties should not treat this identifier as an email address for the subject as it is unlikely (though not precluded) for it to be valid for that purpose. Most organizations will find that existing email address values will not serve well as values for this Attribute.

Out of these identifiers, the first two (ePTID and ePPN) are commonly used in eduGAIN, but they do not meet our requirements. ePTID is targeted and thus will change from one service to the other, while for ePPN there is no guarantee that it will not be recycled, unless the Identity Provider supports the Research & Scholarship Entity Category. Both identifiers, usually, represent the user in the user directory and they do not reflect the student identifier that follows the student record. 

Regarding the schacPersonalUniqueCode and schacPersonalUniqueID, these are identifiers that are not commonly found at the inter-federation, eduGAIN level, but might be found more commonly within the boundaries of a Federation or an institution.

The subject-id identifier, as it was mentioned, is a rather new identifier and the adoption is rather low.

Another identifier worth mentioned is the Orcid identifier. ORCID iDs are persistent digital identifiers for individual researchers. Their primary purpose is to unambiguously and definitively link them with their scholarly work products. ORCID iDs are assigned, managed and maintained by the ORCID organization.

The European Student Identifier

The European Student Card project has introduced a new identifier the European Student Identifier. The European Student Identifier (ESI) is made up of the following data, separated by a hyphen:

  1. Country code of the HEI that issued the card, on two upper case characters, according to the ISO 3166-1 norm:
  • DE for Deutschland;
  • FR for France;
  • IE for Ireland;
  • IT for Italy.
    1. Region code of the HEI that issued the card. This code is optional. The format is free. It is proposed to use the nomenclature of statistics territorial units (NUTS). NUTS codes already contain the country code, that should be omitted. 
    2. HEI Participation Identification Code (PIC). This code identifies the HEI as part of the ERASMUS network. Every high education institution in Europe has such a code, or can obtain one with a simple administrative action. This code includes 9 digits. It can be found by searching on the web site In the rare case of a lack of PIC code, a pseudo code will be generated 

  • Student unique code in the HEI where she is enrolled. From case to case, this code may be national wide, regional wide or the home institution own identifier. 

At the moment the adoption of the European Student Identifier is rather low, limited to the institution that have been piloting with the European Student Card. One important characteristic of the European Student Identifier as defined the ESC project, is that links directly to the student identifier that is in the student record. On the other hand, one limitation of the current specification is that it requires the use of PIC number. The PIC number as a way to identify institutions has been reported to have a number of issues, the most important of which is that it is planned to be replaced by another identifier in the near future.

  • No labels