This page was moved to https://esci-sd.atlassian.net/wiki/spaces/EWP/overview
Click in the link above if you are not automatically redirected in 10 seconds.


You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

If you are using software from a third party provider, you will join EWP via your provider. Please contact your provider to inform about the status of their implementation. 

Below you can find information on how your provider can join EWP.

Vetting process

a. Terms of use

Your third party provider will have to sign the Terms of Use Collaboration Agreement as a third party provider. They need to send it to us as a signed PDF. On the EWP side Joao Bacelar (Executive Director of the European University Foundation - EUF) signs it for the EWP consortium as representative of the coordinating institution.

It is up to the third party provider to keep evidence that it has your official permission to send the data over the EWP Network and which APIs are to be covered by the Provider for your institution.

b. Authentication

Your third party provider is responsible for the authentication part. Only institutions that have an Erasmus Charter for Higher Education (ECHE) can join the network (organizational units of a given HEI (faculties, departments) are not allowed to connect to the network separately). 

c. Technical admission

In the EWP network we have both a Development (DEV) and a Production (PROD) environment. There are no conditions to enter the Development environment, but the Production environment is where the real data exchanges take place, so you need to fulfill several conditions to enter it.

As a first step your provider needs to send us the URL of the so called manifest file (the manifest includes information about the HEI in question and which services (APIs) it implements). Your provider will either use a specific manifest file for your institution or your institution will be part of general manifest file covering several institutions.

This information will then be entered in the development environment (DEV) so your provider can start testing (ask your provider if they can make a testing installation available).

For each of the APIs supported, the server implementation should work properly to assure the data exchange.

The technical admission procedure consists of four steps:

  1. The URL to the manifest file is added to the development registry (DEV):
    Therefore a manifest file and its corresponding URL will be needed. The manifest file contains information about the supported APIs and hosts. The URL will be added to the development registry and as a first step the ECHO API needs to be developed.
  2. The applicant institution performs some automated self-tests.
  3. The applicant institution performs testing with three partner institutions.
    Newcomers will need to demonstrate their technical ability to exchange real data in the development environment. Therefore, they will need to develop at least one of the APIs (apart from ECHO) that facilitate the real exchange of data between HEIs. Before an applicant institution can become part of the production registry, the institution needs to prove successful testing.
  4. The EWP technical team performs some ultimate technical testing before adding the institution to the production registry (PROD). 
    The final step of the technical admission consists of an ultimate series of tests by the EWP technical team. Each of the APIs supported by the applicant will undergo this testing.


Entry in the production registry

Once both admission processes have a positive outcome, the EWP Technical Support Team will add the URL of the manifest file(s) to the production registry. By doing so your institution becomes part of the EWP network and agrees to the EWP rules and obligations. In case of a serious violation or complaints by other EWP users a revocation procedure can be installed by contacting us via the Knowledge Base (see below). As part of the obligations, software providers agree not to add additional APIs to their production manifest file before it has released and tested these new APIs in the development environment. 

Revocation

We should keep in mind that things can go wrong. When institutions violate the use of EWP there should be an exit strategy. The contact section in the Knowledge Base will be the central point where institutions can report incidents and complain about the quality of APIs of any particular institution, the unavailability of a server, partners that are not trustworthy, etc ...  The EWP Governance structure will try to settle disputes and has the ability to decide to exclude a certain institution from the production registry. The institution will need to prove its ability and trustworthiness again in the development environment. In cases of extreme violation the EWP governance structure has the competence to temporally exclude an institution from EWP.


The entry procedure for institutions who want to join EWP via their in-house or 3rd party software above is currently revised with the aim to automate the entry procedure through a web application. We hope to release this new entry functionality in the course of 2022.




  • No labels