search

microsoftarchive / iot-journey

a guidance project for implementing an IoT solution on Azure
Other
89 stars 34 forks source link

Device Registry : additional concerns #207

Open ppatierno opened 9 years ago

ppatierno commented 9 years ago

Hi, refering to #201 I think that there are two other possible states for a device : enabled and disabled.

IMHO, when a device is provisioned, it is "installed" in the environment (physically thanks to the operator). When it is deprovisioned it is removed from the environment.

A device that is running (in the environment) could be "disabled" to send/receive data/commands for a specific period of time and then reactivated "enabled".

Paolo.

bennage commented 9 years ago

Are you primarily concerned with the labels registered, provisioned, and deprovisioned? I do think that our current labels are weak.

Based on what we've seen with customer, here are some descriptions of possible states:

  1. The system has metadata about a device, but the device has no rights to communicate to the backend. In particular, the device has never been authorized to communicate. This could happen is information about a device is collected before it is provisioned.
  2. A device is authorized to connect to the backend to receive commands, but not to send anything.
  3. A device is authorized to send events.
  4. A device's authorization is explicitly removed (deprovisioned), either temporarily or permanently.

It might be useful to think of this using a claims-based identity model.

ppatierno commented 9 years ago

I think that 2 and 3 aren't states but thy are related to "authorization" that specifies if a device can send, receive or both. We can also distinguish between revoking authorization for send, receive or both; if I revoke authorization to send I can't say that the device is deprovisioned because it can still receive.