Architecture of eduTAP Vendor specific API#

A set of libraries to be used by developers writing management software for passes. Additionally, support services are provided to be used by the libraries or the vendor specific systems.

They interact either with the specific vendor REST APIs or provide the functionality.

In eduTAP the APIs are meant to be used by the Pass Management Portal and the Pass User Portal.

It is planned to support the following vendors

Each vendor works conceptional different. Thus the libraries are different in their structure and API.

At first, we will implement APIs for Google and Apple. The next part focuses on this.

For both, passes (Google: wallet objects) and pass templates (Google: wallet classes) the eduTAP API provides the following functionality:

  • create,

  • read,

  • update,

  • notify (messaging)

  • manage the state (lifecycle),

  • list (with basic filters).

There are predefined, vendor-specific pass types. The libraries are defining models for all of these. The models can be referenced by name on the above operations using a registry.

First, those libraries will be implemented using Python. There will be a Python package for each vendor, at first:

  • edutap.wallet_google

  • edutap.wallet_apple

Both libraries follow the same basic structure and public API, as well as upcoming APIs. In the future, there might be also a JAVA-based (other languages welcome) implementation of those libraries.

While Google provides a RESTful API to manage passes, Apple uses an approach to provide passes as signed files, generated by the issuer.

For Google we provide a callback handler to receive events from Google and pass them to the event system.

To download and communicate updates of passes to Apple devices we implemented a web service to be contacted by the Apple devices application, such as browser, apps or wallet as a client.

For both, callback handlers and pass-server we will provide a FastAPI applications aside with the libraries.