Specifications, Validators and Tools

Summary:

This document describes how EWP deals with integrity and confidentiality of the messages exchanged.

Summary:

This document describes how EWP deals with integrity and confidentiality of the messages exchanged.

Summary:

Discovery API is the first API that the partner developer needs to implement in order to become a basic member of the *Erasmus Without Paper* Network.

Discovery manifest files serve to announce which HEIs your system covers, which features (APIs) you have implemented, and which credentials your clients are going to use when fetching the data from the EWP Network.

Summary:

This API allows beginner EWP developers to test the security of their EWP Network connections. It doesn't "do" anything, but it requires the developer to implement the core security framework (which will be needed by all the other APIs later on).

Summary:

This document describes the API implemented by the Registry Service. It is placed in the "APIs" section of the documentation, but this does not imply that we want you to implement it. You will be only using it (as a client).

Summary:

This document describes the File API. This API allows partners to share files securely.

Summary:

This document describes the Monitoring API implemented by the EWP Stats Portal, which is hosted by EWP administrators. This API allows clients in EWP network to inform network's administrators about any issues encountered when making requests. This API SHOULD NOT be implemented by anyone other than EWP Stats Portal. Clients MUST call this API in case of detecting any exceptions or incorrect responses from any of the servers in the EWP network, except EWP Stats Portal and the Registry Service. In case of issues with calling this API, like server unavailability, clients are not required to call this API repeatedly or store messages until further time. It means that simple "call and forget" is good enough. Calls to this API MUST NOT contain any private data.

Summary:

This document describes the Beneficiary Module Mobilities API. It is assumed that this API is implemented by only one host managed by the Directorate-General Education and Culture Unit (DG EAC) of the European Commission.

Once implemented by the host, it allows external clients to automatise reporting of individual mobilities of students to the Beneficiary Module.

Summary:

This document describes the Mobility Tool+ Institutions API. It is assumed that this API is implemented by only one host managed by the Directorate-General Education and Culture Unit (DG EAC) of the European Commission. However, the specification itself does not limit the number of hosts.

Once implemented by the host, it allows external clients to retrieve general information on institutions known by this host.

Summary:

This document describes the Mobility Tool+ Projects API. It is assumed that this API is implemented by only one host managed by the Directorate-General Education and Culture Unit (DG EAC) of the European Commission. However, the specification itself does not limit the number of hosts.

Once implemented by the host, it allows external clients to retrieve list of projects for a particular institution and call year.

Summary:

This document describes the Mobility Tool+ Dictionaries API. It is assumed that this API is implemented by only one host managed by the Directorate-General Education and Culture Unit (DG EAC) of the European Commission. However, the specification itself does not limit the number of hosts.

Once implemented by the host, it allows external clients to retrieve terms from a particular MT+ dictionary and call year.

Summary:

This document describes the Mobility Tool+ Mobilities API. It is assumed that this API is implemented by only one host managed by the Directorate-General Education and Culture Unit (DG EAC) of the European Commission. However, the specification itself does not limit the number of hosts.

It allows external clients to report their mobilities to Mobility Tool+.

Summary:

This document describes the .ewpmobility file format. This specialized file format is intended for exchanging student mobility data, in a form strictly compatible with EWP. .ewpmobility files might prove useful when moving mobility data from one institution to another, i.e. when migrating to EWP workflow.

Summary:

This repository contains XML Schemas used in EWP APIs for street and postal addressing. It follows the same versioning rules as all EWP APIs do. Other projects are welcome to reuse this schema, along with its namespace. We are also open to suggestions of extending it.

Summary:

This repository contains XML Schemas used in EWP APIs for encoding phone and fax numbers. It follows the same versioning rules as all EWP APIs do. Other projects are welcome to reuse this schema, along with its namespace. We are also open to suggestions of extending it.

Summary:

This repository contains XML Schemas used in EWP APIs for addressing academic years and academic terms. It follows the same versioning rules as all EWP APIs do. Other projects are welcome to reuse this schema, along with its namespace. We are also open to suggestions of extending it.

Summary:

This repository contains XML Schema used in some EWP APIs in contexts when multiple, non-identifiable, abstract contact entities need to be attached to a business entity. It follows the same versioning rules as all EWP APIs do.

Summary:

This repository describes the identifier type we plan to use in EWP APIs to uniquely identify people. It follows the same versioning rules as all EWP APIs do. Other projects are welcome to reuse this data type, along with its XML namespace. We are also open to suggestions of extending this document.

Summary:

This document describes a format which can be used to transfer encrypted binary payload to a single recipient, with help of symmetric AES-128 GCM encryption and the recipient's public RSA key.