-
Notifications
You must be signed in to change notification settings - Fork 9
security models #2
Comments
Please check out the onboarding repo: https://github.com/openT2T/onboarding. We are hoping to start a discussion around common security models (e.g. auth/pairing/etc) for similar things, e.g. all Bluetooth LE devices have similar onboarding requirements. In the translators repo https://github.com/openT2T/translators you will find examples of Things that implement the same schema, but have different onboarding types (e.g. check out the different types of Window Shades). What do you think? We are hoping to start a discussion here with the community, and we would love your feedback. Thanks! |
It seems to me that there are two sides to this. First is the aspect of getting the IoT devices connected to the translator itself. That would be the most common definition of onboarding for me. Suppose a user is running the translators on a raspi. The user will have to configure these devices to communicate securely with the raspi first (e.g. exchanging wifi credentials, etc). It seems we might have less control over the specifics of this process, as it is upto the device manufacturer, and the specific low level protocol (wifi, zigbee, ble, etc) to decide how this happens. A translator for that device would have to account for such variation. The more interesting aspect is what kind of security model is exposed to the app side. This model has to be uniform, and correct enough so as to properly guard access to device operations, events, and data to ensure least privilege etc. I think this security model "schema" should be worked into the current schemas (like, define a privilege that a caller app needs before it can invoke an operation from a schema). |
100% agree with you. For now, we started working on the first side of what you described to see how much of the second side we need practically. We also started this exact conversation in the IAB workshop I attended a few weeks ago (https://www.iab.org/activities/workshops/iotsi/, they will be publishing the report soon) so I am looking forward to continue the conversation. |
What you forget to mention is the clashing of various security models. The security model of philips hue might be different from ZWave schlage locks. How does this project address this heterogeneity in sec models? Is there a plan to do this?
The text was updated successfully, but these errors were encountered: