The EWP Registration Portal (RP) is an online service that plays a pivotal role in supporting the deployment of the EWP Network. In the RP, Higher Education Institutions (HEIs) can enter or change their EWP settings, having full control as to how they are represented in the EWP Network. Mobility software providers may register manifest files of their customers enabling them to have easy access to technical data.
Installations of the Registration portal | Contact emails
|
Goals of the Registration Portal
Improve governance HEIs get agency and tools to manage their connection to the Network. This goal is achieved by giving institutions the way to sign in to the Registration Portal with the credentials passed from their home authorisation system and the right to approve their manifests. | Improve network management In the Registration Portal all stakeholders – HEIs and mobility software providers – manage all network parameters of their connectivity by themselves, anytime. Registry administrators and EWP network authorities also can handle the needed activities via the web portal. |
Easy access to documents All important documents, such as the signed EWP Collaboration Agreement, are gathered in one place which is easily accessible to all stakeholders. | Automatic verification of ownership In line with the carefully crafted verification rules, the portal supports security and ownership by verifying the identifiers (such as SCHAC code) transported in the set of attributes from MyAcademicId against identifiers obtained from other sources (ECHE List API, HEI List API, manifest files). |
Actions performed in the Registration Portal
In this section, we shortly explain what actions providers and HEI representatives should perform to properly register their manifests in the EWP network. The only way to place the manifest on the Internet is for the provider to enter it into the Registration portal, verify the correctness of the manifest (including the APIs it contains) and have the manifest confirmed by the HEI for which it is intended.
3rd-party provider |
|
In-house provider (represented by the EWP Administrator) |
|
Important functionalities of the Registration Portal
Activating the provider’s account
When a provider creates an account in the Registration Portal, the account status is New. After the Collaboration Agreement signed by the provider is loaded into the system, the account status changes to Pending. Once the MoU Administrator submits the countersigned MoU, the account status changes to Active. Only then, the provider can register the manifest files.
Registration of the manifests
A provider registers the manifests. The system validates them and only those manifests which validate positively, are exported to the EWP Network. The manifest has to be reachable, have a proper certificate, have a proper XML format. Additionally, there are some restrictions concerning names:
the provider’s name in the manifest must be identical to the technical name of the provider (or a name, if no technical name is provided); be aware, that the provider’s name in the manifest does not include the part in parenthesis, eg. for an element <admin-provider>MUCI (USOS)<admin-provider> the name of the provider is MUCI, the name of the mobility software of the provider is USOS.
in case of the manifest registered by an in-house system provider, the SCHAC code in the manifest must be identical to the SCHAC of the HEI (delivered by MyAcademicID).
If the manifest does not validate, the provider has to correct errors and try again.
Confirmation of the manifests by HEIs
A manifest registered in the system by the 3rd-party provider gets the status Unconfirmed. Such manifests have to be confirmed by the HEIs for which they are intended. The HEI’s representative with a EWP Admin role should sign in to the system via MyAcademicID and confirm the manifest(s) on behalf of the institution.
Only confirmed manifests are exported to the EWP Network.
In special cases, the 3rd-party provider can ask the RP administrator to confirm manifests on behalf of the institution. The system delivers a functionality which allows the provider to select the manifests and mark them as Admin confirmation requested. An email is sent to the RP administrator, who can confirm the manifests or reject the request.
Manifests registered by in-house system providers by default get the status Confirmed.
Verification status of the provider’s APIs
The system keeps track of the major versions of the APIs which can be present in the EWP Network. Currently (October 2023) the following major versions are acceptable in the DEV and PROD networks.
# | Name of the API | Versions acceptable in DEV | Versions acceptable in PROD |
|---|---|---|---|
1 | courses | 0.0.0 | 0.0.0 |
2 | discovery | 6.0.0 | 6.0.0 |
3 | echo | 2.0.0 | 2.0.0 |
4 | factsheet | 1.0.0 | 1.0.0 |
5 | file | 1.0.0 | 1.0.0 |
6 | iia-approval-cnr | 1.0.0, 2.0.0 | 1.0.0 |
7 | iia-cnr | 2.0.0, 3.0.0 | 2.0.0 |
8 | iias | 6.0.0, 7.0.0 | 6.0.0 |
9 | iias-approval | 1.0.0, 2.0.0 | 1.0.0 |
10 | imobilities | 1.0.0 | 1.0.0 |
11 | imobility-cnr | 1.0.0 | 1.0.0 |
12 | imobility-tor-cnr | 1.0.0 | 1.0.0 |
13 | imobility-tors | 1.0.0, 2.0.0 | 1.0.0, 2.0.0 |
14 | institutions | 2.0.0 | 2.0.0 |
15 | omobilities | 1.0.0, 2.0.0 | 1.0.0, 2.0.0 |
16 | omobility-cnr | 1.0.0 | 1.0.0 |
17 | omobility-la-cnr | 1.0.0 | 1.0.0 |
18 | omobility-las | 1.0.0 | 1.0.0 |
19 | organizational-units | 2.0.0 | 2.0.0 |
20 | simple-course-replication | 1.0.0 | 1.0.0 |
The RP administrator in theReviewer’s role verifies the mobility software of a provider and sets the status of the provider’s APIs accordingly. In the DEV Network generally all acceptable APIs are set as Verified. In PROD the status of the API depends on the results of testing - only after successful testing the APIs get status Verified, otherwise they have status Unverified.
The status of the manifest depends on the status of the APIs defined in it. If any of the APIs is Unverified, the manifest also gets status Unverified.
Status of the manifests
The status of the manifest depends on the following flags:
Confirmed (Yes/No)
Verified (Yes/No)
Enabled (Yes/No) - this flag is set manualy by the RP administrator who can, for some reason, temporarily disable the manifest.
Valid (Yes/No) - this status depends on the result of the validation performed upon registration and periodically by the system.
Each of these flags can change independently of the others.
Only the manifests which are Confirmed, Verified, Enabled, and Valid are exported to the EWP Registry:
In the Registration Portal the manifests which are Confirmed, Verified, Enabled, and Valid are shown as Active, otherwise as Inactive.
Periodical check of the manifests' status
The system validates and verifies manifests when they are registered, and also periodically:
If the manifest is not reachable for a long time, or it does not parse according to XSD, or the name is not correct, it gets the Invalid status.
If the manifest contains unverified APIs, it gets the Unverified status.