At the moment, the European Commission is calling on alchemists who are transforming the leaden blanket of eFTI regulation into an increasingly palpable ecosystem - the story does not yet say whether gold is at stake, but some prophecies state €27 billion in savings over the next 20 years. Circle and RINA are working on the functional specifications of the eFTI ecosystem.
#Briefing
Efforts are currently underway to define the IT architecture and processes to be used by the eFTI ecosystem, including how it will be connected to, and what actions it will carry out. Several possibilities are being considered, and the DTLF is presently analyzing the advantages and disadvantages of each alternative to make a decision and move forward. Above all, the DTLF is assuming these technical choices in front of the hordes of forwarders who are enraged at the idea of changing their processes.
Who is phosphorus?
Circle is an Italian company founded in 2012 that has developed MILOS (Making International Logistics Optimization Simple), an ecosystem of tracking, planning and automation applications for the entire supply chain (TOS, GOS, PCS, Customs Registers). Circle also provides consulting services for digital solutions and tenders for EU projects and runs a platform for exchanges on the Motorways of the Sea (if the Motorways of the Sea remind you more of Kevin Costner in rags than the Commission's 2001 White Paper, have another slice of TEN-T). And since the homeland of Vivaldi and Ennio Morriconne shows the way to fraternity between peoples in its video presentation of MILOS, treat yourself to a Tchaikovsky interlude between two sips of IoT.
As for RINA (Registro Italiano Navale), it was originally (160 years ago) a foundation member of IACS that issued class certificates for ships, but today it provides services in areas broader than transport and contributes to the development of regulations.
Everything is still under construction, and a large part of what is to come currently exists primarily on paper, except for pilot sites, living labs, and other proof of concepts (POCs) that address all or part of the problem. The challenge of thissummary document is to project the functioning of the eFTI ecosystem, identify essential functionalities and areas that are still unclear, gauge the complexity of the entire system, and present different alternatives to minimize complexity as much as possible. At this stage, the solutions described in this document are merely proposals, and nothing is confirmed.
Principles
For guidelines, refer to S01E01. It is important to keep in mind that eFTI jargon may appear suddenly and without mercy at any point. If this happens, consult your glossary or use the appropriate search bar to find the definition and alleviate your lexical anxiety, as if offering garlic to an over-ambitious vampire.
eFTI dataset or eFTI data are used interchangeably to refer to the same concept, which is a 'property' involved in the transportation of goods. It is important to note that the definition of the eFTI dataset is currently being developed by the DTLF. eFTI data can represent both:
- A Freight Forwarder (with their name, ID, address, and website).
- A means of transport (a ship and its Lloyd's code, an aircraft and its empty weight, a train and its braking system).
- Goods (their description, HS code, IMDG code if applicable, etc.).
- A port (its city, its UNLOC code, its role—is it a port of unloading, loading, transshipment?).
- An event (unloading? Loading? Stuffing? Unstuffing? Docking? When?).
One of the ongoing issues, which is not discussed here due to a lack of information, is how to break down all this data and how to link it from the perspective of the eFTI data model. If a commodity has several IMDG codes, how should this be managed? If the contents of a container involve several freight forwarders, several consignees, and several shippers, how should this different information be linked?
On this subject, FEDeRATED has published its semantic/ontological model. It's a bit austere but it allows us to visualize how the different objects that could be manipulated on eFTI platforms are articulated (conditional, this model is not authentic at this stage).
Components
Eco Actor, competent authority & access points
Let's take an economic actor, whom we will call Bernard, and a competent authority, whom we will call Corine. Bernard will use an eFTI platform to provide the information required by Corine. Corine will use another system to process Bernard's data: an Access Point (AP), possibly connected to a National Access Point (NAP). To know that Bernard is Bernard, we need authentication mechanisms. To know that Corine has the right to stamp the document, we need authorization mechanisms.
The eFTI platforms are at the heart of the matrix. All data is stored, traced, and modified there. The access points serve as intermediaries to facilitate Corine's access to the eFTI platforms. Bernard communicates with his eFTI platform, while Corine speaks to her access point, which in turn communicates with the national access point. Since there will be multiple eFTI platforms, a mechanism must be in place to help Corine locate where Bernard's data is stored. The National Access Point (NAP) identifies and communicates with all certified eFTI platforms (Note: Certification is an important aspect that will be discussed in the next episode).
When we talk about eFTI data or information (eFTI dataset), we are talking about the transport of a good from point A to point B through a contract. In common cases, an eFTI dataset is either a shipment or a good. To locate the eFTI dataset in the ecosystem, as Corine wishes, each shipment is given a unique identifier and it is this identifier that the access point uses to query the eFTI platforms. The immediate, heavy, and implacable consequence is that for a shipment in transit, the transport data may be hosted on platform A and the goods data on platform B.
If you think this is confusing, you haven't seen anything yet. But don't worry, we won't bore you with 300-page technical specifications that require a degree in cryptography. We're committed to making eFTI accessible and user-friendly, without sacrificing accuracy or efficiency. So let's leave the jargon behind and focus on what matters: a seamless, secure, and transparent supply chain ecosystem that benefits everyone involved. And let's be happy, because the time of ARPANET brochures is over, today everything is more beautiful.
What form will the Access Points take? What form will the national Access Points take? Will the Competent Authorities share Access Points or will each Competent Authority have its own Access Point? These are questions that cannot yet be resolved and that will be at the heart of the implementation of tomorrow's IT infrastructure. Another management issue is the identity of the entities that will certify and accredit the new Access Points and National Access Points, as well as the location where the certificate will be stored.
NAP and Certificates
If they add one more intermediary in the eFTI chain, the National Access Points have several advantages. It knows all the eFTI Platforms and their public certificates and can easily communicate with them. It knows all the Access Points that depend on it and their public certificates. Conclusion, being at the crossroads:
- It can serve as a router between the constellation of eFTI Platforms (managed by private actors, and therefore potentially operating independently of states) and the constellation of Competent Authorities (managed by states but specific to each state).
- It can stop erroneous requests (e.g., invalid certificate) from one constellation before they pollute the other constellation.
- It can guarantee data integrity through cryptographic mechanisms (which use the aforementioned certificates).
No tricks with cryptochats: we are dealing here with public-key cryptography, or asymmetric cryptography, an ancient mechanism (1976) that allows two parties to guarantee the confidentiality of their exchanges. For example, an eFTI platform communicates with the NAP by encoding the message using the NAP's public key (i.e., accessible and known to all), and the NAP decodes the message with a private key (i.e., known only to the NAP). Even if a third party intercepts the message between the eFTI platform and the NAP, they will have in their hands a jumble of gibberish that is far more convoluted than the specifications of the eFTI's functional architecture and will not be able to decode the content without the NAP's private key.
Authentication & authorization mechanism
It is the Access Point or the National Access Point that will integrate this mechanism. As soon as a Competent Authority connects to an eFTI Platform, it is allocated a token that identifies it and gives it access for a specific period, all against the backdrop of a cryptographic mechanism, this time the NAP encodes with the public key of the eFTI Platform which decodes with its private key. Hence, once again, the interest in aggregating the transit of connections in the NAPs limits the number of actors involved in the security aspects.
The authentication mechanism secures the connection phase to the ecosystem, while the authorization mechanism determines what each user can or cannot do within the ecosystem. For each shipment, any user (such as an economic actor or competent authority) will have one or more roles. These roles allow the user to either read or edit a shipment and also determine which data the user has access to (such as eFTI data or eFTI dataset). For example, as an Economic Operator, I may have the right to edit a container's unloading date without being allowed to view the contents of the container. By default, the Competent Authority will have read access to the shipment, but the searchable data will be in the hands of the shipment owner.
It is only the owner of the shipment who assigns the roles and can change them at any time. In other words, if I am not the owner of a shipment and I can do something on it at a given moment, I may not be able to do anything a few moments later if I am no longer concerned by this shipment. To spice things up, the owner can decide to give a delegation to a third party, this third party will then be able to create and edit data on behalf of another.
In addition to these two mechanisms that fulfill the eFTI regulation specifications, a third mechanism is envisaged for performance reasons: the update notification.To avoid multiple actors connecting to the eFTI Platform to know the status of a shipment, a notification system within the platform will inform concerned parties when an event occurs that moves the shipment forward in the chain, such as additional cabotage information.
"Discovery" mechanism
During our digressions, Corine is still looking for Bernard's equipment. For that, we consider two solutions for the implementation of the unique identifier:
- The URL (Uniform Resource Locator) which is aptly named
- The UUID (Universally Unique Identifier), which also describes it quite well.
URL
Concretely, if we use a URL, we will manipulate this kind of string: https://www.IT-HHJUO-12.efti.eu/045484cc-9e15-11ec-b909-0242ac120002/ [Consignee]
If everything is in place and:
- I am registered on the eFTI IT-HHJUO-12 platform.
- I am authorized to view (and possibly edit) the shipment with the ID 045484cc-9e15-11ec-b909-0242ac120002
So I can view the service at this address, which will return, for example (completely fictitious example that does not follow any specification).
{
"economic-operator": {
"type": "Consignee"
"id": "1234589-87",
"name": "Jean-Jacques Codeman",
"address": {
"country": "FR",
"city": "Trouville",
"street": "Rue Saint Paul de Métatarse"
}
}
}
This allows me to manipulate data in order to enrich myself and my information systems, or to contribute to enriching the downstream information chain from my position.<br>
This mechanism is based on the mechanism that has been running "Internet addresses" for a long time, so it is robust, cheap, and easy to implement. One DNS, and rollover. The most important weakness is that if an eFTI platform changes its ID - "Often, platform changes" - the URL changes and previous URLs are invalid.
UUID
The principle is quite similar, but with a couple of differences. Firstly, a URL is global while a UUID is local. This means that we can be sure that a URL is unique at a web-scale level, while two UUIDs can exist that designate different objects (although the UUID nomenclature makes this unlikely - similar to the unlikely circumstances that led to the Fukushima accident). The second, more structural difference, is that each eFTI platform needs to maintain a registry of the UUIDs for all the eFTI datasets it contains to create a UUID repository. At first glance, this may seem like a more tedious solution to set up, especially considering that there are already other registries in play (see below).
Access Point Certificate Registers
There are two options for managing public certificates/keys for Access Points (implying checking the validity of Access Points at any time):
- Access Point Certificate Registry: An additional tool will serve as a centralized registry—and therefore potentially an isolated point of weakness in the ecosystem—where National Access Points—and eventually other tools—can verify that the Access Point is properly referenced and certified.
- Interconnection of National Access Points: No additional registry this time. Each National Access Point encodes the certificates of the Access Points that depend on it, and each National Access Point knows the public keys of the other National Access Points. This implies that at some point in the process, the National Access Point knows that the Access Point certificate was issued by a certified National Access Point. The certifier must also be certified, after all...
Do you want to be more productive?
Actions
Here is an informative and laconic list of actions that will be the heart of the eFTI ecosystem and the daily life of the actors of the chain. Each action has a consequent description to take the measure of all the steps, mechanisms, and actors involved. We bet that this will be the subject of the next episode.
For economic operators:
- Connecting to an eFTI platform: The crucial step.
- Creation of eFTI data: The action that makes him the owner of the data (data holder).
- Linking two eFTI datasets: When two eFTI datasets interact, a link will need to be created between them (not necessarily on the same eFTI platform!).
- Modification of eFTI data (direct data or linked data): This is the whole point of the eFTI ecosystem—the data is ALIVE!
For the competent authorities:
- Access to eFTI data (with or without an access point): Added value if it is digitized → Everything is available from a PC.
- eFTI metadata request: For example, the nature of the shipment in a truck based on the truck's license plate number → This avoids stopping the truck.
For both:
- Notification of changes to eFTI data: Inform interested third parties that transport is progressing or that formalities are advancing without them having to refresh their web page themselves.
Architecture proposals
To orchestrate everything, the open field of possibilities and the multiplicity of use cases and situations compel us to list everything, ensuring the viability of the ecosystem in all circumstances, especially in the event of exceptions.<br>
When we talk about use cases, we can work with three variations:
- Single commodity, single shipper
- Multiple commodities, single shipper
- Multiple commodities, multiple shippers
The variations in terms of infrastructure can be broken down into five scenarios. Each scenario makes it possible to carry out one of the possible actions within the eFTI ecosystem, but not necessarily in all configurations. All of these are working hypotheses that will have to be fixed one day (URL or UUID? Existence of a NAP or not?).
- Scenario 1: NAP with Pull from CA → "Classic" case where the Competent Authority goes through a NAP connected to the Search Mechanism (DNS server) in order to retrieve eFTI data from an eFTI platform.
- Scenario 2: NAP with Push metadata → Configuration in which eFTI platforms feed (push) metadata (truck license plate, case of transport of hazardous materials or waste) into NAPs to enable, for example, generic searches by a competent authority for inspection purposes or by firefighters in an emergency.
- Scenario 3: No access point → No AP, no NAP, in other words, the competent authorities must authenticate themselves directly on each eFTI platform, and each eFTI platform must regularly check for updates to eFTI data from other eFTI platforms linked to its own eFTI data.
- Scenario 4: NAP and Update dispatch mechanism → Scenario 1 with the addition of the update notification mechanism.
- Scenario 5: Share encrypted eFTI dataset → A configuration that relies on the update notification mechanism and eFTI data encryption so that each platform hosts all eFTI data relevant to it (in encrypted form for linked eFTI data originating from another platform).
Conclusion
We are in the middle of the difficult task of discernment and technical choices. Without a crystal ball, the DTLF must convince itself and the logistics community of the best solutions to adopt on an immeasurable scale, given that it concerns the entire European Union. In this daunting task, initiatives such as FEDeRATED and FENIX are invaluable. They provide opportunities to fuel the discussion, shape ideas, and test potential solutions to meet the demands of the holy eFTI and its requirements.
