<abstract>This specification describes an architecture for efficient provisioning of services, access rights and user privileges in for the Internet of Things, where
communication between Things is done using the XMPP protocol.</abstract>
<p>Element renamed from <strong>Friend</strong> to <strong>friend</strong> when recommending friendships.</p>
<p><strong>clearCache</strong> IQ stanzas now of type <strong>set</strong> instead of <strong>get</strong>.</p>
<p>Corrected schema with regards to tokens.</p>
<p>The <strong>getToken</strong> command now takes a base-64 encoded X.509 certificate (public part) instead of arbitrary string IDs.</p>
<p>An additional challenge/response step has been added to make sure the sender of a certificate has access to the private part of the certificate.</p>
<p>Named links to all sections in the document.</p>
<p>Added reference to XEP-0347, for how things can find provisioning servers.</p>
<p>Added method of finding provisioning server, if server hosted as a server component.</p>
<p>Updated examples to reflect a provisioning server hosted as a server component, harmonizing with XEP-0347.</p>
<p>Added a section about token challenges and token propagation.</p>
<p>Added a security note regarding token challenges.</p>
This specification describes an architecture for efficient provisioning of services, access rights and user privileges in for the Internet of Things, where
communication between Things is done using the XMPP protocol.
</p>
<p>
Note has to be taken, that this XEP, and other Internet of Things-related XEP's, are designed for implementation in small devices, many of which have very limited
amount of memory (both RAM and ROM) or resources (processing power). Therefore, simplicity is of utmost importance. Furthermore, Internet of Things networks can
become huge, easily containing millions or billions of devices in peer-to-peer networks.
An added complexity in the provisioning case is that Things (small sensors for example) often have very limited user interface options. Therefore, this document
explains how provisioning can be done efficiently using a trusted third party with more power and options when it comes to user interface design and storage.
This XEP relies on &xep0323; and &xep0325; for sensor data readout and control interfaces. It relies on &xep0326; for bridging protocols and interfaing entities with multiple devices
behind them. It also ties into &xep0347; for automatic discovery of provisioning servers by things.
</p>
<p>
Internet of Things contain many different architectures and use cases. For this reason, the IoT standards have been divided into multiple XEPs according to the following table:
<td>Defines guidelines for how to achieve interoperability in Internet of Things, publishing interoperability interfaces for different types of devices.</td>
<td>Defines how human-to-machine interfaces should be constructed using chat messages to be user friendly, automatable and consistent with other IoT extensions and possible underlying architecture.</td>
Defines how to EXI can be used in XMPP to achieve efficient compression of data. Albeit not an Internet of Things specific XEP, this XEP should be considered
<td>Defines the peculiars of sensor discovery in sensor networks. Apart from discovering sensors by JID, it also defines how to discover sensors based on location, etc.</td>
<dd>A value that is computed instead of measured.</dd>
</di>
<di>
<dt>Concentrator</dt>
<dd>Device managing a set of devices which it publishes on the XMPP network.</dd>
</di>
<di>
<dt>Field</dt>
<dd>
One item of sensor data. Contains information about: Node, Field Name, Value, Precision, Unit, Value Type, Status, Timestamp, Localization information, etc.
Fields should be unique within the triple (Node ID, Field Name, Timestamp).
</dd>
</di>
<di>
<dt>Field Name</dt>
<dd>Name of a field of sensor data. Examples: Energy, Volume, Flow, Power, etc.</dd>
</di>
<di>
<dt>Field Type</dt>
<dd>What type of value the field represents. Examples: Momentary Value, Status Value, Identification Value, Calculated Value, Peak Value, Historical Value, etc.</dd>
</di>
<di>
<dt>Historical Value</dt>
<dd>A value stored in memory from a previous timestamp.</dd>
</di>
<di>
<dt>Identification Value</dt>
<dd>A value that can be used for identification. (Serial numbers, meter IDs, locations, names, etc.)</dd>
</di>
<di>
<dt>Localization information</dt>
<dd>Optional information for a field, allowing the sensor to control how the information should be presented to human viewers.</dd>
</di>
<di>
<dt>Meter</dt>
<dd>A device possible containing multiple sensors, used in metering applications. Examples: Electricity meter, Water Meter, Heat Meter, Cooling Meter, etc.</dd>
</di>
<di>
<dt>Momentary Value</dt>
<dd>A momentary value represents a value measured at the time of the read-out.</dd>
Graphs contain nodes and edges between nodes. In Internet of Things, sensors, actuators, meters, devices, gateways, etc., are often depicted as nodes whereas links between sensors (friendships)
are depicted as edges. In abstract terms, it's easier to talk about a Node, rather than list different possible node types (sensors, actuators, meters, devices, gateways, etc.).
An ID uniquely identifying a node within its corresponding context. If a globally unique ID is desired, an architecture should be used using a universally accepted
<dd>An application that can configure a network and provide services to users or Things. In Internet of Things, a Provisioning Server knows who knows whom,
what privileges users have, who can read what data and who can control what devices and what parts of these devices.</dd>
In physics, precision determines the number of digits of precision. In sensor networks however, this definition is not easily applicable. Instead, precision
determines, for example, the number of decimals of precision, or power of precision. Example: 123.200 MWh contains 3 decimals of precision. All entities parsing and
delivering field information in sensor networks should always retain the number of decimals in a message.
</dd>
</di>
<di>
<dt>Sensor</dt>
<dd>
Device measuring at least one digital value (0 or 1) or analog value (value with precision and physical unit). Examples: Temperature sensor, pressure sensor, etc.
Sensor values are reported as fields during read-out. Each sensor has a unique Node ID.
</dd>
</di>
<di>
<dt>SN</dt>
<dd>Sensor Network. A network consisting, but not limited to sensors, where transport and use of sensor data is of primary concern. A sensor network may contain actuators, network applications, monitors, services, etc.</dd>
</di>
<di>
<dt>Status Value</dt>
<dd>A value displaying status information about something.</dd>
</di>
<di>
<dt>Timestamp</dt>
<dd>Timestamp of value, when the value was sampled or recorded.</dd>
Internet of Things basically consists of Things connected to the Internet. Things can be any device, sensor, actuator etc., that can have an
Internet connection.
</dd>
</di>
<di>
<dt>Thing Registry</dt>
<dd>
A registry where Things can register for simple and secure discovery by the owner of the Thing. The registry can also be used as a database for meta information
A client, device or user can get a token from a provisioning server. These tokens can be included in requests to other entities in the network, so these entities can validate
<dd>Physical unit of value. Example: MWh, l/s, etc.</dd>
</di>
<di>
<dt>Value</dt>
<dd>A field value.</dd>
</di>
<di>
<dt>Value Status</dt>
<dd>Status of field value. Contains important status information for Quality of Service purposes. Examples: Ok, Error, Warning, Time Shifted, Missing, Signed, etc.</dd>
</di>
<di>
<dt>Value Type</dt>
<dd>Can be numeric, string, boolean, Date & Time, Time Span or Enumeration.</dd>
</di>
<di>
<dt>WSN</dt>
<dd>Wireless Sensor Network, a sensor network including wireless devices.</dd>
</di>
<di>
<dt>XMPP Client</dt>
<dd>Application connected to an XMPP network, having a JID. Note that sensors, as well as applications requesting sensor data can be XMPP clients.</dd>
</di>
</dl>
</section1>
<section1topic='Use Cases'anchor='usecases'>
<p>
The most basic use case in sensor networks is to read out sensor data from a sensor. However, since protecting end-user integrity and system security is vital, access
rights and user privileges have to be imposed on the network.
</p>
<p>
To store access rights in all sensors might be very impractical. Not only does it consume memory, it's difficult to maintain track of the current system status, make sure
all devices have the latest configuration, distribute changes to the configuration, etc.
</p>
<p>
Furthermore, most sensors and small devices have very limited possibility to provide a rich user interface. Perhaps all it can do is to provide a small LED and a button,
useful perhaps for installing the sensor in the network, but not much more.
</p>
<p>
As an added complexity, the sensor network operator might not even have access to the XMPP Servers used, and provisioning needs to lie outside of the XMPP Server domains.
</p>
<p>
To solve this problem in an efficient manner, an architecture using distributed trusted third parties is proposed. Such third parties would:
</p>
<ul>
<li>Provide a rich user interface and configurable options to end user or back end systems.</li>
<li>Control friendships (who can communicate with whom).</li>
<li>Control content available for different friends (what can be read by whom).</li>
<li>Control operations accessible by different friends (what can be controlled/configured by whom).</li>
<li>Provide additional interoperability services to nodes in the network (for instance, unit conversion).</li>
<section3topic='Delegating original trust to a Provisioning Server'anchor='delegatingoriginaltrust'>
<p>
A provisioning server can be accessed either through a JID published by the provisioning server, or through a subdomain address, if hosted as a server component.
This section will show how to delegate original trust to a Provisioning Server, in the case the server uses a JID to communicate with things.
</p>
<p>
Trust is delegated to a provisioning server by a device, simply by befriending the provisioning server and asking it questions and complying with
its answers. As an illustrative example, following is a short description of how such a trust relationship can be created in a scenario where the sensor only
<li>Somebody is installing the sensor, giving it a connection to an XMPP server and a JID, reachable from the provisioning server.</li>
<li>The provisioning server is told to create a friendship request to the new sensor.</li>
<li>The sensor flashes its LED for a given time (for example: 30 seconds).</li>
<li>Viewing the LED, the person installing the sensor presses the button.</li>
<li>Receiving the button press within the given time period, accepts the friendship request. Optionally, the device can give user feedback using the LED.</li>
<li>The device performs a service discovery of the new friend, having been a manually added friend.</li>
<li>If the new friend supports this provisioning extension, further responsibilities are delegated to this device.</li>
<li>As the last step the device asks the provisioning server for a token. This device token is later used in calls to other devices and can be used to check access rights.</li>
<strong>Note:</strong> In many cases, an address to a provisioning server might be preprogrammed during production of the
device. In these cases, parts of the above procedure may not be necessary. All the client needs to do, if the provisioning server is not available
in the roster of the device, is to send a subscription request to the provisioning server, to alert the server of the existence of the device,
and possibly request a device token.
</p>
<p>
<strong>Note 2:</strong> A certificate token has an undefined lifetime. It can be reused across sessions.
</p>
<p>
The following use cases will assume such a trust relationship has been created between the corresponding device and the provisioning server.
</p>
</section3>
<section3topic='Provisioning Server as a server component'anchor='servercomponent'>
<p>
A provisioning server can also be hosted as a server component, and in these cases be addressed by using the component address, or sub-domain address of the component.
In this case, the client searches through the components hosted by the server to see if one of them is a Provisioning Server. There are no friendship requests and
presence subscriptions necessary, when communicating with a Provisioning Server hosted as a server component.
</p>
<p>
To search for a Provisioning Server hosted as a component on an XMPP Server, you first request a list of available components, as follows:
</p>
<examplecaption="Checking if server supports components">
<section3topic="Tokens and X.509 Certificates"anchor="tokenscertificats">
<p>
The provisioning server contains a set of rules defining what operation can take place and by whom, by participants in the network. Rules can be applied based on JIDs used,
content affected, and also through device, service and user identities based on X.509 Certificates. In order for a service (for instance) to identify itself in the network, it
uses an X.509 certificate. It sends the public part of this certificate to the provisioning server, and receives a token back in the form of a simple string. This token can then
be used in requests and propagated through the network.
</p>
<p>
To validate that the sender is allowed to use the certificate using its token, it encrypts a challenge using the public part of the certificate and sends it to the sender of the
token, who in turn decrypts it using the private part of the certificate and returns it to the server. The provisioning server can also use the public part of the certificate to
perform validation checks on the certificate itself. If the certificate becomes invalid, the provisioning server can invalidate any corresponding rules in the network. If the sender
of a token cannot respond to a token challenge, the provisioning server can also refuse to allow the operation.
</p>
<p>
In case of multiple units being part of an operation, a token can be propagated in the network. For example, a service can read data from U1, who reads data from U2. The service
provides a token to U1, who propagates this token in the request to U2. When U2 asks the provisioning server if the operation should be allowed or not, the server knows what entity
originated the request. If the provisioning server wants to challenge U2, concerning the token, U2 propagates the challenge to U1, who propagates it to the service, who can resolve
the challenge, returns the response back to U1 who returns the response to U2 who in turn returns it to the provisioning server.
<section4topic='Requesting a token'anchor='requesttoken'>
<p>
The following example shows how a device or service can request a token from the provisioning server, by providing the base-64 encoded public part of an X.509 certificate.
This step is optional, but can be used as a method to identify the device (or service), apart from the JID it is using. This might be useful if you want to assign a particular
device or service privileges in the provisioning server, regardless of the JID it uses to perform the action.
</p>
<examplecaption='Requesting a token'>
<