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

Specification for the European Student Identifier using the schacPersonalUniqueCode


Please note the ESI Specification is being reviewed to address the comments received. If you have any questions about the revision or on the ESI in general please do not hesitate to contact us.

This specification defines a profile for the schacPersonaUniqueCode, as defined in the SCHema for Academia, that will be used to transport the European Student Identifier.


European Student Identifier (ESI)


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.

The European Student Identifier is globally unique, persistent, non-targeted, protocol neutral and data transport neutral.

  • 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 protocol 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.


The European Student Identifier


  • <country-code> is a valid two letter ISO 3166 country code identifier or the string “int” and assigned by the SCHAC URN Registry.
  • <eNS> is the string “ESI” or a string from a nationally controlled vocabulary that denotes that this is a European Student Identifier and which is published in the SCHAC URN Registry.
  • <sHO> OPTIONAL – This is the schacHomeOrganization. Required if the student code is provided by the Home Organization of the student and there can be no guarantees that it uniquely identifies the student within the member state.
  • <code>: The code of the student that uniquely identifies the student within the scope that has been issued. <code> has to be a URN string following the requirements of RFC 2141


Student codes issued and managed centrally at the Member State level


Student codes are issued and managed by the HEI

Student codes are issued by sub units of HEI

SAML Attribute


OpenID Connect claim


  • No labels


  1. I think the identifier structure proposed here doesn't make proper use of the attribute as defined in SCHAC 1.5 spec (nor the registry), nor does it match the (better structured, albeit ficticious) so-called "common usage" example provided in SCHAC 1.5 itself, "urn:schac:personalUniqueCode:int:studentID:<country-code>:<code>":

    A European Student Identifier itself by design is valid/used cross-border and not tied to national/country-specific customs. So the country-code (mandated in the SCHAC spec for this attribute) for an ESI would always be "int", followed by the iNSS (again, according to the spec), which is "esi" here (or "ESI", it's defined to be case-insensitive in the spec).
    But since the whole schacPersonalUniqueCode attribute value string up to this point only actually identifies the attribute name (a problem inherent in this SCHAC attribute) you'd of course still have to add qualifiers after that to make not globally unique values (such as local or national student "codes") globally unique. I.e., the proper format should be:

    • urn:schac:personalUniqueCode:int:esi:<country-code>:<code>
      for nationally unique/assigned identifier values, or
    • urn:schac:personalUniqueCode:int:esi:<country-code>:<sHO>:<code>
      for locally assigned identifier values.

    Note that my latter example above tries to accomodate the (possibly ill-advised) parsing of the identifier structure to allow for consistently determining the country of origin, because that way urn:schac:personalUniqueCode:int:esi:<country-code> will always be present for all values, no matter the convention chosen. If that is not actually a requirement of the architecture or a shared concern then the structure for locally assigned identifier values (the second case above) should actually be:

    • urn:schac:personalUniqueCode:int:esi:<sHO>:<code>

    because qualifying any local "code" with the schacHomeOrg value (which itself is a DNS domain) already makes it globally unique. So there's no "further uniqueness" to be gained by additionally also qualifiying it with a country code.

    (And of course urn:schac:personalUniqueCode:int:esi would have to be added to the SCHAC URN Registry as a delegated namespace unter the "int" arc.)

  2. I agree with Peter.

    His proposed syntax is closer to the intended, and suggested, use for schacPersonalUniqueCode, it respects the international nature of the proposed ESI and it makes the information naturally flow from the general (ESI) to the particular (the final code).

    Let me add another reason, which to be honest is already implicit in what Peter said: in the SCHAC specification it is stated that the Namespace Specific String after the country code comes from a nationally controlled vocabulary, but this is not clearly the case for the ESI. So the use of "int" country-code does make it clear that both the scope and the  governance is global,