Better IoT (fka Open IoT Certification Mark) Principles – June 13th 2018
This work by betteriot.org is licensed under Creative Commons BY-SA 4.0.
This is the latest version of a working document to develop a certification mark for connected products by IoT community members worldwide. This is a work in progress and you may comment freely, join the conversation on Slack, sign up to our newsletter or give us feedback in writing ([email protected]) or on our monthly open calls.
This is a set of principles that we think a vendor — a connected product manufacturer, team or founder — would use to make a good, secure, ethical, product that also takes into account the General Data Protection Regulation (GDPR). But also to push beyond the GDPR and look at the entire life cycle of a smart device. From manufacture, to final disposal.
The terminology in this document is a bit technical, bear with us. We use MUST, SHOULD, and MAY because of a technical writing standard called RFC 2119.
The following definitions are based on a simple reference model for connected products.
A connected product is the entirety of one or more devices, gateways, a backend, apps and the services they represent.
A device is a physical thing with connectivity, an embedded computer, sensors and actuators. (A client running a dashboard app is not a device in this sense.)
A gateway is a physical device, often bridging physical transports to connect devices to the backend. It might aggregate data, or enact local control.
The device is connected to a backend, consisting of one or more server(s) "in the cloud". The connection is established over the Internet, sometimes via a gateway.
A client is any app, dashboard or third party service. Once a device is connected, it allows for virtual interaction, often through a backend API.
An API is an application programming interface. It defines an endpoint, a protocol and a data format. The backend API allows devices or clients to programmatically talk to the backend.
The vendor builds, sells or operates the connected product and implements the IoT Mark principles. The term is not very concise, but seems more accurate than manufacturer, seller, integrator, maintainer or service operator.
The user buys, owns or uses the connected product. The term is quite broad, but seems more fitting than consumer, customer, owner or data subject.
A third party is everybody else than the vendor or the user.
The assessment criteria below are intended to be "self-assessed but verifiable" and allow "verification through documentation" as specified in this presentation by Peter Bihr / ThingsCon (CC BY-SA 4.0).
To enable a central repository, assessment deliverables should be one or more URL links to publicly accessible resources on the vendor (or third party) website, including technical and user documentation, privacy and security policies, terms and conditions, and source code.
Note: What does GDPR compliance mean for IoT? Connected products often collect data through device sensors or by logging user commands. The distinction between personal user data and environmental data becomes fluent. All data is assumed to be personal.
Assessment: The vendor submits a link to public documentation explaining how to export collected data, and a link to the respective section in terms & conditions.
Example: GDPR for things
Assessment: The vendor submits a link to its public privacy policy explaining how the collected data is used.
Example: Arduino privacy policy
Assessment: The vendor submits a link to public documentation explaining how to delete collected data, to "be forgotten".
Example: TODO
Assessment: The vendor submits a link to public documentation explaining how to export collected data, and a link to the respective section in terms & conditions.
Example: TODO
Assessment: The vendor submits a link to public documentation explaining how to opt out of direct marketing based on the collected data.
Example: TODO
Assessment: The vendor submits a link to public documentation explaining how to restrict the use of the collected data.
Example: TODO
Assessment: The vendor submits a link to public documentation explaining how to update the collected data.
Example: TODO
8. The vendor MUST allow users to stop automated decisions being made, if there are personal legal or significant consequences.
Assessment: The vendor submits a link to public documentation explaining how to stop automated decisions and get a human to re-evaluate the decision.
Example: TODO
Note: Interoperability is about making it technically possible to use devices, backends and clients of the vendor with those of a third party. Interoperability does not imply unrestricted access to user data.
Assessment: The vendor submits a link to public documentation of the client-specific backend API.
Example: Safecast HTTP Client API
- Endpoint: api.safecast.org:443
- Protocol: HTTPS
- Methods: GET /measurements.json, ...
- Data format: JSON, e.g. Measurement {"value":47.0,"unit":"cpm","captured_at":"2011-04-23T21:53:03.000Z","latitude":35.640968333333,"longitude":139.72069833333}
- Data model: users, measurements, devices
10. The vendor SHOULD grant third party clients the same functional scope on the backend as its own clients.
Assessment: The assessor collects complaints, including screenshots or video "proof", filed by users or third parties.
Example: Some client-specific backend APIs delay measurements they make available to third party clients, preventing them from making real-time decisions.
Assessment: The vendor submits a link to public documentation of the device-specific backend API.
Example: ThingSpeak MQTT Device API
- Endpoint: mqtt.thingspeak.com:8883
- Protocol: MQTT with TLS
- Methods: PUB channels/CHANNEL_ID/publish/API_KEY
- Data format: ASCII, field1=T_VALUE&field2=H_VALUE
- Data model: channels, measurements, e.g. temperature & humidity
12. The vendor SHOULD allow third parties to communicate directly with its devices, without going through the backend.
Assessment: The vendor submits a link to public documentation of the device communication interface.
Example: Generic BLE heart rate sensor
- Physical communication standard: Bluetooth Low Energy (BLE)
- Protocol: BLE [GATT](https://www.bluetooth.com/specifications/gatt/generic-attributes-overview)
- Access primitives: BLE [Heart Rate Profile](https://developer.bluetooth.org/TechnologyOverview/Pages/HRP.aspx)
- Data format: binary encoding, [heart rate measurement](https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.heart_rate_measurement.xml&u=org.bluetooth.characteristic.heart_rate_measurement.xml)
- Data model: heart rate, sensor location, control point
Note: Openness is about open source, which is considered a simple way to reduce dependencies between a vendor and a user and build trust between them. Openness does not imply unrestricted access to user data.
Assessment: The vendor submits a link to a public source code repository or ZIP file. The source code is licensed with MIT License or Apache 2 or GPLv3 or at least a license compliant with the Open Source Definition.
Example: TheThingsNetwork firmware
Assessment: The vendor submits a link to a public repository or ZIP file. Hardware design files may include but are not limited to schema files, PCB layouts, and any other materials that would support the recreation of the product by the user or a third party. The license is compliant with the Open Source Hardware Definition.
Example: Safecast devices
Assessment: The vendor submits a link to a public repository or ZIP file. The source code is licensed with Apache 2 or AGPLv3 or at least a license compliant with the Open Source Definition.
Example: TheThingsNetwork backend source code
Assessment: The vendor submits a link to a public source code repository or ZIP file. The source code is licensed with MIT License or Apache 2 or GPLv3 or at least a license compliant with the Open Source Definition.
Example: TODO
Assessment: The vendor submits a link to user documentation explaining how to turn off the connection from the device to the backend.
Example: TODO
Assessment: The vendor submits a link to public user documentation explaining how to transfer ownership of a device to another user.
Example: TODO
19. When ownership of the device is transferred, the new user MUST NOT have access to previous user's data.
Assessment: The vendor submits a link to video proof. The assessor collects user complaints.
Example: TODO
Assessment: The vendor submits a link to public user documentation explaining the (secondary) legal implications of changing how the device is used, or taking it offline.
Example: Turning off a car's blackbox on the race track might lead to increased insurance fees.
Assessment: The vendor submits a link to the terms of service which have to include a "best before" expiration date.
Example: TODO
Assessment: The vendor submits proof that terms & conditions changes are communicated to users and their permission is sought explicitly.
Example: TODO
Assessment: The vendor submits a link to a blog or feed or other public, auditable trail of firmware revisions.
Example: TODO
Assessment: Demonstrate training, regular security assessment, security requirements for their suppliers, threat intelligence. Provide a [email protected] email contact with quick response.
Example: TODO
Assessment: Define security requirements, strong crypto, provide security support via OTA update (see 5), integrate the security of dependencies (see 5), secure firmware.
Example: TODO
Assessment: Users need to change the password at first run, no unencrypted communication, no unneeded open service.
Example: TODO
Assessment: The vendor submits a risk assessment of the security of the device and its backend (OWASP Top 10, secure backend).
Example: TODO
Assessment: The vendor submits a link to public user documentation showing how to factory reset the device.
Example: TODO
Assessment: Include on the packaging of the product and on the online presence of the vendor a clear statement of intended lifetime and support. Post-lifetime support should be clearly explained ( replacement part vendor list. An End of Life T&C’s and End of Life actions should be well defined - including in case of bankruptcy, takeover, etc. Should include ‘what happens to my data?’ and ‘what happens to my device(s)?’
Example: TODO
30. The vendor MUST be clear about the levels of user support provided during the lifetime of the connected product.
Assessment: The vendor submits a link to a public description of user support mechanisms online or on the on the packaging.
Example: TODO
31. The vendor SHOULD NOT degrade or change the core functionality of the connected product over its lifetime.
Assessment: Core functionality is declared once by the vendor and backed by submitting a link to public marketing materials. Compliance with the principle can be verified on audit or by users at any time by comparing the current functionality with the declared core functionality.
Example: TODO
Assessment: The vendor submits a link to public user documentation including a visual overview of how repairs can be done. Design files should be made available if the piece is expected to be 3D-printed.
Example: TODO
Assessment: A clear and accessible form that a user can fill in to request these parts should be included as part of the packaging or online presence of the vendor.
Example: TODO
Privacy: Mark Simpkins (@marksimpkins),
Interoperability: Andy Stanford-Clark (@andysc), Boris Adryan (@borisadryan), Peter Robinson (@nullr0ute), Bob van Luijt (@bobvanluijt), Thomas Amberg (@tamberg)
Openness: Thomas Amberg (@tamberg)
Data Governance: Dr. Alison Powell, Mark Simpkins (@marksimpkins), Selena Nemorin (@digiteracy)
Permissions & Ownership: Martin Dittus (@dekstop), Mark Simpkins (@marksimpkins), Selena Nemorin (@digiteracy)
Transparency: Pilgrim Beart (@pilgrimbeart)
Security: Mark Carney (@LargeCardinal), Graham Markall (@gmarkall), Jan-Peter Kleinhans (@JPKleinhans), Alasdair Allan (@aallan), Cédric Lévy-Bencheton (@clevybencheton)
Lifecycle: Alasdair Allan (@aallan), Chris Adams (@mrchrisadams), Adrian McEwen (@amcewen), Dries De Roeck (@driesderoeck), Matthew Macdonald-Wallace (@mbconsultinguk), Joanna Montgomery (@joannasaurusrex), Gavin Starks (@agentGav)
Berlin March 2018 edit by: Alasdair Allan (@aallan), Anthony James Munns (@bitshiftmask), Albrecht Kurze (@AlbrechtKurze), Thomas Amberg (@tamberg), Chris Adams (@mrchrisadams), Alexandra Deschamps-Sonsino (@iotwatch)
London June 2018 edit by: Alexandra Deschamps-Sonsino (@iotwatch), Thomas Amberg (@tamberg), Chakshu Saharan (@Ignius_IoT), Laura James (@LaurieJ), Albrecht Kurze (@AlbrechtKurze), Viktor Petersson (@vpetersson), Alasdair Allan (@aallan), Duncan Wilson (@djdunc), Dom Guinard (@domguinard), Geusseppe Gonzalez (@GeuseppeGC), Dries De Roeck (@driesderoeck), Konrad Komorowski, Alison Powell (@a_b_powell), Mark (@ukmoose), Louise Hugen (@louisehugen), Funda Ustek-Spilda (@fundaustek), Alex Kosenkov, Cédric Lévy-Bencheton (@clevybencheton)
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent