Building theNew Economy of Movement

JUNE 2021

SUPPLY CHAIN
REFERENCE IMPLEMENTATION

Use Case
Parts Traceability

MOBI SC0002/RI/2021
Version 1.1

INTRODUCTION
MOBI Supply Chain Working Group is a global,
multi-stakeholder project working to co-design blockchain
and distributed ledger technologies standards to improve
efficiency in the automotive supply chain. The project
engages stakeholders across the chain: OEMs, Tier-N
suppliers, dealers, consumers, and regulatory agencies.
This report is based on numerous discussions, workshops,and research. Opinions expressed herein do notnecessarily reflect the views of individual members.
Sincere thanks are extended to those who contributed theirunique insights to this report.

AuthorJohannes Sedlmeir, FIM Research Center

SC Working Group Co-Chairs
Pramita Mitra, Ford
Daniel Miehle/Dominik Batz, BMW GroupSC Working Group Team Members
Loren Adams, Accenture
Chris Ballinger, MOBI
Sebastian Banescu, Quantstamp
Olof Belfrage, CEVT
Roger Berg, DENSO
Betul Betul Kahya, MOBI
José Manuel Cantera, IOTA Foundation
Josh Cartellone, Accenture
Alisa DiCaprio, R3
Thad Dungan, AmazonChris Floersch, Honda
Josh Fodale, FordKami Gaweda, Arxum
Jeremy Goodwin, SyncFabShannon Hamilton, DLT Labs
Philips Harrison, Fifth-9
Carsten Hiemsch, IBMThi Hong Tran, NAIST
Chris Hwee, Honda
Karthik Krishnamurthy, Amazon
Marco Lang, Marelli
Jens Lund-Nielsen, IOTA Foundation
Piyush Manocha, Accenture
Vinay Munjewar, SyncFabHeiko Musa, BMW
Diwakar Muthu, FordRichard Nolk, CEVT
Drew Paroz, Honda
Dean Philips, Amazon
Angela Ruthenberg, AutoData Solutions
Kristin Marie Slanina, Thirdware
Anne Smith, IOTA
Kellie Treppa, Thirdware
Carl Youngblood, Amazon

MOBI Team
Chris Ballinger, Co-director + FounderTram Vo, Co-director + Founder
Rajat Rajbhandari, Working Groups Lead
Robin Pilling, Technical Lead

Matt Shi, Fellow
Kelly Clark, Communications Manager
Grace Pulliam, Communications AssociateTABLE OF
CONTENTS

01

Executive Summary

07

Glossary of Terms

11

Use Case Summary

10

Technical Building Blocks and ArchitecturalConsiderations
1. The identification of parties on a blockchain
2. Replicated storage of data

39

Technical Workflows
1. Onboarding of a party to the identity andmaster data management solution
2. Issuing an access credential to an
onboarded party
3. Requesting data from another party usingan access credential
4. Triggering an event at another party using
an access credential
5. Cascading API calls
6. Interactions with the Distributed Ledger(s)52Business Case Requirements and How theStandard Addresses Them
1. General (System Accessibility)
2. Requirements for Tier-1… N Suppliers
3. Requirements for Logistics ServiceProviders
4. Requirements for OEMs to Receive, Test,and Assign Parts from Tier-1
5. Requirements for OEMs to Send Parts toOEM-SD/Repair Shops
6. Requirements for OEM - SpecificDealers/Repair Shops

111 Bibliography

ExecutiveSummary

Blockchain/Distributed Ledger
Technology in supply chain
improves efficiency andautomation by coordinating
multi-stakeholder processes
and dissemination of mutually
beneficial events.

Blockchain/Distributed Ledger Technology (DLT) provides many
capabilities to make supply chains more transparent andefficient. It can address acknowledged challenges of today’scomplex supply chains, for example, by making it easier to checkfor data integrity and authenticity, allowing the prevention ofdouble-spending of production decisions, parts custody, recalls
etc. Blockchain improves efficiency and automation bycoordinating multi-stakeholder processes and the disseminationof events.

Blockchain/DLT provides atrust anchor to support
multiple stakeholders toauthenticate each other'sidentities and data.

Two foundational capabilities are required to address thesechallenges, i.e., the ability for stakeholders to securely
authenticate each other’s identities and exchange data, and theability to track and trace part lifecycle events from birth to endof life. Both of these capabilities require a single source of truth
for supporting multi-stakeholder workflows around trusted data,
and that’s where blockchain / distributed ledger technology act
as a pivotal enabler.

Significant challenges exists
in implementing
blockchain/DLT primarily insolving tradeoffs of privacy,scalability, and replicatedstorage.

However, there are also significant technical challenges involved
with the adoption of blockchain in supply chains, as the specificscalability and privacy requirements of each use case need tobe met. Tackling these challenges, which are associated withthe replicated storage and execution of transactions on a
blockchain, is the goal of many ongoing research and industry
projects. Solutions that have been proposed exhibit different
tradeoffs: for example, integrating Trusted Execution
Environments or developing hand-crafted solutions based on
advanced cryptography, such as Secure Multiparty Computation
or Zero-Knowledge Proofs, can avoid information exposure but
add additional complexity and computational overhead.

© 2021 MOBI — SC Reference Implementation Architecture2

Executive Summary
Other established methods, such as writing only transaction
hashes on a blockchain, are simple to implement; yet theycannot bring the anticipated benefits in every use case as thisapproach reduces the number of participants with access tothe blockchain or the information is stored on-chain and hence
accessible to other participants and smart contracts. Besides
the application-layer design choices, there are also manydegrees of freedom regarding the setup of a blockchain-based
supply chain solution on the infrastructure layer: Tradeoffs exist
for the usage of permissionless or permissioned architectures;
and, in the latter case, there may be one blockchain thatcomprises the whole supply chain ecosystem, one blockchain
per node, or even many blockchains that may involve only two or
three parties each.
Use cases in supply chain are
diverse in terms ofrequirements pertaining todata protection, antitrustregulation. Hence, one-size
fits all reference architecture
is difficult to design.

On the other hand, use cases differ considerably regarding thesensitivity of the related data in terms of data protection
regulation, antitrust regulation, and their classification ofbusiness secrets. Stakeholders also do not have the same
technical capabilities and willingness to adopt innovative yetcomplex solutions that help to leverage the advantages ofblockchains while addressing the challenges. In summary, theheterogeneity of use cases and the variety of potential design
choices prevent the feasibility of a one-size-fits-all blockchainarchitecture as a solution.
Consequently, this reference architecture focuses on discussing
the benefits and potential interplay of different blockchain
setups, embedded into a system that provides a basic
communication layer, and the role of privacy enhancing
technologies. The system would offer a rich toolkit to accountfor the spectrum of requirements of use cases that need to beimplemented. The reference implementation suggests

3This reference architecture
focuses on standardizedbilateral communication using
extensive API calls,
decentralized identity withblockchain/DLT as a trustanchor.

© 2021 MOBI — SC Reference Implementation Architecture

standardized bilateral communication and process
management between business partners in the supply chain in
combination with replicated execution on a DLT where useful.
Application Programming Interfaces (API) can shield the specificchoices of stakeholders regarding their integration of a
blockchain behind a layer of abstraction and enable multistakeholder workflows such as recalls through the supply chain
without disclosing related information to third parties. This
design is facilitated by cross-organizational digital identities for
all parties, managed in a decentralized approach that may beanchored to a blockchain and oriented at the W3C DID and
Verifiable Credentials (VC) standards that have already built
the basis for the MOBI VID II standard.
Decentralized identity management enables a crossorganizational access management for the standardized API
endpoints that we propose as the base infrastructure for theexchange of information between business partners, as well as
the source for demonstrating permissions on a joint DLTplatform. As this approach supports many degrees of exposing
the exchanged information to further stakeholders, benefits ofincreased transparency can be leveraged while challenges
associated with sensitive data, that blockchains frequently
encounter, can be avoided.

This architecture uses
"cascading API calls" andsmart contracts based event
handling.

Depending on the use case under consideration, multistakeholder processes, such as recalls, can be automatedthrough “cascading API calls” or smart-contract based event
handling. This spectrum hence supports both coordinating use
cases that allow for a high degree of transparency acrossmultiple stakeholders with a highly robust design that does not© 2021 MOBI — SC Reference Implementation Architecture4

Executive Summary
rely on the availability of information from each individual party
in the supply chain of a specific component in a recall.
The standard hence motivates the combination of digital
identities, bilateral data exchange, distributed ledgers, andprivacy-enhancing technologies to offer transparency to theextent that is required and providing the benefits of smart
contracts in terms of efficiency where the related informationexposure is justified or privacy-enhancing technologies canreduce information exposure while maintaining the corebenefits.

5© 2021 MOBI — SC Reference Implementation Architecture© 2021 MOBI — SC Reference Implementation Architecture 6

Glossary of Terms
Application Programming Interface (API) — An API is defined as a specification ofpossible interactions with a software component, allowing two applications to interact witheach other. It defines the kinds of calls or requests that can be made, how to make them,the data formats that should be used, the conventions to follow, etc (Hubspire, 2021).
Examples for APIs are digital services that can be triggered via HTTP requests to change thestate of, or receive information from, this application over the internet.

Open ID Connect (OIDC) — A standard for federated identity management (that is often
used in enterprise single sign-on and social login) in which clients (such as a mobile
application or a server) can request and receive information about valid sessions. Inessence, a user proves attributes attested by a dedicated identity provider (such as thecompany HR or IT department, or Google/Facebook) by means of a signed JSON documentthat contains information about their identity.

Differential Privacy (DP) — A method for obfuscating sensitive information by adding noisewith expectation value 0 to data (deterministically if repeated queries are possible asotherwise the true value could be localized easily). Differential Privacy is best suitable inscenarios where large datasets are aggregated as the expected value of the average does
not change under adding noise whose distribution is centered at 0, and wheremathematical guarantees for the indistinguishability of entities with respect to query results
are required.

Oracle — An oracle can be used to store data from the outside world, such as the daily
temperature, a flight’s delay, or the number of votes a political candidate received, on a
blockchain such that a data consumer or smart contracts that trusts the Oracle (or at least
trusted the Oracle when the smart contract was deployed) can use the data to makedecisions (adapted from https://www.coindesk.com/what-is-an-oracle andhttps://www.itu.int/en/ITU-T/focusgroups/dlt/Documents/d11.pdf). Oracles can build on asingle trusted third party that signs the data directly or indirectly (the data was signed by asensor that in turn was certified by the trusted third party), a consortium of third parties suchthat the majority is trusted (often involving multi-signatures and threshold-schemes).

Digital Identifier (DID) — from VID II (W3C-oriented).
Homomorphic Encryption (HE) — Allows performing computations on encrypted data (i.e.,making meaningful operations without decrypting and knowledge of the decryption key). HE
is either very limited in scope (either additions or multiplications, such as in the Palliercryptosystem) or brings significant performance challenges when arbitrary operations need
to be supported (“fully homomorphic encryption”).
Logistics Service Provider (LSP) — from the business draft.
Master Data — Specifications and information related to products and business partners,
such as supplier’s address and banking information. Master data management aims toprovide data and processes for collecting, matching, persisting, and distributing such data
within an organization but potentially also with business partners to ensure a single sourceof truth that provides consistency and control.

7© 2021 MOBI — SC Reference Implementation Architecture(Secure) Multiparty Computation (MPC) — allows the computation of a function withmultiple inputs provided by different entities where every participant does not learn theothers’ private inputs but only the final result. Often, MPC also involves methods to makesure that the participants perform their task correctly, e.g., through using ZKP. This is basedon cryptographic primitives such as secret sharing (splitting an input into multiple parts anddistributing it to other parties), and/or oblivious transfer (sending multiple messages toanother party and making sure that the recipient can only decrypt exactly one of them, but
the sender does not learn which one). In this sense, MPC is strictly more general than ZKP, as
the latter requires a party that has access to all private inputs for a computation to create a
proof of the correct execution of a program. More details on this can, e.g., be taken from(Buterin, 2014).
Original Equipment Manufacturer (OEM) — from VID II.

© 2021 MOBI — SC Reference Implementation Architecture8Glossary of Terms
Trusted Execution Environment (TEE) — Hardware for which the manufacturer guaranteesthat code is executed correctly on it (“remote attestation”) and no information is leakedoutside the hardware. A prominent example is Intel’s Software Guard Extensions (SGX)
solution. By creating a private key inside the TEE and only making the corresponding public
key available, information can be encrypted in a way that makes sure it can only bedecrypted inside a TEE. Besides known vulnerabilities such as side-channel attacks,
challenges of TEEs include high integration efforts (particularly in the cloud) and therequired trust in the TEE’s manufacturer as it provides a single point of failure. On the other
hand, TEEs can run basically arbitrary code in a rather efficient way, which offers
advantages over cryptographic alternatives such as MPC and ZKP that typically exhibit
lower performance and require the implementation of hand-crafted solutions by experts
with deep cryptographic expertise.

possesses the associated private key. By signing the verifier’s challenge with the private key,
the prover can convince the verifier that they possess the private key without revealing it (itis, however, not zero-knowledge as the verifier learns at least something new that they
could not have computed on their own, namely the value of the signature on the nonce.
However, this information will be pretty useless in any other context, so for illustration, theanalogy fits). A specialized form of ZKPs is used in so-called Anonymous Credentials thatare also being used in some SSI implementations, such as the Anoncreds in Hyperledger
Aries and the BBS+ Linked Data Proofs in MATTR’s Verifiable Credentials. They allow proving
selected attributes contained in a VC or predicates derived thereof, for example, aninequality proof for an integer-valued attribute such as age or expiration timestamp. These
specialized ZKPs are highly efficient, with signing and verification lasting only a few
milliseconds.

Verifiable Credential (VC) — from VID II (W3C-oriented). There are related standards thathave many commonalities with Verifiable Credentials, such as X.509 certificates that areused to authenticate servers in the world wide web (HTTPS), JSON Web Tokens (JWT) thatare frequently used in federated identity management schemes such as the OIDC standard,or JSON-LD documents that may include a Linked Data Proof, such as the GS1 EPCIS 2.0
standard. In the following, we will refer to the W3C VC standard, however, more narrow or
not compatible competing standards would also enable us to reach the goals of thisreference implementation, with a few exceptions (not all standards support ZKPs, forexample).

In general, ZKPs can also be used to prove that a specific computation has been conducted
correctly, without the need to disclose inputs, outputs, or intermediate steps. For example,using a zk-SNARK or zk-STARK, one could prove that given two Merkle roots (hashes) ofdifferent composite parts represented by Merkle trees (where the root hashes are known tothe verifier and both Merkle trees are known to the prover), a specific parts ID is present inboth of them, and checking this statement can be conducted by the verifier quite efficiently(in milliseconds) and without learning any additional information. However, the prover needs
to know all the data for the original computation for the proof, in particular, in the given
example, the prover needs to know the preimages of the hashes.

Verifiable Presentation (VP) — from VID II.
Zero-Knowledge Proof (ZKP) — In cryptography, a zero-knowledge proof (ZKP) is a methodby which one entity (the prover, assumed to be computationally powerful) can prove toanother party (the verifier, assumed to be computationally restricted) that a particularstatement is true without revealing any further information. A digital signature of achallenge for authentication can be thought of as “almost” a ZKP: The verifier knows theprover’s public key and wants to be convinced that the entity that wants to authenticate9© 2021 MOBI — SC Reference Implementation Architecture© 2021 MOBI — SC Reference Implementation Architecture

10Full access to this Standard and other MOBI Standards are available to MOBI members.
If you are not part of the MOBI community and would like to become a member, please fill out our"Membership Inquiry Form" at dlt.mobi/join.
Members gain access to standards, working groups, and many other benefits. Join us in building
the New Economy of Movement!
If you have any questions regarding the MOBI Supply Chain working group, please email
SC@dlt.mobi.

dlt.MOBI@dltMOBI

MOBI@dltMOBI

SC@dlt.MOBI