XEP-xxxx: XEP - Sensor Networks - Provisioning

Abstract:This specification describes an architecture for efficient provisioning of services, access rights and user privileges in sensor networks.
Author:Peter Waher
Copyright:© 1999 - 2013 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:ProtoXEP
Type:Standards Track
Version:0.0.3
Last Updated:2013-03-18

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.


Table of Contents


1. Introduction
2. Glossary
3. Use Cases
    3.1. Delegating original trust to a Provisioning Server
    3.2. Friendship request accepted
    3.3. Friendship request rejected
    3.4. Unfriending existing friends
    3.5. Recommending friendships
    3.6. Rejecting read-outs
    3.7. Restricting nodes during read-out
    3.8. Restricting fields during read-out
    3.9. Clear cache
    3.10. Getting a service token
    3.11. User access to service
    3.12. User privileges in service
    3.13. Download all user privileges
    3.14. Delegating Secondary Trust
    3.15. Multiple tokens
4. Determining Support
5. Implementation Notes
    5.1. Caching and cache time
    5.2. Working with multiple provisioning servers
    5.3. Automatic aggregation of services, users and privileges
    5.4. Reading devices from large subsystems
    5.5. Different types of tokens
6. Security Considerations
7. IANA Considerations
8. XMPP Registrar Considerations
9. XML Schema
10. Acknowledgements

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


1. Introduction

This XEP provides the underlying architecture, basic operations and data structures for provisioning of services, access rights and user privileges in sensor networks.

Note has to be taken, that these XEP's are designed for implementation in sensors, many of which have very limited amount of memory (both RAM and ROM) or resources (processing power). Therefore, simplicity is of utmost importance. Furthermore, sensor networks can become huge, easily containing millions of devices in peer-to-peer networks.

An added complexity in the provisioning case is that sensors 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 heavily on xep-0000-SN-SensorData [1]. Sensor networks contain many different architectures and use cases. For this reason, the sensor network standards have been divided into multiple XEPs according to the following table:

Table 1: Sensor Network XEPs

XEP Description
XEP-0000-DynamicForms Defines extensions for how dynamic forms can be created, based on Data Forms [2], Data Forms Validation [3], Publishing Stream Initiation Requests [4] and Data Forms Layout [5].
XEP-0000-Exi Defines how to EXI can be used in XMPP to achieve efficient compression of data. Albeit not a sensor network specific XEP, this XEP should be considered in all sensor network implementations where memory and packet size is an issue.
xep-0000-SN-BatteryPoweredSensors Defines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network.
xep-0000-SN-Concentrators Defines how to handle architectures containing concentrators or servers handling multiple sensors.
xep-0000-SN-Control Defines how to control actuators and other devices in sensor networks.
xep-0000-SN-Discovery 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.
xep-0000-SN-Events Defines how sensors send events, how event subscription, hysteresis levels, etc., are configured.
xep-0000-SN-Interoperability Defines guidelines for how to achieve interoperability in sensor networks, publishing interoperability interfaces for different types of devices.
xep-0000-SN-Multicast Defines how sensor data can be multicast in efficient ways.
xep-0000-SN-Provisioning This specification. Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented.
xep-0000-SN-PubSub Defines how efficient publication of sensor data can be made in sensor networks.
xep-0000-SN-SensorData Provides the underlying architecture, basic operations and data structures for sensor data communication over XMPP networks. It includes a hardware abstraction model, removing any technical detail implemented in underlying technologies. This XEP is used by all other sensor network XEPs.

2. Glossary

The following table lists common terms and corresponding descriptions.

Table 2: Glossary

Term Description
Actuator Device containing at least one configurable property or output that can and should be controlled by some other entity or device.
Computed Value A value that is computed instead of measured.
Concentrator Device managing a set of devices which it publishes on the XMPP network.
Field 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).
Field Name Name of a field of sensor data. Examples: Energy, Volume, Flow, Power, etc.
Field Type What type of value the field represents. Examples: Momentary Value, Status Value, Identification Value, Calculated Value, Peak Value, Historical Value, etc.
Historical Value A value stored in memory from a previous timestamp.
Identification Value A value that can be used for identification. (Serial numbers, meter IDs, locations, names, etc.)
Localization information Optional information for a field, allowing the sensor to control how the information should be presented to human viewers.
Meter A device possible containing multiple sensors, used in metering applications. Examples: Electricity meter, Water Meter, Heat Meter, Cooling Meter, etc.
Momentary Value A momentary value represents a value measured at the time of the read-out.
Node Graphs contain nodes and edges between nodes. In Sensor Networks, sensors, actuators, meters, devices, gateways, etc., are often depicted as nodes and links between sensors (friendships) are depicted as edges. In abstract terms, it's easier to talk about a Node, than have to list different types of nodes possible (sensors, actuators, meters, devices, gateways, etc.). Each Node has a Node ID.
Node ID 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 ID scheme.
Parameter Readable and/or writable property on a node/device. The XEP xep-0000-SN-Concentrators deals with reading and writing parameters on nodes/devices. Fields are not parameters, and parameters are not fields.
Peak Value A maximum or minimum value during a given period.
Precision 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.
Sensor 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.
SN 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.
Status Value A value displaying status information about something.
Timestamp Timestamp of value, when the value was sampled or recorded.
Token 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 access rights with the provisioning server.
Unit Physical unit of value. Example: MWh, l/s, etc.
Value A field value.
Value Status Status of field value. Contains important status information for Quality of Service purposes. Examples: Ok, Error, Warning, Time Shifted, Missing, Signed, etc.
Value Type Can be numeric, string, boolean, Date & Time, Time Span or Enumeration.
WSN Wireless Sensor Network, a sensor network including wireless devices.
XMPP Client Application connected to an XMPP network, having a JID. Note that sensors, as well as applications requesting sensor data can be XMPP clients.

3. Use Cases

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.

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.

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.

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.

To solve this problem in an efficient manner, an architecture using distributed trusted third parties is proposed. Such third parties would:

3.1 Delegating original trust to a Provisioning Server

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 has a single LED and a single button.

The following diagram shows the general case:

The successful case can also be illustrated in a sequence diagram, as follows:

The following example shows how a device can request a device token from the provisioning server:

Example 1. Requesting a device token

                
   <iq type='get'
       from='device@clayster.com'
       to='provisioning@clayster.com'
       id='13'>
      <getToken xmlns='urn:xmpp:sn:provisioning' deviceId='WatchamacallitDevice1'/>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='device@clayster.com'
       id='13'>
      <getTokenResponse xmlns='urn:xmpp:sn:provisioning' token='device0001'/>
   </iq>
            

The provisioning server must not return tokens that contain white space characters.

Note: 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 neccessary. 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.

The following use cases will assume such a trust relationship has been created between the corresponding device and the provisioning server.

3.2 Friendship request accepted

The following diagram displays how a friendship request from an external party can be handled, delegating the responsibility to a trusted third party:

The communication between the XMPP Device and the Provisioning Server could be as follows:

Example 2. Friendship request accepted

                
   <iq type='get'
       from='device@clayster.com'
       to='provisioning@clayster.com'
       id='1'>
      <isFriend xmlns='urn:xmpp:sn:provisioning' jid='client1@clayster.com'/>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='device@clayster.com'
       id='1'>
      <isFriendResponse xmlns='urn:xmpp:sn:provisioning' jid='client1@clayster.com' result='true'/>
   </iq>
            

Note: The provisioning server implicitly understands which two JIDs that are to be checked: The first one is the sender of the message, the second one is the JID available in the jid attribute in the request.

Note 2: Any resource information in the JID must be ignored by the provisioning server.

3.3 Friendship request rejected

The following diagram displays a friendship request from an external party being rejected as a result of the trusted third party negating the friendship:

The communication between the XMPP Device and the Provisioning Server could be as follows:

Example 3. Friendship request rejected

                
   <iq type='get'
       from='device@clayster.com'
       to='provisioning@clayster.com'
       id='2'>
      <isFriend xmlns='urn:xmpp:sn:provisioning' jid='client2@clayster.com'/>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='device@clayster.com'
       id='2'>
      <isFriendResponse xmlns='urn:xmpp:sn:provisioning' jid='client2@clayster.com' result='false'/>
   </iq>
            

3.4 Unfriending existing friends

If the provisioning server decides that two friends in the network should no longer be friends and communicate with each other, it simply sends a message to at least one of the friends as follows:

The provisioning server should only send such messages to clients that have previously asked the provisioning server if friendship requests should be accepted or not.

Note: The device should only honor such messages, if the sender is the trusted third party. Such messages received from other entities not trusted should be silently ignored.

Example 4. Unfriending existing friend

                
   <message from='provisioning@clayster.com'
            to='device@clayster.com'>
      <unfriend xmlns='urn:xmpp:sn:provisioning' jid='client2@clayster.com'/>
   </message>
            

3.5 Recommending friendships

The provisioning server can, apart from accepting new friendships and rejecting old friendships, also recommend new friendships. In this case, the provisioning server simply sends a message to one or both of the soon to be friends, as follows:

Example 5. Recommending friendships

                
   <message from='provisioning@clayster.com'
            to='device@clayster.com'>
      <friend xmlns='urn:xmpp:sn:provisioning' jid='client2@clayster.com'/>
   </message>
            

Note that the receptor can still ask the provisioning server if it can form a friendship with the suggested friend, using the isFriend command.

3.6 Rejecting read-outs

An important use case for provisioning in sensor networks is who gets to read out sensor data from which sensors. This use case details how communication with a provisioning server can help the device determine if a client has sufficient access rights to read the values of the device.

Note: This use case is an extension of the use case 'Read-out rejected' in the XEP xep-0000-SN-SensorData.

The following example shows the communication first between the client and the device, then the device and the provisioning server, and last between the device and the client:

Example 6. Rejecting read-outs

                
   <iq type='get'
       from='master@clayster.com'
       to='device@clayster.com'
       id='3'>
      <req xmlns='urn:xmpp:sn' momentary='true' serviceToken='service0001' userToken='user0001' seqnr='1'/>
   </iq>
   
   <iq type='get'
       from='device@clayster.com'
       to='provisioning@clayster.com'
       id='4'>
      <canRead xmlns='urn:xmpp:sn:provisioning' jid='master@clayster.com' serviceToken='service0001' userToken='user0001' momentary='true'/>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='device@clayster.com'
       id='4'>
      <canReadResponse xmlns='urn:xmpp:sn:provisioning' jid='master@clayster.com' momentary='true' result='false'/>
   </iq>
   
   <iq type='result'
       from='device@clayster.com'
       to='master@clayster.com'
       id='3'>
      <rejected xmlns='urn:xmpp:sn' seqnr='1'>
         <error>Access denied.</error>
      </rejected>
   </iq>
            

Note that the provisioning server responds with a canReadResponse element, with the same content as the canRead element in the request.

3.7 Restricting nodes during read-out

In case the device handles multiple nodes that can be read, the provisioning server has the possibility to grant read-out, but to limit the nodes that can be read out. The provisioning server does this by returning the list of nodes that can be read.

Note: This use case is an extension of the use case 'Read-out of multiple devices' in the XEP xep-0000-SN-SensorData.

Note 2: If the server responds, but without specifying a list of nodes, the device can assume that all nodes available in the original request are allowed to be read. If no nodes in the request are allowed to be read, the provisioning server must respond with a result='false', so the device can reject the read-out request.

The following example shows the communication first between the client and the device, then the device and the provisioning server, and last between the device and the client:

Example 7. Restricting nodes during read-out

                
   <iq type='get'
       from='master@clayster.com'
       to='device@clayster.com'
       id='5'>
      <req xmlns='urn:xmpp:sn' momentary='true' serviceToken='service0001' userToken='user0001' seqnr='2'>
         <node nodeId='Device02'/>
         <node nodeId='Device03'/>
      </req>
   </iq>
   
   <iq type='get'
       from='device@clayster.com'
       to='provisioning@clayster.com'
       id='6'>
      <canRead xmlns='urn:xmpp:sn:provisioning' jid='master@clayster.com' momentary='true' serviceToken='service0001' userToken='user0001'>
         <node nodeId='Device02'/>
         <node nodeId='Device03'/>
      </canRead>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='device@clayster.com'
       id='6'>
      <canReadResponse xmlns='urn:xmpp:sn:provisioning' jid='master@clayster.com' momentary='true' result='true'>
         <node nodeId='Device02'/>
      </canReadResponse>
   </iq>
   
   <iq type='result'
       from='device@clayster.com'
       to='master@clayster.com'
       id='5'>
      <accepted xmlns='urn:xmpp:sn' seqnr='2'/>
   </iq>
            

Note that the provisioning server responds with a canReadResponse element, similar to the canRead element in the request, except only the nodes allowed to be read are read. The device must only permit read-out of nodes listed in the response from the provisioning server. Other nodes available in the request should be ignored.

3.8 Restricting fields during read-out

In case the provisioning server wants to limit the fields a device can send to a client, the provisioning server has the possibility to grant read-out, but list a set of fields the device is allowed to send to the corresponding client.

Note: If the server responds, but without specifying a list of field names, the device can assume that all fields available in the original request are allowed to be sent. If no fields in the request are allowed to be sent, the provisioning server must respond with a result='false', so the device can reject the read-out request.

The following example shows the communication first between the client and the device, then the device and the provisioning server, and last between the device and the client:

Example 8. Restricting fields during read-out

                
   <iq type='get'
       from='master@clayster.com'
       to='device@clayster.com'
       id='7'>
      <req xmlns='urn:xmpp:sn' momentary='true' serviceToken='service0001' userToken='user0001' seqnr='3'/>
   </iq>
   
   <iq type='get'
       from='device@clayster.com'
       to='provisioning@clayster.com'
       id='8'>
      <canRead xmlns='urn:xmpp:sn:provisioning' jid='master@clayster.com' momentary='true' serviceToken='service0001' userToken='user0001'/>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='device@clayster.com'
       id='8'>
      <canReadResponse xmlns='urn:xmpp:sn:provisioning' jid='master@clayster.com' momentary='true' result='true'>
         <field name='Energy'/>
         <field name='Power'/>
      </canReadResponse>
   </iq>
   
   <iq type='result'
       from='device@clayster.com'
       to='master@clayster.com'
       id='7'>
      <accepted xmlns='urn:xmpp:sn' seqnr='3'/>
   </iq>
            

Note that the provisioning server responds with a canReadResponse element, similar to the canRead element in the request, except only the fields allowed to be sent are listed. The client must only send fields having field names in this list.

Also note, that the provisioning server can return both lists of allowed nodes and allowed field names in the response. In this case, the device must only send allowed fields from allowed nodes, and ignore all other fields and/or nodes.

3.9 Clear cache

When the provisioning server updates access rights and user privileges in the system, it will send a clearCache command to corresponding devices. If a device was offline during the change, the provisioning server must send the clearCache message when the device comes online again. To acknowledge the receipt of the command, the client responds with a clearCacheResponse element. This response message does not contain any information on what was done by the client. It simply acknowledges the receipt of the command, to make sure the provisioning server does not resend the clear cache command again.

Note: The clearCache command does not include information on what has been changed, so the device needs to clear the entire cache. This to avoid complexities in making sure updates made to the provisioning rules works in all cases, and to minimize complexity in the implementation of the protocol on the sensor side. It is also not deemed to decrease network performance, since changing provisioning rules for a device is an exceptional event and therefore does not affect performance during normal operation.

Example 9. Clear cache

                
   <iq type='get'
       from='device@clayster.com'
       to='provisioning@clayster.com'
       id='17'>
      <clearCache xmlns='urn:xmpp:sn:provisioning'/>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='device@clayster.com'
       id='17'>
      <clearCacheResponse xmlns='urn:xmpp:sn:provisioning'/>
   </iq>
            

3.10 Getting a service token

A service requesting provisioning assistance, needs to retrieve a service token from the provisioning server. The following example shows how this can be done.

Example 10. Requesting a service token

                
   <iq type='get'
       from='service@clayster.com'
       to='provisioning@clayster.com'
       id='14'>
      <getToken xmlns='urn:xmpp:sn:provisioning' serviceId='WatchamacallitService1'/>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='service@clayster.com'
       id='14'>
      <getTokenResponse xmlns='urn:xmpp:sn:provisioning' token='service0001'/>
   </iq>
            

3.11 User access to service

Provisioning in sensor networks also requires control of user access to different services in the network. This use case shows how service access rights are controlled using a trusted provisioning server.

First, the user connects to the service in some way. This can be done using XMPP, HTTP, HTTPS or some other means. The service need to extract some form of identifying credentials from the user, and provide that to the provisioning server. The provisioning server determines if the client has access rights to the service based on these credentials, and also provides the service with a userToken that the service can use in further communication with the provisioning server regarding the user and its privileges.

The following table lists some different types of credentials that the service can extract from the client:

Table 3: User Credentials

Type Protocols Description
JID XMPP Allows provisioning to be done on the JID the user has.
IP Address HTTP, HTTPS Allows provisioning to be done on IP address or IP-ranges for instance.
Host Name HTTP, HTTPS with DNS If the service has access to the client host name, for instance in an intra network, this can be used for provisioning.
X.509 Certificate HTTPS If the client provides a client certificate, such a certificate can be used to provide provisioning.
X.509 Certificate Thumbprint HTTPS The client can also choose to validate the certificate itself and only send the certificate thumbprint to the provisioning server. Even though this provides somewhat lesser security than providing the entire certificate, it might be an option to distribute certificate validation checks across the network to lower the work load on the provisioning server.
User Name HTTP, HTTPS, XMPP If authenticated HTTP(S) access is implemented, the service can provide the user name as credentials. XMPP based clients can use information in the roster to provide user name information to the provisioning server.
Geolocation HTML5 over HTTP(S), XMPP If the geographic location (longitude & latitude) of the user client is known, it can be used. HTML 5 provides mechanism whereby the location of the client can be fetched. User Geolocation [6] provides a mechanism whereby client location can be obtained over XMPP.
SSO Token Intranet If a single sign on token is available, such a token could be provided as credentials.
Protocol Any Connection protocol used to connect to the service.

The provisioning server receives these credentials, and decides if the user should have access to the service or not, based on rules configured in the provisioning service. If the user is granted access, a userToken is generated and returned to the service. This token

Now, the service can determine if this access grant is sufficient or not. It can require the user to login into the service first. If so, the service should provide the provisioning server with the user name used during login, when logged in.

Example 11. User access to service

                
   <!-- user connects to service -->
   
   <iq type='get'
       from='service@clayster.com'
       to='provisioning@clayster.com'
       id='9'>
      <canAccess xmlns='urn:xmpp:sn:provisioning' serviceToken='service0001'>
          <credentials type='IpAddress' value='10.0.0.1'/>
          <credentials type='Longitude' value='123.45'/>
          <credentials type='Latitude' value='67.89'/>
      </canAccess>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='service@clayster.com'
       id='9'>
      <canAccessResponse xmlns='urn:xmpp:sn:provisioning' userToken='user0001' result='true'/>
   </iq>
 
   <!-- user performs login into service -->
 
   <message from='service@clayster.com'
            to='provisioning@clayster.com'>
      <userLoggedIn xmlns='urn:xmpp:sn:provisioning' serviceToken='service0001' userToken='user0001' userName='Kermit' />
   </message>
   
   <!-- user continues interacting with service -->
            

3.12 User privileges in service

When a user has been given access to a service, and properly been identified, the service can ask the provisioning service for detailed user privileges to control different aspects of the service. This can be done using the hasPrivilege command. Here, the service sends its serviceToken and the userToken earlier received when being granted access to the service. Furthermore a privilegeId has to be provided.

A Privilege ID is a string composed of one or a sequence of parts, delimited by period characters. The Privilege IDs form a tree of privileges, using an invisible, but common, root privilege.

The following table suggests some examples of Privilge IDs, with suggestive descriptions. (Only used as an example.)

Table 4: Privilege ID examples

Privilege ID Description
Databases.Energy.Select Gives the user the rights to select data from the Energy database.
Databases.Energy.Insert Gives the user the rights to insert data into the Energy database.
Databases.Energy.Delete Gives the user the rights to delete data from the Energy database.

Note: Note that privilege IDs are local to the service. Different services are allowed to use similar or same Privilege IDs, in different contexts and with different meanings. The provisioning server must separate Privilege IDs from different services.

The client must always provide full Privilege IDs to the provisioning server. The provisioning server however, can grant partial privilege IDs, pointing to parent privilege nodes to a user or a role object, granting a user a specific role. If granting a parent privilege ID to a user or role, this is interpreted as giving the corresponding user or role the privileges of the entire sub-tree defined by the parent privilege ID.

If additional control over privileges is desired, negative privileges can be assigned to the user or role. Granted or explicitly rejected privileges are specified in a sequential list of full or partial privilege IDs. This list is then processed sequentially to determine if a privilege is granted or not.

Example: Consider the privileges above. Give a user or its corresponding role the following privileges in a sequential list:

This would give the user rights to select and insert data, but not to delete data from the Energy database.

Note: Care should be taken when constructing Privilege IDs, so they do not include variable data that potentially can create an infinite amount of privilege IDs. For example: Do not include user names, sensor IDs, etc., in privilege IDs, as the number of such entities cannot be estimated or is scalable beforehand.

The following diagram shows an example of how a service asks permission from a provisioning server before an action is taken:

Example 12. User privileges in service

                
   <!-- user wants to perform action -->
   
   <iq type='get'
       from='service@clayster.com'
       to='provisioning@clayster.com'
       id='10'>
      <hasPrivilege xmlns='urn:xmpp:sn:provisioning' serviceToken='service0001' userToken='user0001' privilegeId='Sensors.View'/>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='service@clayster.com'
       id='10'>
      <hasPrivilegeResponse xmlns='urn:xmpp:sn:provisioning' result='true'/>
   </iq>
 
   <!-- user performs action -->
            

3.13 Download all user privileges

To improve performance, services can download the entire set of user privileges, and perform privilege checks internally. The following diagram displays how the above two use cases could be handled in such a case:

Note: When downloading privileges using this command, a sequential list of full or partial privilege IDs will be returned together with the corresponding include or exclude flags. The above mentioned algorithm of determining user privileges must be implemented by the service, if this method is to be used.

Example 13. Download all user privileges

                
   <!-- user connects to service -->
   
   <iq type='get'
       from='service@clayster.com'
       to='provisioning@clayster.com'
       id='11'>
      <canAccess xmlns='urn:xmpp:sn:provisioning' serviceToken='service0001'>
          <credentials type='IpAddress' value='10.0.0.1'/>
          <credentials type='Longitude' value='123.45'/>
          <credentials type='Latitude' value='67.89'/>
      </canAccess>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='service@clayster.com'
       id='11'>
      <canAccessResponse xmlns='urn:xmpp:sn:provisioning' userToken='user0001' result='true'/>
   </iq>
 
   <!-- user performs login into service -->
 
   <message from='service@clayster.com'
            to='provisioning@clayster.com'>
      <userLoggedIn xmlns='urn:xmpp:sn:provisioning' serviceToken='service0001' userToken='user0001' userName='Kermit' />
   </message>
   
   <iq type='get'
       from='service@clayster.com'
       to='provisioning@clayster.com'
       id='12'>
      <downloadPrivileges xmlns='urn:xmpp:sn:provisioning' serviceToken='service0001' userToken='user0001'/>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='service@clayster.com'
       id='12'>
       <privileges>
           <exclude id='Sensors.Delete'/>
           <include id='Sensors'/>
       </privileges>
   </iq>
 
   <!-- user performs actions without interaction with the provisioning server -->
            

3.14 Delegating Secondary Trust

The isFriendResponse element returned by the provisioning server contains an attribute secondaryTrustAllowed that is by default set to false. If the provisioning server has no problem with allowing multiple trust to be delegated by devices in the network, it can choose to set this attribute to true in the response. If true, the device knows it has the right to add its own friends, or to add secondary trust relationships.

The following diagram continues with the example given above, of how a sensor with a limited user interface, can allow to manually add new friends, including new trust relationships using a single LED and a button.

3.15 Multiple tokens

When multiple trust is used, the entity (client, user, service, etc.) has one token from each provisioning server. However, when sending a token to a third party, the sender does not know what provisioning server(s) the third party uses to check access rights and user privileges. Therefore, the client must send all tokens, separated by a space.

When a provisioning server receives a request containing multiple tokens, the most forgiving response must be returned.

Example 14. Readout request using multiple tokens

				
   <iq type='get'
       from='master@clayster.com'
       to='device@clayster.com'
       id='15'>
      <req xmlns='urn:xmpp:sn' momentary='true' serviceToken='service0001 servicio0001' userToken='user0001' seqnr='4'/>
   </iq>
   
   <iq type='get'
       from='device@clayster.com'
       to='provisioning@clayster.com'
       id='16'>
      <canRead xmlns='urn:xmpp:sn:provisioning' jid='master@clayster.com' serviceToken='service0001 servicio0001' userToken='user0001' momentary='true'/>
   </iq>
   
   <iq type='result'
       from='provisioning@clayster.com'
       to='device@clayster.com'
       id='16'>
      <canReadResponse xmlns='urn:xmpp:sn:provisioning' jid='master@clayster.com' momentary='true' result='true'/>
   </iq>
   
   <iq type='result'
       from='device@clayster.com'
       to='master@clayster.com'
       id='15'>
      <accepted xmlns='urn:xmpp:sn' seqnr='4'/>
   </iq>
			

4. Determining Support

If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:sn:provisioning" in response to Service Discovery [7] information requests.

Example 15. Service discovery information request

            
<iq type='get'
    from='device@clayster.com'
    to='provisioning@clayster.com'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
        

Example 16. Service discovery information response

            
<iq type='result'
    from='provisioning@clayster.com'
    to='device@clayster.com'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:sn:provisioning'/>
    ...
  </query>
</iq>
        

In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in Entity Capabilities [8]. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

5. Implementation Notes

5.1 Caching and cache time

To minimize network traffic, and optimize response time, devices should cache access rights and user privileges provided by the provisioning server. If memory is limited, items in the cache should be ordered by last access, and items with the oldest last access timestamp should be removed first. A safety valve can optionally be implemented as well, removing unused cache items after a certain age, even if memory is available.

The device can assume that access rights and user privileges on the provisioning server do not change over time, unless the provisioning server says so.

The provisioning server on the other hand, must keep track of when a device is online and offline, and clear the cache of the device if changes are made that affects the device. If the device was offline when those changes occurred, the provisioning server must send the clear cache command as soon as the device comes online again.

When creating a new trust relationship, the device should always clear its cache, if it contains information from before.

To minimize stress of the provisioning server during synchronous sensor start up, for instance after a power failure, all clients should aim to persist its cache if possible. Clients not persisting its cache may produce too much stress on the provisioning server on start-up, practically removing it from the network.

5.2 Working with multiple provisioning servers

When working with multiple provisioning servers, there are some things that should be considered:

5.3 Automatic aggregation of services, users and privileges

One important design consideration when implementing a provisioning server is how to handle new services, users and privileges. One option might be to automatically ignore anything not recognized. Another option might be to dynamically add new services, user names and privileges to internal data sources, making it easier to manage new types of services dynamically. However, adding such items automatically might also make such data sources grow beyond control.

5.4 Reading devices from large subsystems

All examples in this document have been simplified examples where a few devices containing a few fields have been read. However, in many cases large subsystems with very many sensors containing many fields have to be read, as is documented in xep-0000-SN-Concentrators.html [9]. In such cases, a node may have to be specified using two or perhaps even three ID's: a sourceId identifying the data source controlling the device, a possible cacheType narrowing down the search to a specific kind of node, and the common nodeId. For more information about this, see xep-0000-SN-Concentrators.html.

Note: For cases where the nodeId is sufficient to uniquely identify the node, it is sufficient to provide this attribute in the request. If there is ambiguity in the request, the receptor must treat the request as a request with a set of nodes, all with the corresponding nodeId as requested.

5.5 Different types of tokens

A small note regarding the use of different tokens. A service can get a Service Token, a device a Device Token and a user a User Token. When delegating these tokens to third parties, a service sends its Service Token. But, if the service does this within the context of a user action, the service sends both its Service Token and the users User Token. The same with a device. If a device delegates its token to a third party, it sends its Device Token. But if the device performs the action in the context of a user action, the device sends both its Device Token as well as its User Token.

6. Security Considerations

Delegating trust to a third party may create a weak link in the overall security of a sensor network. Therefore, it's vitally important that the following be adhered to:

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [10].

8. XMPP Registrar Considerations

REQUIRED.

9. XML Schema

            
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:sn:provisioning'
    xmlns='urn:xmpp:sn:provisioning'
    xmlns:sn='urn:xmpp:sn'
    elementFormDefault='qualified'>
 
    <xs:import namespace='urn:xmpp:sn'/>
 
    <xs:element name='getToken' type='GetToken'/>
    <xs:element name='getTokenResponse' type='GetTokenResponse'/>
 
    <xs:complexType name='GetToken'>
        <xs:attribute name='deviceId' type='xs:string' use='optional'/>
        <xs:attribute name='serviceId' type='xs:string' use='optional'/>
    </xs:complexType>
 
    <xs:complexType name='GetTokenResponse'>
        <xs:attribute name='token' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:element name='isFriend' type='Friend'/>
    <xs:element name='isFriendResponse' type='FriendResponse'/>
    <xs:element name='unfriend' type='Friend'/>
    <xs:element name='Friend' type='Friend'/>
 
    <xs:complexType name='Friend'>
        <xs:attribute name='jid' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='FriendResponse'>
        <xs:complexContent>
            <xs:extension base='Friend'>
                <xs:attribute name='result' type='xs:boolean' use='required'/>
                <xs:attribute name='secondaryTrustAllowed' type='xs:boolean' use='optional' default='false'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:element name='canRead' type='CanRead'/>
    <xs:element name='canReadResponse' type='CanReadResponse'/>
 
    <xs:complexType name='CanReadBase' abstract='true'>
        <xs:choice minOccurs='0' maxOccurs='unbounded'>
            <xs:element name='node'>
                <xs:complexType>
                    <xs:attribute name='nodeId' type='xs:string' use='required'/>
                    <xs:attribute name='sourceId' type='xs:string' use='optional'/>
                    <xs:attribute name='cacheType' type='xs:string' use='optional'/>
                </xs:complexType>
            </xs:element>
            <xs:element name='field'>
                <xs:complexType>
                    <xs:attribute name='name' type='xs:string' use='required'/>
                </xs:complexType>
            </xs:element>
        </xs:choice>
        <xs:attributeGroup ref='sn:fieldTypes'/>
        <xs:attribute name='all' type='xs:boolean' use='optional' default='false'/>
        <xs:attribute name='historical' type='xs:boolean' use='optional' default='false'/>
        <xs:attribute name='jid' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='CanRead'>
        <xs:complexContent>
            <xs:extension base='CanReadBase'>
                <xs:attribute name='token' type='xs:string' use='optional'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='CanReadResponse'>
        <xs:complexContent>
            <xs:extension base='CanReadBase'>
                <xs:attribute name='result' type='xs:boolean' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:element name='clearCache'>
        <xs:complexType/>
    </xs:element>
 
    <xs:element name='clearCacheResponse'>
        <xs:complexType/>
    </xs:element>
 
    <xs:element name='canAccess'>
        <xs:complexType>
            <xs:choice minOccurs='0' maxOccurs='unbounded'>
                <xs:element name='jid' type='jidCredential'/>
                <xs:element name='ip4' type='ip4Credential'/>
                <xs:element name='ip6' type='ip6Credential'/>
                <xs:element name='hostName' type='hostNameCredential'/>
                <xs:element name='x509Certificate' type='x509CertificateCredential'/>
                <xs:element name='x509CertificateThumbprint' type='x509CertificateThumbprintCredential'/>
                <xs:element name='userName' type='userNameCredential'/>
                <xs:element name='longitude' type='longitudeCredential'/>
                <xs:element name='latitude' type='latitudeCredential'/>
                <xs:element name='sso' type='ssoCredential'/>
                <xs:element name='protocol' type='protocolCredential'/>
            </xs:choice>
            <xs:attribute name='serviceToken' type='xs:string' use='required'/>
        </xs:complexType>
    </xs:element>
 
    <xs:element name='canAccessResponse'>
        <xs:complexType>
            <xs:attribute name='result' type='xs:boolean' use='required'/>
            <xs:attribute name='userToken' type='xs:string' use='optional'/>
        </xs:complexType>
    </xs:element>
 
    <xs:complexType name='jidCredential'>
        <xs:attribute name='value' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='ip4Credential'>
        <xs:attribute name='value' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='ip6Credential'>
        <xs:attribute name='value' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='hostNameCredential'>
        <xs:attribute name='value' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='x509CertificateCredential'>
        <xs:attribute name='base64' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='x509CertificateThumbprintCredential'>
        <xs:attribute name='base64' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='userNameCredential'>
        <xs:attribute name='value' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='longitudeCredential'>
        <xs:attribute name='value' type='xs:double' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='latitudeCredential'>
        <xs:attribute name='value' type='xs:double' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='ssoCredential'>
        <xs:attribute name='value' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='protocolCredential'>
        <xs:attribute name='value' type='ProtocolName' use='required'/>
    </xs:complexType>
 
    <xs:simpleType name='ProtocolName'>
        <xs:restriction base='xs:string'>
            <xs:enumeration value='XMPP'/>
            <xs:enumeration value='HTTP'/>
            <xs:enumeration value='HTTPS'/>
            <xs:enumeration value='TcpSocket'/>
            <xs:enumeration value='UdpSocket'/>
            <xs:enumeration value='Queue'/>
            <xs:enumeration value='Internal'/>
            <xs:enumeration value='Other'/>
        </xs:restriction>
    </xs:simpleType>
 
    <xs:element name='userLoggedIn'>
        <xs:complexType>
            <xs:attribute name='serviceToken' type='xs:string' use='required'/>
            <xs:attribute name='userToken' type='xs:string' use='required'/>
            <xs:attribute name='userName' type='xs:string' use='required'/>
        </xs:complexType>
    </xs:element>
 
    <xs:element name='hasPrivilege'>
        <xs:complexType>
            <xs:attribute name='serviceToken' type='xs:string' use='required'/>
            <xs:attribute name='userToken' type='xs:string' use='required'/>
            <xs:attribute name='privilegeId' type='PrivilegeId' use='required'/>
        </xs:complexType>
    </xs:element>
 
    <xs:element name='hasPrivilegeResponse'>
        <xs:complexType>
            <xs:attribute name='result' type='xs:boolean' use='required'/>
        </xs:complexType>
    </xs:element>
 
    <xs:simpleType name='PrivilegeId'>
        <xs:restriction base='xs:string'>
            <xs:pattern value='^[^.]+([.][^.]+)*$'/>
        </xs:restriction>        
    </xs:simpleType>
 
    <xs:element name='downloadPrivileges'>
        <xs:complexType>
            <xs:attribute name='serviceToken' type='xs:string' use='required'/>
            <xs:attribute name='userToken' type='xs:string' use='required'/>
        </xs:complexType>
    </xs:element>
 
    <xs:element name='downloadPrivilegesResponse'>
        <xs:complexType>
            <xs:choice minOccurs='0' maxOccurs='unbounded'>
                <xs:element name='include' type='Privilege'/>
                <xs:element name='exclude' type='Privilege'/>
            </xs:choice>
        </xs:complexType>
    </xs:element>
 
    <xs:complexType name='Privilege'>
        <xs:attribute name='id' type='PrivilegeId' use='required'/>
    </xs:complexType>
 
</xs:schema>
        

10. Acknowledgements

Thanks to Joachim Lindborg and Karin Forsell for all valuable feedback.


Appendices


Appendix A: Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.3
Last Updated: 2013-03-18
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0001, XEP-0030, xep-0000-SN-SensorData
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
This document in other formats: XML  PDF


Appendix B: Author Information

Peter Waher

Email: peter.waher@clayster.com
JabberID: peter.waher@jabber.org
URI: http://se.linkedin.com/pub/peter-waher/1a/71b/a29/


Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright (c) 1999 - 2013 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.


Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.


Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Appendix G: Notes

1. xep-0000-SN-SensorData

2. XEP-0004: Data Forms <http://xmpp.org/extensions/xep-0004.html>.

3. XEP-0122: Data Forms Validation <http://xmpp.org/extensions/xep-0122.html>.

4. XEP-0137: Publishing Stream Initiation Requests <http://xmpp.org/extensions/xep-0137.html>.

5. XEP-0141: Data Forms Layout <http://xmpp.org/extensions/xep-0141.html>.

6. XEP-0080: User Geolocation <http://xmpp.org/extensions/xep-0080.html>.

7. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

8. XEP-0115: Entity Capabilities <http://xmpp.org/extensions/xep-0115.html>.

9. xep-0000-SN-Concentrators.html

10. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.


Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.0.3 (2013-03-18)

Added information about how to read sensors from large subsystems.

Added friend recommendation message.

Added client/device/service tokens.

(pwa)

Version 0.0.2 (2013-03-12)

Added use cases for service access rights and corresponding user privileges.

(pwa)

Version 0.0.1 (2013-03-11)

First draft.

(pwa)

END