This document is the full technical description of EMREX, and describes what has to be implemented locally to connect to the EMREX Network. For a short guide – se below.
This is a technical description of EMREX, you can find here information on what has to be implemented locally to connect to the EMREX network.
Each country has two roles in the EMREX network:
Because EMREX is a decentralized system, there is no major component that each country can reuse. The EMREX project does provide some modules, plugins and examples that can be used and built upon, however there are a couple of issues that cannot be solved in a general way:
There are 5 main parts that will be referred to through this document:
The following diagram shows in detail the data flow for a student wanting to import results from two different result providers (for instance, higher education institutions) in the same country.
It is up to each implementer to decide whether the SMP will run as a standalone service, or embedded into their client. The EMREX project provides a SMP library which can be used out-of-the-box as a standalone service.
The same remark applies to the result provider(s), the implementation is very much dependent on the underlying system(s).
This chapter is meant for consumers of results from other countries. There are 3 main steps the client needs to perform in order to get results from another country, each of which will be described in detail:
In order to initiate the transfer, one must first choose the National Contact Point to get the results from. This is done by contacting EMREG, a centralized service that gives a list of all available NCPs, as well as other information necessary to establish communication with each of them.
At the moment, the URL for EMREG is as follows:
The response from EMREG contains a list in the following JSON format:
The list contains a parameter called “singleFetch” saying whether a particular country has separate NCPs for each institution. In that case, after the country has been selected, the student will be presented with a list of all NCPs registered for that country, and for each NCP only the first institution on the list will be presented to the student (even though, for compatibility reasons, it will still be delivered by EMREG as a list).
The request is sent from a requester as HTTP POST and has two parameters. Note that the form must be of the default type, not “multipart/form-data”:
The hidden parameters are as follows:
As this service is still under development, additional parameters might be added at a later point.
The response is sent as a HTTP POST back to the EMREX Client with four parameters:
The following return codes are supported (the list is subject to change):
The “sessionId” must be the same as the one sent in the request. If it is not the same as the one that was sent, this response should not be processed.
The “elmo” parameter is the main piece of this response. It will be gzipped and encoded in Base64 for transfer.
The ELMO XML format contains the results themselves. The document is signed, using the XML DSig format, with the private key of the NCP that issued it. The public key can be obtained from EMREG. If signature verification fails, it means the results have been tampered with and MUST be rejected.
In addition to verifying the signature, the receiving client must ensure the results belong to the same person requesting them. ELMO includes the person’s name and birthday which can be used for this purpose. Both signature and person verification are provided by the SMP library.
The EMREX code is open source and can be downloaded from the EMREX GitHub account.
The following repositories are provided:
The ELMO XML format is the basis for the exchange of result information. ELMO is based on the CEN standard EN 15981-2011 EuroLMAI. EuroLMAI is a data model describing assessments, primarily Diplomas, Diploma Supplements and Transcripts of Records for higher educations. The schema describing the profile of the ELMO format used in EMREX is available in the EMREX GitHub repository.