Architecture of the Interoperability section of EWP Network

This section contains diagrams depicting overall architecture of the interoperability section of the EWP Network (DEV and PROD) and its central components.

Technical insides of these components are also described, with links to source code in GitHub, where relevant.

Architecture

Architecture of the EWP Network is described in GitHub.

The EWP Network is strictly a middle layer solution where no information exchanged among the parties is ever stored. It follows a hub and spoke design, where the only centralised service is the Registry (see Registry section) that contains the identification info of the various members’ servers and the list of APIs (the connectors) implemented at each member’s server. An institution server wishing to initiate a data transaction consults the identification data of the concerned partner in the Registry and sends a data package directly to the receiving server via the relevant API. The data package is encrypted according to EWP defined standards (see Authentication and Security section) ensuring the communication cannot be accessed by other parties; this guarantees high levels of security and privacy. Each server takes care of the authentication and user rights of its own users. 

Figure 1 and Figure 2 show the general overview of the architecture of the EWP Network. More figures are available in GitHub.

Registry

The following repositories in GitHub are related to the EWP registry:

1. EWP Registry API. It contains a specification of the EWP Registry API. The Registry API is implemented by the Registry Service.

2. EWP Registry Service. It contains Java implementation of the registry server part. There are two public installations of the EWP registry:

   1. PROD Network,

   2. DEV Network.

3. EWP Registry Client. It contains Java implementation of the EWP Registry Service client.

   1. Developers, who implement a client, can use it to discover institutions in the network, and APIs implemented by them.

   2. Developers, who implement a server, can use it to verify incoming requests (prove that they come from within the EWP Network, and prove which institutions the requester covers).

4. EWP Registry Catalogue. It contains implementation of the application that enables replicating the EWP registry service on multiple servers.

5. EWP Registry log. It contains a record of changes made to the Registry’s catalogue in the production network (for logging purposes).

6. EWP DEV Registry log. It contains a record of changes made to the DEV Registry’s catalogue (for logging purposes).

The Registry Service is described in GitHub. It is the only centralized part of the EWP architecture. It allows all EWP hosts to access the list of other EWP hosts, and to list APIs implemented by these hosts, along with the URLs these APIs are implemented at.

The registry is being updated automatically. It periodically reads all the information which all EWP Hosts provide within their Discovery Manifest files, and these changes are instantly reflected in the Registry Service responses.

The major advantage of such automatic updating is that the partners do not need to contact the registry maintainer when they want to change some of their Registry entries. Most changes in the registry can be performed simply by updating the manifest on the partner's server (and the Registry will fetch these changes automatically). This process is both more convenient and more secure than updating the registry manually.

Authentication and Security

Authentication and security in the context of the EWP Network is described in the GitHub repository. The security of the communication is split into four security aspects, for which the following methods are available:

1. Client authentication

   1. Handling Anonymous Clients.

   2. Authenticating Clients with TLS Certificate.

   3. Authenticating Clients with HTTP Signature.

2. Server authentication

   1. Authenticating Servers with TLS Certificate.

   2. Authenticating Servers with HTTP Signature.

3. Request encryption

   1. TLS and Request Confidentiality.

   2. ewp-rsa-aes128gcm Request Encryption.

4. Response encryption

   1. TLS and Response Confidentiality.

   2. ewp-rsa-aes128gcm Response Encryption.

Each endpoint of each API must support at least one method of covering each of these security aspects. Before making the request, clients verify security protocols supported by the server, and construct their request appropriately.

APIs

There are many repositories in GitHub with API specifications. The APIs (and their versions) are listed and shortly introduced in the separate page and links to the respective repositories in GitHub are given there.