Using uPort For Authentication On Blockchain To Improve Standards On The Food Logistics Chain

Zach Miller


Supply chains – made up of individual suppliers, shippers, warehouses, and customers – are extremely complicated conglomerates.  When something goes wrong along a supply chain, knowing where and how a shipment went bad can be a huge use of time and energy.  This is especially true in the food logistics industry. While modern consumers may not think too much about the journey food products take before ending up on our plates, ingredients travel thousands of miles through multiple stages on the logistics chain.

In the case that a bad batch of produce is discovered, traditionally it has been challenging to highlight which stage of the logistics process was the root of the problem. Did the farm produce a contaminated batch? Was the produce stored at the right temperature during different stages of transportation and storage? Or has the restaurant or store simply prepared the food badly?

Restaurants and stores risk ruining customer trust and facing lawsuits if they cannot ensure that the products they sell adhere to the standards of quality legislated by multiple jurisdictions across a complicated network of local, national, and international regulations.  This means that once a trustworthy supplier is found, switching to a cheaper one or trying someone new can be far too risky to even attempt.

Aiming to tackle this multifaceted problem, Microsoft partnered with Hitachi‘s Application Services Division to build out a sample infrastructure together, leveraging the power of blockchain.  Such an infrastructure could ensure that suppliers, carriers, and distributors are more accountable for producing, storing and serving food in a safe manner.

Blockchain technology is offering a new level of accountability across a range of industries. From storing energy companies’ emissions data to recording the source of raw minerals, wood, and metals, the tamper-proof nature of data stored on the blockchain is making it more difficult for individual players to cut corners and use unethical practices.  It also offers a means of increasing transparency in the food logistics industry, allowing restaurants and stores to put their faith in new suppliers and distributors.  By leveraging a publicly distributed ledger, the supplier, carrier, and restaurant can effectively work together to get the best food possible to customers – without risking exposure to bad actors along the way.

Using blockchain, individual players on the logistics chain can be assigned an identity that, while tied to the underlying chain, is otherwise interchangeable.  For example, while we used uPort, another app that implemented the same callbacks and protocols would work just as well.  This identity off-chain could be used to take ownership of a crate of goods. The individual can sign for the goods received and record a picture of the item, which should include a thermochromatic seal. The seal changes colors once a certain temperature is reached, and won’t change back. Anyone with access to the chain can audit the information stored and catch bad actors.

Challenges and Objectives

We needed a way to track products as they changed hands along a complicated network of organizations.  The solution needed to be versatile – anything platform-specific wouldn’t fly, since we needed most organizations to be able to pick this solution up easily.  Additionally, because of the nature of supply chains, one actor in the chain might deal with two competitors at any level.  While we ended up with a local solution, a long-term centralized store of trust was a luxury we couldn’t afford.

This unique set of prerequisites meant blockchain was a perfect fit.  For this discussion, suffice to say that blockchain is immutable, decentralized, and trusted by those who use it.  While these statements come with some qualifiers, we won’t be delving into those nuances here.

Our approach was to build a web page that could be accessed via mobile or desktop.  This web page would use a public blockchain as a back end, storing ownership immutably.  The proof of concept would only deal with proof and transfer of ownership of generalized objects.  A theoretical implementation would include a picture stored in a hash addressable storage network (IPFS/Swarm) and that hash being stored on chain.  A peer would just have to look up the hash of the image via its address, compare it to the hash of the image received, and verify they match.  However, we wouldn’t deal with actual pictures on chain just yet.  This approach was versatile, decentralized, and secure.

Since blockchain is still a technology in its infancy, we knew that good design principles would be hugely important to the hack.  Blockchain as a concept is a highly secure system, but only if it’s used correctly.  Badly written contracts are still contracts, and we knew that secure and durable contract design would be our biggest challenge during the hack.

General Flow

Going into the hack, there was some interest in blockchain as a technology, but there wasn’t much expertise in this area.  The user for this solution would be low-income earners, including farmers, in Southeast Asia.  Given this, a low-cost system that could be built up quickly and distributed easily was required.  We suggested the use of uPort, a smartphone app.  This was a great fit for us, since smartphones are nearly ubiquitous. In Vietnam, for example, smartphone penetration is over 70%, which means that an app-based solution would be able to support the majority of use cases, without any additional infrastructure investment.  While Hitachi had already started working with blockchain, with Microsoft’s help they were able to get their idea fully realized in a proof of concept.  Additionally, we were able to provide vital insights into best practices in using the chain.
In general, the flow that we ended up with from farm to table follows the path outlined in the following chart:

Image detailedusecase

In this example, a farmer creates a shipment and registers it on the chain.  When a carrier picks it up, they initiate a transfer with the farmer and take responsibility for the package on the chain.  Additionally, they could include a picture of the state of the seal to verify that it’s been added to the package and that it hasn’t risen above the allowed temperature during storage.
They take the package to a warehouse in this example, which puts another transfer on the chain. The warehouse can add that same info, and so can the second carrier, who finally takes it to the restaurant.  Not only is there undeniable proof of where a bad shipment went wrong, but if the patrons want (and the restaurant made their view of the chain available to them), they could trace the history of their food all the way back to the farm where their produce came from, since all of that information is saved on the chain.

Proof of Concept (PoC)



Since we knew that the system was going to be used by multiple users within the supply chain, we of course needed a way to associate users with steps on the chain.  That way, when a user transferred goods to another user, we would be able to follow that transaction through the chain as a transaction between two different addresses, each address representing a user.  On top of that, we have to associate users with sessions within a web browser, in case users want to access the page from desktop.  We wrote a webpage that interacts with a blockchain to allow an actor to create or take ownership of a crate of goods, with approval needed from the current owner if there is one.  First, the user would create a browser session and associate it with their identity as stored in the uPort app.

Image login 1

To do this, the user would be presented with a QR code.  The QR code is a graphical representation of a token, created to be associated with this session.  The web service uses a local data store to keep track of this session information.
app.get('/login-qr', async function (req: any, res: any) {
    const claims = {
    await _uport.LoginQrCode(res, await _self.tokens.Sign(claims));

All that would be left for the user to do is to scan the QR code they’ve been presented with (they could also simply click the QR code if they’re accessing the page from mobile).

Image login 2

Upon scanning the QR code, the user would receive a notification on their phone, letting them know which application they’re about to interact with, and allowing them to approve or deny the attestation.  The user would verify who they’re working with, and the web client would associate the user’s identity with the current client session.

Image login 3

Every QR code generated encodes a callback with a token associated with the user and desired action.  This QR code in particular, as stated, was designed to associate the session on the browser with the user’s information from uPort via callback on the blockchain.  To observe when this has happened, the browser polls the web service to see when a login request comes in.  With each request, the browser checks if that request contains some known user’s information to associate with the session created.  If it’s a match, the browser can proceed, and will grab information from the web service about other known transactions.  In the future, there is an opportunity to build out functionality on chain.  We realized that things like membership fees, subscription levels, and more could be stored on chain, but for now we don’t actually have to have login associated on chain.

Package Creation

Now that the user has logged in, we wanted them to be able to do something.  Namely, this would be the point where a supplier in the supply chain would be able to add new goods to be tracked on the blockchain.  In this example, the supplier has just grown and packed a new shipment of cucumbers.  While ideally they’d include a picture of the cucumbers with a thermochromatic seal that was mentioned earlier, for the proof of concept we just built out a system that could track transfer ownership through a system.

Image login 4

We built a simple UI to allow a farmer to create a package of some product.  Upon creating the package, the farmer is presented with a popup on the uPort app associated with the identity associated with this browser session, asking if they’re sure they want to create a new package.

Image login 5

We needed creating packages to be easy and secure.  On top of that, this was a perfect fit for our need to be able to verify every step of the way.  Once the farmer hits approve, the transaction would be signed with the private key within the uPort app.  That signature would then be sent back to the service, which submits the transaction to a node in the Ethereum network.  This submission is relayed to other nodes, and the transaction is added to a new block on chain.  An example of one of these transactions on chain can be seen here on

Package Transfer

The only other piece that we wanted to prove out on chain was to be able to transfer a package to another user.  To do so, we built a UI flow around this, allowing us to setup a transfer QR code to be shown to another organization within the supply chain.  Since this is a permanent transfer of ownership, we made sure to make the current owner confirm that this was indeed the package they wanted to transfer.

Image transfer

This creates and displays another QR code.  Here again, the browser watches the public chain to make sure it understands when and where that transaction takes place.

public async MonitorTxQueue(const txHash): Promise<any> {
        const receipt = await this.web3.GetTransactionReceipt(txHash);

        if (receipt !== null && receipt.blockNumber) {
  `Pushing TX for Package ${this.tsList[txHash]}`);
            const packageId = this.tsList[txHash];
            const pkg = this.packages_cache[packageId];

            pkg.transaction = txHash;
            pkg.contractAddress = '0x' + this.GetContractAddress(receipt);

While the browser watches the chain for updates, the user is presented with another QR code to scan.  This time, the recipient would scan the QR code and get a notification ensuring that they’re taking ownership of what they’re expecting.  In the future, they could include information about the pickup (such as the date and time) and also a picture of the package itself, to ensure that the chromatic seal is applied and associated with that crate.  This is especially useful if this transfer process is automated: since a human wouldn’t be checking each and every seal at each and every transfer, storing all the information on the chain automatically would mean that anyone could trace the package back and see where exactly the seal was broken.

Image transfer 2

Once the carrier accepts, that information goes onto the chain and the transfer is complete. The web browser – which again, has been watching the chain for the completion of this transfer – updates its internal model of who owns the package.  And voila!  We’ve transferred a package from supplier to carrier, all verifiable yet decentralized, sitting on a blockchain.


Once this demo was built out, Hitachi had a working proof of concept for blockchain-backed proof of ownership of packages, as well as a way to transfer those packages from an owner to a recipient.  Our solution also offers the exciting opportunity to bring OAuth to the blockchain. We are working to understand what a general solution for this might look like, and considering how we might build out an open source library that fits the specs of OAuth 2.0 for blockchain.  In particular, the flow that we created resembles Google’s OAuth for devices flow, and we believe that this solution could be transformed into a library for OAuth on blockchain.
Today this solution lives here. We’d appreciate any feedback, comments, concerns, questions, and ideas for what this project could use to expand.


Transaction Latency

In this example, every time a QR code is displayed that turns into a transaction which is mined on the chain.  This can be slow.  It takes, at the time of writing, somewhere between 15 and 30 seconds to mine a block. For a traditional application, comparable transactions take nowhere near this amount of time. Also, if packages are added individually to the chain, this can mean that the time to transfer a truckload of goods from a carrier to a restaurant may increase quite a bit.
This can be mitigated by reducing the number of times a block is introduced to the chain. In particular, two parties transferring could perform multiple transactions together off chain, logging them to the chain afterwards.

Sacrifices for the demo

In this demo, we manually scanned QR codes with our phones. In reality, this could be automated to a certain degree. We did play around a little with adding links to QR codes so that the users could just interact with mobile pages.  At the end of the day, carriers won’t be dealing with unitary crates of cucumbers, but with truckloads of them at a time, and having some sort of sidechain would be a great way to minimize the number of times that a transaction hits the chain.  This was not explored in this demo.
While pictures were part of our ideal flow, this wasn’t built into the demo either.  Initially, we stored pictures on chain, but this amount of information would be very expensive to store.  Instead, a different solution would have to be built out for picture storage.  When pictures are generated, they’d be hashed, and that hash would be stored on chain.  This, along with other useful metadata, was not built into the demo, due to time constraints.


Discussion is closed.

Feedback usabilla icon