30 principles for an Open Internet of Things Certification Mark.

These are the principles of the Open Internet of Things Mark as of October 18th 2017. This is a simplified overview, do look at the larger document with full requirements.

 

Privacy

Contributors: Mark Simpkins (@marksimpkins)
    1. The product or service the company supplies MUST be General Data Protection Regulation (GDPR) compliant. The company should make sure customers are able gain access to information about the use of their data (e.g how the data is processed, insights generated from the data). The company offers customers the right to delete their data and metadata.Customers are given the ability to selectively withdraw permissions of use of their data (entitlements) temporarily or permanently. In response to this, the company can selectively withdraw access to select services to consumers based on the entitlement level that a consumer provided.
    2. The company SHALL NOT utilise their products to sell customer data to third parties without the knowledge of their customers. Their customer’s data SHALL NOT be used for profiling, marketing or advertising without transparent disclosure.

Interoperability

Contributors: Andy Stanford-Clark (@andysc), Boris Adryan (@borisadryan), Peter Robinson (@nullr0ute), Bob van Luijt (@bobvanluijt), Thomas Amberg (@tamberg)
    1. The company MUST allow third parties to connect devices, apps and services to its backend API.
    2. A company SHOULD grant third parties the same functional scope on the backend as its own devices, apps and services.
    3. A company MUST allow third parties to communicate with its devices.

 

Openness

Contributors: Thomas Amberg (@tamberg)
    1. A company SHOULD publish the device source code under an open source license.
    2. A company SHOULD publish the device hardware designs under an open hardware license.
    3. The company SHOULD publish the backend source code under an open source license.

 

Data Governance

Contributors: Dr. Alison Powell, Mark Simpkins (@marksimpkins), Selena Nemorin (@digiteracy)
    1. The company SHOULD make it visible to its customers what data and channels of communication the device / service uses.
    2. The company MUST/SHOULD make it possible for customers to turn off the connection/s to any data cloud. They should make clear the ‘risk’ associated with doing this.
    3. The company MUST not degrade/change the current core functionality of the device in the future, offering the same core product functionality throughout the natural life of the product. The company MUST not actively reduce core functionality through the natural life of the product.

 

Permissions & Entitlement

Contributors: Martin Dittus (@dekstop), Mark Simpkins (@marksimpkins), Selena Nemorin (@digiteracy)
    1. A company SHOULD offer customers the right to transfer ownership of hardware, to export their data, and to migrate service providers.
    2. The company MUST be explicit as to the expected duration of terms (e.g. for how many years is device support guaranteed?)
    3. If a company wants to change the above, it MUST first ask permission from the customer (not just notify, or silently change terms).

 

Transparency

Contributors: Pilgrim Beart (@pilgrimbeart)
    1. A company MUST be explicit to a customer as to whether there are secondary legal obligations, e.g. if they’re buying car insurance via a monitoring device, they might have an obligation to provide valid data.

 

Security 

Contributors: Mark Carney @LargeCardinal, Graham Markall @gmarkall, Jan-Peter Kleinhans 
    1. The company MUST provide minimum cryptographic security on its servers & secure configuration
    2. The company’s backend service systems  MUST implement additional secure setup options (aka Defence In Depth)
    3. The company SHOULD implement reliable and appropriate patching procedures which should be evidenced.
    4. The company MUST enforce a strong user identity policy
    5. A company’s product MUST be compliant with the IoTSF Security Compliance Framework
    6. A company’s product MUST use cryptographic schemes
    7. A company’s firmware MUST be compliant with industry security standards.
    8. A company MUST clearly communicate with a customer in the event of a change in firmware
    9. A company MUST clearly communicate with a customer in the event of opting out of Automated Patching
    10. A company MUST have clear admin user management policies.
    11. A company MUST offer the ability for a customer to do a factory reset on its product.
    12. A company MUST take every precaution to protect its customers from the product being exposed to local / adjacent subnet attacks or any other attack.

Lifecycle, provenance, sustainability & futureproofing

Contributors: Alasdair Allan (@aallan), Chris Adams (@mchrisadams), Adrian McEwen (@amcewen), Dries De Roeck (@driesderoeck), Matthew Macdonald-Wallace (@mbconsultinguk), Joanna Montgomery (@joannasaurusrex),  Gavin Starks (@agentGav)
    1. The company MUST be clear about the expected lifetime of the product and the expected support the customer should expect
    2. The company MUST document any parts that a customer could be realistically expected to repair.
    3. The company MUST supply spare parts on request during the lifetime of the product.
    4. The company SHOULD be able to list the countries involved in their supply chain comprising their product.

 

 

NB: The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,  “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119, https://www.ietf.org/rfc/rfc2119.txt.

 

Advertisements