IoT Broker

The IoT Broker is a message broker that helps ensure things connected to the Internet has a secure, open and interoperable communication environment. It does this by:

Using this IoT Broker allows you to create open, yet secure and interoperable applications for the Internet of Things.

How does it work?

The IoT Broker helps secure the Smart City by providing the following set of services:

Incentivising the development of the Smart City
Incentivising the development of the Smart City

IEEE IoT Harmonization

The IoT Broker is based on the results of the IEEE IoT Harmonization effort. The goal is to create open standards that facilitate the interoperable communication of things across the Internet, in a secure manner. Interfaces and descriptions are made available at the IEEE-SA XMPP IoT Interfaces repository. During Q3-Q4 2018, this set of interfaces will be expanded with interfaces for contracts and economic feedback models.


The infrastructure is federated by design. This means that you can freely extend the network by setting up your own integration servers on your own domains using your own domain names. Devices connected to any integration server on the Internet can communicate with any device connected to any other integration server on the Internet, as long as they are authorized to do so. This is possible, since the integration servers cooperate and exchange messages between themselves, in real time, just like mail servers do, but faster. For this reason, Integration Servers are also known as message brokers. They broker messages between entities on the Internet.

Topology Independence

Entities connect outward to their assigned message broker. Never do things need to establish different connections depending on who they communicate with. All messages sent and received are passed over the same connection. Never do entities need to accept incoming connections. This allows things and users to reside behind firewalls. Since message brokers interconnect and exchange messages, things and users can reside behind different firewalls, connect to different message brokers, and still communicate with each other.

Global Scalability

The federated nature of the infrastructure also provides a natural way for it to grow organically. It is not necessary to create huge complex data centres that host services for everyone at once. Instead, anyone can host their own set of message brokers, without affecting the network performance of others needlessly. At the same time, this is done without restricting who entities can communicate with. Message brokers collaborate to form a global network of interconnected things.


Federation is also a great tool for creating resilient networks, as you divide the risks across the network. The failure of a message broker only affects a small portion of the entire network, just as a router only affects a small part of the larger interconnected network.

Open Standards

Basing the infrastructure on Open Standards has several advantages: Infrastructure components become replaceable and exchangeable. It also removes the need for the development of bespoke or proprietary back-end software to make entities interconnect and communicate. It becomes possible to create Smart City applications without the requirement to develop server software or to rely on server-storage of sensitive sensor data.

IEEE IoT Harmonization is based on the XMPP protocol, which is an open standard, standardized by the Internet Engineering Task Force, IETF in RFC 6120, RFC 6121 and RFC 6122. XMPP is federated, open, extensible, secure, proven and robust. It is XMPP that defines the basic operation of message brokers. The XMPP Standards Foundation, XSF publish XMPP extensions for different purposes. The IEEE IoT Harmonization effort bases its work on these standards, as well as interfaces published in the IEEE-SA XMPP IoT Interfaces repository.

Protocol Bridging

IEEE IoT Harmonization defines interfaces for concentrators that collect, or concentrate, a set of devices behind a single communication endpoint in the network. This can be used for embedding devices (or nodes) in a single physical device, such as a Programmable Logic Controller (PLC). It can also be used to bridge protocols in real time or connect large back-end systems to the network. Nodes in a concentrator behave just as any other thing connected to the infrastructure, and therefore also benefit from its features such as discovery, decision support, ownership, contracts, and so on.

If you are interested in acquiring protocol gateways between XMPP and any other protocol, such as M-Bus, Modbus, Bluetooth, MQTT, LWM2M, etc., leave a note in the feedback form.


The goal of IEEE IoT Harmonization is to provide, as the name suggests, a means to harmonize different IoT-based technologies and allow them to integrate and interoperate, even if they are based on different communication patterns and protocols. This is possible through the concept of bridging, and because XMPP provides a great support for popular communication patterns. IEEE IoT Harmonization allows for interoperable communication, not only across topology barriers, but also across technology and protocol barriers.

Global Identities

For an entity to be able to connect to a message broker, it needs an account on that broker. The account name, together with the domain name of the broker, becomes a global identity for the entity. The identity, or address takes the form of what looks very much like an e-mail address: account@domain, also called a Bare Jabber ID, or Bare JID. An entity connected to this broker using an account named my.thing would have a global address of Once connected, the message broker provides the entity with a random resource string. Together with the Bare JID, this forms a Full JID, in the form

For concentrators, the Bare JID points to the concentrator itself. A thing that resides in, or behind, a concentrator, is further identified using a Node ID, and optionally by a Source ID and Partition as well. Nodes can reside in sources, which may, or may not be partitioned into segments. The quadruple (Bare JID, Node ID, Source ID, Partition) is globally unique. Node ID, Source ID and Partition are optional


Authentication in distributed environments such as a Smart City is typically difficult. Does everyone need to have access to the credentials of everyone else that it is to be able to communicate with?

In XMPP, this problem is delegated to the brokers. One important task they have is to authenticate all clients connecting to them. You cannot send messages to others in the network before the message broker has successfully authenticated your identity. Brokers also annotate all messages forwarded in the network with the address of the source of the message. This identity is very difficult to spoof, as the brokers also mutually authenticate each other and reject messages not annotated with a source address corresponding to the domain of the emitting broker. This allows the receivers of messages to estimate the validity of a received message simply based on the trust it places on the immediate broker, which is only one.

Simply put: The infrastructure authenticates all participants, and all participants are informed about the authenticated identities of everyone sending them messages. This makes it very easy to make good security decisions in a distributed environment such as a Smart City.

In order to be able to communicate efficiently with another entity in the network, you need its Full JID, not only its Bare JID. The Full JID is transmitted to approved parties when the corresponding entity reports its presence. This is done, among other things, when the entity comes online or goes offline. The Bare JID can be used to request a presence subscription from the entity, which will allow the Full JID to be known if the entity consents to the request. If the corresponding entity does so, its message broker registers this event, and forwards future presence information to the party making the request. The entity can withdraw the consent at any time, making sure the corresponding party is no longer informed about the Full JID of the entity. When reconnecting, receiving a new resource, the party having lost the presence subscription, will not be able to communicate efficiently with the entity any longer.


XMPP includes several authorization mechanisms that help protect entities in the network:

IEEE IoT Harmonization adds an authorization layer of decision support to this list.

Secure Registration

To automate the installation and configuration of huge quantities of devices into the network, along the principles of zero-configuration networking for the operator, an automatic registration procedure is available. To prohibit malicious bots from being able to create identities fraudulently, requests must be identified using an API key and signed using a private key. API keys can be limited with regards to the number of accounts that can be created using it.

On this broker, you can request an API key.


During production, the manufacturer is only aware of the conceptual identity of the devices being manufactured. This identity can include information about serial number, make and model of device, information about manufacturer, etc., as well as a secret key. Typically, the manufacturer and the device are unaware of the network identity the device will have.

After installation and during configuration, the device will find its broker, either through pre-configuration, or through information available in the network, create its network identity. The device then registers itself with a Thing Registry available on the message broker. This registration contains the conceptual identity of the device, and its new network identity.

The conceptual identity, known at the time of production, is transferred out-of-band to the owner of the device. This can be done using a QR-code (for instance) on a sticker or sharing a iotdisco URI. The owner sends a claim to the same Thing Registry. The registry matches registrations and claims, and if they match, pairs the thing with its owner, and informs each one about the network identity of the other.

iotdisco URI encoded as a QR code
iotdisco URI encoded as a QR code

Once claimed, the owner can decide if the thing should remain in the registry or not, and if it should be publicly searchable. The thing, as well as the owner, can annotate the thing with tags. This makes it easier to find relevant things. As the thing knows its owner, it also knows who is responsible for making the correct security decisions. The broker also knows who the owner of each claimed device is. This allows the broker to help things make good security decisions.

Claiming ownership of a device
Claiming ownership of a device


Once each thing knows the network identity of its owner, it becomes possible to define ownership, not only of the thing, but also of the data it generates. Typically, in cloud-based solutions, data ownership is challenging, if not undefined.

Mimicking how ownership of everyday physical objects is defined, or enforced, the infrastructure helps define a method of enforcing ownership of information:

Ownership of information is enforced by utilising the decision support provided by the infrastructure, together with edge computing principles, instead of relying on centralized processing in the cloud, except in cases when required or in accordance with the wishes of the owner.

Decision Support

The infrastructure provides your things with decision support, helping them make security decisions in real time. This provisioning capability allows owners to control who can communicate with their devices and do what with them. It also reduces the responsibility of the manufacturer, who cannot possibly know beforehand for what purpose each device will be used.

When something new happens to a thing, to which it does not know how to react, it can ask the provisioning service in the broker what to do. Designed on the principles of data protection by default, the provisioning service will reject the petition if it does not know how to solve it. But it knows who its owner is, and therefore also, who should know. An asynchronous message is sent to the owner, which the owner can respond to when time is available. Once responded to, the provisioning service learns. The next time the thing asks a related question, the provisioning server knows how to respond. The service has been provisioned in accordance of the will of the owner, and with no impact on the infrastructure operator.


Using the discovery and provisioning features proposed by the IoT Broker, the entire life cycle of the thing is supported. From production, through installation, configuration, production, change of ownership to decommissioning.

Product Lifecycle
Product Lifecycle

Decision support can further be fully automated, using contracts, in accordance with zero-configuration networking principles, and still maintaining a high level of security.


Owners can automate decision support by uploading digital contracts for their things. These contracts stipulate requirements that must be met in order to gain access to their devices, under what conditions access can be given, for how long and how often. Identified third parties wanting access to devices can accept their contracts and are automatically granted access in accordance with the contracts. Things report usage to the infrastructure, which uses this usage information to monitor compliance with the contract. This usage information is also used to create billing information or the Marketplace of Things and Data.

Ubiquitous Encryption

Ubiquitous Encryption is a policy that requires that all client ⇔ broker connections (c2s), and all broker ⇔ broker (s2s) are encrypted and properly authenticated. This is one of many features that provide for added security. In cases where very sensitive information is communicated, End-to-end encryption (E2E) and/or Peer-to-Peer (P2P) communication can be used.


The IoT Broker helps you maintain a high level of data protection by design and by default for your Smart City applications. It does so by providing:

Edge Computing

Edge computing is the paradigm that information should be processed as close to the edge, or the source, as possible. It is the opposite of centralized (or cloud) processing. The IoT Broker helps you realize the Edge Computing paradigm, by not participating actively in the processing of sensor data. The IoT Broker only acts as a message broker, and furthermore provides registry and decision support services for things. Sensor data is never collected by the broker. If an entity wants access to the data, it needs to request it from the thing directly, helped by the infrastructure to do so. If an infrastructure component should try to collect such information from things integrating with the IoT Broker, their corresponding owners would be alerted, and data collection would only be possible in instances where owners consent.


The IoT Broker helps applications respect the privacy of any data subjects related to any sensitive information measured by devices connected to the broker. This is done on an infrastructure level, in several ways:

Marketplace of Things and Data

The law of supply and demand requires you to limit access to a resource for it to be valuable, i.e. having a price above zero. An unlimited resource has no price, or a price of zero. While the resource might have non-monetary values, such as emotional, philosophical or spiritual values, for it to have a monetary value, access to it must be restricted. This does not automatically mean any restricted resource has a value. But all valuable resources are restricted. And so, it is for information too: Only restricted information can be valuable.

For this purpose, the IoT Broker provides a marketplace of things and data, and helps owners restrict access to their things and their data. Owners publish their things in the Thing Registry where others can discover them. Through contracts, owners define the conditions required of acquiring access to their things. Accepting these contracts is done using a digital signature; a deal is made. The plurality of offerings available in the registry forms a marketplace of things and their data.

Economic Feedback

The integration server provides billing information to the infrastructure operator, based on signed contracts and reported usage. The operator can use this information to bill the parties participating in the network, in accordance with their usage. A part of these earnings is used to reimburse the owners whose devices have been used. This creates an economic feedback, helping the owners to get a return on their investment.

Incentives to develop the Smart City

The original question being solved by the proposed infrastructure is as follows: What incentive does an owner of a thing have for allowing others to connect to it and use it in their systems? In the vision of a Smart City, there’s ubiquitous access to things and services in all niches of society. But what incentives are there for this to occur?

In a traditional IoT system there are few. Allowing third parties access to your things will only put more load on your devices, decreasing the performance of your system, while a competitor can publish a similar service as yours without having to invest in hardware. For this reason, most IoT solutions are closed systems prohibiting integration with their things directly, permitting access at most through controlled back-end server platforms using proprietary APIs. Integrations are therefore limited.

Through the proposed infrastructure, there is a clear economic incentive to allow others access to your things. If you provide the type of device for which others are willing to pay to get access to, you might not only get a return on your investment, but also turn a profit. It will become profitable in its own right, to provide access to devices and their data and services. The marketplace will provide a platform for competition, which will accelerate development of the Smart City.


The reasons for choosing XMPP for an IoT backbone are many. Here are some:

XEP support by the IoT Broker

The IoT Broker is an XMPP server dedicated to IoT-related applications. It has support for a specific set of protocols to achieve this. The following table lists what server-specific protocols are supported by the broker. (All client-side protocols are by their very nature automatically supported.) The IoT Broker also supports the IEEE XMPP IoT Interfaces.

Protocol Title
RFC-6120 Extensible Messaging and Presence Protocol (XMPP): Core
RFC-6121 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC-7395 An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket
RFC-7590 Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)
RFC-7622 Extensible Messaging and Presence Protocol (XMPP): Address Format
XEP-0008 IQ-Based Avatars
XEP-0030 Service Discovery
XEP-0049 Private XML Storage
XEP-0054 vcard-temp
XEP-0059 Result Set Management
XEP-0060 Publish-Subscribe
XEP-0065 SOCKS5 Bytestreams
XEP-0077 In-Band Registration
XEP-0092 Software Version
XEP-0115 Entity Capabilities
XEP-0124 Bidirectional-streams Over Synchronous HTTP (BOSH)
XEP-0156 Discovering Alternative XMPP Connection Methods
XEP-0160 Best Practices for Handling Offline Messages
XEP-0163 Personal Eventing Protocol
XEP-0178 Best Practices for Use of SASL EXTERNAL with Certificates
XEP-0185 Dialback Key Generation and Validation
XEP-0191 Blocking Command
XEP-0199 XMPP Ping
XEP-0202 Entity Time
XEP-0203 Delayed Delivery
XEP-0220 Server Dialback
XEP-0288 Bidirectional Server-to-Server Connections
XEP-0324 Internet of Things - Provisioning
XEP-0337 Event Logging over XMPP
XEP-0347 Internet of Things - Discovery
XEP-0348 Signing Forms
XEP-0363 HTTP File Upload
XEP-0377 Spam Reporting

e-Mail Integration

Each account in the IoT Broker, is also a mail account. This means you can mail information to an XMPP client. An XMPP client can also implicitly mail back to a mail client, by sending stanzas to the corresponding mail address. Integration is seamless. Plain text and HTML or Markdown formatted e-mail will be translated automatically to corresponding XMPP message stanzas, and vice versa.

There’s one major difference in how the IoT Broker works with mail, and how normal mail servers work: While both use the Simple Mail Transfer Protocol (SMTP) to send mail messages, the IoT Broker operates using white lists, as opposed to black lists that normal servers operate under. This means that you need explicit approval, or consent, from the recipient, before you can send an e-mail message to a recipient. If such an approval does not exist, the e-mail will not be delivered. Instead, a presence request is issued. The white-list is implemented using presence subscription, just as in the XMPP case. Any XMPP client can add senders to the white-list, by accepting a presence subscription, or subscribing to the presence of an e-mail client. Removal from the white-list is done by simply removing the presence subscription, or corresponding roster item. The e-mail client will be informed of all actions related to its status in the white-list through e-mail status updates.

To be able to send e-mail messages to the IoT Broker, the sender must pass SPF verification (Sender Policy Framework) as defined in RFC 7208. The sender must also pass any DNSBL (DNS Black List) checks set up by the operator.

For more information

For more information on how to build things and services that utilize the infrastructure provided by the IoT Broker, check the following resources.

Mastering Internet of Things

The book “Mastering Internet of Things” by Peter Waher describes many of the above technologies and communication patterns. You can find the book on Packt, Amazon, Bokus and other stores.

Mastering Internet of Things
Mastering Internet of Things

Example projects

Many example projects are available on GitHub in the Mastering Internet of Things repository. References to examples, client libraries and software are also available in the IEEE-SA XMPP IoT Interfaces repository.

The IoT Gateway

The IoT Gateway repository contains software, libraries and examples for integrating with the IoT Broker.


If you have any questions or comments, if you would like to request added features, or if you would like to license the software, please go to the Feedback page. If you want to try the IoT Broker, you can Request an account. If you want to automate account creation, you can Request an API key. Account creation on this broker requires a valid API key.