Building theNew Economy of Movement

March 2021

CONNECTEDMOBILITY DATAMARKETPLACETECHNICAL SPECIFICATIONSMOBI CMDM0003/TS/2021
Version 1.0

INTRODUCTION
MOBI (Mobility Open Blockchain Initiative) is a global smart mobility consortium
established to accelerate the adoption of blockchain, distributed ledger, andrelated technologies in the mobility industry through the creation and promotion ofstandards.The work of preparing standards is carried out through MOBI working
groups. Each member of the consortium interested in a subject for which a working
group has been established has the right to be represented and participate in thatworking group. Mobility providers, technology companies, governments, and NGOs,in liaison with MOBI, take part in this work.

The procedures used to develop this document and those intended for its
further maintenance are 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 is drawn to the possibility that some of the elements of thisdocument may be the subject of intellectual property rights. In accordancewith MOBI IPLR policy, a 60 day review period is provided 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 this document
will be contained within the Introduction upon public release of thisstandard.
Any trade name used in this document is information given for theconvenience of users and does not constitute an endorsement. The workinggroup responsible for this document is the Connected Mobility Data
Marketplaces (CMDM) Working Group.
Sincere thanks and appreciation are extended to those who contributed theirunique insights to this report.

Authors
Griffin Haskins, MOBI
Rajat Rajbhandari, MOBICMDM Working Group Co-Chairs
Roger Berg, DENSO
Michal Filipowski, General Motors

CMDM Working Group Team Members
Loren Adams, Accenture
George Ayres, IBM
Tim Bos, ShareRing
Joshua Cartellone, Accenture
Benjamin Diggles, Constellation NetworkArjun Hassard, NuCypher
Thomas Hulse, Fifth9Jerry Kim, AMO Labs
Suresh Kumar Sundararaj, FordDuy Linh Nguyen, Cognizant
Chalid Mannaa, Ocean Protocol
Jim Mason, DMX

Pramita Mitra, Ford Motor CompanyDavid Noack, Continental
Evripidis Paraskevas, GM
Manan Patel, Ocean Protocol
Derek Pierre, NuCypher
Anthony Salamone, RouteOne
Liu Shaowei, CPChain
Sudha Sriram, Ford
Sukesh Tedla, Swedish Blockchain Association
Wanda Wang, Toyota Insurance Mgmt Solutions (TIMS)
Chris Wood, Filament

MOBI Team
Chris Ballinger, Founder + CEO
Tram Vo, Founder + COO
Rajat Rajbhandari, Working Groups Lead

Robin Piling, Technical Lead
Griffin Haskins, Fellow
Kelly Clark, Communications Manager

01

Executive Summary

03

Scope05

Glossary of Terms

10

System Overview

18

TABLE OFCONTENTS

Actors and Identity
1. Decentralized Identifiers Framework
2. EIDs
2.1. Common Entity Certificate (EC) Structure
2.2. User
2.3. Physical Assets
2.4. Service Providers
2.5. Data Hosts
2.6. Trust Anchor

49

Registering Data
1. Data Writes

52

CMDM Extensions of Infrastructure
1. CMDM Buyer/Seller Entity Certificate
1.1. Sensor Identity Birth Certificate Extension
1.2 Sensor Ownership Certificate Extension
1.3 Vehicles Birth Certificate Extension
2. Communication Bootstrapping

Infrastructure Subsystems
1. Identity Subsystem
2. Data Subsystem
3. Permissioning Subsystem
3.1 Permissioning Subsystem Program Flow

39

65

Permissioned Access
1. Data Host Bootstrapping Certificate (DBC)
2. Access Session Setup (Unlock)2.1. Session Request Packet (Unlock Request)
2.2. Session Rejection (Unlock Response)
2.3. Session Acceptance (Unlock Response)
3. Groups
4. Allow Lists
4.1. Access Certificates (ACs)
5. Block Lists

69

CMDM Processes
1. Infrastructure Subsystem Processes
2. Misc. Sub Processes

76

Use Case - Decentralized Data Marketplace
1. Vehicle to Grid (V2G)
2. Tokenized Carbon Credits (TCC)
3. Peer-to-Peer (P2P)

96

Vehicle and Infrastructure Schemas
1. Vehicle Sensor Schema
2. Infrastructure Sensor Schema

107

Appendix A: Certificate Structures

107

Appendix B: End-to-End Encryption

111 Bibliography

Executive
Summary

Blockchain, or distributed
ledger technologies, play asignificant role in ensuringthat data exchange preserves
privacy and keeps the datasecure.

With advances in short and long range low latency, peer-to-peer
communication technologies, data exchanges between vehicles
and the roadside infrastructure is an obvious use case. For
example, data exchange in a low latency environment isbeneficial for vehicles to share braking or lane preference
information with other vehicles. Vehicles can receive
information from roadside and cloud infrastructure regarding
road conditions. Single vehicle drivers, or fleet owners, canmonetize by selling a vehicle’s performance data to algorithm
developers, road condition providers, and more.
MOBI working group members believe that blockchain, ordistributed ledger technologies, play a significant role inensuring that data exchange preserves privacy and keeps thedata secure from outside tampering.

Use of blockchain/DLT would
not scale without coherent
and standardized methods
adopted and implemented by
the industry stakeholders

MOBI working group members believe that the use ofblockchain/DLT would not scale without coherent andstandardized methods adopted and implemented by the industry
stakeholders who manufacture and service the vehicles. The lackof interoperability in the absence of industry standards becomesproblematic at scale.
The Connected Mobility Data Marketplace (CMDM) standards atits core provides blockchain/DLT as a trust layer for V2X dataexchange. This standard prescribes reference architecture, data
schema, certificates, etc. for vehicles and infrastructure to beable to exchange data by leveraging blockchain/DLT.

© 2021 MOBI — CMDM Technical Specifications

2

MOBI CMDM TECH. SPEC. SCOPE
The CMDM standard
specifies high-level systemdesign. The provided CMDMspecific data structures canbe utilized throughout theecosystem.

The CMDM standard specifies the high-level system design,reference architecture, multi-party processes, and the CMDM
specific data structures that are utilized throughout theecosystem. Finally, this document provides guidance toimplementation of the CMDM Standard, covering three primaryuse cases and their process flows.
With the systems for identity, data, and permissioning
referenced above, it is possible to outline a variety of use cases.
Each use case is broken down into three main categories which
are Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2X),
and Infrastructure-to-Infrastructure (X2X). In all of these usecases, a connected device, such as a vehicle or a sensor device,
has connectivity through the same network, to other devices.
These devices are able to authenticate each other’s identities,
securely share data, and securely record transactions. Theirability to communicate well enables a rich array of functionality.

This document provides
reference implementation
covering three primary use
cases and their process flows
broken down into Vehicle-toVehicle (V2V), Vehicle-toInfrastructure (V2X), andInfrastructure-toInfrastructure (X2X).

Note that while this standard references certain underlying
technologies, it provides no opinion on what specifictechnologies are to be used. Such details are left as an option
at implementation. In particular, the following underlying
systems choices are not covered:Communication protocols
Link layer protocols (WiFi, 5G, etc.)
Transport layer and above protocols (REST, gRPC, etc.)
Trusted key-value store
Ethereum, Distributed Hash Tables, DNS, etc.
Cryptography/Security
TLS, SSL, Hashing/MACs, Signatures, etc.
Best practices such as recommended key lengths ordeprecated protocols
Bootstrapping trigger
Triggers for creating a new entity, certificate, data
source, or other should be handled by the implementer,not the standard.
User interfaces
Users are assumed to have Entity IDs (EIDs) and caninteract with the system. This standard provides noopinion on how an interface is abstracted away. In many
situations, users may interact with a system through an
intuitive user interface without knowledge of theunderlying system and its technical details.

Blockchains/DLT Protocols
Ethereum, Bitcoin, Hyperledger, IOTA, Corda etc.
Settlement mechanisms (Ethereum, Bitcoin, PayPal, wiretransfer, etc.)
Usage of layer 2 technologies such as side-chains or statechannels3 © 2021 MOBI — CMDM Technical Specifications© 2021 MOBI — CMDM Technical Specifications

4Glossary of Terms
ACAccessor

Access Certificates (ACs) are documents providing the abilityfor a particular entity to access a particular endpoint in thenetwork’s data layer.
An entity is an Accessor if it attempts to access a resource’s URIendpoint. An Accessor may need to go through security andauthentication processes in order to access said endpoint.
A list that specifies entities that are allowed to access aparticular resource.

Allow ListA list that specifies entities that are allowed to access aparticular resource.

Block List

A list that specifies entities that are not allowed to access aparticular resource.

Blockchain

Data Host

Data Owner

DBC

A growing list of records, called blocks, that are linked using
cryptography. Each block contains a cryptographic hash of theprevious block, a timestamp, and transaction data (generallyrepresented as a cryptographically secure tree structure suchas a Merkle tree). Examples of blockchain include Ethereum andHyperledger.

DBC (Cont.)

Host) is allowed to serve a particular type of data from a
specific URI.

DID

W3C Decentralized Identifier (DID) represents a globally unique
identifier that can be resolved to a DID Document, or dereferenced on a specific distributed ledger network, much like a
URL on the Internet.

DID Document

A DID Document is a simple text document that describes how
to use that specific DID. Each DID Document may contain atleast three things: proof purposes, verification methods, andservice endpoints. A DID Document can specify that a particularverification method, such as a cryptographic public key or apseudonymous biometric protocol, can be used to verify a proof
that was created for the purpose of authentication. Serviceendpoints enable trusted interactions with the DID controller.
This document specifies a common data model, format, andoperations that all DIDs support.

DLT

A Data Host is an entity that stores data and is trusted withauthenticating requests to access and distribute the data asneeded.
The Data Owner is the owner of a particular piece of data. Thisowner is usually the same entity that generated said data
(referred to as the Data Generator).

Distributed Ledger Technology (DLT) enables consensus
regarding the state of replicated, shared, and synchronizeddigital data widely spread across multiple sites, countries, andinstitutions. A peer-to-peer network is required as well as
consensus algorithms to ensure replication across all nodes isachieved. Blockchains are the most common and well-known
example of DLT. General practical byzantine fault tolerantsystems fall under this category as well.

Data Bucket

A logical data abstraction for a persistent data store. Data
written to a Data Bucket can be used repeatedly over time.

The Data Host Bootstrap Certificate (DBC) is a certificate thatprovides a cryptographic proof that a particular entity (Data5 © 2021 MOBI — CMDM Technical Specifications© 2021 MOBI — CMDM Technical Specifications

6Glossary of Terms
Data Stream

A logical data abstraction for data buffers. Acts as an
ephemeral “stream” of data and persists for a set period oftime in the network until it is purged within the online systems.
Afterwards, it is moved to nearline data systems, then ultimately
sent to offline data systems.

KV StoreECAn Entity Certificate (EC) is the certificate that represents all ofa particular entity’s network-level information and metadata.
This includes, but is not limited to, identifiers about who they
are, the URIs to delegate trust to, and their public keys. An EC isalways paired with a corresponding EID.

KYC

EID

Network

An Entity Identifier (EID) is a unique alphanumeric string thatuniquely identifies any entity within the system’s network
described in this document.
NodeEntity

GPC

An entity such as a vehicle, corporation, or individual, is a
network participant that interacts with the system byreading/writing data, enforcing permissioning, or otherwisesupporting the network in a particular manner. An entity isidentified using an entity certificate anchored within a
distributed ledger.
Group Permission Change Certificates (GPCs) are certificatessigned by a data owner, prompting a Data Host to change thepermissioning information of the group.

ISOInternational Organization for Standardization.

Identity

Identity is a combination of one or more unique identifiers
having meta-data associated with them. Identity meta-dataconsists of certificates such as verifiable credentials (per theW3C definition) and other non-verifiable data objects
associated with the unique identifier(s).

7 © 2021 MOBI — CMDM Technical Specifications

OEM

Personally Identifiable
Information (PII)RCA Key-Value Store (KV Store) is a system that stores (key, value)
pairs. The key is used to obtain access to the value in some way.
Distributed KV stores are KV stores spread across multiple
machines and can effectively maintain a global state table.
Know Your Customer (KYC) is the process of verifying theidentity, risks, and other pertinent information associated with acustomer before initiating a business relationship.
A group of entities that all participate in a digital system with a
specific goal in mind. For example, a group of entities thatparticipate in a distributed ledger such as Ethereum would beconsidered a network.
A node is a computer connected to other computers which
follows rules and shares information. A large number of nodes ismeant to provide network availability and prevent collusion
attacks.
An Original Equipment Manufacturer (OEM) is an organizationthat makes devices from component parts either made internallyor sourced from other organizations. In the context of thisdocument, this is generally a vehicle manufacturer.
PII is any information that (1) identifies or can be used toidentify, contact, or locate the person to whom such information
pertains, (2) has identification or contact information of anindividual that can be derived, or (3) is or might be directly or
indirectly linked to a human being.[ISO/IEC 29100:-1]
Revocation Certificates (RC) revoke AC permissions if the AC
has not expired automatically.

© 2021 MOBI — CMDM Technical Specifications

8

Glossary of Terms
Role

SSL

Roles regulate creation of and access to data contained within
the network.
(Secure Sockets Layer) is the standard security technology forestablishing an encrypted link between a web server and abrowser. This link ensures that all data passed between the web
server and browsers remain private and integral.

TLS

The Transport Layer Security protocol is the successor of SSL
and aims primarily to provide privacy and data integrity
between two or more communicating computer applications.

Trust Anchor

Administrator for users and roles. On/Off-boarding of entities isfacilitated by the network governance in Section 6.

UUID

Universally Unique Identifiers (UUIDs) are unique identifiers thatare associated with pieces of digital information and can beused to address and identify each one.

URI

Uniform Resource Identifiers (URIs) ensure that a named URI will
always point to the same resource it was assigned to. This
example is similar to the addressing system on many blockchain
platforms and represents one way to implement a URI.

URL

Tokenized Carbon Credits(TCC)A specific type of URI referencing web resources.
This refers to a collection of use cases that center arounddigitizing carbon credits for ease of transfer and auditability. In
particular, TCC’s are digital, tradable certificates or permits
that represent the right to emit a specified amount ofgreenhouse gases.

9 © 2021 MOBI — CMDM Technical Specifications

Vehicle-to-Grid (V2G)

Peer-to-Peer (P2P)

V2G refers to a collection of use cases that center around thecoordinated unidirectional or bidirectional energy exchange
between vehicles and the grid.
P2P refers to a collection of use cases focused on direct energy
exchange between energy peers (equally privileged entities thattransact electricity) in a decentralized manner.

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

dlt.MOBI@dltMOBI

MOBI@dltMOBICMDM@dlt.MOBI