Vehicle ID
Last updated
Last updated
Whitelisted attributes: Make, Model, Year
DIMO unlocks a digital story of a vehicle’s life by creating an on-chain open Vehicle ID of a car. As vehicle data is sent to the DIMO network, it is linked as vehicle lifecycle history. Not just a url to a jpeg of your vehicle, it’s a key to ownership records and selected driving data.
At any point in time, the owner of the asset can access the vehicle's data, analyze , delegate or grant access to a 3rd party for users like insurance, accident reconstruction, carsharing, pre-sale inspection, and more.
As an open and extensible building block, further data can be attached over time, increasing the value of the vehicle ID as a digital asset.
This contract represents a vehicle owned by a DIMO user. To keep the tree structure hierarchical, a vehicle can only be minted under a Manufacturer node.
In order to ensure data consistency, prevent users from minting unwanted or inappropriate vehicles, some precautions are taken and must be followed by the users. The minting function only accepts calls from authorized addresses, and metatransaction is the mechanism employed to allow users to mint their vehicles with the following steps:
The user accesses the DIMO app to request to mint their vehicle.
The user signs a typed structured message with the following information:
Manufacturer node: token Id associated to the manufacturer of the vehicle.
Owner: the address of the user.
Make: the manufacturer of the vehicle.
Model: the model of the vehicle.
Year: the year the vehicle was made.
The request is submitted to the server that will perform verifications to ensure the given information matches the user’s data.
The server sends a transaction to the Vehicle contract invoking the function mintVehicleSign containing the information above along with the bytes of the signature submitted by the user.
The contract performs the following instructions:
Verifies if the Manufacturer node exists.
Recreates the user’s message with the same information passed as arguments.
Utilizes Eip712Checker to recover the signer of the message.
Verifies if the signer recovered matches the owner candidate of the vehicle.
Mints the Vehicle node to the user.
Permissions — that is, "who is allowed to do this thing" — are incredibly important in the world of device and vehicle ownership. The access control of asset may govern who is able to read data from your device or write data to your device, or to execute an over the air update.
Vehicles in particular have a complex relationship model. Your vehicle lien holder, your dealer, or even your family each have their own set of things they can and cannot do with a vehicle.
While the simplicity of ownership can be useful for simple systems or quick prototyping, different levels of authorization are often needed. An account may be able to transfer a vehicle for sale, but not unlock the doors.
In essence, we will be defining multiple permissions, each allowed to perform different sets of actions. Instead of granting admin access everywhere - you will use, for example, unlock:doors in some places, and claim:rewards in others. Separately, you will be able to define rules for how accounts can be assigned a permission, transfer it, and more.
While the infinite customization of permission based access control is useful for making sure we can support any interaction model required by the application, it is in many times beneficial to roll up permission sets into roles.
This allows 3rd party developers building on DIMO to define their own role with an associated permission set...Fleet Manager, Lien Holder, etc.
The Vehicle ID is a NFT that represents the DIMO users’ real-world vehicles and is linked to the aforementioned Vehicle node in the DIMORegistry. Additionally, it has features inherited from the Multi Privilege contract that are required to share user data.
This contract is based on the EIP-5496: Multi-privilege Management NFT Extension, which allows users to set multiple privileges for the NFTs they own.
The contract admin creates the privileges, which are saved as straightforward integers. The contract just keeps track of the associations between privileges and NFTs and determines whether a user has a certain privilege for an NFT; it does not hold any privilege logic.
It is important to notice that the user does not create new privileges; they are just allowed to set them for another user. Only a contract admin can create, enable, and disable privileges. This way, we can put out of action an obsolete privilege and also make new privileges available to be used by everyone at once.
To set a privilege, the user must observe the following:
Be the owner or approved by the NFT owner
The privilege must be enabled
Once the rules above are met, the user can call the functions setPrivilege or setPrivileges containing information about the privilege they want to set, the NFT, the user, and the expiration of this privilege. Note that, in order to revoke a privilege, the same function can be called with expiration set to zero.
For security concerns, Vehicle ID holders are now prevented from transferring their NFTs. To assure data consistency, however, several safety measures had already been taken. We want to make sure that all privileges are reset after the Vehicle ID has been transferred to a new user to prevent unauthorized access to your vehicle. The NFT version is mapped for this and updated anytime a transfer occurs in the contract. It always consults the most recent NFT version when someone inquires about a user's privileges.
