Source-linked AI summary
Trustless Accountable Data Sharing for Supply Chains: A Reference Architecture and MoreMedDiet Proof-of-Concept
Michal Kit, Montassar Naghmouchi, Maryline Laurent, Badis Hammi, Hella Kaffel Ben Ayed, Mohamed Amine Hamdi, Jihene Khoualdi, Ilhem Abdelhedi Abdelmoula, Sami Sboui
TL;DR
Sensitive data exchange among heterogeneous, partially trusted supply-chain stakeholders creates challenges for transparency, privacy, and accountability. The paper proposes a permissioned-ledger, IoT, and SSI/VC reference architecture and demonstrates it through a MoreMedDiet proof of concept. A verified credential was presented to the next stakeholder in 130 ms, supporting the reported applicability of the design to real-world supply chains.
Problem
Heterogeneous supply-chain stakeholders must exchange traceability and quality data despite limited mutual trust and the need to avoid exposing commercially sensitive or personal information.
Method
The paper combines a permissioned ledger, IoT-based evidence ingestion, on-/off-chain data placement, smart-contract quality assurance, and SSI/VC-based access governance in a MoreMedDiet proof of concept.
Results
130 ms was achieved for presenting a verified credential to the next stakeholder in the supply chain.
Takeaways & Limitations
The design offers a reusable blueprint for controlled, auditable, privacy-preserving data sharing across multi-actor supply chains.
Takeaways & Limitations
The contribution excludes securing IoT devices and gateways and recognizes that auditors’ richer visibility can enable misuse of commercially sensitive information.
Abstract
from arXiv · showhide
Modern supply chains are increasingly dependent on the exchange of sensitive business data between heterogeneous stakeholders who do not trust each other. %under partial trust. Conventional integration approaches typically rely on centralized intermediaries or require extensive data disclosure, which hinders collaboration, compliance, and innovation. We propose a generic reference architecture for privacy preserving, trustless data sharing in supply chains. The architecture combines permissioned distributed ledgers, IoT-based evidence ingestion, and modular privacy mechanisms to enable controlled transparency: stakeholders can extract verifiable insights and support audits while minimizing data exposure. We instantiate the architecture in the context of the MoreMedDiet project, which promotes sustainable farm-to-fork food systems and adoption of the Mediterranean diet. By mapping the MoreMedDiet use case into our architecture, we demonstrate how channel topologies, IoT-to-ledger data flows, and smart contract-based quality assurance (QA) can support secure data exchange, transparency, interoperability, and regulatory alignment. Our proof-of-concept illustrates how Self-Sovereign Identity (SSI) and W3C Verifiable Credentials (VCs) can provide portable and auditable access governance over Hyperledger Fabric channels. The resulting design offers a reusable blueprint for multi-actor supply chains, including agri-food and pharmaceutical domains. Moreover, the performance achieved -- presenting a verified credential to the next stakeholder in the supply chain in 130 ms -- is promising and demonstrates the potential applicability of the approach in real-world supply chain environments.
1. Introduction
Supply chains face pressure for verifiable transparency while needing to protect sensitive information across heterogeneous, low-trust relationships. The paper proposes and instantiates a privacy-preserving reference architecture using permissioned ledgers, IoT evidence, and controlled disclosure.
- EU Digital Product Passports link products to verifiable origin, production, and lifecycle information through digital identifiers.
- Food supply-chain stakeholders must exchange traceability and quality-assurance data despite divergent incentives and limited mutual trust.
- IoT, distributed ledgers, and smart contracts support continuous monitoring, tamper-evident records, consensus, automated quality checks, and compliance verification.
- The proposed architecture combines a permissioned ledger, IoT-based evidence ingestion, and on-/off-chain data placement to provide flexible transparency with integrity and accountability.
- The MoreMedDiet instantiation demonstrates channel topology, IoT-to-ledger flows, smart-contract quality assurance, and auditor workflows for a sustainable farm-to-fork scenario.
- The paper presents a generic reference architecture for controlled transparency in multi-actor supply chains.
2. Background and Related Work
The background reviews permissioned ledgers, SSI, VCs, IoT monitoring, and privacy-preserving supply-chain exchange. It positions the proposal as combining Fabric-based traceability and data isolation with SSI/VC-based, fine-grained disclosure while avoiding additional on-chain privacy overhead.
- Blockchain and Hyperledger Fabric: Hyperledger Fabric provides permissioned, channel-based ledgers with confidentiality, accountability, policy control, and private-data support for enterprise consortia.
- Self-Sovereign Identity and Verifiable Credentials: SSI enables portable identity assertions across organizations, while DIDs support decentralized identifiers controlled through associated cryptographic material.
- Self-Sovereign Identity and Verifiable Credentials: Verifiable Credentials are signed claims that can attest roles, certifications, mandates, device registration, or access authorization.
- Self-Sovereign Identity and Verifiable Credentials: Verifiable presentations can selectively disclose credential attributes so verifiers assess required conditions without learning all original credential information.
- Architecture integration: The architecture keeps Fabric MSPs for network membership while using SSI and VCs for portable, privacy-preserving application-layer authorization.
- IoT-enabled supply chains: IoT devices provide ledger data, while gateways aggregate, validate, and submit measurements to channels while balancing granularity, scalability, and privacy.
- Related work: Prior work identifies Fabric strengths in performance, scalability, and channel isolation, but reviews continue to identify privacy integration as a primary challenge.
- Related work: The proposal segregates IoT monitoring and smart-contract quality authentication on blockchain from inter-organizational data exchange through off-chain SSI and VCs.
3. Organizational System Model and Requirements
The paper models a partially trusted, multi-actor supply chain involving sequential actors, a QA auditor, and an authority. Its requirements prioritize verifiable custody, role-specific evidence, targeted oversight, selective disclosure, automated checks, and accountability rather than unrestricted transparency.
- Organizational entities: The organizational model comprises upstream, intermediate, and downstream actors that exchange products and information under partial trust.Actors originate batches, perform value-adding or logistics operations, preserve custody, and support downstream verification.
- Organizational entities: The QA auditor verifies compliance, defines quality-assurance policies, deploys checking smart contracts, and can issue signed certificates or credentials after conformity checks.QA auditors remain accountable for their smart contracts.
- Organizational entities: The authority defines, enforces, or recognizes operating rules and determines the evidence required for regulatory or certification purposes.Its mandate may include supervising auditors and certification procedures.
- Functional and regulatory requirements: The requirements cover batch identification, continuous chain of custody, role-dependent evidence contributions, targeted audits, regulatory supervision, selective disclosure, automated checks, and evidence-based accountability.Auditors and authorities may need broader visibility, but consumer-facing views remain limited to nonsensitive information.
- Functional and regulatory requirements: The objective is controlled transparency: automate regulatory and quality obligations while allowing organizations to limit additional visibility beyond the required minimum.All actors’ data is on the shared ledger, but the architecture enforces segregation.
- Threat and privacy assumptions: The model recognizes that auditors’ broader visibility can enable excessive extraction, retention, disclosure, or sharing of commercially sensitive information.This risk motivates constrained auditor access and privacy expectations alongside traceability and compliance.
4. Reference Architecture
The reference architecture maps organizational roles to technical components for identity, evidence ingestion, ledger coordination, access governance, and data storage. Its central design separates visibility and placement across public channels, private channels, and off-chain storage.
- Technical system model: The architecture maps organizational entities to wallets, IoT devices, gateways, Fabric peers and MSPs, channels, smart contracts, and application services.These components support identity management, transaction submission, evidence storage, and controlled data access.
- Identity and access: Wallets hold credentials for authentication and, in the SSI/VC variant, support verifiable presentations.Wallets are associated with actors, the QA auditor, and the authority.
- Evidence ingestion: IoT devices capture product, environmental, location, or process measurements, while gateways validate, contextualize, and submit evidence to the technical backend.Gateway management affects admission control, credential handling, filtering, aggregation, replay protection, and measurement integrity.
- Ledger and contracts: The permissioned Fabric ledger provides shared state management, ordering, endorsement, validation, and tamper-evident recording across organizations.It records provenance events, compliance-relevant states, and integrity anchors for off-chain data.
- Channels and data placement: Public channels support broad traceability for nonsensitive information, whereas private channels restrict visibility by organizational membership and application policies.Write access is governed by chaincode endorsement and submission policies; read access depends on membership and application-layer controls.
- Ledger and contracts: Smart contracts manage batch lifecycles, handovers, compliance flags, access preconditions, and quality-assurance or real-time monitoring logic.Application services enforce fine-grained SSI/VC authorization and controlled release of off-chain artefacts.
- Channels and data placement: The architecture places public provenance anchors, restricted operational or compliance data, and detailed sensitive artefacts in distinct technical spaces.Off-chain storage retains large or sensitive payloads while the ledger stores metadata, references, or cryptographic commitments.
5. Security and Privacy Analysis
The security and privacy analysis evaluates the architecture against evidence integrity, confidentiality, accountability, and governance threats. It combines cryptographic binding, attributable submissions, channel segregation, off-chain anchoring, SSI/VC authorization, and immutable access logging.
- Evidence falsification: Immutable cryptographic binding and attributable submissions mitigate attempts by malicious actors to suppress, repudiate, or falsify non-compliance evidence.Segregation of duties limits unilateral control, while chain-of-custody and accountability requirements support non-repudiation.
- Competitive intelligence: Separate private channels protect business confidentiality by limiting competitors’ ability to infer relationships, production volumes, and other competitive intelligence.Each actor’s data is stored in a separate private channel created for that actor.
- Controlled governance: SSI/VC credentials provide fine-grained authorization and purpose limitation for honest-but-curious auditors and authorities with broader visibility.Actors can choose how to authorize access to private channels, while access decisions and purposes are immutably logged.
- Data protection: Off-chain storage and on-chain integrity anchoring support data minimization and personal-data protection for sensitive or bulky IoT-related evidence.Authentication and attributability address vulnerabilities at the IoT-device and gateway boundary.
6. MoreMedDiet Proof-of-Concept
The MoreMedDiet PoC instantiates the reference architecture for a sustainable agri-food chain, combining private evidence contexts, IoT ingestion, Fabric mediation, and selective disclosure. It validates workflows including QA-based proof requests and credential presentation between actors.
- 6.1. MoreMedDiet Scenario: Primary producers, transporters, processors, distributors, and retailers are mapped to product-flow actors in the farm-to-fork chain.Each actor maintains evidence for product attributes and events within its operational responsibility.
- 6.1. MoreMedDiet Scenario: The PoC combines provenance, food-quality evidence, transport and storage monitoring, and selective disclosure without requiring consortium-wide sharing of operational data.Actors record evidence in private ledger contexts and disclose selected claims or proofs for legitimate requests.
- 6.2. Prototype Platform and Data Flow: The deployed blockchain uses private channels as evidence spaces, with access controlled through MSP permissions and certificates.The implementation includes three peer nodes, one orderer, and three private channels.
- 6.2. Prototype Platform and Data Flow: IoT gateways aggregate readings and forward them to the Blockchain Agent, which invokes smart contracts to insert evidence into actor-specific Fabric channels.This separates heterogeneous devices from ledger-specific transaction logic.
- 6.3. Validation and Performance Characterization: Food processors can request proof of transport conditions through a mobile application, using ledger data and an authorized QA smart contract.The workflow supports selective information disclosure between supply-chain actors.
- 6.3. Validation and Performance Characterization: 210 ms is the reported average latency for writing aggregated IoT data from devices to the blockchain.This combines around 160 ms from gateway to agent with 50 ms from agent to blockchain; batch writes occur only a few times daily.
- 6.3. Validation and Performance Characterization: 130 ms is the reported delay for generating and presenting a verified credential to another supply-chain actor for verification.The paper compares this with credential transfers taking hours to days and with 2.2 seconds for certifying mango origin in Walmart’s supply chain.
7. Conclusions and Future Work
The paper concludes that integrating IoT monitoring, consortium blockchain infrastructure, private channels, and SSI-based authorization supports controlled transparency and trusted data exchange. It reports feasibility while identifying credential revocation as future work.
- 7. Conclusions and Future Work: IoT integration with consortium blockchain helps automate and accelerate logging, certification, and trusted data exchange between supply-chain actors.
- 7. Conclusions and Future Work: Private channels, MSP certificates, verifiable credentials, and off-chain storage support controlled transparency while protecting business interests and reducing on-chain proof burdens.
- 7. Conclusions and Future Work: The architecture, MoreMedDiet instantiation, proof-of-concept evaluation, and security and privacy analysis are reported to demonstrate feasibility and potential real-world applicability.
- 7. Conclusions and Future Work: Credential revocation remains an open issue because multiple VC-revocation methods exist, including cryptographic accumulators and W3C Bitstring Status Lists.
Appendix A. Benchmarking Methodology
The benchmarking methodology characterizes the experimental MoreMedDiet prototype rather than providing deployment-independent performance benchmarks for the reference architecture.
- Appendix A. Benchmarking Methodology: The measurements characterize the experimental prototype deployment rather than general performance benchmarks for all reference-architecture deployments.
- Appendix A. Benchmarking Methodology: Results depend on the local network, container configuration, Hyperledger Fabric setup, device profile, and software versions used in the experiment.
Appendix A.1. Experimental Setting
The experimental setting connects MQTT-based IoT ingestion to a local Hyperledger Fabric network through the Blockchain Agent, which processes events and invokes channel-specific smart contracts.
- Appendix A.1. Experimental Setting: IoT gateways publish sensor events through MQTT, while the Blockchain Agent mediates ingestion and Fabric interactions.
- Appendix A.1. Experimental Setting: The measured ledger operations ran on a local network with two organizations, two peers, and a Raft ordering service.
- Appendix A.1. Experimental Setting: The latency measurements reflect this local experimental setup and should not be interpreted as deployment-independent properties of the architecture.
Appendix A.2. Gateway-to-Agent Submission Latency
Gateway-to-Agent latency measures MQTT message delivery from the gateway layer to the Blockchain Agent. The benchmark used timestamped messages and summarized 1000 samples with mean, median, and 95th-percentile values.
- Gateway-to-Agent latency measures the IoT ingestion path between the MQTT gateway layer and the Blockchain Agent.Each message contained a unique identifier, publication timestamp, and synthetic sensor value.
- Latency was computed as the difference between MQTT publication and receipt timestamps in the Blockchain Agent pipeline.The metric excludes Fabric transaction endorsement, ordering, and commitment.
- 1000 MQTT messages were measured, with results reported as mean, median, and 95th percentile.
Appendix A.3. Agent-to-Ledger Transaction Latency
Agent-to-Ledger latency measures the mediated Fabric write path in the prototype. The benchmark timed smart-contract invocations across 100 executions and reported mean, median, and 95th-percentile values.
- Agent-to-Ledger latency measures the mediated Fabric write path by timing smart-contract invocations through the Hyperledger Fabric command-line interface.Timing started immediately before transaction submission and ended after invocation completion.
- The metric includes interaction with Fabric ordering and peer infrastructure required for invocation completion.It excludes MQTT publication latency and mobile application processing.
- 100 transaction invocations were executed, with results reported as mean, median, and 95th percentile.
Appendix A.4. Private-Channel Query Latency
The appendix describes private-channel query latency and application-side VC proof measurements in the prototype. It distinguishes ledger-query response time from isolated cryptographic processing and states deployment and scale limitations.
- Appendix A.4. Private-Channel Query Latency: Private-channel query latency measures evidence retrieval from the Fabric ledger through repeated smart-contract query operations.Timing covered the interval from query request to completion.
- Appendix A.4. Private-Channel Query Latency: Because queries do not require Fabric ordering, the measurement primarily reflects peer-side processing, chaincode execution, and local testbed communication.
- Appendix A.4. Private-Channel Query Latency: 100 query operations were executed, with results reported as mean, median, and 95th percentile.
- VC proof generation and verification were measured inside a mobile wallet after initialization using a complete in-memory AnonCreds credential stack.The setup excluded network communication, ledger access, mediator calls, and external service calls.
- Five proof-exchange iterations measured zero-knowledge proof generation and verification independently using fresh nonce-bearing presentation requests.The same locally stored credential was reused, and operations used the Hyperledger AnonCreds Rust library through Android bindings.
- The measurements were collected locally, excluded network and ledger costs for VC operations, and were not a large-scale stress test.Results are sensitive to deployment and configuration conditions and characterize execution paths validated by the proof of concept.