Device identifiers
To ensure an update is correctly matched to your device, Device Management Update uses two unique identifiers to identify the "type" of device.
We recommend these be RFC-4122 Type 5 UUIDs.
Vendor ID
The following use the vendor ID:
- Device Management Update, to verify manifests.
- Device Management Update service, to verify that only accounts associated with a particular domain name can sign manifests for the corresponding vendor ID.
We recommend deriving the vendor ID from the manufacturer's domain name using the algorithm in RFC-4122, Section 4.3.
Here is a Python example:
import uuid
vendor_id = uuid.uuid5(uuid.NAMESPACE_DNS, 'vendor.com')
A vendor ID is static - it does not change in the lifetime of the firmware - so you can build it into the firmware image. You can use the manifest tool to create a UUID that follows this convention:
manifest-tool init -d "vendor.com"
Class ID
Together with the vendor ID, Device Management Update uses the device class to check that a manifest is compatible with a device.
We recommend:
- The device class ID conforms to RFC-4122, Type 5.
- You use the vendor ID as the namespace. The ID within the namespace is arbitrary.
- You use a model name and revision number as the ID.
For example:
import uuid
vendor_id = uuid.uuid5(uuid.NAMESPACE_DNS, 'vendor.com')
class_id = uuid.uuid5(vendor_id, 'widget X rev A')
A device class ID is static - it does not change in the lifetime of the firmware - so you can build it into the firmware image. You can use the manifest tool to create a UUID that follows this convention:
manifest-tool init -d "vendor.com" -m "widget X rev A"
Usage
Both of these parameters are stored in Device Management Update's configuration for a device. See the Update client section for more information on how to store these. When the Update client receives a manifest, Update client checks the class and vendor in the manifest to make sure they match the configured values.
Also, when a device connects to Device Management, Device Management receives and stores these parameters. Operators can then create device filters to find specific device types.
Together, these act as a "double check" for firmware compatibility - by both accurate cloud-based targeting using filters and a final check by the device itself.