The Digital Supply Chain of the Future

After building software at a major global ocean carrier for about half a decade, I decided this year to switch to a technology startup company. I had come across a particular set of emerging technologies, and the more I dug into them the clearer it became to me that they would define and revolutionize the future of digital supply chains. Passion took over; I just had to be part of driving these revolutionary technologies forward.

This article aims to explain to supply chain participants the future which these technologies will enable. In particular, we will explore what they do, what brought them about, how they fit together, and how they can be applied to our industry.

The Present

Today, supply chain operations are largely based on manually handled documents: PDFs, pictures, Excel sheets and even physical paper. These require human processing — vast amounts of emails are exchanged to enable the flow of goods.

EDI messaging is also very prevalent for automatic data processing. However, EDI connections have generally been over-customized for decades, which shifts the manual burden from business processing to EDI maintenance. EDI is the technological legacy of the industry: we are forced to respect it, but we all wish it would go away.

In recent years, we’ve made steps towards HTTP-based API integration, exchanging JSON-encoded data. Forward thinkers have exposed their business services this way, allowing customers to integrate with modern tooling and prevalent programming languages. Industry standard groups such as IATA, DCSA, UN/CEFACT play an important role guiding the industry ahead.

The Future

The macro trend towards API adoption is clear, but technologies continue to evolve. Particularly, Linked Data, Verifiable Credentials, and Decentralized Identifiers are emerging standards which will revolutionize all industries of trade.

Linked Data

Let me start with a real example from two of my favorite ocean carriers’ developer portals: what CMA-CGM calls `voyageCode` on their schedules APIs, Maersk calls `voyageNumber` on theirs. Humans can infer that `voyageCode` and `voyageNumber` both mean the same thing, but computers need very explicit instructions and can only connect these terms with human assistance. This puts the interpretation burden on the developer tasked to integrate to these APIs. Interpreting two APIs doubles the risk of making incorrect interpretations.

Adding more carriers means the complexity and risk increases further. When we multiply that risk by the thousands upon thousands of customers integrating these APIs we come to a sad conclusion: every developer is doing the same costly repetitive work. And since we all have different backgrounds, language, cultures and skills, we invariably interpret API intention and meaning differently.

This is the challenge which JSON Linked Data addresses. JSON-LD is a W3C standard which acts as a “layer” on top of JSON and literally adds context to the data. The context defines web Unique Resource Identifiers (URIs) for each of the terms used in the API.

The common meaning behind the above voyage example is in fact formally defined by UN/CEFACT. The URI for this definition looks like this: https://service.unece.org/trade/uncefact/vocabulary/uncefact/#scheduledIdentificationId. This URI is not exactly sexy, but computers love (unsexy) unique identifiers. Now, using JSON-LD CMA-CGM can define `voyageCode` by pointing at the UN/CEFACT URI. Maersk, in turn, can point their `voyageNumber` to the same UN/CEFACT URI. Now there’s no interpretation left for the developer. Both terms are explicitly defined and can be directly consumed by computer code.

JSON-LD switches the responsibility of determining meaning from the many consumers to the one single provider — where it belongs!

Linked Data deals with semantics: the meaning of the exchanged data. Ensuring that we “speak the same language” is the very essence of standards.

Verifiable Credentials

Verifiable Credentials is a W3C standard for cryptographically signing JSON data. Explained very briefly, encryption means mathematically signing a chunk of data with a private key known only by you. Subsequently, using your public key anyone can verify that the chunk of data indeed comes from you.

Cryptography is nothing new, but it is traditionally applied on the transport layer (HTTPS, for example); Verifiable Credentials bring cryptography to the data-layer. Instead of keeping track and remembering “I received this piece of data from that party via this channel”, at any point in the future you can verify where data came from and trust that it hasn’t been tampered with.

There is a reason why traditional paper-based contracts are printed on letterhead paper and are signed: it’s so that the agreement can be proven in the future. The idea of just jotting down contractual data on a white piece of paper and trusting its validity based on the courier who carried it is absurd. Nonetheless, that is exactly what happens with a standard API call over HTTPS. This also explains why paper (physically as well as PDFs) is still so widely used in supply chains. The fundamental requirements remain while technology is catching up.

A Verifiable Credential is a container for data, which can be whatever the API call requires to support a business use case. The container adds `issuer` and `proof` elements. `issuer` captures the identity of the entity issuing the data, typically in the form of a Decentralized Identity (more on that in the next section). `proof` contains the cryptographic material needed to verify the data, particularly the “signature” string which is generated based on the data and the issuer’s private key. Anyone receiving this “contained” data will know who it came from and can verify that the data is how the issuer intended it to be.

Again, the paper analogy is useful: `issuer` corresponds to the pre-printed company letterhead on paper contracts while `proof` corresponds to the analogue signature. This analogy falls short, however, since a cryptographic signature is many times more secure than an analogue signature on paper.

I do want to quickly mention what Verifiable Credentials are not: a Verifiable Credential does not deal with data access management. Sensitive data still needs to be securely handled when sent (in transit) and stored (at rest). Also, a Verifiable Credential does not deal with originality. Verifiable Credentials can be copied and distributed just like any other JSON file, every copy is tamper-proof and can be verified.

Verifiable Credentials couple trust with data.

Decentralized Identifiers

The third and final aspect deals with identity. Managing who is who is a massive undertaking all over supply chains. Every organization keeps registries of customers, suppliers, contractors, and employees. Essentially, everyone maintains a model of everyone else. This is an exponentially complex problem, computer science-wise. The total amount of effort that goes into keeping customer master data up-to-date is staggering, and costly mistakes are a standard part of operations.

Traditional digital identity is based around identity providers which lends out tokens that represent you. The identity provider typically knows nothing more about you than verifying a working email and checking that “you’re not a robot.” This falls way short of knowing and trusting a supply chain counterpart on a foreign continent.

Decentralized Identifiers turn the identity solution inside out. DIDs can be generated freely and can represent anyone or anything. They are trustless, meaning they don’t pretend to represent any sort of objective vetting; rather, trust is built from Verifiable Credentials. A DID is just an identity. DIDs are controlled by the holder of a private key, and additional keys can be associated with it to perform actions like authentication or signing Verifiable Credentials. Keys and DIDs are related, but clearly distinct aspects. So again: DIDs only represent identity.

There is no limit to what a DID can identify. The obvious examples are organizations and people, as explained above. They can also represent assets such as shipping containers, seals, boxes, vessels, or locations, and intangible concepts like bookings, agreements, transactions, or documents.

Here is an example of a DID: `did:web:transmute.industries`. DIDs are strings which always start with `did:`. What comes after depends on its type, its so-called DID Method. Just like a URL resolves a web page, DIDs resolve a DID Document. That DID Document carries public information relevant to the DID, notably its associated public keys. This way, anyone in the world can verify that someone claiming to control a DID indeed does hold its private key, or that a Verifiable Credential was indeed issued by the controller of the `issuer` DID.

There are a number of different DID Methods to choose from serving a range of requirements such as availability, confidentiality, censorability, and affordability, just to name a few. Some examples include `did:key` where the DID and its keys are consciously hard coupled (self contained, fast, simple), `did:web` where the DID Document is kept on a web server (tangible, transparent), and `did:elem` where the DID Document is kept on Ethereum (immutable, censorless).

So, an organization may control many DIDs. One could represent the organization itself and its geographic subsidiaries (`did:web` would likely be a suitable choice for these). But the same organization could also control DIDs representing, say, owned shipping containers and the seals applied to them (`did:key` would be a good choice here). As the DID controller, the organization can perform all corresponding actions such as proving ownership of assets and issue claims on behalf of legal entities.

Decentralized Identifiers put the digital identity of every supply chain actor in their own hands. It is the only globally scalable solution to a challenge faced by this truly global industry.

Bringing It All Together

Let’s bring together Linked Data, Verifiable Credentials, and Decentralized Identifiers to more closely examine the future of supply chain data flows. When combined, these three emerging technologies lead to semantically unambiguous data, well-managed identities, and claims based on trusted sources. Let’s imagine what the future would look like.

As a domestic buyer, I can remotely establish a trusted relationship with a foreign supplier. The risks inherently present in intercontinental trade are largely mitigated by the credentials which the supplier presents. These credentials prove government-issued company legality, long standing relationships with several known carrier brands, and show ethical and environmental certificates issued by established NGOs. I may not know the exact issuer of the environmental inspector, but I am also presented with an agency credential issued to that inspector from a global NGO which I do know. So, all the needed claims are issued by DIDs which I know and trust, or through a “trust chain”, which links back to trusted entities.

The products I purchase are given precise DIDs and their quality is inspected on-site by a trusted 3rd party. The manufacturer is also able to present credentials proving a degree of recycling and sustainable materials sourcing.

Since all documentation is completely digital, the carrier booking and export documentation processing is completely automated. Product DIDs are linked to a carrier consignment DID which cryptographically proves they have taken ordered goods into custody. I have chosen “slow steam, low emission” transport, so the consignment gets issued a reduced carbon-footprint credential which in turn links back to my products.

Upon arrival, Customs can easily build a holistic model of origin, commodity, provenance, transport routing risks, and factor in backgrounds of every party involved from the presented credentials. Fully automated, Customs can make near real-time risk assessments, duties calculations, and release determinations.

With the goods landed, I can flaunt the exact certificates of the ethical and low carbon premium choices which I made during production and transportation. Selective disclosure allows me to cryptographically prove this to my customers without revealing any other data elements from, say, the commercial invoice or bill of lading documents.

Linked Data, Verifiable Credentials, and Decentralized Identifiers are standards, comparable to the likes of HTTP or JSON. All these advanced use cases are cross-vendor interoperable, and each actor can freely choose whichever tool or software provider they fancy.

All data will eventually become verifiable. After all, why would you ever again settle for ambiguous data from vaguely identified sources?