Skip to main content

D3 Notes and Discussion

Firmware assertion

The existence of each distinguishable piece of firmware is asserted.

Typically this is done by the manufacturer, and in reality by an individual employed by the manufacturer.

[PERSON-SK]("FIRMWARE", https://devices.com/firmware-address, {firmware-descriptor})

A firmware descriptor is minimally composed of:

  • the firmware payload
  • URL from which the firmware can be downloaded
  • Version number
  • User readable friendly name
  • Optional notes field

SAM: As above. Is a person neceeary? Can a robot make such assertions? Maybe a contiuous integration and build process has no human-in-the-loop for firmware releases.

I think we need to think through the semanitcs of signing chains.

a) code can sign firmware

b) person can sign code that signs firmware

c) person signs code that firmware has already signed

plus of course we can embed further semantics in the command

Firmware Type Binding

A firmware can be bound to one or more device types.

If a firmware is bound to a device type, it implies that the firmware is compatible with this device type:

[PERSON-SK]("FIRMWARE-BINDING", https://devices.com/firmware-address, https://devices.com/-device-type)

Firmware Version Update

A firmware increment statement, is used to describe the fact that a firmware has been superseeded by a newer version:

[PERSON-SK]("FIRMWARE-VERSION-UPDATE", https://devices.com/firmware-address-new, https://devices.com/firmware-address-old)

The most up to date firmware is the asserted firmware version for which no version update statemement exists.

Device Type - Updater

REMOVE: we have removed this, and replaced this by binding the URI source to the firmware assertion

The updater property, identifies the "Human usable" URI from which the most up to date firmware for this device can be accessed

[PERSON-SK]("UPDATER",https://devices.com/this-device-type, https://devices.com/this-device-updater-uri)

Local device onboarding

If a device is formally provisioned/onboarded then critical information can be persisted and exposed at the gateway level.

[PERSON-SK]("DEVICE-ONBOARD", local://this-device-instance, {local-device-descriptor})

This process assumes a PERSON has explicitly onboarded the device to the home gateway.

Device descriptors workflow

The device descriptor workflow is designed to support the following properties:

  • Any individualcan propose a device or make a statement about a device
  • Each of these statements stands as an autonomous cryptographically verifiable statement by the author
  • We envisage a system where these statements are centrally gathered (e.g. IoTSF)
  • But - the autonomous descriptors can exist in private ecosystems also
  • Trusted authorities/intermediaries can apply processes to the atomic statements, which may include preferential treatment by trusted authors.
  • Subsets and extracts can be made from the universe of device descriptors, as appropriate for different applications.

SAM: Does private mean not published? SAM: Caution must be taken when dealing with sources that are not Authoritative (see the Global Identity Foundation for more on this.)