Specifications, Validators and Tools

Who should be reading this?

The following chapters and tools are written by developers and for developers. If you're a project manager, then please assign developer(s) from your team to keep track of the changes in these specifications.

Developers chosen by the partners SHOULD:

  • Understand Git and be able to work with it fluently, in order to continually keep track and review all the changes to the specifications.

  • Have significant experience with XML namespaces, and XML Schema language.

Integration with other EU projects

We have designed our Registry in a way that should allow it to be of use in other EU projects too. If you are developing such a project, consider using our Registry Service by hosting the Discovery Manifest file compatible with our specifications. It's pretty straightforward and it should give you a head start (as you won't need to implement a Registry of your own).

We are aiming for our Registry and Discovery API to become common underlying parts of all similar projects focused on higher education in Europe. They are designed to be extendible and can be used to describe all kinds of APIs (even if some of these APIs clash together, by serving similar purpose in a different manner).

What is EWP?

Erasmus Without Paper (EWP) project aims to ease exchanging data on student mobility between computer systems in different countries (more information here). In order to make use of EWP, you will need to implement a subset of its APIs.

There are many APIs already present, and each partner will be allowed to choose which of them he wants to implement (which allows you to start early, and then expand to other scopes you want to participate in, step by step). Each such API is documented separately.

Issue tracker

You can find all unresolved EWP issues here (if you get 404 error, then sign in to GitHub first). If you want to browse only for the issues regarding one particular repository, then go to the Issues tab on that repository's GitHub page (these are quite mixed up though). You may also be interested in the available search qualifiers.

Documents and specifications

Status labels used for not yet released documents

  • DRAFT - working on it;
  • REVIEW RECOMMENDED - still not a final version, but initial review is recommended;
  • PENDING APPROVAL - waiting for the partners to officially accept the document.

Note, that discontinued drafts are usually simply removed from the index of documents below. That's why there's no label for them.

Status labels used for released documents

  • LATEST RELEASE - the latest accepted version of the document;
  • OBSOLETE - might still be in use, but a newer version exists;
  • DEPRECATED - might still be in use, but SHOULD be upgraded;
  • DISCONTINUED - might have been used in the past, but is no longer; do not use it.

Expand/Collapse All

Chapter 1. Working with EWP Technical Documentation v1.2.0

Chapter 2. Introduction to EWP Network

Chapter 2.1. Architecture and Common Datatypes v1.10.0

Chapter 2.2. Authentication and Security v2.0.2

Chapter 2.3. Client Authentication Methods

Chapter 2.3.1. Handling Anonymous Clients v1.1.0
Chapter 2.3.2. Authenticating Clients with TLS Certificate v1.1.0
Chapter 2.3.3. Authenticating Clients with HTTP Signature v1.0.0

Chapter 2.4. Server Authentication Methods

Chapter 2.4.1. Authenticating Servers with TLS Certificate v1.1.0
Chapter 2.4.2. Authenticating Servers with HTTP Signature v1.0.0

Chapter 2.5. Request Encryption Methods

Chapter 2.5.1. TLS and Request Confidentiality v1.1.0
Chapter 2.5.2. ewp-rsa-aes128gcm Request Encryption v0.2.0: REVIEW RECOMMENDED

Chapter 2.6. Response Encryption Methods

Chapter 2.6.1. TLS and Response Confidentiality v1.1.0
Chapter 2.6.2. ewp-rsa-aes128gcm Response Encryption v0.2.0: REVIEW RECOMMENDED

Chapter 3. Primary Network APIs

Chapter 3.1. Discovery Manifest API v4.1.1 + v5.0.0-rc1: PENDING APPROVAL

Chapter 3.2. Echo API v2.0.0

Chapter 3.3. Registry API v1.3.2

Chapter 4. EWP Mobility Process Explained v0.3.1: REVIEW RECOMMENDED

Chapter 5. General Purpose APIs

Chapter 5.1. Institutions and Faculties

Chapter 5.1.1. Institutions API v2.0.0
Chapter 5.1.2. Organizational Units API v2.0.0

Chapter 5.2. Courses

Chapter 5.2.1. Courses API v0.7.0: REVIEW RECOMMENDED
Chapter 5.2.2. Simple Course Replication API v1.0.0-rc9: REVIEW RECOMMENDED

Chapter 6. Erasmus Mobility APIs

Chapter 6.1. Interinstitutional Agreements (IIAs)

Chapter 6.1.1. Interinstitutional Agreements API v2.0.1
Chapter 6.1.2. Interinstitutional Agreement CNR API v2.0.1

Chapter 6.2. Outgoing Mobilities

Chapter 6.2.1. Outgoing Mobilities API v0.12.1: REVIEW RECOMMENDED
Chapter 6.2.2. Outgoing Mobility CNR API v0.4.0: REVIEW RECOMMENDED

Chapter 6.3. Incoming Mobilities

Chapter 6.3.1. Incoming Mobilities API v0.1.1: REVIEW RECOMMENDED
Chapter 6.3.2. Incoming Mobility CNR API v0.1.0: REVIEW RECOMMENDED
Chapter 6.3.3. Incoming Mobility ToRs API v0.7.0: REVIEW RECOMMENDED
Chapter 6.3.4. Incoming Mobility ToR CNR API v0.1.0: REVIEW RECOMMENDED

Chapter 7. Appendices

Chapter 7.1. .ewpmobility Exchange File v0.4.1: REVIEW RECOMMENDED

Chapter 7.2. EWP Address Data Types v1.0.1

Chapter 7.3. EWP Phone Number Types v1.0.1

Chapter 7.4. EWP Academic Term Data Types v1.0.0

Chapter 7.5. EWP Abstract Contact Data Type v1.1.0

Chapter 7.6. Universal Person Identifiers ("UPIDs") v0.1.1: REVIEW RECOMMENDED

Chapter 7.7. ewp-rsa-aes128gcm Encryption v1.0.0

Libraries and tools

Echo API Validator

This tool helps you to determine if your implementation meets the basic EWP standards (in particular, all its security requirements).

Echo API has been designed to serve two purposes: (a) to make developers aware of the specific security features required by EWP, and (b) to allow us to run automated tests on all existing implementations (thus reducing the risk of security misconfiguration). You will need to implement this API first, and make sure it is connected to our developer network.

Select Echo API instance to run validation on:

XML Schema Validator

This tool will help you with writing EWP XML documents. For example, you can paste the contents of your Manifest file here before you upload it onto your production site. You should be able to validate any XML document described in all RELEASED, DEPRECATED and OBSOLETE specifications above (plus, perhaps, some of the DRAFT ones).

Note, that this tool will validate against the schema only! Even if such validation succeeds, your file may still be invalid (if, for example, you didn't adhere to the guidelines described in <xs:documentation> elements included in the XSD files).

Paste your XML document below and press