ioID Specification

This specification provides a comprehensive overview of the ioID system, detailing its methods, workflows, and security considerations for effective deployment in DePIN applications.

On-Device DID Generation

DePIN devices and network nodes can generate a DID and the corresponding DID document by means of SDKs, CLIs or other tools.

ioID Registration and Binding

A DePIN device owners and node operators can onboard their devices via a the following steps

  1. Generate/obtain the device's DID and DID document (e.g. use a CLI for nodes, or obtain it via the serial port for embedded devices).

  2. Store the DID document on a selected storage layer (e.g. AWS S3, IPFS, etc...)

  3. Invoke the device registry contract with the device's DID, DID document hash, and URI.

Upon successful onboarding, an ioID NFT representing on-chain ownership of the device is minted in the owner's blockchain wallet.

Security Considerations

To mitigate risks such as the registration of fake devices, the system can require device owners to make a small deposit for each DID registration. Additional information, such as manufacturer ID and serial number, can be included in the device registry to help identify and manage fake devices.

Secure Machine-to-Machine Interactions

Once registered on-chain, a DePIN entities can authenticate each other and establish secure off-chain communications with other entities in the network using DID-based protocols.

ioID Specification

did:io Method

DIDs in ioID conform to the Generic DID Scheme described in the DID specification. They follow the format did:io:io-specific-idstring, where io-specific-idstring is generated by:

  1. Creating a private/public key pair over the elliptic curve secp256k1.

  2. Converting the public key to an Ethereum address.

Example of an ioID DID:

did:io:0x5576E95935366Ebd2637D9171E4C92e60598be10

DID Document for a DePIN Device

A sample DID document:

{
    "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://w3id.org/security/suites/ed25519-2018/v1"
    ],
    "id": "did:io:0x123456789abcdefghi",
    "verificationMethod": [{
        "type": "Ed25519VerificationKey2018",
        "id": "did:io:0x123456789abcdefghi#key-1",
        "publicKeyBase58": "......"
    }],
    "authentication": [
        "did:io:0x123456789abcdefghi#key-1"
    ],
    "service": [{
        "id": "did:io:0x123456789abcdefghi#mqtt",
        "type": "MqttEndpoint",
        "serviceEndpoint": "broker.example.mqtt.com"
    },
    {
        "id": "did:io:0x123456789abcdefghi#http",
        "type": "HttpEndpoint",
        "serviceEndpoint": "example.com"
    }]
}

DePIN Node Onboarding

To onboard a server within a specific layer of a DePIN modular stack (e.g., a sequencer node), a node operator needs to:

  1. Log into the DePIN node using their server credentials.

  2. Generate a DID and DID document (e.g. using a CLI)

  3. Upload the DID document to a storage provider and take note of the URI.

  4. Using the operator's blockchain account, invoke the ioID on-chain registry to perform a Device Registration for the node, with the node DID, DID document hash, and URI.

  5. The ioID device registry is updated with the new information and a "device NFT" is minted to the node operator's blockchain address.

DePIN Device Onboarding

To onboard a device (e.g., a 5G Cellular Antenna) that belongs to a certain DePIN project, a device owner needs to:

  1. Retrieve the device's DID and DID document (e.g. via a usb tool paired with an embedded SDK installed on the device).

  2. Upload the DID document to a storage provider and get the URI.

  3. Register the device with its DID, DID document hash, and URI.

  4. Using the owner's blockchain account, invoke the ioID on-chain registry to perform a Device Registration with the device DID, DID document hash, and URI.

  5. The ioID device registry is updated with the new information and a "device NFT" is minted to the owner's blockchain address.

DePIN Node Discovery

Once DePIN nodes and devices are registered in the ioID device registry, a DePIN device will rely on a bootstrapping node to discover the service endpoint(s) of a DePIN application.

  1. A DePIN device sends a project descriptor (e.g., a project ID) to a bootstrapping node.

  2. The bootstrapping node uses the project descriptor to retrieve the project configuration URL from the project registry on the blockchain.

  3. The bootstrapping node uses the URI to read the project configuration file from the storage.

  4. The bootstrapping node parses the project configuration file to obtain the service endpoint(s) of the DePIN project.

  5. The bootstrapping node returns the service endpoint(s) to the device.

  6. The device stores the service endpoint(s) in its flash.

Such a DePIN node discovery protocol might need to run periodically to handle potential changes in DePIN nodes within the network.

DePIN Machine-to-Machine Communication

With the service endpoint available, a DePIN device can interact with a DePIN node in a secure manner. To this end, a number of DID-based sub-protocols need to be performed.

4.1 Mutual Authentication

A DID-based mutual authentication protocol enables secure communication between devices and nodes.

4.2 VC Issuance

Optionally, DePIN devices receive a VC from an issuer to exchange for a W3bstream access token.

4.3 VC Presentation

Optionally, Devices present the VC to obtain an access token.

4.4 Data Upload

Devices upload data to a node via a DID-based encrypted channel.

Last updated

Logo

This documentation portal is currently undergoing updates to align with the IoTeX 2.0 Whitepaper release. Information provided here may be incomplete, or out-of-date. Please use this portal for preliminary reference only, and check out the official IoTeX 2.0 Whitepaper for updated information.

.

2024 | IoTeX