This document provides an overview of the current technology landscape as seen by the W3C WoT interest group.
This is a template to capture the inputs from the wiki into a deliverable format.
Please contribute using github or the direct edit.
This document uses the following terms defined elsewhere:
The OMA DM Management Objects (Matthias and Mohammed)
Lemonbeat Device Language (Frank)
ECHONET device objects (Naka)
OMA Lightweight M2M (LWM2M) Objects
IPSO Smart Object
IOTDB.org (David Janes)
Vorto (Matthias)
Semantic Sensor Network (SSN) Ontology (Danh)
Tool/Development Support: ontology tools: SPARQL engine & RDF Parser etc.
Resource identification: URIs/URN
SensorML (check from OGC, Simon and Arne)
Device Registry and Thing Shadows for AWS IoT (Michael Koster?)
HyperCat catalogue (John from BT)
The Smart Appliances REFerence (SAREF) ontology (Jasper Roes)
oneM2M (Martin)
RDF Schema (RDFS) (Victor)
Schema.org, based on RDFS, is a popular vocabulary for general information on the Web: persons, events, places, products... Its development has been driven by today's major search engines to help them structure search results using annotations on Web pages (e.g. in the RDFa or microdata formats).
An overview of Web vocabularies can be found on the Linked Open Vocabulary platform.
Web Ontology Language (OWL) (Victor)
OWL proved successful (especially in specific domains like biology) and many Web vocabularies use it (see the LOV platoform for an overview). However, only few of them take full advantage of its expressiveness.
DTD/XML Schema (Sebastian)
JSON Schema (Victor)
Serialization formats suitable for representing Thing Descriptions are surveyed here.
Efficient XML Interchange (EXI) (Taki)
EXI for JSON (Taki)
JSON (Taki)
JSON-LD (Victor)
CBOR (Carsten)
XML Schema (XSD) Datatypes (Daniel)
SenML (Ari)
Functional descriptions for RESTful APIs, hypermedia controls are surveyed here.
HATEOAS (Matthias)
RAML (Victor)
Open API Initiative (OAI) (Victor)
Hydra (Victor)
RESTdesc (Matthias)
JSON HyperSchema (Michael)
Optical markers
NFC
Markerless recognition
UriBeacon (Google's Physical Web)
iBeacon (Apple)
mDNS (+ DNS-SD)
Multicast CoAP
SSDP
WS-Discovery
XMPP Service Discovery
µPnP
CoRE Resource Directory
XMPP IoT Discovery
HyperCat
Push API
SIR
SPARQL Endpoints
Research article: "Mobile digcovery: A global service discovery for the IoT"
Research article: "A discovery service for smart objects over an agent-based middleware"
Research article: "A Semantic Enhanced Service Proxy Framework for Internet of Things"
"RFC7650": CoAP usage for RELOAD
"IETF Draft": Distributed RD
Research article: "A Scalable and self-configurable architecture for service discovery in the IoT"
CoRE Link Format
HATEOAS
SOS
A web service discovery computational method for IOT system
Semantic Enhanced Service Proxy Framework for Internet of Things
An evaluation of semantic service discovery of a U-city middleware
Evaluation Criteria
Category: 1) Finding things around me
| Technology | Follows Identified Interaction Pattern | Higher Layer Discovery | Bootstrapping | Sleeping Time Support | Range | Local / Remote Discovery | Richness of Query | Ranking of Results |
|---|---|---|---|---|---|---|---|---|
| Optical Markers | No (marker cannot send messages) | No | Pointing to thing endpoint | n/a | vicinity of client | Local (vicinity of client) | n/a | n/a |
| NFC | No (NFC initiator [client]starts interaction with target [thing]) | No | Pointing to thing endpoint | n/a | < 10 cm | Local | n/a | n/a |
| Markerless Recognition | No (things are not part of interactions) | Yes (could be supported by filtering out things on an AR layer) | Pointing to thing endpoint | n/a | vicinity of client | Local | n/a | n/a |
| UriBeacon | Yes | No | Advertise message points to thing endpoint | There is support for sleep state in BLE and depends on which power mode is being used in the thing. For lowest power mode, the radio is switched off completely and the thing will not periodically announce its URI. There are power mode configurations where the thing powers on once every so many seconds, broadcasts, listens, then goes back to sleep. | < 100 m (link) | Local (around the client) | n/a (since this discovery is not initiated by manual search) | n/a |
| iBeacon | Yes | No | Advertise message points to thing endpoint | Same as above (need to confirm) | < 100 m (link) | Local (around the client) | n/a | n/a |
Category: 2) Finding things on my network
| Technology | Follows Identified Interaction Pattern | Higher Layer Discovery | Bootstrapping | Sleeping Time Support | Range | Local / Remote Discovery | Richness of Query | Ranking of Results |
|---|---|---|---|---|---|---|---|---|
| mDNS | Yes | No (but can be implemented on application layer) | Client receives an IP address of the thing for direct interaction | No | n/a | Local (network point of view) | N/A since there is no manual entry of keywords | No |
| Multicast CoAP | yes | yes, if resource directory is used | address, port, and resource descriptions | No | n/a | Local (network point of view) | N/A since there is no manual entry of keywords | No |
| SSDP | Yes | No (only basic filtering for devices or services with a specific type) | Client receives the endpoint of the UPnP device description | No | n/a | Local (network point of view) | N/A querying using keywords is not possible | No |
| WS-Discovery | Yes | Only basic filtering is possible. They use the term 'scope' for this. | Discovery happens in two steps: (1) find services and (2) locate a target service, i.e., to retrieve its transport address(es) | No | n/a | Local (network point of view) | basic querying using service types and scopes | No |
| XMPP Service Discovery | No | Yes (Two kinds of information can be discovered: (1) the identity and capabilities of an entity, including the protocols and features it supports; and (2) the items associated with an entity, such as the list of rooms hosted at a multi-user chat service) | Provides information on identity and capabilities of an entity. | No | n/a | Local discovery | basic querying which discovers entity, features etc | No |
Category: 3) Searching in Directories
| Technology | Follows Identified Interaction Pattern | Higher Layer Discovery | Bootstrapping | Sleeping Time Support | Range | Local / Remote Discovery (DOES THIS MAKE SENSE HERE??) | Richness of Query | Ranking of Results |
|---|---|---|---|---|---|---|---|---|
| CoRE Resource Directory | Yes | Yes, key-value-pair search based on tagged resources (e.g., "resource type", "interface type" etc.) is supported | IP address & port of thing and list of resources matching the query | No | n/a | Local and remote | No. Not beyond tag concatenation. | No |
| XMPP IoT Discovery | Yes | Yes | Provides various metadata for discovered thing. | Yes | n/a | Local and remote | Basic (the spec is not finalized) | No |
| HyperCat | Yes | Yes, flexible key-value-pair search based on tagged resources is supported | Provides reference to thing. | No | n/a | Local and remote | No. Not beyond key-value-pairs. | No |
| Push API | Yes | (???) | Yes, through notifications | Yes, Service Worker runs in the background | n/a | Yes | (???) | (???) |
| Sensor Instance Registry | Yes | Yes (bound to SensorML as thing description) | Provides rich metadata description (SensorML) of discovered device | No | n/a | Local and remote | Yes. Spatial and Temporal queries. | No |
| SPARQL Endpoint | Yes | Yes (flexible search interface - independent of underlying thing description) | Provides description of discovered thing. | No | n/a | Local and remote | Yes, high flexibility in query formulation. | Yes (with 'order by') |
Category: 4) Searching across Peers
| Technology | Follows Identified Interaction Pattern | Higher Layer Discovery | Bootstrapping | Sleeping Time Support | Range | Local / Remote Discovery | Richness of Query | Ranking of Results |
|---|---|---|---|---|---|---|---|---|
| CoAP RELOAD | No pattern has been investigated | See CoAP RD | See CoAP RD | No | n/a | Local and remote | See CoAP RD | No |
Category: 5) Accessing thing metadata
| Technology | Follows Identified Interaction Pattern | Higher Layer Discovery | Bootstrapping | Sleeping Time Support | Range | Local / Remote Discovery | Richness of Query | Ranking of Results |
|---|---|---|---|---|---|---|---|---|
| CoRE Link Format | Yes | No | Yes, this format can be used for bootstrapping. | No | n/a | Local and remote | Low. Just direct access to metadata. | Can be used by application layer to rank results |
| HATEOAS | No (typically, not one metadata document, but information distributed and advertised via links) | No | Bootstrapping information can be gathered by following links. | No | n/a | Local and remote | Low. | No |
| Sensor Observation Service | Yes | No | Yes, it returns SensorML when metadata is queried. | No | n/a | Local and remote | Medium. Temporal queries are supported. | No |
| Consortium | Focus Domain | 1. Category: Finding things around me | 2. Category: Finding things on my network | 3. Category: Searching in Directories | 4. Category: Searching across Peers | 5. Category: Accessing thing metadata |
|---|---|---|---|---|---|---|
| IETF | all | -- | mDNS; Multicast CoAP; SSDP | CoRE Resource Directory | CoAP RELOAD | CoRE Link Format |
| OMA | all | -- | -- | OMA LwM2M uses CoAP | -- | OMA LwM2M can be extended to work with CoRE Link Format |
| OIC | all | ? | ? | ? | ? | ? |
| Allseen Alliance | smart home | About Announcement | mDNS | ? | -- | -- |
| IPSO Alliance | all | -- | Not explicitely supports this but CoAP can be extended | CoAP | -- | CoRE Link Format |
| oneM2M | telecomunication (Note from Soumya - oneM2M proposes to be independent of the underlying network and does not propose any specific protocols to work with. But they have worked on binding to HTTP and MQTT) | Possible through UriBeacon | Possible through mDNS | Possible through CoAP | -- | CoRE Link Format |
| ThreadGroup | smart home | ? | ? | ? | ? | ? |
| Hyper/Cat | smart cities | -- | -- | HyperCat Catalogue | -- | -- |
| Open Group | ? | ? | ? | ? | ? | ? |
| OGC SWE | smart cities, environmental monitoring | -- | -- | Sensor Instance Registry | -- | Sensor Observation Service |
httpscheme
coapscheme
REST or representational state transfer assumes that requests/responses transfer the state of the resource, but what does that mean when the state is constantly changing?
This has been addressed by creating extensions to the REST design style, both in CoAP Observe and HTTP EventSource, that allow for multiple serial state changes to be returned asynchronously in response to a request. The client/application simply responds to these using a handler and applies the resource state changes to the application state.
For example, if the application is a thermostat, the asynchronous temperature state updates invoke a handler that evaluates the thermostat mode and other controls and decides, on each response from the sensor, whether to turn the heating system on or off, heat or cool mode.
Additionally, a request can provide the URI for asynchronous call backs. This provides the notion of a subscription, or binding, where you may CREATE (POST) a control to a location that starts "web callbacks" which are POST or PUT operations sent to the destination address configured by the CREATE operation.
These patterns are becoming more well known and are described in the abstract transfer layer proposal.
In the CoRE Interfaces draft, there is a description of Observe Attributes, which are additional controls on the Observation. For example, the pmin attribute specifies the minimum interval between responses. By using pmin in conjunction with a content format that allows batch sample reporting (e.g. SenML) rapidly changing samples may be buffered at the source and sent as a batch in each periodic notification. Additional conditional observe attributes are defined and being defined to provide additional controls and filtering. These are appropriate for including in the payload when creating a subscription or binding.
Additionally, in a REST based hypermedia system, resources may be assigned media types and content formats that are designed for media streams. This works like a websocket upgrade, where a separate socket connection is made from the media stream data source to the handler in the application.
rt) as semantic tag and interface (
if) for interaction type labels
There are numerous exisiting web api frameworks that can or could serve as current practise, e.g. refer to todobackend.com
While things may be of low value (say <50$) they can control (parts of) high value assets such as smart locks controlling access to homes or offices/factories. WoT aims at exposing the functonality of such things at public-facing endpoints in the Internet/Web. This establishes security as a top concern for WoT.
Things can reveal/expose data related to user habits such as lightning/heating practices or the human body such as heartbeat rates. This establishes privacy as another top concern for WoT. In the first place this refers to things owned/used by individuals esp. consumer goods. Privacy can also concern things owned/used by legal entities e.g. capital/investment goods such as health care equipment. But not all things owned/used by legal entities are subject to privacy concerns. There also are WoT scenarios which do not process individual user data such as industrial control systems.
This chapter provides the security&privacy landscape for WoT.
The WoT provides distributed IT-systems. The study of protecting distributed IT-systems started soon after their invention i.e. in the 60/70ies. So there is lots of prior art for security&privacy - collectively providing the current toolbox. But WoT needs security&privacy tools that are not yet present in the current toolbox. New security&privacy tools for WoT will come in 2 forms:
The inclusion of physical goods and processes is the key differentiator between the Web-of-Things on the on hand and the Web-of-Services resp. the traditional Web (Web-of-Pages) on the other hand.
There are Web-of-Services and Web-of-Pages security&privacy requirements which translate to Web-of-Things in a straight-forward manner such as user authentication->thing authentication. For such requirements security&privacy mechanisms were established by other domains such as office/enterprise IT or Cloud computing. Corresponding standards and best practices do exist and may apply or may be translated to WoT. Note that constraints (number of instances, computing power, memory, IO and networking capabilities etc.) do change when considering the WoT image of a traditional requirement such as the authentication of a caller.
The inclusion of physical goods and processes also leads to security&privacy requirements or constraints with no real/good analogies in the digital World. These requirements resp. constraints are not yet covered by security&privacy technologies developed for existing domains. This includes security&privacy requirements as well as constraints such as:
The W3C IG WoT is considering same as well as cross-domain interactions among resp. with things:
Numerous security&privacy-enabling tools do already exist. Prominent examples are Kerberos, SSL/TLS and OAuth. They were created to serve the needs encountered in office/enterprise IT (e.g. Kerberos), the classical Web (e.g. SSL/TLS) as well as new Web application styles esp. service-oriented applications, apps/REST APIs (e.g. OAuth). The corresponding mechanisms often are very mature i.e. they represent broadly accepted standards that are in large-scale production use.
This prior-art can help to address security&privacy for (parts of) WoT scenarios. But there is no guarantee that a (mature) security or privacy means with non-WoT origin/heritage does present a good match for WoT. For security/privacy mechanisms with non-WoT origin, fitness checks are needed.
Security&privacy mechanism with WoT or IoT origin are work-in-progress nowadays. They do not yet present the same maturity level (not yet broadly accepted standards, not yet in large-scale protection use). Hence (and for the time being) maturity checks are needed for security/privacy mechanisms with WoT origin.
Different security&privacy tools do have different impact on the architecture and implementation of WoT systems:
Mechanisms invented <2010 for distributed IT-System security e.g. Kerberos, SSL/TLS, SAML happen to distribute logical and computational complexity quite evenly over client and server components.
This was a major issue for the Web app/API economy where 3rd pary developers create components (e.g. mobile apps) that interact with services provided by other parties. To overcome this obstacle the new generation security resp. security-enabling technologies invented >2010 (e.g. OAuth) distribute complexity unevenly:
The table below surveys potential building blocks for WoT security and privacy and identifies their current evolution stage (as of 2016-02-29):
| - | Informational Self-Determination | Anonymization, Pseudonymization | Authorization Management | Authorization Enforcement | Initial Authentication | Single-Sign-On | Confidentiality | Data Origin Authentication, Integrity | Credentialing | Provisioning | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|
| UMA | Core objective (through user-managed authorizations) | - | Addressed (users as primary policy management authorities) | Addressed (push model, HTTP) | - | - | - | - | - | - | IETF draft (individual submission to IETF oauth WG) |
| OATH | - | - | - | - | Core objective (time, event or challenge-based OTP schemes) | - | - | - | Addressed (symmetric key containers and provisioning of symmetric keys) | - | IETF standards |
| OpenID Connect | Side concern (users decide if their identity information is supplied to relying parties | Implementation-specific | - | - | Core objective (requests reports about [initial] authentication events) | Core objective (SSO across organizations/domains and in the same domain) | - | - | See OAuth | See OAuth | OpenID Forum standards |
| JWT | - | - | - | - | Core objective (reports about [initial] authentication events) | Side concern (allows to transfer and sustain information about authentication events) | - | - | - | - | IETF standard |
| CWT | - | - | - | - | Core objective (reports about [initial] authentication events) | Side concern (allows to transfer and sustain information about authentication events) | - | - | - | - | IETF draft (individual submission to IETF ace WG) |
| FIDO | - | Core objective (uses long-lived public key associations instead user names/identifiers) | - | - | Core objective (framework for initial user authentication in the Web) | - | - | - | Side concern (defines the creation/supply of public/private keys to FIDO clients) | - | Submitted to W3C |
| OAuth | - | - | Core objective (users or legal entities as policy management authorities) | Core objective (push model, HTTP) | - | - | - | - | Side concern (registration/management of OAuth clients) | Side concern (registration/management of OAuth clients) | IETF standards |
| OAuth-for-CoAP | - | - | Core objective (legal entities as policy management authorities) | Core objective (push model, CoAP) | - (DTLS-based client authentication) | - (no user actor) | - | - | - | - | IETF working group draft (IETF ace WG) |
| DCAF | - | - | Core objective (legal entities as policy management authorities) | Core objective (push model, CoAP) | - | - | - | - | - | - | IETF draft (individual submission to IETF ace WG) |
| DTLS | - | - | - | - | Core objective (transport-level client/server authentication) | - (does not define the transfer of authentication state across network servers) | Core objective (transport-level message encryption) | Core objective (transport-level signature) | - | - | IETF standard |
| DICE | - | - | - | - | As for DTLS | - | As for DTLS | As for DTLS | - | - | IETF working group draft (IETF dice WG) |
| JOSE | - | - | - | - | - | - | Core objective (application-level encryption, JSON) | Core objective (application-level signature, JSON) | - | - | IETF standards |
| COSE | - | - | - | - | - | - | Core objective (application-level encryption, CBOR) | Core objective (application-level signature, CBOR) | - | - | IETF working group draft (IETF dice WG) |
| OSCOAP | - | - | - | - | - | - | Core objective (application-level encryption, CBOR or JSON) | Core objective (application-level signature, CBOR or JSON) | - | - | IETF working group draft (IETF ace WG) |
| SCIM | - | - | - | - | - | - | - | - | - | Core objective (manage metadata about system actors-not limited to users) | IETF standards |
As of today there are no broadly accepted protocol standards for authenticating and authorizing things. Current projects do either not address these challenges or create silos.
The IETF ACE working group happens to be the leading initiative in order to overcome this limitation:
A decentralised, peer-to-peer (P2P) system is a collection of applications run on several local computers, which connect remotely to each other to complete a function or a task. A decentralised peer to peer overlay network manages connections between human and Internet of Things peers. The participants in the network are the peer nodes. The peer to peer network is scalable and an unlimited number of nodes can participate in the network.
Centralized corporate owned cloud is certainly an easier way to build out IoT platforms; however, the owners, application service providers, cloud service providers and authorities of these topologies have an influence upon the network and can exploit it. They can ban devices, spy on devices, and compromise the data integrity of the devices. In fact, the government can order the cloud service operators and centralised application providers to do all of these things.
In the near future, the doors, air condition units, and security system of homes will be fully internet connected. The users will be able to control their home automation system from a mobile phone device. It is essential that only the end user has full control over the IoT devices. Decentralised P2P Internet of Things aims to provide users with such exclusive and full control.
The following areas are in scope for decentralised P2P IoT