1MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

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 definedby 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
to software 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,and conversions 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 thisLicense, Derivative Works shall not include works that remain separable from, or merely link (orbind by name) to the interfaces of, the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including the original version of the Work andany modifications or additions to that Work or Derivative Works thereof, that is intentionallysubmitted 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 thisdefinition, "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 or otherwise designated in writing by the copyrightowner as "Not a Contribution."© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom aContribution 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, eachContributor 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
combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.
If You institute patent 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 shall terminate 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 meet the following conditions:a. You must give any other recipients of the Work or Derivative Works a copy of this License; andb. You must cause any modified files to carry prominent notices stating that You changed thefiles; andc. You must retain, in the Source form of any Derivative Works that You distribute, all copyright,
patent, trademark, and attribution notices from the Source form of the Work, excluding those
notices that do not pertain to any part of the Derivative Works; andd. If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that
You distribute must include a readable copy of the attribution notices contained within such
NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in atleast one of the following places: within a NOTICE text file distributed as part of the Derivative
Works; within the Source form or documentation, if provided along with the Derivative Works; or,within a display generated by the Derivative Works, if and wherever such third-party notices
normally appear. The contents of the NOTICE file are for informational purposes only and do not
modify the License. You may add Your own attribution notices within Derivative Works that You
distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such
additional attribution notices cannot be construed as modifying the License.
You may add Your own copyright statement to Your modifications and may provide additional
or different license terms and conditions for use, reproduction, or distribution of Your
modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

distribution of the Work otherwise complies with the conditions stated in this License.
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 conditionsof this License, without any additional terms or conditions. Notwithstanding the above, nothingherein shall supersede or modify the terms of any separate license agreement you may haveexecuted 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 andcustomary use in describing 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 theappropriateness of using or redistributing the Work and assume any risks associated with Your
exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory, whether in tort (including
negligence), contract, or otherwise, unless required by applicable law (such as deliberate andgrossly negligent acts) or agreed to in writing, shall any Contributor be liable to You fordamages, including any direct, indirect, special, incidental, or consequential damages of any
character arising as a result of this License or out of the use or inability to use the Work (including
but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction,or any and all other commercial damages or losses), even if such Contributor has been advisedof the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works
thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty,
indemnity, or other liability obligations and/or rights consistent with this License. However, in
accepting such obligations, You may act only on Your own behalf and on Your sole
responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend,
and hold each Contributor harmless for any liability incurred by, or claims asserted against, such
Contributor by reason of your accepting any such warranty or additional liability.
Licensed under the Apache License, Version 2.0 (the "License"). You may not use this file except
in compliance with the License.
END OF TERMS AND CONDITIONS© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Introduction
This standard was issued by MOBI and its members. MOBI is a nonprofit alliance of many of theworld’s largest vehicle manufacturers, startups, governments/transit agencies, NGOs, financial
institutions, e-mobility providers, consultancies, suppliers, logistics providers, and more working tocreate standards and build the Web3 digital infrastructure for connected ecosystems and IoT
commerce.
MOBI is creating standards for trusted self-sovereign data and identities (e.g. vehicles, people,
businesses, things), verifiable credentials, and cross-industry interoperability, with the goal of
making transportation more efficient, equitable, decentralized, and circular, all while preserving
the data privacy of users and providers alike. MOBI is technology and ledger agnostic. The workof preparing standards is carried out through MOBI Working Groups. Each member of theconsortium interested in a subject for which a Working Group has been established has the rightto be represented and participate in that Working Group.
The procedures used to develop this document and those intended for its further maintenanceare described in the working group charter. In particular, the different approval criteria needed
for the different types of MOBI documents should be noted. Approvals of MOBI Steering
Committee and Board of Directors are obtained upon the final document release. Attention isdrawn to the possibility that some of the elements of this document may be the subject ofintellectual property rights. In accordance with MOBI IPLR policy, a 60-day review period isprovided to the MOBI community to disclose any and all IP matters pertaining to this standard.
MOBI shall not be held responsible for identifying any or all such rights. Details of any IP rights
identified during the development of the document will be in the Introduction upon public
release of this standard.
Any trade name used in this document is provided for the convenience of users and does notconstitute an endorsement. The Working Group responsible for this document is the Vehicle
Identity I (VID I) Working Group. Sincere thanks and appreciation are extended to those who
contributed their unique insights to the VID I Technical Specifications.
Contact
connect@dlt.mobi© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Authors
Griffin Haskins, MOBI
Rajat Rajbhandari, MOBI

Andreas Freund, MOBI
Sid Masih, MOBIWG Co-Chairs
Sebastien Henot, Renault Group

Alan Gordon, Ford

MOBI Team
Tram Vo, CEO + Founder
Chris Ballinger, Advisor + Founder
Rajat Rajbhandari, Head of Standards & Certification
Andreas Freund, CTO

Matt Shi, Supply Chain Lead
Betul Kahya, Mobility Lead
Parth Bhatt, Technical Product Manager
Grace Pulliam, Communications Manager

Contributors
Praveen Abbaraju, Hitachi
Steve Amancha, State FarmMark Anders, Ford
Hiromasa Aoki, TradeLog
Alessandro Arciero, Henshin Group
Mitsuharu Arinori, TradeLog
Murad Baig, Netsoltech
Sebastian Banescu, Quantstamp
Joe Bannon, KAR Auction Services
Patrick Bartsch, AWS
Brian Behlendorf, Hyperledger Foundation
Massimo Belluz, Henshin Group
Roger Berg, DENSOBill Brewster, Olinda SolutionsPeter Busch, Trusted IoT Alliance
Lucie Chabert, Stellantis
Alex Choo, ASJade
Nicola Cianci, Stellantis
Etienne Costet, Stellantis
Michelle Corson, On The Road Lending
Claudia Damari, Henshin Group
Daisuke Date, Mazda
Pierre Delaunay, Stellantis
Martin Derka, Quantstamp
Steven Douglas, DENSO
Olivier Emsalem, Stellantis
Aaron Fong, Honda
Daniel Fox, Olinda Solutions
David Freeman, DLT Labs
Masahiro Fujita, TradeLog
Sanshiro Fukao, ITOCHU© 2024 MOBI. All rights reserved.

Matteo Gandolfi, Henshin Group
Fabrizio Garetto, Stellantis
Todd Gehrke, Luxoft
John Gerryts, Oaken Innovations
Alan Gordon, Ford
Shigemitsu Hara, Orico
Kawanishi Hiromi, Mazda
Kinoshita Hiroshi, Mazda
Max Huang, Celebri AI
Haolun Huang, DENSO
Tooru Inoue, Orico
Alvin Ishiguro, TradeLog
Hitoshi Iwamoto, Honda
Divyesh Jadav, IBM
Nick James, AWS
Sajit Janardhanan, AWS
Matthew Jones, IBM
Kazuya Kamata, TradeLog
Motohisa Kamijo, Nissan
Masaru Kakuchi, Orico
Yoji Kawanishi, ITOCHU
Toru Kimura, Honda
Christian Koebel, Honda
Yasuhiro Komine, Honda
Karthik Krishnamurthy, AWS
Audrius Kucinskas, CarVertical
Jignesh Kumar, DENSO
Subrata Kundu, Hitachi
Frederic Legrand, Stellantis
Chengnian Long, CPChain
Phebe Lu, ASJadeMOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Kanishk Mahajan, Accenture
Ishii Makoto, Mazda
Domenico Mangiacapra, Henshin GroupJim Mason, DMX
Hisashi Matsumoto, Anritsu
Eiji Matsumura, Anritsu
Lowell McComb, BMW
Richard Meszaros, Accenture
Takuya Mimori, Vitesco
Emmanuel Monzies, Stellantis
Takumi Mori, Hioki
Ryosuke Morisada, Mazda
Tsunehiko Murai, OricoHiroaki Murase, ITOCHU
Ash Naik, AAIS
Hiroshi Nakajima, Orico
Yasuhiro Nakayama, AUCNET
Taro Nakata, Kaula Lab
Alberto Nasi, Stellantis
Andrea Neri, Stellantis
Keisuke Nisugi, TICO
Matsuo Naoya, TradeLog
Takehisa Obara, Hioki
Yasuhiko Ogushi, Kaula Lab
Shuichi Ohki, Kaula Lab
Harunobu Ohmae, ITOCHU
Katsuji Okamoto, Kaula Lab
Mitsuyuki Okano, Orico
Adewale Omoniyi, AWS
Sunil Paul, SpringFreeEVFrancesco Petrignani, Traent
Boris Polania, Honda
Christian Poulain, Stellantis
Nick Pudar, GM
Mathias Reinhartz, Stellantis
Sandeep Saini, Vitesco
Futoki Saito, ITOCHU
Yoshihide Sakai, ITOCHU© 2024 MOBI. All rights reserved.

Davide Salerno, Henshin Group
Shoki Sato, Orico
Takashi Sendo, TradeLog
Fabio Severino, Traent
Otto Schell, Stellantis
Vyacheslav Sharipov, Aucnet
Mark Shih, ASJade
Kikuchi Shinichi, Mazda
Arwen Smit, MintBit/MOBI
Sudha Sriram, Ford
Suresh Sundararaj, Ford
Srinivasa Sunil, Vitesco
Yoshinori Suzue, Nissan
Katsutoshi Yamazaki, Honda
Yasuhiko Yuasa, Honda
Priya Tabaddor, Cognizant
Nobuaki Tabata, Mazda
Yasuhiro Takabe, Mazda
Yuhei Takai, ITOCHU
Takahara Shinji, Mazda
Tatsurou Takahashi, Mazda
Tetsuya Takahashi, Hioki
Leonardo Tapanelli, Stellantis
Sam Teng, ASJade
Sajjad Thaika, Accenture
Vitthal Thamke, Vitesco
Shinnosuke Tsuboyama, Mazda
Kaiho Tsuneki, Softbank Drive
Long Tran, AWS
Christain Umbach, Xapix
Hisakazu Usui, Mazda
Wanda Wang, AIOI Insurance
Takashi Watanabe, Anritsu
Spencer White, Ford
Xin Xu, DENSO
Kubota Yasuyuki, Mazda
Xiaoliang Zhu, Hitachi

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Table of Contents
1. About MOBI Vehicle Identity (VID) I Technical Specifications (Tech Specs)

1

2. Scope of MOBI VID I Tech Specs2

3. Glossary of Terms

2

4. Typographical Conventions

5

5. General System Requirements

55.1. Overview

55.2. System Security and Identity

6

5.3. Security Considerations

6

5.4. Addressing and Uniform Resource Identifiers

7

6. Certificate Data Format

7

6.1. Unique Vehicle Identifier (UVI)

7

6.2. Vehicle Birth Certificate (VBC)

8

7. Entities

12

7.1. Overview

127.2. Entity Certificate

128. References

14

Changelog:
VersionDate Release

Updates

1.0.

07/2019

N/A

1.1.

09/2023

Changed Section 3 title from “System Overview” to “Overview”

2.0.

03/2024

Full rewrite of the Standard, converting it into a concise set oftechnical requirements. Removed all system-level requirements,
making this standard a data specification© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 1

1. About MOBI VID I Tech Specs
This document specifies the first standard for MOBI Vehicle Identity (VID), which represents theprincipal digital foundation of future mobility. The Vehicle Identification Number (VIN), a current
vehicle identity system, is insufficient for the digitization of many mobility use cases such as
maintenance history, usage-based insurance, microtransactions, and, ultimately, the creation of
a vehicle’s Self-Sovereign Digital Twin™1 (a Self-Sovereign Digital Twin™, or SSDT™, is a digitaltwin that can automatically authenticate its identity and selectively disclose pertinent data for
Web3 transactions at the edge without the need to connect to centralized databases). The
complete VID and its immutable data can be employed by connected and future autonomousvehicles and the IoT infrastructure that will support them.
The VID is defined as an authoritative form of identity that can be cryptographically verified.
Central to this system is a vehicle linked to its unique VID. This VID, established at the vehicle's
inception, includes the Vehicle Birth Certificate (VBC) and is indexed by a Unique Vehicle
Identifier (UVI). Key stakeholders involved in this system comprise the owner, lien-holder, theoriginal equipment manufacturer (OEM), and government entities, such as Motor Vehicle
Authorities (MVAs). Each party may have wallets containing their digital certificates, whichunambiguously define their relationship with the vehicle.
The VID operates as the vehicle's distinctive identifier, facilitating its interaction with various
mobility networks. These networks offer services like toll payments, parking, congestion pricing,and more. A key advantage of this connected vehicle ecosystem, compared to traditional
methods, is its capacity to authenticate the source and origin of data through the use ofdecentralized identity and verifiable claims. The data owner has the option to participate in adata marketplace, thereby monetizing the vehicle data they decide to share.
Unlike a centralized architecture where each organization or entity might hold a different
perspective of the same vehicle, the decentralized identity-based approach offers analternative that enables the sharing and regulation of vehicle data, as well as
Vehicle-to-Infrastructure (V2I) communication. This method significantly streamlines the intricate,trusted, single-entity systems.
The VID standard is engineered to guarantee that vehicle data can be securely stored within adecentralized environment with access granted only to authorized entities. This facilitates
mobility providers in verifying identities, credentials, and related metadata. Consequently, thisallows vehicles to establish secure connections with infrastructure, other vehicles, devices,
services, and so on.

MOBI. 2023, dlt.mobi/self-sovereign-digital-twins/.

1© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 2

2. Scope of MOBI VID Tech Specs
The VID I Technical Specifications specify the methods and requirements to implement a
decentralized vehicle identification system utilizing World Wide Web Consortium (W3C)
Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) standards. These specifications
focus solely on the vehicle birth event, as depicted in Figure 1. This birth event along with thedata structure and all required technical details are described within this document.

Figure 1. VID Standard, Initial Release Scope (Vehicle Birth). NOTE: The “Wallet” can be implemented
using different methods, including as a Citopia Passport.

3. Glossary of Terms
This section contains the definitions of all technical and specific terms used throughout thisdocument.
Blockchain: A blockchain is a growing list of records, called blocks, that are linked using
cryptography. Each block contains a cryptographic hash of the previous block, a timestamp,
and transaction data (generally represented as a cryptographically secure tree structure suchas a Merkle tree.)
Cryptographically Sound: A cryptographic method is cryptographically sound if the(cryptographic) statement is false and no cheating prover can convince an honest verifier that
it is true (excepting some small probability).
Decentralized Storage System (DSS): A DSS is a non-static collection of data storage nodes witha global identifier where each node typically consists of a set of object revisions (“commits”)© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 3

which each represent a change (creation, update, or deletion) of a single node object. Eachcommit is signed, immutable, and content-addressable (typically stored and referenced by itshash). The set of commits representing an object is generally append-only, with certain
exceptions made, for example, to allow garbage collection of older commits. Objects areassociated with a permissioning structure (read/write) controlled by one or more DSS users. The
set of data storage nodes utilizes a replication protocol that is deterministic and eventuallyconsistent.
Decentralized Identifier (DID): A DID is a globally unique identifier that can be resolved, orde-referenced on a distributed ledger network, much like a URL on the Internet. The DID is
resolved to its associated DID Document, which contains the authentication method andservice endpoints. A DID can be deactivated. The DID Document also contains cryptographic
material, typically in the form of a public-key, that is used to encrypt the payload of allcommunications to the endpoints. Payload encryption is done independently, and usually in
addition to, transport encryption schemas such as SSL or TLS. DIDs can be used with any transport
protocol.
DID Document: A DID Document is a simple text document that describes how to use thatspecific DID. Each DID Document may contain at least three things: proof purposes, verification
methods, and service endpoints. A DID Document can specify that a particular verification
method, such as a cryptographic public key or a pseudonymous biometric protocol, can beused to verify a proof that was created for the purpose of authentication. Service endpoints
enable trusted interactions with the DID controller. This document specifies a common data
model, format, and operations that all DIDs support.
Distributed Ledger Technology (DLT): DLT is a consensus of replicated, shared, and synchronizeddigital data geographically spread across multiple sites, countries, or institutions. There is nocentral administrator or centralized data storage. A peer-to-peer network is required as well as
consensus algorithms to ensure replication across nodes is undertaken.
Entity: An entity (e.g. vehicle, corporation, individual, etc.) is a network participant that interacts
with the system by reading and/or writing data. An entity is identified using an entity certificate(see Section 5.2 Entity Certificate).
Entity Identifier (EID): An EID is an unique alphanumeric string that uniquely identifies any entity
within the system network described in this document.
Engine Serial Number (ESN): The ESN is a unique number that identifies (within the context of aknown manufacturer) an engine block.
Fuel Type: Type of fuel a vehicle uses (diesel, gasoline, fuel cell, electric, etc.).
Governance: Administrator for users, roles and certificate/UVI. On-/Off-boarding of entities isfacilitated by the network governance in Section 6.
Identity: Identity is a combination of one or more unique identifiers having meta-data associatedwith them. Identity meta-data consists of certificates such as verifiable credentials (per the W3C© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 4

definition) and other non-verifiable data objects generated by or on behalf of the unique
identifier(s).
ISO: International Organization for Standardization
Motor Vehicle Authority (MVA): An MVA is an administrative body responsible for overseeing andregulating aspects related to motor vehicles, including licensing, registration, safety standards,
and enforcement of related laws and regulations.
Network: The system’s network is shared equally among network nodes such that no single node(within limits described) may gain an unfair advantage over the overall system.
Node: A node on the system network which is maintained by affiliates. A large number of nodes
is meant to provide network availability and prevent collusion attacks.
Original Equipment Manufacturer (OEM): An OEM is an organization that makes devices fromcomponent parts either made internally or sourced from other organizations. In the context of
this document, this is synonymous with the vehicle's manufacturer and originator of the vehicle's
birth certificate.
Role: Roles regulate the creation of and access to data contained within the network.
Secure Sockets Layer (SSL): SSL is the standard security technology for establishing an encrypted
link between a web server and a browser. This link ensures that all data passed between the
web server and browsers remain private and integral.
Transport Layer Security (TLS): The TLS protocol is the successor of SSL and aims primarily toprovide privacy and data integrity between two or more communicating computer
applications.
Trust Anchor: A trust anchor is an authoritative entity that validates and qualifies entities on the
network specific to the entity’s corresponding role.
Transmission Serial Number (TSN): The TSN is a unique number that identifies (within the context ofa known manufacturer), a transmission unit.
Uniform Resource Identifier (URI): URIs ensure that a named URI will always point to the same
resource it was assigned to. Note that this is similar to the addressing system on many blockchain
platforms and represents one way to implement a URI.
Unique Vehicle Identifier (UVI): A UVI is a distinct alphanumeric code within a specific system,
differing from a Vehicle Identifier (VID). It acts as a specialized DID for vehicles, linking uniquely
to a particular vehicle through its associated Verifiable Credential (VBC), representing thevehicle's minimum digital identity. The UVI facilitates various functions such as verifying existence,
controlling access, and confirming specifications. In a simplified view, the UVI serves as a key in a
key-value store, allowing for the retrieval of vehicle data from an OEM's network.

© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 5

Vehicle Birth Certificate (VBC): A VBC is a data structure of strings and integers that records
information about a particular vehicle at its creation. See Section 4.2 Vehicle Birth Certificate(VBC) for definition and more details.
Vehicle Identity (VID): A VID is defined by the verifiable credential adhering to this VID
specification issued by the manufacturer as identified by its entity certificate and associated
DID.
Vehicle Identification Number (VIN): A VIN is a structured combination of characters assigned toa vehicle by the manufacturer for identification purposes.

4. Typographical Conventions
Requirement IDs
A requirement is identified by a unique ID composed of its requirement level followed by arequirement number, as per the following convention:[RequirementLevel-RequirementNumber]
Note that requirements are uniquely numbered in ascending order within each requirementlevel. Four requirement levels are coded in requirement IDs as per the following convention:[R] - The requirement level for requirements whose IDs start with the letter R is to be interpreted as
MUST as described in RFC2119.
[D] - The requirement level for requirements whose IDs start with the letter D is to be interpreted
as SHOULD as described in RFC2119.
[O] - The requirement level for requirements whose IDs start with the letter O is to be interpreted
as MAY as described in RFC2119.
It should be read that [R1] is an absolute requirement of the specification whereas [D1] is arecommendation and [O1] is truly optional.

5. General System Requirements
5.1.

Overview

The system is designed to associate each UVI with a VBC (which includes a VIN). Each individual
distributed ledger network node hosts an indistinguishable portion of the network, which
improves the resilience of the information on the distributed ledger against hostile network node

© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 6

behavior. Relationships between users regulate API access privileges to the VBC data contained
within the network. Certificates are cataloged by a UVI that indexes vehicle certificate entries.
Non-vehicle entities, including corporate entities, as well as individuals, are given unique
identifiers per W3C-specified DIDs or federated identities (reference Section 6 for technicaldetails) within the system to manage access and activity within certificates.

5.2.

System Security and Identity

VID-R1: Vehicle IDs MUST follow the W3C DID standard.
VID-R2: A vehicle MUST be assigned a Vehicle ID.
Note1.R2: The primary components of the Identity Subsystem will be a global Key Value (KV)
store and cryptographic primitives. These two components will interact to allow any user toretrieve another actor’s identity and verify that the identity is trusted.
Note2.R2: The VID schema MAY be implemented in a federated method by simply wrapping the
VID and VBCs in an existing verifiable, distributed datastore.
Note3.R2: Although a DID is an identifier, it should not be thought of as an identity. An entity’s
identity can have many DIDs associated with it.
VID-D1: Every entity SHOULD use different DIDs for each relationship.
Note1.D1: This strategy helps prevent correlation across systems and other predatory profilingbehavior.
Note2.D1: In the case of a vehicle communicating with a system collecting data, correlation isdesired, so long-lived DIDs shared across systems is an acceptable model. This could also bedone for UVIs, which are an instance of a DID.
VID-R3: A DID, combined with an entity certificate, is required to form an authoritative identity.
Note1.R3: Here, an authoritative identity is a fully instantiated, distinct interacting entity.

5.3.

Security Considerations

This section introduces some typical requirements for key management. It covers widely
recognized best practices and established cryptographic standards.
VIDI-R4: All cryptographic services utilized in a VID system MUST be cryptographically sound.
VID-D2: Lifecycle management for cryptographic materials generation, exchange, anddistribution for use in a VID system SHOULD follow industry best practices such as those outlined in
NIST SP 800-57, ISO/IEC 11770, or equivalent thereof.

© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 7

VID-D3: Key management SHOULD follow security best practices as defined in FIPS 200, ISO/IEC
27001, or equivalent thereof.

5.4.

Addressing and Uniform Resource Identifiers

Overview
Uniform Resource Identifiers (URIs) ensure that a named URI will always point to the same
resource it was assigned to.
VID-R5: All URIs MUST have a max length of 1024 characters.

6. Certificate Data Format
In the context of this standard, the minimum viable VID consists of the UVI and its associated
VBC. In the following sections, these two key components of VID are described in more detail.

6.1.

Unique Vehicle Identifier (UVI)The UVI (distinct from the VID), is a unique alphanumeric string that is verifiably mapped to a
specific vehicle through its associated VBC. This is a minimum representation of that vehicle’s
digital identity. It can be used to establish existence, enable access control, confirm productspecifications, etc. If we abstract the view of the system to a key-value store, then the UVI is thekey.
VID-R6: The UVI MUST be compliant with the JSON-LD 1.1 schema below:[{"@context": "http://schema.org","@type": "Unique Vehicle Identifier","attributes": [{"name": "UVI","description": "Unique Vehicle Identifier, a 64 characteralphanumeric string used to uniquely identify a vehicle.","mandatory": "Y","dataStructure": "TEXT UTF8","standardized": "64 character alphanumeric string"}]}]© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 8

Note1.R6: The UVI is validated through the signature of an issuer (entity). The entity itself can be
identified through its authoritative identity complaint with the W3C VC specification

6.2.

Vehicle Birth Certificate (VBC)

In the abstract view of the system as a KV store, the VBC is a value associated with the UVI. It
contains multiple fields including the VIN, manufacturer, model, model year, etc. Some of thesefields are intentionally provided for redundancy with respect to the VIN. This adds ease ofusability to this VID standard.
VID-D4: The Vehicle Birth Certificate SHOULD be compliant with the JSON-LD 1.1 schema below:[{"@context": "http://schema.org","@type": "Vehicle Birth Certificate","attributes": [{"name": "Certificate URI","description": "A URI for the Vehicle Birth Certificate.","mandatory": "Y","dataStructure": "URI","standardized": "NOT STANDARDIZED"},{"name": "Color (OEM code)","description": "The color of the vehicle, according to the OEM
code.","mandatory": "Y","dataStructure": "TEXT UTF8","standardized": "NOT STANDARDIZED"},{"name": "Country of Origin","description": "The country where the vehicle was manufactured, as
per ISO 3779 World Manufacturer Identifier standard.","mandatory": "Y","dataStructure": "TEXT UTF8","standardized": "ISO 3779 WMI"},{
"name": "Date of Production","description": "The date when the vehicle was manufactured,
represented as a Linux timestamp.","mandatory": "Y","dataStructure": "LINUX TIMESTAMP",© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 9"standardized": "RFC 3339/ ISO8601"},{"name": "Engine Code","description": "The code identifying the engine installed in thevehicle, as per ISO 3779 Vehicle Descriptor Section standard.","mandatory": "Y","dataStructure": "TEXT UTF8","standardized": "ISO 3779 VDS"},{
"name": "Engine Serial Number","description": "The unique serial number of the engine installed in
the vehicle.","mandatory": "Y","dataStructure": "TEXT UTF8","standardized": "NOT STANDARDIZED"},{"name": "Fuel Type","description": "The type of fuel used by the vehicle.","mandatory": "Y","dataStructure": "ENUM","standardized": "NOT STANDARDIZED"},{"name": "Manufacturer","description": "The manufacturer of the vehicle, as per ISO 3779
World Manufacturer Identifier standard.","mandatory": "Y","dataStructure": "TEXT UTF8","standardized": "ISO 3779 WMI"},{
"name": "Model","description": "The model of the vehicle, as per ISO 3779 Vehicle
Descriptor Section standard.","mandatory": "Y","dataStructure": "TEXT UTF8","standardized": "ISO 3779 VDS"},{
"name": "Model Year","description": "The year of the model of the vehicle, as per ISO
3779 Vehicle Identifier Section standard.","mandatory": "Y","dataStructure": "TEXT UTF8",© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 10"standardized": "ISO 3779 VIS"},{
"name": "Plant Code","description": "The code identifying the manufacturing plant wherethe vehicle was produced, as per ISO 3779 World Manufacturer Identifier standard.","mandatory": "N","dataStructure": "TEXT UTF8","standardized": "ISO 3779 WMI"},{
"name": "Previous VBC","description": "A link to the previous Vehicle Birth Certificate,if applicable.","mandatory": "N","dataStructure": "URI","standardized": "NOT STANDARDIZED"},{"name": "Transmission Serial Number","description": "The unique serial number of the transmission
installed in the vehicle.","mandatory": "Y","dataStructure": "TEXT UTF8","standardized": "NOT STANDARDIZED"},{"name": "Trim Type","description": "The type of trim of the vehicle.","mandatory": "Y","dataStructure": "TEXT UTF8","standardized": "NOT STANDARDIZED"},{"name": "UVI","description": "Unique Vehicle Identifier, a 64 characteralphanumeric string used to uniquely identify a vehicle.","mandatory": "Y","dataStructure": "TEXT UTF8","standardized": "64 character alphanumeric string"},{"name": "VIN","description": "Vehicle Identification Number, as per ISO 3779:2009
Content and Structure standard.","mandatory": "Y","dataStructure": "TEXT UTF8",© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 11"standardized": "ISO 3779:2009 Content and Structure"},{"name": "Electric Motor Serial Number","description": "The unique serial number of the electric motor
installed in the vehicle, if applicable.","mandatory": "N","dataStructure": "STRING UTF","standardized": "NOT STANDARDIZED"},{"name": "Battery ID",
"description": "The unique identifier of the battery installed in
the vehicle, if applicable.","mandatory": "N","dataStructure": "STRING UTF","standardized": "MOBI BIN"},{
"name": "Battery Installed Date","description": "The date when the battery was installed in thevehicle, if applicable.","mandatory": "N","dataStructure": "LINUX TIMESTAMP","standardized": "NOT STANDARDIZED"},{"name": "Manufacturer EID","description": "A self-pointer to the EID","mandatory": "Y","dataStructure": "Bytestring","standardized": "W3C DID Protocol"}]}]
Note1.D4: The following table provides more details regarding some of the fields of the VBC
enumerated in the previous subsection.

2

Term

Description

Date

An unsigned integer indicating the number of milliseconds since midnight ofJanuary 1, 1970 UTC (the Linux-Style Timestamp2).

http://man7.org/linux/man-pages/man1/time.1.html© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Fuel Type

Page | 12

0 = Petroleum
1 = Diesel
2 = Electric
3 = Hybrid
4 = Fuel Cell
5 = Natural Gas
6 = Other

VID-R7: A valid VBC MUST be issued by the legal identity of an Original Equipment Manufacturer(OEM).

7. Entities
7.1.

Overview

Entities form the means of interaction among participants in the network. System participants are
represented by entities that also take on specific roles within the systems' role-based
permissioning. An entity certificate defines an identity within the system which allows the entity tointeract with VBCs through the role permission system.
VID-D5: Entity actions MUST be cryptographically authenticated by one of the Verification
Methods listed in the verificationMethod data property and referenced in the authentication
data property of the DID Document of the DID referred to in the Entity's EID.

7.2.

Entity Certificate

An “Entity” in the system can be any network participant, from a government entity to anindividual, who wants to interact with a vehicle (Fig. 1). In this context, an entity defines anidentity, which consists of an identifier (e.g. W3C-compliant DID) and an associated Entity
Certificate (EC).
VID-R8: The EC MUST be compliant with the JSON-LD 1.1 schema below:[{"@context": "http://schema.org","@type": "Entity Certificate","attributes": [{"name": "EID","description": "A self-pointer to the EID","mandatory": "Y","dataStructure": "Bytestring",© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 13"standardized": "W3C DID Protocol"},{"name": "Type","description": "Type of Entity, values see below","mandatory": "Y","dataStructure": "Int","standardized": "Not Standardized"},{"name": "PubKey","description": "The public key in the PKI that is used tocommunicate with this EID","mandatory": "Y","dataStructure": "Bytestring","standardized": "TLS 1.3"},{
"name": "---","description": "Custom fields","mandatory": "---","dataStructure": "---","standardized": "---"}]}]
Note1.R8: For the onboarding process, entities may receive a verifiable credential compliant
with the W3C DID specification or, alternatively, receive one based on a federated identity
provider3.
Note2.R8 The “Type” field from above is one of either 1, 2, 3, 4, or 5 with definitions as follows:- Users- Physical Assets- Service Providers- Data Hosts-

3

Trust Anchors (Government, Consortium, etc.)

https://en.wikipedia.org/wiki/Federated_identity#Examples© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)

Page | 14

8. References
Normative References
The following documents are referenced in such a way that some or all of their content
constitutes requirements of this document.
[RFC 2119]
S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,
http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
[RFC 3986]
T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier (URI): Generic Syntax,
https://datatracker.ietf.org/doc/html/rfc3986, IETF RFC 3986, January 2005.
[ISO 3779]
ISO, Road vehicles — Vehicle identification number (VIN) — Content and structure,https://www.iso.org/standard/52200.html, ISO 3779:2009, October 2009.
[RFC 3339]
G. Klyne, C. Newman, Date and Time on the Internet: Timestamps,
https://datatracker.ietf.org/doc/html/rfc3339, IETF RFC 3339, July 2002.

Non-Normative References[W3C-DID]
Decentralized Identifiers (DIDs) v1.0, M. Sporny, D. Longley, M. Sabadello, D. Reed, O. Steele, C.
Allen, W3C W3C Recommendation, July 2022,
https://www.w3.org/TR/2022/REC-did-core-20220719/. Latest version available athttps://www.w3.org/TR/did-core/.
[FIPS 200]
National Institute of Standards and Technology, Minimum Security Requirements for Federal
Information and Information Systems, https://doi.org/10.6028/NIST.FIPS.200, FIPS 200, March 2006.
[NIST SP 800-57]
E. Barker, Recommendation for Key Management: Part 1 – General,
https://doi.org/10.6028/NIST.SP.800-57pt1r5, NIST SP 800-57 Part 1 Rev. 5, May 2020.
[ISO/IEC 11770]
ISO/IEC, Information security — Key management — Part 3: Mechanisms using asymmetrictechniques, https://www.iso.org/standard/82709.html, ISO/IEC 11770-3:2021, October 2021.
[ISO/IEC 27001]
ISO/IEC, Information security management systems - Requirements,
https://www.iso.org/standard/27001, ISO/IEC 27001:2022, October 2022.

© 2024 MOBI. All rights reserved.

MOBI VID0002/TS/2024 Version 2.0 (Version 1.0 © 2019)[JSON-LD 1.1]
JSON-LD 1.1, M. Sporny, D. Longley, G. Kellogg, M. Lanthaler, Pierre-Antoine Champin, N.
Lindström, W3C Recommendation, July 2020 ,https://www.w3.org/TR/2020/REC-json-ld11-20200716/. Latest version available athttps://www.w3.org/TR/json-ld11/.

© 2024 MOBI. All rights reserved.

Page | 15