Integrated Trust
Network (ITN)
VALUE AND TECHNICAL NARRATIVEB U S I N E S S W H I T E PA P E R
MOBI ITN0001/WP/2023 Version 1.0

May 2023© 2023 MOBI. All rights reserved

TERMS AND CONDITIONS FOR USE, REPRODUCTION,
AND DISTRIBUTION© 2024 MOBI
1. Definitions.
“License” shall mean the terms and conditions for use, reproduction, and distribution as defined by
Sections 1 through 9 of this document.
“Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is
granting the License.
“Legal Entity” shall mean the union of the acting entity and all other entities that control, arecontrolled by, or are under common control with that entity. For the purposes of this definition,“control” means (i) the power, direct or indirect, to cause the direction or management of such
entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of theoutstanding shares, or (iii) beneficial ownership of such entity.
“You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by thisLicense.
“Source” form shall mean the preferred form for making modifications, including but not limited tosoftware source code, documentation source, and configuration files.
“Object” form shall mean any form resulting from mechanical transformation or translation of a
Source form, including but not limited to compiled object code, generated documentation, andconversions to other media types.
“Work” shall mean the work of authorship, whether in Source or Object form, made available under
the License, as indicated by a copyright notice that is included in or attached to the work (an example
is provided in the Appendix below).
“Derivative Works” shall mean any work, whether in Source or Object form, that is based on (orderived from) the Work and for which the editorial revisions, annotations, elaborations, or othermodifications represent, as a whole, an original work of authorship. For the purposes of this License,

Derivative Works shall not include works that remain separable from, or merely link (or bind byname) to the interfaces of, the Work and Derivative Works thereof.
“Contribution” shall mean any work of authorship, including the original version of the Work and any
modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to
Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized
to submit on behalf of the copyright owner. For the purposes of this definition, “submitted” means
any form of electronic, verbal, or written communication sent to the Licensor or its representatives,
including but not limited to communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of
discussing and improving the Work, but excluding communication that is conspicuously marked orotherwise designated in writing by the copyright owner as “Not a Contribution.”“Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution
has been received by Licensor and subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor
hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform,
sublicense, and distribute the Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor
hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable(except as stated in this section) patent license to make, have made, use, offer to sell, sell, import,
and otherwise transfer the Work, where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their Contribution(s) alone or by combinationof their Contribution(s) with the Work to which such Contribution(s) was submitted.If You institutepatent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging
that the Work or a Contribution incorporated within the Work constitutes direct or contributory
patent infringement, then any patent licenses granted to You under this License for that Work shallterminate as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof
in any medium, with or without modifications, and in Source or Object form, provided that You meetthe following conditions:a. You must give any other recipients of the Work or Derivative Works a copy of this License; andb. You must cause any modified files to carry prominent notices stating that You changed the files;

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence),

andcontract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent

c. You must retain, in the Source form of any Derivative Works that You distribute, all copyright,acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct,

patent, trademark, and attribution notices from the Source form of the Work, excluding thoseindirect, special, incidental, or consequential damages of any character arising as a result of thisnotices that do not pertain to any part of the Derivative Works; andLicense or out of the use or inability to use the Work (including but not limited to damages for loss ofd. If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that

goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages

You distribute must include a readable copy of the attribution notices contained within such NOTICE

or losses), even if such Contributor has been advised of the possibility of such damages.

file, excluding those notices that do not pertain to any part of the Derivative Works, in at least oneof the following places: within a NOTICE text file distributed as part of the Derivative Works; within

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Worksthe Source form or documentation, if provided along with the Derivative Works; or, within a display

thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity,

generated by the Derivative Works, if and wherever such third-party notices normally appear. Theor other liability obligations and/or rights consistent with this License. However, in accepting suchcontents of the NOTICE file are for informational purposes only and do not modify the License. You

obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf

may add Your own attribution notices within Derivative Works that You distribute, alongside or asof any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor

an addendum to the NOTICE text from the Work, provided that such additional attribution notices

harmless for any liability incurred by, or claims asserted against, such Contributor by reason of yourcannot be construed as modifying the License.

accepting any such warranty or additional liability.

You may add Your own copyright statement to Your modifications and may provide additional ordifferent license terms and conditions for use, reproduction, or distribution of Your modifications, orLicensed under the Apache License, Version 2.0 (the “License”). You may not use this file except infor any such Derivative Works as a whole, provided Your use, reproduction, and distribution of thecompliance with the License.

Work otherwise complies with the conditions stated in this License.
END OF TERMS AND CONDITIONS
5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionallysubmitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions. Notwithstanding the above, nothing hereinshall supersede or modify the terms of any separate license agreement you may have executed with
Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade names, trademarks, service
marks, or product names of the Licensor, except as required for reasonable and customary use indescribing the origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor
provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUTWARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation,
any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or
redistributing the Work and assume any risks associated with Your exercise of permissions under
this License.

MOBI ITN0001/WP/2023 Version 1.0

Introduction

MOBI ITN0001/WP/2023 Version 1.0

Authors

Andreas Freund, MOBI
Parth Bhatt, MOBI
Rajat Rajbhandari, MOBI
Matt Shi, MOBI

MOBI is a nonprofit alliance of many of the world’s largest vehicle manufacturers, startups,

Tram Vo, MOBI

governments/transit agencies, NGOs, financial institutions, e-mobility providers, consultancies,
suppliers, logistics providers, and blockchain protocols working to create standards and build theWeb3 digital infrastructure for connected ecosystems and IoT commerce.

MOBI Team

Tram Vo, CEO + Founder
Chris Ballinger, Advisor + Founder

MOBI is creating standards to identify vehicles, individuals, businesses, and MOBI Trusted Trips inRajat Rajbhandari, Head of Standards and Certification

order to securely exchange and share data, and pay for mobility services, with the goal of making
transportation more efficient, equitable, decentralized, and sustainable, all while preserving theAndreas Freund, CTO

data privacy of users and providers alike. MOBI is technology and ledger agnostic.

Parth Bhatt, Technical Product Manager
Griffin Haskins, Mobility Finance Lead
Matt Shi, Supply Chain Lead
Betul Kahya, Mobility Lead
Grace Pulliam, Communications Manager
Kierra Maggs, Digital Media Associate

Contact

1©2023
2023MOBI.
MOBI.All
Allrights
rightsreserved.
reserved.
©

connect@dlt.mobi© 2023 MOBI. All rights reserved.

2

MOBI ITN0001/WP/2023 Version 1.0

Table Of Contents

01

Executive Summary

02

Acronyms

03

04
05

3

The Business Problem

05

08

09

3.1

Centralized Identities and Moving to Zero Trust Framework		

09

3.2

Use Case: Implementing Battery Passport in a Zero Trust Framework

12

MOBI’s Roadmap
Integrated Trust Network: New Federated
Certificate Authority

07

13

15

5.1

About the Integrated Trust Network					

15

5.2

Unique Value Proposition of ITN				16© 2023 MOBI. All rights reserved.

06

08

About the Self-Sovereign Digital TwinTM

18

6.1

Self-Sovereign Digital TwinTM Introduction					

18

6.2

Purpose of SSDTTM								186.3How Does an SSDTTM Work?							

19

6.4

SSDTTM Architecture and Technical Descriptions				21

About the ITN Node

23

7.1

Purpose of ITN Node								

23

7.2

How Does the ITN Work?							

24

7.3

ITN Architecture and Technical Descriptions					

27

7.4

Description of Two ITN Example Workflows					

28

7.4.1

Workflow to create an ITN DID based on W3C DID		

31

7.4.2

Workflow to issue ITN membership credential by MOBI		

33

References36© 2023 MOBI. All rights reserved.

4

Executive Summary

In a decentralized ecosystem, it is necessary
to develop new ways to identify and verify
entities and transactions in a secure,auditable, tamper-evident, and privacypreserving manner.

In a decentralized ecosystem, it is necessary to develop new ways to identify
and verify entities and transactions in a secure, auditable, tamper-evident,
and privacy-preserving manner. Currently, we rely on identifiers issued bycentralized intermediaries to verify our identities during interactions withothers. This has big consequences for our privacy, as those intermediaries
cash in on our participation by collecting vast amounts of personal data andmetadata.

In 2019, W3C published the first draft of its
Decentralized Identifiers (DIDs) standard.

Creating a standardized framework for decentralized trusted identity will
reduce reliance on centralized authorities, allowing connected entities tocontrol their data and protect sensitive information. This promises to improve
IoT security, reduce trust costs, and enable multi-party applications forbusiness automation.

Today, 40% of all internet traffic is made up of “bad bots,”1 whose functions
include generating spam, scraping data, assisting in account hacks, sensitive
data leaks, identity theft, and more.
In light of growing cybersecurity threats, with the rise of big tech data
aggregators and increasingly pervasive malware, consumers, regulators, andorganizations are increasingly concerned with the ability to preserve data
privacy and assert ownership over their identity and digital assets. Recent
measures such as the European Union’s General Data Protection Regulation(GDPR)2 and the California Privacy Rights Act (CPRA)3 highlight the growing
demand for improved data privacy around the globe. As data security
concerns continue to grow in the US, Colorado4, Connecticut5, Utah6, andVirginia7 are preparing to enact statewide legislations that align with CPRA
and its principles.

In 2019, W3C published the first draft of its Decentralized Identifiers (DIDs)
standard8. Rather than being issued and controlled by centralized authorities,
DIDs are self-sovereign — i.e. created and managed by the entities to whomthey belong (or a verified owner/controller of that entity). The DIDs standard
was advanced to a W3C recommendation in July 2022.

The Integrated Trust Network (ITN) isa scalable, protocol-agnostic digital
infrastructure to provide trusted identity
services for connected mobility and IoT
commerce.

The Integrated Trust Network (ITN), launched by the MOBI communityand developed with MEF, AAIS, and other consortia, is a scalable digital
infrastructure for trusted identity services. The goal is to unlock monetization
opportunities across usage-based services by allowing applicationinteroperability and multiparty data sharing, enabling participants to executetrusted decentralized transactions at the edge.
This white paper describes the problem of centralized identity and hence thesecurity burdens businesses face, how the ITN solves these problems, andour roadmap to make the ITN available to verticals beyond mobility.

1“Bad Bots Account for Almost 40% of Internet Traffic.” n.d. IT PRO. https://www.itpro.com/networkinternet/bots/360765/bad-bots-make-up-huge-slice-of-internet-traffic-and-target-e-commerce.

5“General Data Protection Regulation (GDPR).” General Data Protection Regulation (GDPR). 2018. https://
gdpr-info.eu/.‌

62“The Connecticut Data Privacy Act.” n.d. Portal.ct.gov. https://portal.ct.gov/AG/Sections/Privacy/TheConnecticut-Data-Privacy-Act.
“Consumer Privacy Act ,” Utah State Legislature. https://le.utah.gov/~2022/bills/static/SB0227.html.

“Consumer Data Protection Act,” Code of Virginia Code - Chapter 53. Consumer Data Protection Act, https://law.lis.virginia.gov/vacodefull/title59.1/chapter53/.
7

3“California Consumer Privacy of 2018. ” n.d. Cppa.ca.gov. https://cppa.ca.gov/regulations/pdf/cppa_act.pdf“Colorado Privacy Act (CPA) Rulemaking,” Colorado Attorney General, March 20, 2023, https://coag.gov/
resources/colorado-privacy-act/.
45© 2023 MOBI. All rights reserved.

8“Decentralized Identifiers (DIDs) V1.0.” n.d. Www.w3.org. https://www.w3.org/TR/did-core/.

© 2023 MOBI. All rights reserved.

6

MOBI ITN0001/WP/2023 Version 1.0

Glossary
Of Terms

API-

Application Programming Interface

CAS-

Content Addressable Storage

DID-

Decentralized Identity

DIF		 -

Decentralized Identity Foundation

DPKI		 -

Decentralized Private Key Infrastructure

DLT		 -

Decentralized Ledger Technology

EDV

Encrypted Data Vault-

GDP		 -

Gross Domestic Product

IMC		 -ITN Maintainer Council

ITN		 -

Integrated Trust Network

SSI		-

Self Sovereign Identity

PII		-

Personal Identifiable Information

SDK		 -

Software Development Kit

SSDTTM -Self-Sovereign Digital TwinTM

VC		-Verifiable Credential

W3C		 -

World Wide Web Consortium© 2023 MOBI. All rights reserved.

8

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

Approx. 15 billion connected Things in 2022 (doubling every 3
years)13 are exponentially increasing the vulnerability of digitalbusiness activities as their number, and, therefore, attack
vectors grow exponentially.

The Business Problem

The above two points showcase how the security and regulatory compliancecosts of conducting digital business are exploding. Consequently, thisdevelopment will soon threaten the profitability of new and existing digitalbusinesses.

3.1 Centralized Identities and the Shift toward Zero Trust
Frameworks
Digitally transformed organizations are projected to contribute to more thanhalf of the global gross domestic product (GDP) by 2023, accounting for $53.3
trillion9. 65% of the world’s GDP is predicted to be digitized by 2022 (IMF,2020). The advantages of digitization have been clear for a while (Fig 1).

Historically, costs have been driven byincreased distribution and decentralizationof data, computing resources, andthe unavoidable rise in the number ofconnected devices.

But why now? Because the exponential growth of digital business costs is not
new but has been happening for a long time. Historically, costs have been
driven by increased distribution and decentralization of data, computing
resources, and the unavoidable rise in the number of connected devices.
Today, who doesn’t have a mobile phone, a tablet, a digital watch, a laptop,
one or more AI assistants, connected TVs, connected lights, connected cars,etc.? And this trend will not change — quite the contrary, as the above
numbers demonstrate.

We also know that exponential change isinsidious; humans do not recognize it until
it is too late.

We also know that exponential change is insidious; humans do not recognize
it until it is too late. Take the classic example: If 1% of a lake’s surface iscovered with water lilies and the water lily population doubles every day, theentire lake will be covered in less than a week. However, the water lilies will
be barely noticeable until day 4, at which point it would be too late. We are
currently approaching day 4 — not for the water lilies, but for the Internet;
we are almost too late to turn the ship around.

But why do the costs grow exponentially?
Because the cost of trust arises fromvulnerabilities in digital business related toregulatory compliance and cybersecurity.

But why do the costs grow exponentially? Because the cost of trust arises
from vulnerabilities in digital business related to regulatory compliance andcybersecurity. Vulnerabilities increase with the square of the number of entities(network size) that can interact with one another and the number of trust
boundaries that are crossed when those entities interact (decentralization).
As the attack surface of digital businesses grows exponentially, so does thecost of defense.

Any device connected to the Internet, oreven an internal network, is an attack
vector on your digital business.

Given that centrally orchestrated security frameworks do not scale incredibly
well unless you are the size of Google or Amazon, it is not surprising that
security failures and resulting costs rise as digital services become increasingly
decentralized. Any device connected to the Internet, or even an internal
network, is an attack vector on your digital business.

Fig 1. The benefits of digitization are well-documented.

Improve operational efficiency
Meet changing customer expectations
Improve new product quality
Increase design reuse
Reduce product development costs
Introduce new revenue streams
Reduce the cost of poor quality
Increase first pass yield
0%

10%

20%

30%

40%

Yet this drive to digitize business has a rapidly increasing dark side:
40% of internet traffic originates from malicious bots10 withcybercrime causing $10.5T in damage annually by 202511(almost 10% of the projected 2025 global GDP)12, with anannual, accelerating growth rate of 15%.

Morgan, Steve. 2020. “Cybercrime to Cost the World $10.5 Trillion Annually by 2025.” Cybercrime
Magazine. November 10, 2020. https://cybersecurityventures.com/cybercrime-damage-costs-10-trillionby-2025/.
11

Eira, Astrid. 2019. “50 Vital Digital Transformation Statistics: 2020 Spending, Adoption, Analysis & Data.”
Financesonline.com. September 27, 2019. https://financesonline.com/digital-transformation-statistics/.
9

Inc, Barracuda Networks. n.d. “Barracuda Research Reveals Skyrocketing Levels of Bot Traffic.” Www.
prnewswire.com. Accessed April 10, 2023. https://www.prnewswire.com/news-releases/barracuda-researchreveals-skyrocketing-levels-of-bot-traffic-301366777.html.
109© 2023 MOBI. All rights reserved.

Statista. 2010. “Global GDP 2010-2022 | Statista.” Statista. Statista. 2010. https://www.statista.com/
statistics/268750/global-gross-domestic-product-gdp/.
12

Hasan, Mohammad. 2021. “State of IoT 2021: Number of Connected IoT Devices Growing 9% to 12.3 Billion
Globally, Cellular IoT Now Surpassing 2 Billion.” IoT Analytics. September 22, 2021. https://iot-analytics.com/
number-connected-iot-devices/.
13© 2023 MOBI. All rights reserved.

10

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

This dynamic is encapsulated in the Digital Business Trilemma14 proposed by
Dr. Andreas Freund: Only two of three characteristics can be met at the sametime for all participating digital service consumers and providers:»Decentralization»

Security»

PerformanceThis trilemma is a weaker version of the Blockchain Trilemma15 describedby Ethereum founder Vitalik Buterin because in our situation — unlike inthe case of Blockchains — there is no requirement for data consistency andintegrity across all participants.
Since the overall decentralization of digitalbusinesses is outside the control of asingle entity, one must choose whether
to optimize performance or security — aseemingly impossible trade-off.

Therefore, a business can improve security
and performance by better managing its
attack surface by shiftingf computing andstorage for digital services to a network’s
edge.

Then the next question is this: What does
security at the edge require? The answer isZero Trust.

Until now the adoption of self-sovereign
decentralized identities has been slow due
to both a general lack of understanding
surrounding the concepts and the lack of atrusted, yet sufficiently decentralized group ofentities underwriting these identities.

3.2 Use Case: Implementing Battery Passport in a Zero Trust 		
Framework
Global implementation of Battery Passports will enable visibility andtraceability across the value chain in a decentralized environment, meaningzero trust architecture is essential to keep stakeholder data secure as they areshared between trading partners.
Decentralized implementation of the battery
passport will lower the cost of trust, promote
open governance, ensure data integrity,
enable cross-border data privacy compliance,and more.

Since the overall decentralization of digital businesses is outside the control ofa single entity, one must choose whether to optimize the performance or the
security of digital services — a seemingly impossible trade-off. However, thischoice can be made easier by focusing on digital services for subnetworks.
Such subnetworks have lower levels of decentralization i.e., the number ofparticipants.

Implementation of the Battery Passport requires a large number ofstakeholders to share data about carbon footprint, environmental impact,
performance, etc. These stakeholders vary from large suppliers/auto
manufacturers to small businesses and even individual vehicle owners.
While the European Union has not mandated centralized vs. decentralizedarchitecture, we are of the opinion that the latter will:

Therefore, a business can improve security and performance by better
managing its attack surface by shifting computing and storage for digital
services to a network’s edge. This is possible thanks to the rapidly decreasing
computing and storage costs described by Moore’s Law16. Therefore, abusiness can now focus on optimizing security at the edge.
Then the next question is this: What does security at the edge require? The
answer is Zero Trust. This means that no entity trusts another entity at any
given time, even if the prior transaction was trusted. As a consequence, every
participant must minimally be able to authenticate and authorize every otherparticipant for every single digital business interaction at all times.
Since this is not possible through centralized means at scale, we need ways toestablish trusted identities that are self-sovereign and decentralized. In otherwords, we need identities that will be under the control of the transacting
entities at all times without relying on any third party such as Google or Okta
to maintain the security and integrity of the identity. Until now the adoptionof self-sovereign decentralized identities has been slow due to both a generallack of understanding surrounding the concepts and the lack of a trusted, yetsufficiently decentralized group of entities underwriting these identities.

For such an implementation of the Battery
Passport, there must be federated or
decentralized digital Zero Trust architecture.

»

Lower the barriers to entry for any value chain stakeholders to join
and contribute data to the Battery Passport.

»

Enable Web3 components (Self-Sovereign Identity, Layer 2 scaling
stack, distributed storage and processing) to lower the cost of trust
while verifying battery information.

»

Enable the use of open governance for creating open standards andinteroperability.

»

Allow participants to maintain control over their private data,
including which partners receive which updates.

»

Enable data/transaction sharing through a consortium network
directly between partners, without any party sitting in the middle.

For such an implementation of the Battery Passport, there must be federated
or decentralized digital Zero Trust architecture17 since 1) it can easily provide
low-cost identities to entities (companies, individuals, and devices) in theBattery Passport ecosystem; and 2) it provides a common and standardized
identity infrastructure that is not controlled by one centralized entity.
The ITN provides such a Zero Trust infrastructure, which is critical for the
stakeholders’ systems to significantly up-level their security posture due tothe unprecedented level of data exchange between stakeholder systems
horizontally and vertically in the battery value chain.

Integrated Trust Network. 2023. “The Digital Business Trilemma, Zero Trust, and the ITN.” Medium. January
26, 2023. https://itntrust.medium.com/the-digital-business-trilemma-zero-trust-and-the-itn-14d80b9599e8.
14

Buterin, Vitalik. 2021. “Why Sharding Is Great: Demystifying the Technical Properties.” Vitalik.ca. April 7,
2021. https://vitalik.ca/general/2021/04/07/sharding.html.
15

Wikipedia Contributors. 2019. “Moore’s Law.” Wikipedia. Wikimedia Foundation. March 7, 2019. https://en.wikipedia.org/wiki/Moore%27s_law.
1611© 2023 MOBI. All rights reserved.

“Zero Trust Security Model.” 2021. Wikipedia. June 18, 2021. https://en.wikipedia.org/wiki/Zero_trust_security_model.
17© 2023 MOBI. All rights reserved.

12

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

Following is a roadmap detailing the outlook for the ITN in the next 3-5 years:

ITN’s Roadmap»

Create an ecosystem — The ITN leveraged the MOBI community tobuild out its initial ecosystem. Since then, the ITN has expanded toinclude MEF18 and AAIS19, with other consortia to come.

We believe there is a huge business opportunity for solving the
aforementioned problem for which we must build a fundamentally different
federated infrastructure for verification of identities and transactions (trust
anchor) using Web3 principles.

»

Build the infrastructure — MOBI developed the initial ITN
infrastructure and code. MOBI’s Board of Directors authorized thetransfer of the ITN code and libraries to the incorporated ITN in April
2021.

The ITN is the first Web3 infrastructure for trusted, self-sovereign identities
for business automation. The ITN is backed by industry consortia and global
companies representing over $450bn in annual revenue, spanning acrossindustries representing over 18% of global GDP. The ITN was specificallycreated to address the threats to highly decentralized digital business
transactions. As the first federated Certificate Authority (CA) for IoT,
eCommerce, and business automation, the ITN acts as a global trust anchor
for digital business. Using the ITN, businesses will be able to create secure
digital services that are locally highly performant while also decentralized intheir use.

»

Build a network of node operators — This involves onboarding
consortia members as node operators, which is essential for afederated network. Chapter 7 describes how ITN nodes function.

»

Demonstrate the technology with multiparty pilots — MOBI is
working on 6 use cases that involve multiparty business automation.
These use cases include multi-OEM battery birth certificate sharing,
CO2 emissions tracking and reporting, floor plan auditing, vehicle-tobuilding bi-directional charging/discharging, and parts traceability.

»

Seed fundraising from investors including MOBI members — In orderto scale ITN, we require additional funds to take the infrastructure
into production.

»

Take the ITN testnet infrastructure to production — Complete
security audit, scale up the development team, and launch the
production network.

»

Continue building the network with adjacent industries such as
semiconductor manufacturing, energy, and aerospace.

»

Sales and marketing — We plan to market the ITN infrastructureservices to global companies and industries interested in building
Web3 applications.

The ITN leveraged the MOBI community tobuild out its initial ecosystem. Since then,the ITN has expanded to include MEF and
AAIS, with other consortia to come.

The ITN is the first federated Certificate
Authority (CA) for IoT, eCommerce, andbusiness automation.

MOBI is working on 6 use cases that involve
multiparty business automation.

Note: Descriptions about the ITN including the architecture are described insubsequent chapters.
ITN’s history goes back to 2020, when the idea for ITN was conceived, as
shown in Figure 2 below.

Fig 2. ITN Roadmap — Q2 2020 to Q1 2024

13

© 2023 MOBI. All rights reserved.

18

MEF. https://www.mef.net/.

19

https://aaisonline.com/© 2023 MOBI. All rights reserved.

14

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

Integrated Trust Network:
New Federated Certificate Authority

The ITN enables compliance withcybersecurity frameworks such as the federal
Zero Trust mandate.

Order to mandate a Zero Trust cybersecurity framework. This is achievedby requiring that every participant utilizes the ITN through its SSDTTM
authenticates and authorizes every other participant through its SSDTTM forevery single digital business interaction at all times through the usage of W3C
and DIF standards implemented in the SSDTTM — namely W3C Decentralized
Identifiers (DIDs), DIF DID AuthN, and DIF DIDComm 2.0. The details of those
implementations will be detailed in the later part of this document.

5.1 About the Integrated Trust Network
The ITN is a federated network of memberowned and operated ITN nodes designed toovercome the security and resiliency failuresof centralized systems and organizations.

The ITN is targeting almost 20 initial use cases
across the mobility, telecom, and insurance
industries.

The ITN is a federated network of member-owned and operated ITN nodes
designed to overcome the security and resiliency failures of centralized
systems and organizations by providing decentralized digital infrastructure
as the required core trust services of governance, authority, identity, andassurance for multi-party business ecosystems:»

Federated certificate authority based on established standards fromthe World Wide Web Consortium (W3C), the Decentralized Identity
Foundation (DIF), and the Hyperledger Foundation»

Open Source»

Protocol and cloud agnostic»

No centralized control»

Member-owned and operated»

Applicable to any industry and ecosystem20»

Integrates easily with existing corporate systems21»

Fully security audited22

The ITN is targeting almost 20 initial use cases across the mobility, telecom,
and insurance industries. It has also already established initial traction acrossall three industries with over 6 active pilot products utilizing the existing ITN
test network over the last 12 months.

5.2 Unique Value Proposition of ITN
ITN governance is administered through the
ITN Maintainer Council, which consists of ITN
node operators with equal voting rights (oneorganization = one vote).

Fig 3. ITN Governance

ITN MaintenanceCouncil (IMC)

Board ofDirectors (BoD)

Integration capabilities are based on a very common computer language and a simple softwaredevelopment kit (SDK) utilizing API types commonly used on the internet without any assumptions madeabout the connector types to existing computer systems.

»
»

»
»

»

Identity and trust services are universal and not unique to any industry.

21

»
»

»

Furthermore, ITN together with its Self-Sovereign Digital TwinTM (SSDTTM)
enables applications to implement nation-states’ mandates of more stringent
cyber security frameworks as encapsulated by the US Government’s Executive

20

The ITN is organized as a cooperative of its shareholders and is legally
registered as a US California corporation. ITN governance regarding all
financial, operational, technological, legal, and regulatory questions isadministered through the ITN Maintainer Council (IMC), which consists of
ITN node operators with equal voting rights (one organization = one vote).
The operating team of the ITN appointed by the IMC will comprise a small
group of executives, operational and marketing experts, as well as a small
software development team to build and test new ITN features with all noncore business functions outsourced.

Executive
Team

»
»

Equity holders that are also operators of Network Nodes
The decision body (One vote per Operator. Non-operator equity holders
have a right to veto reimbursement payments to Operators)
Network manager (testnet & commercial)
Elects the Board of Directors (Yearly)

5-11 directors, always odd in number and less than the number of
nominees
Nominated by operators
Manages the business affairs of the Corporation◦
Hire and oversee the executive management team (The CEO is thechairperson of the Board)
Elect the President and officers (e.g. secretary, controller)

Experienced Operators (CEO, CFO/COO, CIO/CTO) hired after the SAFE
closes
IMC functions as the executive team until thenThe security audit is not yet complete. Several open-source modules have already been audited with anaudit planned for the custom ITN code base contingent on the rate of ITN fundraising.
22

15© 2023 MOBI. All rights reserved.

© 2023 MOBI. All rights reserved.

16

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

thousands of nodes in production which will allow the ITN to reach its goal ofa large number of globally dispersed ITN nodes.

Furthermore, based on the technical requirements and the measured andreported operational metrics established by the IMC, each ITN node operator
must:

Because the ITN is technically organized
as a federated network, its business value
increases as the square of the number of ITN
nodes as described by Metcalfe’s Law —muchfaster than any centralized entity can.

The ITN has chosen a highly modular,
standards-based architecture to maximize
business value by significantly increasing thenumber of ITN nodes, possibly to hundreds or
thousands over time.

»

Ensure the proper operation and availability of its node(s) – an ITN
node operator can operate more than one node if desired —, and»Ensure the proper security of its node(s).

The business model of the ITN is strictly business-to-business. The initial
customer base of the ITN will be the current 15 ITN node operators themselves.
The ITN node operators will be the first to buy ITN services (typically as service
bundles), package them into new digital products, and sell those products totheir existing customer base of over 100 Million individuals and companies
for a profit. Note that because the ITN is technically organized as a federated
network, its business value increases as the square of the number of ITN
nodes as described by Metcalfe’s Law23 — much faster than any centralized
entity can.
The ITN has chosen a highly modular, standards-based architecture to achieve
its goal of maximizing business value by significantly increasing the numberof ITN nodes, possibly to hundreds or thousands over time. This architecture
utilizes only open-source components comprising the SSDTTM, a core services
module, and a security and data integrity layer. The SSDTsTM can be deployedeither on devices or servers and act as “universal translators” between
company systems and the trust services of the ITN. The ITN core services
component implements ITN identity and assurance services functionalities.
The ITN’s integrity layer component comprises initially one private Distributed
Ledger Technology (DLT) network with each ITN node operator runninga DLT node, and a public DLT where ITN node operators are not operating
DLT nodes24. The ITN only utilizes the data integrity and security capabilities
provided by the public DLT for the ITN services and does not require any
token economics outside of the public DLT’s protocol token.

It is crucial for the ITN both to gain acceptanceand trust within the wider Web3 community.

About The Self-Sovereign Digital TwinTM
6.1 Self-Sovereign Digital TwinTM Introduction
An SSDTTM is a digital representation of aphysical object or system that is owned,
controlled, and managed by its real-world
counterpart.

An SSDTTM is a digital representation of a physical object or system thatis owned, controlled, and managed by its real-world counterpart. It is a
cryptographically secured and cryptographically controlled entity that caninteract with its environment and other digital twins. The concept of SSDTsTM
is based on the idea of self-sovereign digital identity, which is a decentralized
and user-centric approach to identity management. In the context of digital
twins, self-sovereign identity means that an SSDTTM has its own identity, which
is separate from its physical counterpart and can be used to authenticate andauthorize its interactions with other SSDTsTM/applications/networks.

This also means that an SSDTTM serves as an
abstraction and integration layer between ITN
and other applications/networks.

It is designed to be interoperable and communicate with other SSDTsTM acrossdifferent platforms and networks. It is also designed to be secure, with built-in
mechanisms for privacy, data protection, and trust. It is also part of the ITN’s
core service module and, through SSDTTM-to-SSDTTM communication, allows
a user’s SSDTTM to access ITN services. This also means that an SSDTTM serves
as an abstraction and integration layer between ITN and other applications/networks. It is a software-based container that is owned by a distinct andunique entity or thing. (Refer to the Technical Description Section for moredetails)

The approach of using standards and open-source software helps ITN avoid
technology lock-in and provide more network resiliency25 through multiple
technologies and different network types. The intent is to add more DLT
networks over time to further increase resiliency and add technology
diversity. Furthermore, the utilized open-source data storage and replication
technologies in the ITN core services module have proven to scale to

Wikipedia Contributors. 2019. “Metcalfe’s Law.” Wikipedia. Wikimedia Foundation. March 15, 2019.
https://en.wikipedia.org/wiki/Metcalfe%27s_law.
23

Combining public and private DLTs is a promising approach to solve the “Digital Business Trilemma”, theproblem of optimizing conflicting requirements of decentralization, security and performance. More info at:https://itntrust.medium.com/the-digital-business-trilemma-zero-trust-and-the-itn-14d80b9599e8
24

Resiliency with regard to including but not limited significant internet disruptions, zero-day bugs in the codebase of either private or public DLTs, rapid technology shifts in the DLT such as the emergence of new privacy
or transaction scaling frameworks.
25

17© 2023 MOBI. All rights reserved.

Lastly, it is crucial for the ITN both to gain acceptance and trust within thewider Web3 community and to increase ITN adoption by making it easy andtransparent for others to join the ITN network and deploy a node. Therefore,
the ITN will open-source the ITN identity and assurance core services and the
ITN’s SSDTTM with the launch of the production network.

6.2 Purpose of SSDTTM
An SSDTTM combines secure key management,
communication, privacy, and secure data
sharing and offers all those capabilities to its
user in one application.

Secure key management, communication, privacy, and secure data sharing
across different entities in an ecosystem in an interoperable way that allows
integration with legacy enterprise applications are crucial capabilities for a
Zero Trust environment. An SSDTTM combines and offers all those capabilities
to its user in one application.
For example, Self-Sovereign Identity (SSI), which is critical for scalable Zero
Trust architectures, utilizes decentralized private key infrastructure (DPKI)
such as the ITN provides. Therefore, a public/private key management service© 2023 MOBI. All rights reserved.

18

MOBI ITN0001/WP/2023 Version 1.0

Secure data sharing with others — andsecurely replicating one’s own data —has become a cornerstone of businessapplications.

MOBI ITN0001/WP/2023 Version 1.0

is crucial as those keys will be used for signing all business transactions in a
Zero Trust architecture. Furthermore, sensitive identity-associated data such
as Personal Identifiable Information (PII), Verifiable Credentials (held), andVerifiable Presentations (received) require an encrypted data vault (EDV)
service.
Therefore, an SSDTTM provides such a service that ensures the privacy andsecurity of the user’s most sensitive data at all times. To ensure secureinteractions with business applications in a Zero Trust environment, we
require a secure authentication service working with both SSI and legacy
certificates that ensures only authorized parties can access EDV data stored
in the SSDTTM or specific SSDTTM services.

The SSDTTM can also create Verifiable
Presentations that may contain one or more
VCs to share with other entities based onpresentation requests for identification.

The SSDTTM can also create Verifiable Presentations (VPs) that may contain one
or more VCs to share with other entities (with SSDTsTM) based on presentation
requests for identification by other SSDTsTM. The VPs are used as tamperevident proof by an SSDTTM that it legally holds and is correctly presenting,for example, a requested legal identity VC about the DID controlling the
SSDTTM. This functionality uses an implementation of the W3C VP Creation
and Verification standard within the SSDTTM.

To securely share data with other entities
within the ecosystem, an SSDTTM can use the
DID AuthN authentication service within the
SSDTTM to authenticate its interactions withother SSDTsTM or legacy applications via REST
APIs.

Data Sharing with DID AuthN (DID-based authentication) and DIDComm 2.0(DID-based communication): To securely share data with other entities within
the ecosystem, an SSDTTM can use the DID AuthN authentication service
within the SSDTTM to authenticate its interactions with other SSDTsTM or legacy
applications via REST APIs. It can also use the DIF DIDComm 2.0 messaging
protocol to communicate securely with other SSDTsTM within the ecosystem
in combination with the DID AuthN service.

Lastly, secure data sharing with others — and securely replicating one’s own
data — has become a cornerstone of business applications. Therefore, the
SSDTTM offers both a secure data sharing service (with other SSDTsTM) anda secure data replication service (for replication between a user’s SSDTsTM)
while adhering to Zero Trust requirements, without requiring any 3rd party
services to do so.

Encryption in the EDV: The SSDTTM data vault is encrypted using animplementation of the W3C/DIF Encrypted Data Vault standard within the
SSDTTM. This ensures the privacy and security of data with the SSDTTM. The
EDV uses a CouchDB implementation with a Leader-Leader replication toprovide high availability and fault tolerance of entity data across multiple
devices with SSDTsTM controlled by the same DID.

6.3 How Does an SSDTTM Work?
To understand how an SSDTTM delivers its
value, let us use an abstract example that
demonstrates how the SSDTTM works — andhow it works together with the ITN.

To understand how an SSDTTM delivers its value, let us use an abstract example
that demonstrates how the SSDTTM works — and how it works together with
the ITN:An entity such as an enterprise or an individual can create an SSDTTM on oneof several deployment platforms (server, mobile, or desktop client) following
the respective deployment script as can be found in the ITN Github repository.
The SSDTTM can then be initiated and subsequently used through the SSDTTM
Software Development Kit (SDK).

Battery manufacturers will use the W3C VC
Issuance & Verification component within
the SSDTTM to issue a Battery Birth Certificate(in the form of a VC), which is stored in thebattery SSDTTM Encrypted Data Vault as
mentioned above.

The new SSDTTM is given a unique DID after it is launched, which is managed
using the W3C Universal Wallet implementation within the SSDTTM. The DID
is used to authenticate the SSDTTM when it communicates with other entities
within the ITN ecosystem (such as the ITN or other SSDTsTM). The SSDTTM’s
primary function is to manage the life cycle of such DIDs via APIs – create,
update, archive, and read. Note that one SSDTTM can house and manage avirtually unlimited number of DIDs.
The SSDTTM also manages the lifecycle of
Verifiable Credentials that contain claims
about the credential subject and assertions of
those claims by the VC issuer.

19© 2023 MOBI. All rights reserved.

The SSDTTM also manages the lifecycle of Verifiable Credentials (VCs) that
contain claims about the credential subject (most often the DID(s) managed
by the SSDTTM) and assertions of those claims by the VC issuer. When the
SSDTTM needs to communicate with other entities (that have SSDTsTM)
within the ITN ecosystem via its APIs, it can use VCs to prove its identityand verify the identity proofs of other SSDTsTM. This is done using the W3C
Verifiable Credential Issuance and Verification standard that is implemented
within the SSDTTM as APIs. These VCs are stored in the SSDTTM EDV using animplementation of the W3C/DIF Encrypted Data Vault standard.

A simple use case demonstrates these capabilities. A battery manufacturer
creates an SSDTTM for a battery once it is off the production line. Hence, eachbattery has its own Battery SSDTTM with a unique DID that is managed using
the W3C universal wallet implementation within the SSDTTM. The battery
DID is used to authenticate the Battery SSDTTM when it communicates withother SSDTsTM within the ITN ecosystem, such as the car that the battery is
installed in for data exchange, the SSDTTM of the battery owner, the SSDTTM ofa regulatory agency, or the SSDTTM of a vehicle service shop trying to analyze
a malfunction and having to authenticate itself to gain access to battery data.
Battery manufacturers will use the W3C VC Issuance & Verification component
within the SSDTTM to issue a Battery Birth Certificate (in the form of a VC),
which is stored in the battery SSDTTM Encrypted Data Vault as mentioned
above.
Another use case is when a vehicle OEM receives a battery from its
manufacturer. The battery manufacturer digitally creates a VP with theBattery Birth Certificate VC using the W3C VP Creation and Verification
standard implementation within the SSDTTM and presents it to the vehicle
OEM to install and then create a VC documenting that a specific battery was
installed in a specific car.

The Battery Birth Certificate VC is just one VC
type.

Note: The Battery Birth Certificate VC is just one VC type. Based on the use
case, workflow, and other entities involved there can be various types of VCs
issuance and verification. Different VP creations may occur over time.

© 2023 MOBI. All rights reserved.

20

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

6.4 SSDTTM Architecture and Technical Descriptions

Implementation of ITN Data Sharing APIs bothas REST and as DIDcomm endpoints.

Authentication (OAuth2 | DIF DID AuthN) — Authentication service utilizing
OAuth2 for REST APIs27 and DIF DID AuthN28 for DIF DIDcomm messaging.
Implementation of ITN Data Sharing APIs both as REST and as DIDcomm
endpoints.

One major challenge with existing wallet types
is the need to manage multiple digital assets
across various platforms and applications.

W3C Universal Wallet 2020 — There are several types of wallets out there.
One major challenge with existing wallet types is the need to manage multiple
digital assets across various platforms and applications. Other challenges
include remembering multiple passwords, the risk of losing private keys, andthe difficulty of transferring assets between different wallets. The solution to
the above problems was addressed in W3C Universal Wallet 202029, which
provides a single, secure, interoperable way for users to manage and control
their digital assets, including their keys and documents.

The SSDTTM utilized in each ITN node is implemented in NodeJS and comprises
the following elements:
DIF DIDComm messaging protocol provides asecure, private communication methodology
built on top of the decentralized design of
DIDs.

Strong Decentralized Protocols — There are already strong protocols in place
for secure communication, but the majority of these depend on centralized
entities such as key registries, identity providers, certificate authorities,
browser or app vendors, or similar organizations, whereas DIF DIDComm
messaging enables higher-order protocols that inherit its security, privacy,
decentralization, and transport independence. DIF DIDComm26 messaging
protocol provides a secure, private communication methodology built on
top of the decentralized design of DIDs. That is why developers chose API
Service Endpoints for both REST APIs and DIF DIDComm messaging protocol
for integration with ITN Core Services, other SSDTsTM, and Legacy Applications
via REST APIs. Refer to the design goals of DIDs and DIDComm messaging
design-specific requirements for more details.

W3C VC Issuance and Verification — In today’s digital world, personal data
is often scattered across various centralized databases and is controlled bydifferent organizations, each with its own access policies and procedures. This
comes with many privacy concerns and security risks and creates inefficiencies
not only in the exchange of data but in the verification of the data as well. This
is where W3C VC Issuance and Verification standard, along with DIDComm,
enables the secure, privacy-preserving, and efficient exchange of VCs andmessages in a decentralized manner. That is why developers choose an
implementation of the W3C VC Issuance and Verification standard both as
REST APIs and as DIDcomm endpoints.

Fig 4. ITN Self-Sovereign Digital TwinTM

Today, personal data is stored in centralized
data storage systems controlled by 3rd party
organizations.

W3C/DIF Encrypted Data Vault — There are limitations to the current
centralized data storage solutions. Today, personal data is stored incentralized data storage systems controlled by 3rd party organizations, whichmakes the data vulnerable to cyber attacks, data breaches, and misuse byunauthorized parties. Additionally, individuals have little control over theirpersonal data, and it can be difficult to access and manage their data acrossdifferent services and various platforms. This creates privacy concerns andinefficiencies in addition to hindering innovation. W3C/DIF EDV solves theseissues by providing a secure and decentralized storage solution wherein theuser has complete control over their data and no third-party organization
can access it without the user’s consent. That is why developers choose an
implementation of the W3C/DIF Encrypted Data Vault30 for document storage
currently utilizing CouchDB with Leader-Leader replication.

27“OAuth 2.0 — OAuth.” 2020. Oauth.net. 2020. https://oauth.net/2/.

“DIF - Authentication Working Group.” n.d. Identity.foundation. Accessed April 10, 2023. https://identity.
foundation/working-groups/authentication.html.
28“Universal Wallet 2020.” n.d. W3c-Ccg.github.io. Accessed April 10, 2023. https://w3c-ccg.github.io/
universal-wallet-interop-spec/.
29“DIDComm Messaging Specification v2 Editor’s Draft.” n.d. Identity.foundation. Accessed April 10, 2023.
https://identity.foundation/didcomm-messaging/spec/.
26

21© 2023 MOBI. All rights reserved.

“Confidential Storage 0.1.” n.d. Identity.foundation. Accessed April 10, 2023. https://identity.foundation/
confidential-storage/.
30© 2023 MOBI. All rights reserved.

22

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

Efficiency: ITN nodes allow for fast and efficient processing of

About The ITN Nodetransactions as it is a permissioned network. This can lead to
reduced costs, which can benefit organizations.

7.2 How Does the ITN Work?
All ITN Nodes communicate with one anotherusing standardized communications protocols
and in accordance with DLT principles.

An ITN node is a software stack which»

Provides ITN Core Services – DID CRUD functions and Proof-of-		
Correct-Execution Write and Read services,»

Is operated by an ITN Node Operator, and»Is connected to other ITN nodes in the ITN network.

An ITN node’s software stack typically runs in a cloud environment operated
by an identifiable organizational entity. All ITN Nodes communicate with one
another using standardized communications protocols and in accordancewith DLT principles. (Refer to the Technical Description Section for moredetails)

Before going into details it is important to understand how the ITN defines
identity:

ITN Identity = <ITN Identifier> + <associated data>
The ITN services target the ITN Identifier.
Identity-associated data such as W3C VCs will
be stored in the ITN SSDTTM used by ITN users.

The ITN identifier is specified in accordance with the W3C DID Specification:

7.1 Purpose of ITN NodeAn ITN node is the fundamental building
block of the ITN and enables organizations toperform Zero Trust compliant digital business
transactions.

ITN Identifier = ITN DID

An ITN node is the fundamental building block of the ITN and enables
organizations to perform Zero Trust compliant digital business transactions byproviding a resilient and secure decentralized SSI infrastructure and business
transaction assurance services such as the Proof-of-Correct-Execution.
Fundamentally, the ITN offers:

Where the DID is to be derived as the sha3-256 hash of a random salt of
sufficient entropy. The ITN defines the structure of its DID to be:

Decentralization: ITN Nodes enable the creation ofdecentralized networks. This ensures that the network is more
resilient and less susceptible to attacks as there is no single pointof failure.

Security: ITN nodes utilize standardized communication
protocols and DLT principles to ensure that transactions are
secure and tamper-proof. By utilizing cryptographic algorithms,
ITN nodes can verify the identity of participants, validate
transactions, and ensure that data is kept confidential.

The ITN services target the ITN Identifier. Identity-associated data such as
W3C VCs will be stored in the ITN SSDTTM used by ITN users. This makes the
ITN SSDTTM a true representation of an ITN user’s digital identity and allows
them to participate in any digital business transaction, including thoserequiring Zero Trust.

did:itn:sha3-256(salt)

The primary credential facilitated by the ITN
will be the ITN Digital Passport issued by the
MOBI as its membership credential.

The W3C DID specification does not specify how a DID is generated and leaves
it up to the implementation, provided it ensures uniqueness to a high degreeof confidence.
The primary credential facilitated by the ITN will be the ITN Digital Passport
issued by the MOBI as its membership credential.

Accessibility: ITN nodes can be accessed from anywhere withan internet connection, enabling organizations to participate
in the network regardless of their location. Also, identity dataanchored on-chain is replicated across all ITN nodes to avoid
downtime for ITN core services.

23© 2023 MOBI. All rights reserved.

© 2023 MOBI. All rights reserved.

24

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

ITN Core Services are comprised of the following endpoints:

Create an Identifier
Based on the DID data schema context fileand the DID method, the ITN process anchorsa DID and its DID document and delivers it to
the requestor.

Description: Based on the DID data schema context file and the DID
method, the ITN process anchors a DID and its DID document and delivers it
to the requestor.

Request Create Identity
Based on one or more credential context files
and a DID method, the ITN process createsa list of document requirements that aredelivered to the VC requestor from the VC
Issuer, either directly or through a 3rd party
service.

Constraints: This can be invoked by any entity with a DID. Compliance withcredential context file(s) and DID method requirements is required.

Constraints: This can only be invoked by the DID Controller(s). Compliancewith the DID data schema and DID method requirements.

Register Identity

Get an Identifier
Description: Based on the DID data schema context file and the DID
method, the ITN process delivers a DID document in accordance with the
W3C DID standard.

An Identity VC is revoked by the VC issuer
based on a chosen revocation method, andthe VC revocation is registered by the ITN
service.

Constraints: Compliance with the DID data schema context file and DID
method requirements is required. Any organization should be able to invoke
the process.

Revoke an Identifier
Description: Based on the DID data schema context file and the DID
method, the ITN process revokes an existing DID and its DID document inaccordance with the W3C DID standard.
Constraints: Compliance with the DID data schema context file and the DID
method is required. This can only be invoked by the DID controller(s).

Deactivate an Identifier

Constraints: This can only be invoked by the DID of the VC subject.

Description: An Identity VC is revoked by the VC issuer based on a chosen
revocation method, and the VC revocation is registered by the ITN service.
Constraints: This can only be invoked by the Identity VC issuer.

Description: Based on the DID data schema context file and the DID
method, the ITN process creates an updated DID document in accordancewith the W3C DID standard.
Constraints: This can only be called by the DID controller(s). Compliancewith the DID data schema context file and DID method requirements isrequired.

Description: The identity VC of the requestor is registered onto the ITN by
the ITN service and the registration attestation is delivered to the requestor.

Revoke Identity

Update an Identifier
Based on the DID data schema context fileand the DID method, the ITN process creates
an updated DID document in accordance with
the W3C DID standard.

Description: Based on one or more credential context files and a DID
method, the ITN process creates a list of document requirements that aredelivered to the VC requestor from the VC Issuer, either directly or througha 3rd party service. Upon presentation of document requirements, the VC
issuer issues the Identity VC and delivers it to the VC Requestor.

Write Proof-of-Execution
ITN service retrieves a Proof of Correct Stateof an Enterprise application or network froma Smart Contract that can be used by another
Enterprise to verify the state of an applicationor network at the point in time the proof wascommitted.

Description: ITN service writes a Proof of Correct State of an Enterpriseapplication or network into a set of ITN DLT Smart Contracts that can beused by another Enterprise to verify the state of an application or networkat the point in time the proof was committed
Constraints: Anyone can invoke this service.

Get Proof-of-Execution
Description: ITN service retrieves a Proof of Correct State of an Enterpriseapplication or network from a Smart Contract that can be used by another
Enterprise to verify the state of an application or network at the point intime the proof was committed.
Constraints: Anyone can invoke this service.

Description: Based on the DID data schema context file and the DID
method, the ITN process deactivates a DID and its DID document inaccordance with the W3C DID standard.
Constraints: Compliance with the DID data schema context file and the DID
method is required. This can only be invoked by the DID controller(s).

25© 2023 MOBI. All rights reserved.

© 2023 MOBI. All rights reserved.

26

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

For details on SSDTsTM, please refer to a) So, What Is a Self-Sovereign Digital
Twin (SSDTTM)? and b) SSDTTM Architecture, Technical Description, andStandards Used

7.3 ITN Architecture and Technical Descriptions
Each ITN node is a permissioned networkof nodes, meaning that access to the ITN
network is restricted to authorized parties
only.

Each ITN node is a permissioned network of nodes, meaning that access to
the ITN network is restricted to authorized parties only.

The Core-DLT-API Gateway is used to interact with the DLT networks of the
ITN, while the NodeJS application integrates with the ITN SSDTTM and ApacheKafka, along with Redis. The Service-API-to-DLT-API application serves as abridge between the different DLT networks of the ITN and also integrates with
Apache Kafka; for a (micro) service-oriented architecture these components
serve as necessary abstractions for loose architecture coupling.

Each ITN node is made of several key components. At the center is an SSDTTM
of the ITN node, which is used to represent the node and interact with theother components of the network. Surrounding the SSDTTM are a number
of applications, including a Core-DLT-API Gateway, a NodeJS application, aService-API-to-DLT-API application, and a DID Resolver.

Fig 5. ITN Core Services Architecture for each Core Services NodeThe DID Resolver is responsible for resolving
decentralized identities and is integrated with
the SSDTTM of the ITN node.

Each DLT node is integrated with the ServiceAPI-to-DLT-API, which helps to ensure that alltransactions are verified and validated before
being added to the ledger.

The DID Resolver is responsible for resolving decentralized identities and is
integrated with the SSDTTM of the ITN node. Finally, the ITN node also utilizes
a Content Addressable Storage (CAS) Network, which is an implementationof an OrbitDB31 with content-addressable hashes and a Leader-Leader
replication between ITN nodes. Developers chose OrbitDB because:»

It uses IPFS and is a serverless, distributed, true peer-to-peer
database.

»

It is tamper-resistant as data is cryptographically hashed andreplicated across multiple nodes in the network, making it very
difficult for anyone to tamper with the data.

»

Additionally, it is designed to work even when network connectivity
is limited or non-existent. This makes it well-suited for applications
that need to continue functioning in low-bandwidth or high-latency
environments.

The DLT networks of the ITN are initially comprised of a Hyperledger Fabricnetwork, with more networks to be added in the future. Each DLT node isintegrated with the Service-API-to-DLT-API, which helps to ensure that alltransactions are verified and validated before being added to the ledger.

7.4 Description of Two ITN Example Workflows
How can one use ITN SDK for identity creation and other purposes? The
two example ITN workflows below demonstrate this process using thecomponents described in Figure 5.

31

27© 2023 MOBI. All rights reserved.

»

Creating an ITN DID in accordance with the W3C DID Specification»

Issuance of an ITN membership credential by MOBI

“OrbitDB.” n.d. GitHub. Accessed April 10, 2023. https://github.com/orbitdb.

© 2023 MOBI. All rights reserved.

28

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

Fig 6. Create-Identifier Use Case29

© 2023 MOBI. All rights reserved.

© 2023 MOBI. All rights reserved.

30

MOBI ITN0001/WP/2023 Version 1.0

The controller of the primary enterprise DID
initiates a Create Identifier Message froman application and sends that message tothe application that manages the Enterprise
SSDTTM.

The Enterprise SSDTTM application invokes the
DID AuthN with the ITN (Core Service) SSDTTM
to verify the authenticity of its DID first.

The DLTs currently supported by the ITN are
Hyperledger Fabric 2.5 (a private network)
and Arbitrum One (a public network).

31© 2023 MOBI. All rights reserved.

MOBI ITN0001/WP/2023 Version 1.0

7.4.1 Workflow to create an ITN DID based on W3C DID

9.

An enterprise wants to create a new DID for one of its entities such as a
subsidiary, an employee, or a device. The controller of the primary enterprise
DID initiates a Create Identifier Message from an application and sends
that message to the application that manages the Enterprise SSDTTM. Thisapplication transforms the message into an ITN standard message using the
ITN SSDTTM SDK.

10. The ITN Core Service SSDTTM returns the message completion to therequesting Enterprise SSDTTM.

1.

The Enterprise SSDTTM application invokes the DID AuthN with the
ITN (Core Service) SSDTTM to verify the authenticity of its DID first.
The ITN Core Services DID Resolver retrieves the DID documentfrom ITN’s CAS solution (Orbit DB) together with the Anchor Proof
from the ITN DLT(s). Note that all traffic between SSDTsTM and within
the ITN is encrypted.

2.

Once the requestor’s DID and the message signature are verified,
the Core Service SSDTTM and Enterprise SSDTTM application use theDiffie-Hellman Key Exchange method utilized in an SSDT to create asymmetric encryption key for all payloads.

3.

The Enterprise SSDTTM sends the Create Identifier Message — whichcontains the DID and DID document to be anchored — to the ITNCore Service SSDTTM.

4.

The ITN Core Service SSDTTM transforms the request message andpushes the message into the ITN Core API Getaway to anchor the
DID.

5.

The Core-API-Gateway-to-DLT-API Application pulls the newmessage off the ITN Core API Gateway and calls the ITN Core DLT(s)through the DLT API Gateway to anchor the new DID and the hashof the DID document into a smart contract on the supported DLT(s).
The DLTs currently supported by the ITN are Hyperledger Fabric 2.5(a private network) and Arbitrum One (a public network).

6.

The ITN-supported DLT(s) execute the transactions and returnthe DLT transaction receipts to the Core-API-Gateway-to-DLT-API
Application.

7.

The Core-API-Gateway-to-DLT-API Application updates the ITN
CAS with the DID, DID Document, and the transaction receipts as
metadata.

8.

The Core-API-Gateway-to-DLT-API Application then updates therequest message in the ITN Core API Gateway as complete.

The Enterprise SSDTTM stores the new DID with
its DID Document and transaction metadata
in the SSDTTM.

The ITN Core Service SSDTTM pulls the completed message off the ITNCore API Gateway and transforms the message with the anchored
DID back into ITN format.

11. The Enterprise SSDTTM stores the new DID with its DID Document
and transaction metadata in the SSDTTM, transforms the message
data into the required enterprise format, and returns the message
to the requesting Enterprise application.

©
©2023
2023MOBI.
MOBI.All
Allrights
rightsreserved.
reserved.

32

MOBI ITN0001/WP/2023 Version 1.0

MOBI ITN0001/WP/2023 Version 1.0

The starting point is an Enterprise with its own DID that wants to acquirean ITN membership credential. To find out how to reach the MOBI SSDTTM
required for the issuance, the Enterprise needs the MOBI DID Document. The
required MOBI SSDTTM communication endpoints for credential issuance canbe found in the `services` section.

7.4.2 Workflow to issue ITN membership credential by MOBIThis ITN workflow allows an organization with an existing ITN DID to request
the issuance of a MOBI membership credential by MOBI itself.

Fig 7. Request-Identity and Create-Identifier Use Case

An Enterprise application calls the Enterprise
SSDTTM application with a payload that
contains the DID of the enterprise and adigital credential.

With the MOBI DID Document, the Enterprise
SSDTTM finds the MOBI communication
endpoint and sends an encrypted requestidentity-message.

The MOBI SSDTTM verifies the signatures on
the Enterprise DID Document and generates asymmetric encryption key.

1.

An Enterprise application calls the Enterprise SSDTTM application
with a payload that contains the DID of the enterprise and a digitalcredential that proves the identity of the Enterprise such as an X.509
certificate or a GLEIF Verifiable Credential of identity32.

2.

The Enterprise SSDTTM transforms the request message and makes
an encrypted API call to the ITN Core Service SSDT.

3.

The ITN Core Service SSDTTM responds to the API call by resolving
the MOBI DID and returning the MOBI DID Doc with On-Chain Proof
to the Enterprise SSDTTM.

4.

With the MOBI DID Document, the Enterprise SSDTTM finds the
MOBI communication endpoint and sends an encrypted requestidentity-message to the MOBI SSDTTM.

5.

The MOBI SSDTTM decrypts the request message and calls the ITNCore Service SSDTTM through an encrypted DIDComm channel toresolve the Enterprise DID and obtain the Enterprise DID Document.

6.

The ITN Core Service SSDTTM returns the Enterprise DID Doc with the
DLT Anchor Proof to the MOBI SSDTTM.

7.

The MOBI SSDTTM verifies the signatures on the Enterprise DID
Document and generates a symmetric encryption key using theDiffie-Hellman key exchange protocol for DIDComm payload
encryption.

8.

The MOBI SSDTTM then invokes the request-membership proof
presentation API of the Enterprise SSDTTM to request proof from theEnterprise that it is an ITN member.

9.

Based on the presentation request which contains the required
JSON data schema for the proof, the Enterprise SSDTTM generates
the Identity Proof and returns it to MOBI SSDTTM API endpoint.

10. MOBI SSDTTM decrypts the response message with the proof, verifies
the proof, and calls an ITN Core Service API to check the revocation
status of the Enterprise’s membership.

GLEIF. n.d. “Introducing the Verifiable LEI (VLEI) - VLEI – GLEIF.” Introducing the Verifiable LEI (VLEI) - VLEI –GLEIF. Accessed April 10, 2023. https://www.gleif.org/en/vlei/introducing-the-verifiable-lei-vlei.
32

33© 2023 MOBI. All rights reserved.

© 2023 MOBI. All rights reserved.

34

MOBI ITN0001/WP/2023 Version 1.0

The MOBI SSDTTM creates a membership VC
with an ITN digital signature and registers the
ITN Membership VC as not revoked in the ITNCore Service.

MOBI ITN0001/WP/2023 Version 1.0

11. If the Enterprise’s ITN membership is not revoked (check yields anegative response), the MOBI SSDTTM creates a membership VC withan ITN digital signature and registers the ITN Membership VC as not
revoked in the ITN Core Service.
12. The MOBI SSDTTM packages the membership VC into a VP andpresents the VP with the VC to the Enterprise SSDTTM through its
presentation API endpoint.

References

13. The Enterprise SSDTTM verifies the VP and stores the VC in the EDVof the Enterprise SSDTTM for future use.

Confidential storage 0.1. Accessed April 6, 2023. https://identity.foundation/confidential-storage/.
Curren, Sam, Tobias Looker, and Oliver Terbu. “Didcomm Messaging v2.x Editor’s Draft.” DIDComm Messaging
Specification v2 Editor’s Draft. Accessed April 6, 2023. https://identity.foundation/didcomm-messaging/spec/.
Curren, Sam, Tobias Looker, and Oliver Terbu. “Didcomm Messaging v2.x Editor’s Draft.” DIDComm Messaging
Specification v2 Editor’s Draft. Accessed April 6, 2023. https://identity.foundation/didcomm-messaging/spec/#specificrequirements.
“DIF DID AuthN.” DIF - Authentication Working Group. Accessed April 6, 2023. https://identity.foundation/workinggroups/authentication.html.
Gleif. “Introducing the Verifiable Lei (Vlei) - Vlei.” GLEIF. Accessed April 6, 2023. https://www.gleif.org/en/vlei/introducingthe-verifiable-lei-vlei.
“OAuth 2.0.” OAuth. Accessed April 6, 2023. https://oauth.net/2/.
“OrbitDB.” GitHub. Accessed April 6, 2023. https://github.com/orbitdb.
Sporny, Manu, Dave Longley, Christopher Allen, Orie Steele, Drummond Reed, and Markus Sabadello. “Decentralized
Identifiers (Dids) v1.0.” W3C. Accessed April 6, 2023. https://www.w3.org/TR/did-core/.
Sporny, Manu, Dave Longley, Christopher Allen, Orie Steele, Drummond Reed, and Markus Sabadello. “Decentralized
Identifiers (Dids) v1.0.” W3C. Accessed April 6, 2023. https://www.w3.org/TR/did-core/#design-goals.
Universal wallet 2020. Accessed April 6, 2023. https://w3c-ccg.github.io/universal-wallet-interop-spec/

35

©2023
2023MOBI.
MOBI.All
Allrights
rightsreserved.
reserved.
©

© 2023 MOBI. All rights reserved.

36