Core Functionalities

DIMO Account Creation / Logins

Login with DIMO allow developers to surface an interface for the end users to authenticate by integrating with the Accounts API. This functionality sets up the smart contract wallet for the end user, giving full root access to the user (and only the user), enabling logins across all DIMO platforms with the use of a passkey.

Account Creation, Email OTP, User Sign-in

DIMO Check-in

Learn more about how passkey is more secure and the future for Internet security in this Google blog: https://blog.google/inside-google/googlers/ask-a-techspert/how-passkeys-work/

Vehicle Permission Sharing

This is an optional functionality that you can enable on the Component SDK either by coupling it with the login flow or decoupling it onto a button of its own.

One Flow Approach

When this is enabled in the LoginWithDimo component by providing a permissionsTemplateId, logged in users are prompted with a share permission(s) page to share their selected vehicles with your application.

Two-pronged Approach

When you surface a second component in ShareVehiclesWithDimo, logged in users will need to click on this button to trigger the sharing flow. This allows developers to feed in additional information in between the login and the permissions flow such as vehicle filtering.

An example would be filtering by powertrain, once users log in, the application can then pull the vehicle definitions from Identity API before feeding vehicle tokenId's into the component.

PermissionTemplateId

We provide simplified templates or "groupings" of privileges that you can request from your users via the permissionTemplateId parameter. More of these templates will be available upon request. It's recommended that you review the Permissions Contract (SACD) documentation, along with the table of privileges from the Token Exchange documentation.

permissionTemplateId	Privileges Requested
1	[1,2,3,4,5,6]
2	[1,3,4,5,6]

Permissions

DIMO provides an alternative way to specify the exact permissions that you request from your users by using a permissions parameter. The permissions parameter is an optional binary string in replacement of permissionTemplateId.

• Each digit represents whether a specific privilege is granted (1) or not granted (0).

• The position of the digit corresponds to the privilege number (from left to right).

Example mapping of permissions

Developer Notes

• The leftmost digit corresponds to privilege 1.

• You can pad the string to match the total number of privileges supported.

Expiration Dates

Setting Custom Expiration Dates

This is another optional property that you can enable on the Component SDK, which, if added, sets an expiration date on vehicle privileges granted by a user. If not explicitly added, the expiration date for a vehicle's privileges defaults to 1 year. In TypeScript, you can construct these dates like so:

const customDate = new Date(Date.UTC(2062, 11, 12, 18, 51)); // Note: Month is zero-based
const iso8601String: string = customDate.toISOString();

Developer Notes

While optional, it is recommended that you include an expirationDate in your component. If not included in the component, it will default to 100 years. Once the expiration date passes, you will no longer have privileged access to vehicles that have previously been shared with you, and users will need to re-share their vehicles with your app. It's up to developers to communicate to their users when they may need to re-share their vehicles.

List of Shared Vehicles

For every user session, whenever a vehicle is shared, the SDK returns the sharedVehicles array for the application in the response. This helps the developers identify and manage the user account - vehicles shared relations.

Advanced Transactions

This is an optional functionality where you can trigger any ABI calls.