With the release of TOMP-API version 1.2.0, we have added a few new features. In a series of blog posts over the next few weeks, we would like to go deeper into these innovations and explain the “what” and “why” in more detail. This last post is about new supported ways of opening/accessing assets, we call this access information.
The newly supported methods for access are :
- QR code / Aztec code
- Deeplink
- TOMP-API – internet operated
- AXA-EKey
- Physical key
- OV Chipcard (Dutch)
- EMV
- Barcodes
- HTML / PDF
In the former versions, there was already support for communicating information like QR codes, etc., but it was not formalized. In this version, we’ve tried to standardize the access information types we encountered.
How did we accomplice this? In the planning phase, we are already communicating how assets (or asset types) can be opened. The searching MaaS Provider can move forward with the access types they can handle and ignore the others.
The second step in the process is obtaining the access information itself. In some cases (f.x. train tickets), the Aztec/QR code is already generated and provided when booking (the result of the booking-endpoint). In the other cases, the access information can be requested just before starting the ‘leg’, using the ‘prepare’ event.
For instance, when an AXA EKey lock is used, the MaaS Provider has to call the prepare event. The result will contain the appropriate fields to open the AXA EKey, like a certificate, a passkey, the physical address, and the device name.
This is the last post of three about the new major features in TOMP-API 1.2: personal information, the travelers dictionary, and the standardization of access information. In the upcoming posts we’ll keep you informed about new features we’ll are going to incorporate in version 1.3, like ancillaries and creating handles to cooperate with other ecosystem parts, like discovery services, clearinghouses, etc.
Editor: T.A. Groen