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.

‍

‍

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.

‍

‍

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.

‍

‍

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 forwarder (with his name, an identifier, an address, a website).
• A means of transportation (a ship and its Lloyd's code, an airplane and its empty weight, a train and its braking system).
• A commodity (its name, its HS code, its IMDG code if applicable...).
• A port (its city, its UNLOC code, its role - is it a port of discharge, loading, transshipment?)
• An event (unloading? loading? Stuffing ? Unstuffing ? docking? When?).
  One of the issues at stake, but not mentioned here for lack of information, is to know how to cut all these data and link them from the point of view of the eFTI data model. If a commodity has several IMDG codes, how do we manage it? If the content of a container concerns several forwarders, several receivers, and several shippers, how do we articulate this different information?

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).

‍

‍

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.

‍

Pepper burns but maggot lives in it. Ivorian proverb

‍

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 & certificates

‍

Yes I know I'm paranoid, but just because I'm paranoid doesn't mean they're not all after me. Pierre Descodes facing an avalanche of eFTI

‍

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:

• As a router between the constellation of eFTI Platforms - which are managed by private actors and can potentially operate independently from states - and the constellation of Competent Authorities - which are specific to each state and managed by the states themselves - the National Access Points have the advantage of knowing all the eFTI Platforms and their public certificates, as well as all the Access Points that depend on them.
• It can stop erroneous requests (e.g. invalid certificate) from one constellation before they pollute the other constellation.
• It can guarantee the integrity of the data via cryptographic mechanisms (which use the above-mentioned certificates).
  No trickery in crypto chats, we are here in the context of "Public-key cryptography" or asymmetric cryptography, an antediluvian mechanism (1976) that allows two interlocutors to guarantee the confidentiality of their exchange. For example, an eFTI platform communicates with the NAP by encoding the message with 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, he will have a galimatias far more devious than the eFTI functional architecture specifications. He 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) that bears its name
• The UUID (Universally Unique Identifier) which wears it quite well too

‍

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 platform IT-HHJUO-12
• I am authorized to consult (possibly edit) the shipment which has the identifier 045484cc-9e15-11ec-b909-0242ac120002
  Then I can consult the service at this address which will return me for example (a totally fictitious example which 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 where national Access Points, or other tools in the future, can verify that an Access Point is properly referenced and certified. However, it is important to note that this registry may potentially be an isolated point of weakness in the ecosystem.
• The National Access Point Interconnection mechanism allows each National Access Point to encode the certificates of the Access Points under its control, and to know the public keys of the other National Access Points, without requiring an additional registry. This implies that, at some point in the process, each National Access Point can verify that the Access Point certificate was issued by a certified National Access Point, which in turn must also be certified.

‍

‍

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 most important 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 have interactions, we will have to create a link between them (and not necessarily on the same eFTI platform!).
• Modification of eFTI data (Direct data or linked data): That's the whole point of the eFTI ecosystem - Data LIVE!
• For the competent authorities:
• Access to eFTI data (with or without Access Point): Added value if it is of dematerialization → Everything is available from a PC.
• eFTI metadata query: e.g. nature of the shipment in a truck from the truck's license plate → It avoids stopping the truck.
• For both:
• eFTI data modification notification: Inform the third party that the transport is progressing or that the formalities are progressing without him having to refresh his web page himself.

‍

‍

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 come to feed (push) metadata (license plate of a truck, case of transport of hazardous material or waste) within the NAPs to allow for example generic searches by a Competent Authority for a control or for firemen in case of emergency.
• Scenario 3: No access point → No AP, no NAP, i.e. Competent Authorities will have to authenticate directly on each eFTI platform. In addition, each eFTI platform will need to periodically check for updates of eFTI data from other eFTI platforms that are linked to its own eFTI data.<br>
• Scenario 4: NAP and Update dispatch mechanism → Scenario 1 with the addition of the update notification mechanism.
• Scenario 5: Share encrypt eFTI dataset → A configuration where we rely on the update notification mechanism and encryption of eFTI data so that each platform hosts all eFTI data relevant to it (under encrypted forms for related eFTI data that originates from another platform).

‍

‍

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.