SecuWeb Demonstrator: Food Supply Chain

---

Table of Contents

• Introduction
• Technical Overview
• Prerequisites
• Instructions
  • Automated Smoke Test
• Use Case: Product Shipment
  • Walkthrough
    • Farmer's Perspective
    • Transporter's Perspective
    • Authenticated as Packager
• Development
  • Testing
    • End-to-end smoke test
• License

Introduction

This PoC demonstrates a platform that enables controlled, permission-based data sharing using Solid protocols, combined with guaranteed data immutability through a Blockchain. As a result, organisations to share data in a granular, standards-based way (via Solid Pods) while ensuring that the integrity and history of that data is cryptographically secured on a distributed ledger.

We apply this platform to a food supply chain use case, where the ability to trace products with both fine-grained access controls and tamper-proof records can substantially improve processes such as food recalls. Each actor in a food supply chain—farmers, processors, transporters, retailers—stores their operational data in their own Solid Pod. Key events (e.g., harvest, processing batch, shipment) are anchored on the blockchain. Downstream actors can access only the specific data they are permitted to see, while regulators or auditors can trust the immutable ledger trail to verify the chain of custody during a recall or safety investigation.

Technical Overview

This repository glues to together five main components:

1. Solid Pods (hosted on a Community Solid Server (CSS))
2. A Blockchain development environment for anchoring Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) (submodule: secuweb-anchors)
3. A Verifiable Credentials service (submodule: vc) that handles setup, issuance, verification of VCs.
4. Linked Data Viewer (Miravi)
5. The use case flows (see src/flows)

Prerequisites

• nvm
• npx

Instructions

Pull submodules.

 git submodule update --init --recursive

Install.

npm i

Setup and start Miravi.

# CLI A
source env-localhost
./scripts/setup/finalize-setup.sh
cd ../food-supply-chain-miravi/main
npm run dev

Note

Miravi's configuration can be found here.

Spin up a clean CSS.

# Terminal B
# At repository root
rm -rf css/root
npm run pod

Start the Hardhat node.

# Terminal C
cd secuweb-anchors
nvm use
npm i
npx hardhat node

Redeploy contract and at least one event (in this case: registering a DID). Then, start the verifier service.

# Terminal D
cd secuweb-anchors
npm run setup
npm run server # start verifier service

Run flow.

# Terminal E
# At repository root
# Install vc submodule
cd vc
npm i
npm run build
cd ..
# Create each actor's VCs and store them on their pod
./src/flows/load-actor-data-into-solid-pods.sh
# Anchor each actor's VC on the chain
./src/flows/register-products-and-shipments.sh

Explore chain transactions.

# Terminal F
npm run explore

Automated Smoke Test

The setup steps above can be validated automatically with:

npm run test:readme-setup

This runs a smoke test for the multi-terminal flow (CSS + Hardhat + verifier + flow scripts), and stops all background services automatically at the end.

To also include the Miravi setup/startup checks:

npm run test:readme-setup:viewer

Note

Logs are written to local-run/readme-smoke/logs.

Use Case: Product Shipment

Actors store various data on their Solid Pod, for example:

• A Farmer stores product details about its produces, shipment details, etc.
• A Transporter stores event data, e.g., inbound/outbound shipments.
• A Packager stores packaging details of received goods.
• A Retailer stores inbound receipt data and verifies incoming packaged goods.

Specific to the use case of product shipment, we highlight the following aspects:

• A Farmer ships a product to a Packager using a Transporter.
• The Packager ships the packaged batch to a Retailer using a Transporter.
• The Farmer shares product details with the Packager, but not with the Transporter or Retailer.
• Shipment and transport-event records are readable only by actors involved in that shipment leg.
• The Retailer can verify provenance and delivery using packaged-batch, shipment, and receipt data.

The table below summarizes read access per VC resource (owner means the actor that stores the resource on its own Pod):

VC Resource	Farmer	Transporter	Packager	Retailer
farmer/products/vc/product-x.jsonld	owner	-	read	-
farmer/products/vc/product-y.jsonld	owner	-	read	-
farmer/shipments/out/vc/shipment1.jsonld	owner	read	read	-
farmer/shipments/out/vc/shipment2.jsonld	owner	read	read	-
transporter/transport-events/vc/pickup-shipment1.jsonld	read	owner	read	-
transporter/transport-events/vc/delivery-shipment1.jsonld	read	owner	read	-
packager/products/vc/packaged-batch-001.jsonld	-	-	owner	read
packager/shipments/out/vc/shipment3.jsonld	-	read	owner	read
transporter/transport-events/vc/pickup-shipment3.jsonld	-	owner	read	read
transporter/transport-events/vc/delivery-shipment3.jsonld	-	owner	read	read
retailer/shipments/in/vc/receipt-shipment3-vc.jsonld	read	-	read	owner

Walkthrough

This walkthrough guides through the different data views that can be obtained from the perspective of different actors.

To start, navigate to the data viewer (Miravi) using http://localhost:5173.

Farmer's Perspective

Click on the profile button, then "Login".

Enter the URL of the Solid Server: http://localhost:3000 and click on "Login".

Enter the Farmer's credentials (info@farmer.com, farmer123) and click "Log in".

Click "Authorize" so that Miravi can access data on the Farmer's Solid Pod.

You will arrive at the following landing page:

The Products-view (in left panel) shows product details.

Source information can be viewed by clicking on the information-icon on top of the table with product detials.

The source information shows the data sources that were queried in the selected view.
Moreover, the source information panel shows the following properties for each queried data source:

• Authentication needed: Whether the data source is public, or authentication was needed.
• Fetch status: Indicates whether data retrieval was successful or not.
• Verified: Indicates whether the data source's digital signature is valid. Clicking the question mark initiates this data integrity check, showing whether or not it was successful.
• Chain Verified: Indicates whether the data source's anchored hash (i.e., the hash on the blockchain) matches the locally computed hash. Clicking the question mark initiates this data integrity check, showing whether or not it was successful. In case of succes, the data source's on-chain hash is shown.

Transporter's Perspective

Note

The following assumes the user is authenticated as Transporter

Selecting the Products-view shows no results (as precluded by the use case).

However, the Transporter does have access to the shipments in which it was involved. For example, the shipments requested by the Farmer.

Authenticated as Packager

Note

The following assumes the user is authenticated as Packager

The Packager needs to know the details of the products it has to process (e.g., for product labeling).

In contrast to the Transporter, the Packager does have access to the product details.

Development

Testing

End-to-end smoke test

The following command runs a smoke test that executes this README's instructions (CSS + Hardhat + verifier + flow scripts), and stops all background services automatically at the end:

git submodule update --init --recursive
./scripts/test-readme-setup.sh

To facilitate debugging, the smoke test logs are written to local-run/readme-smoke/logs.

License

This code is copyrighted by Ghent University – imec and released under the MIT license.