[Standards] How to add a new reference to XEP

Peter Waher Peter.Waher at clayster.com
Wed Nov 20 18:15:39 UTC 2013

Hello Teemu

Thanks for all the valuable feedback. I'll respond on the standards list as well, since the topic may be interesting to a larger audience.

Regarding your questions:

>> You're not required to use the new IoT sensor network XEPs between 
>> your devices, in order to use the Profiling XEP. (That's why they are 
>> separated.)
>In 1. Introduction:
>"This XEP relies heavily on sensor-data [1]."
>What does "heavily" mean? Should change this sentence in XEP-0324?

I see what you mean. I have updated that sentence to:

" This XEP relies on Internet of Things - Sensor Data [1] and Internet of Things - Control [2] for sensor data readout and control interfaces."


So, if you don't XEP 0323 & 0325, you don't need the corresponding provisioning commands related to these. It may be sufficient for you to use user, service and user privilege features.

>> If you need a more generic user privilege architecture, see §3.7 User 
>> privileges.
>3.7 User privileges describes: "When a user has been given access to a service, and properly been identified". How this identification have been done? Should we be talking about authentication?

The provisioning server uses both the JID of the sender (which has already been authenticated) and the information sent by the sender to make decisions who can talk to whom (etc.). My idea was that that would be sufficient. If an unknown party would try to connect and get access, it would be noted by the new JID.

> My new XEP is much more about authentication than provisioning. XEP-0324 or some other XEP could be used after the authentication mechanism I would like to present. XEP-0324 mentions several mechanisms in Table 2, this new XEP could perhaps be one of them. I shall mention that after the authentication it is possible to use additional provisioning servers and cite XEP-0324.

That would be a good idea, and also my original thought. For example: Some external SSO mechanism (unknown to the provisioning server) might be used to identify users and/or services. The caller is required to perform user authentication (as described in XEP-0324), since it might be done outside of the realm of XMPP. The administrator of the provisioning server can later easily detect if unknown devices and/or services are trying to get access to the private network.

>> If there's no provision server available: Do you mean temporary or 
>> permanently? If one is available at the time a new user requests 
>> access to a device, of course, it can respond immediately. If one is 
>> not available, for instance, one comes online later, the provisioning 
>> server can recommend new friendships (§3.2.4).
>> If one is not available at all: You still need somebody who determines 
>> who can connect to whom, right? This is the provisioning server. It's 
>> just a name. It's not a product.
>I had misunderstood the location of provision server. As XEP-0324 describes there is not necessarily access to the XMPP servers but still access to provision servers would be available. Because of this, the provision server should have functionality that is normally provided by a XMPP server, righ? 

Not really. The idea can be, for instance, to have a small provisioning server running on a plug computer in your home protecting access to all your devices. This allows you to use any XMPP server available. However, a cloud based provisioning server would also be possible.

>For example blocking mechanisms of privacy lists, mechanism to give access to change status of the device, mechanism to give access to accept pending file transfer in device, or mechanism to give access to change reputation that all need no XMPP servers could be nice, but I am not really sure if they are really needed.

You can create any number of user privileges you like. And you can administer them locally if desired.

>XEP-0324 is already describing many of required functionalities. Are we kind of inventing the same wheel again but to be more efficient in resource limited environments?

The idea behind XEP-0324 is to work perfectly especially in resource constrained environments and with resource constrained devices.

> We can at least control friendships, content available for different friends, and control operations accessible by different friends with only core XMPP. When using core XMPP it is more about designing security policies, presenting them somehow and implementing of them correctly. When everybody do this differently, there will be problems. So, I understand why we need IoT XEPs, without it there would be several XMPP in sensor networks implementations that would not work well together.


>I originally meant temporary. In my case, the provision server would basically locate, in the "intelligence" of XMPP client that does the authentication/verification, or in clients or servers that are authorized to change access rules I use or make additional decisions.
My XEP enables authentication of one client to another, and provisioning can be done during the authentication or after it by the client or additional provision servers. There will be some examples how provisioning and access control rules could be created. So yes, I have kind of provision servers but the XEP does not concentrate on them or present which policies I use myself, it is about authentication. I want no new friendships to be recommended already in the authentication phase.

§3.6.2 (User access to service) contains a diagram showing how user authentication is performed locally by the service, and how the results are presented to the provisioning server. First the service requests a user token for the user (prior to authentication) providing client credentials. Then the results of the (positive) user authentication is sent to the provisioning server.

Note: This XEP only defines how provisioning is performed, not the actual authentication.

>> What do you mean, cannot be friends? Do you mean you want to 
>> communicate with a provisioning server using for instance MUC where 
>> communication is made between entities that have no formal friendships 
>> established? It would be interesting to read those security policies to understand better.
>I mean that there are use cases where XMPP accounts can have no contacts at all in their rosters, so they would basically only know their own JID and the server. XEP-0324 effects directly to some policies, many other XEPs give just recommendations for policies. I am not sure which one approach is better. To build as uniform as possible system, we can specify required policies already in the XEP, as done in XEP-0324, but it also mean that it does not necessarily fit for every possible use case. Yes, using MUC is one option, but I think it makes the solution much more complex when clients require support for one more XEP. In my use case, I need to be able to authenticate other end without need to add it to my roster.

If you're not allowed to have friends, you're limited to communicating using technologies such as MUC. Such communication is for obvious reasons not safe or possible to restrict, when it comes restricting data. If you still want to know whom you can trust in the MUC, how do you propose to do that? Sending the request in the MUC room also?

>> If you want to test the concept, we can invite you to an interesting 
>> test bed together with SUST and SICS, where different actors are 
>> invited to try out different aspects of the IoT XEPs, and where a 
>> provisioning server will be available for you to test. If you're 
>> interested in only testing parts of
>> XEP-0324 (Provisioning) that's fine with us. In this way, you don't 
>> need to develop something similar when the problem has already been 
>> (perhaps partly) solved. And if you notice you require more support, 
>> we're happy to help you extend the provisioning server extension so it suits your needs.
>That would be nice! I will ask from our project manager if I could use some working time to test them. I hope to get answer during next week.

Excellent :) Let me know what you decide.

>In 3. Use cases:
>"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."
>I understand the main idea, but I would like to read more about this, e.g., about description of impractical access rights (we have access models in pubsub, etc.) and what storing access rights mean (is it downloading and storing them from somewhere, reading a kind of pre-stored node whitelist, depending on pre-shared keys, etc.?), and also the limit of too complex access rights for sensors. A very simple access right can be, e.g, to accept messages coming only from same JID that sensor uses (different resource of course). Maybe this is out of scope of this XEP?

The point here is to create an architecture that allows for a multitude of devices and services. It might be a (future) home with hundreds (or thousands?) of devices connected and hundreds (or thousands?) of different services everywhere doing a lot of things. In such an architecture, it would be highly impractical to assume that each individual device in the network would be able to store information about all different types of access rights that may be necessary. Therefore, you need an architecture which would work even though each device only contains a small subset of the information, in a dynamic way, and where the provisioning server would have a bigger picture. 

Also: XEP-0324 allows for multiple provisioning servers to be used, in the case where different operators (for instance) is allowed to maintain rules pertaining to their subset of the network, while other provisioning servers might be available for integration purposes.

Best regards,
Peter Waher

More information about the Standards mailing list