mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 10:12:19 -05:00
ProtoXEP IoT - Discovery v0.0.3 < see revision log >
This commit is contained in:
Matthew A. Miller
parent
92f03abf00
commit
f291286ae5
@ -23,6 +23,7 @@
|
||||
<spec>XEP-0001</spec>
|
||||
<spec>XEP-0030</spec>
|
||||
<spec>XEP-0077</spec>
|
||||
<spec>XEP-0114</spec>
|
||||
<spec>XEP-0174</spec>
|
||||
<spec>XEP-0323</spec>
|
||||
<spec>XEP-0324</spec>
|
||||
@ -46,6 +47,19 @@
|
||||
<jid>TBD</jid>
|
||||
<uri>http://www-rnks.informatik.tu-cottbus.de/~rklauck</uri>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.0.3</version>
|
||||
<date>2014-04-09</date>
|
||||
<initials>pw</initials>
|
||||
<remark>
|
||||
<p>Introduced possibility for hosting Thing Registry as a Jabber Server Component, using XEP-0114.</p>
|
||||
<p>
|
||||
Expanded de section <link url='#support'>Determining Support</link>, explaining how to search through server components.
|
||||
</p>
|
||||
<p>Removed the possibility to search for nick names, as a way of finding Thing Registries.</p>
|
||||
<p>Added Security and Implementation Notes describing the pros and cons of hosting a Thing Registry as a Server Component vs. as a Client.</p>
|
||||
</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.2</version>
|
||||
<date>2014-04-07</date>
|
||||
@ -541,29 +555,27 @@
|
||||
</section2>
|
||||
<section2 topic='Finding Thing Registry'>
|
||||
<p>
|
||||
If a Thing Registry is not preconfigured, one must be found. The following lists methods to obtaining the JID for the Thing Registry. Note that the last two
|
||||
have <link url='#security'>security considerations</link> that need to be taken into account.
|
||||
If a Thing Registry is not preconfigured, one must be found. A Thing Registry can be hosted either as a server component using &xep0114; or as an XMPP Client accessible through
|
||||
a JID. The following lists methods to obtaining the Component Address or JID for the Thing Registry. Note that the last one has <link url='#security'>security considerations</link>
|
||||
that need to be taken into account, if implemented.
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
Preconfigured JID to Thing Registry.
|
||||
Preconfigured Component Address of Thing Registry. A Component address is normally a subdomain to the domain of the XMPP Server that hosts the component.
|
||||
</li>
|
||||
<li>
|
||||
Preconfigured user name only, on the same XMPP domain as the XMPP Server connected to.
|
||||
Preconfigured bare JID of Thing Registry.
|
||||
</li>
|
||||
<li>
|
||||
XMPP Server itself. This can be found out by sending a discovery request to the server,
|
||||
as described in <link url='#support'>Determining Support</link>.
|
||||
Preconfigured subdomain part of Component Address. This will be added to the domain of the XMPP Server used to connet to.
|
||||
</li>
|
||||
<li>
|
||||
Search for accounts on the XMPP server with nick-name "discovery". Search is performed using &xep0055;
|
||||
Preconfigured user name of JID. This will be added to the domain of the XMPP Server used to connected to.
|
||||
</li>
|
||||
<li>
|
||||
Searching through Server Components on the XMPP Server currently connected to, as described in <link url='#support'>Determining Support</link>.
|
||||
</li>
|
||||
</ol>
|
||||
<p>
|
||||
<strong>Note:</strong> The above methods might yield multiple JIDs. Each should in turn be checked if the <link url='#support'>support the discovery extension</link>.
|
||||
Note also that the last two have <link url='#security'>security considerations</link> that need to be taken into account. These methods might be
|
||||
skipped, to avoid the possibility that an external user pretends to be a thing registry to hijack new Things installed into the network.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Registering Thing'>
|
||||
<p>
|
||||
@ -573,7 +585,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='thing@clayster.com/imc'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='1'>
|
||||
<register xmlns='urn:xmpp:iot:discovery'>
|
||||
<str name='SN' value='394872348732948723'/>
|
||||
@ -585,7 +597,7 @@
|
||||
</iq>
|
||||
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='1'/>]]>
|
||||
</example>
|
||||
@ -611,7 +623,7 @@
|
||||
<example caption='Registration response when alrady claimed'>
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='1'>
|
||||
<claimed xmlns='urn:xmpp:iot:discovery' jid='owner@clayster.com'/>
|
||||
@ -631,7 +643,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='thing@clayster.com/imc'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='2'>
|
||||
<register xmlns='urn:xmpp:iot:discovery' selfOwned='true'>
|
||||
<str name='SN' value='394872348732948723'/>
|
||||
@ -643,7 +655,7 @@
|
||||
</iq>
|
||||
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='2'/>]]>
|
||||
</example>
|
||||
@ -665,7 +677,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='rack@clayster.com/plcs'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='3'>
|
||||
<register xmlns='urn:xmpp:iot:discovery' nodeId='imc1' sourceId='MeteringTopology'>
|
||||
<str name='SN' value='394872348732948723'/>
|
||||
@ -677,7 +689,7 @@
|
||||
</iq>
|
||||
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='rack@clayster.com/plcs'
|
||||
id='3'/>]]>
|
||||
</example>
|
||||
@ -722,7 +734,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='owner@clayster.com/phone'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='4'>
|
||||
<mine xmlns='urn:xmpp:iot:discovery'>
|
||||
<str name='SN' value='394872348732948723'/>
|
||||
@ -741,7 +753,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='owner@clayster.com/phone'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='4'>
|
||||
<mine xmlns='urn:xmpp:iot:discovery' public='false'>
|
||||
<str name='SN' value='394872348732948723'/>
|
||||
@ -764,7 +776,7 @@
|
||||
<example caption='Ownership claim successful'>
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='owner@clayster.com/phone'
|
||||
id='4'>
|
||||
<claimed xmlns='urn:xmpp:iot:discovery' jid='thing@clayster.com'/>
|
||||
@ -778,7 +790,7 @@
|
||||
<example caption='Ownership claim of a Thing behind a concentrator successful'>
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='owner@clayster.com/phone'
|
||||
id='4'>
|
||||
<claimed xmlns='urn:xmpp:iot:discovery' jid='rack@clayster.com/plcs' nodeId='imc1' sourceId='MeteringTopology'/>
|
||||
@ -791,7 +803,7 @@
|
||||
<example caption='Ownership claim failure'>
|
||||
<![CDATA[
|
||||
<iq type='error'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='owner@clayster.com/phone'
|
||||
id='4'>
|
||||
<error type='cancel'>
|
||||
@ -806,7 +818,7 @@
|
||||
<example caption='Ownership claimed'>
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='5'>
|
||||
<claimed xmlns='urn:xmpp:iot:discovery' jid='owner@clayster.com'/>
|
||||
@ -818,7 +830,7 @@
|
||||
<example caption='Ownership claim of private Thing successful'>
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='5'>
|
||||
<claimed xmlns='urn:xmpp:iot:discovery' jid='owner@clayster.com' public='false'/>
|
||||
@ -835,7 +847,7 @@
|
||||
<example caption='Ownership of Thing behind concentrator claimed'>
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='rack@clayster.com/plcs'
|
||||
id='5'>
|
||||
<claimed xmlns='urn:xmpp:iot:discovery' jid='owner@clayster.com' nodeId='imc1' sourceId='MeteringTopology'/>
|
||||
@ -848,7 +860,7 @@
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='thing@clayster.com/imc'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='5'/>]]>
|
||||
</example>
|
||||
<p>
|
||||
@ -868,7 +880,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='owner@clayster.com/phone'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='6'>
|
||||
<remove xmlns='urn:xmpp:iot:discovery' jid='thing@clayster.com'/>
|
||||
</iq>]]>
|
||||
@ -881,7 +893,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='owner@clayster.com/phone'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='6'>
|
||||
<remove xmlns='urn:xmpp:iot:discovery' jid='rack@clayster.com/plcs' nodeId='imc1' sourceId='MeteringTopology'/>
|
||||
</iq>]]>
|
||||
@ -893,7 +905,7 @@
|
||||
<example caption='Thing removed'>
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='owner@clayster.com/phone'
|
||||
id='6'/>]]>
|
||||
</example>
|
||||
@ -903,7 +915,7 @@
|
||||
<example caption='Removal failure'>
|
||||
<![CDATA[
|
||||
<iq type='error'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='owner@clayster.com/phone'
|
||||
id='6'>
|
||||
<error type='cancel'>
|
||||
@ -918,7 +930,7 @@
|
||||
<example caption='Thing removed from registry by owner'>
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='7'>
|
||||
<removed xmlns='urn:xmpp:iot:discovery'/>
|
||||
@ -926,7 +938,7 @@
|
||||
|
||||
<iq type='result'
|
||||
from='thing@clayster.com/imc'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='7'/>]]>
|
||||
</example>
|
||||
<p>
|
||||
@ -935,7 +947,7 @@
|
||||
<example caption='Thing behind concentrator removed from registry by owner'>
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='rack@clayster.com/plcs'
|
||||
id='7'>
|
||||
<removed xmlns='urn:xmpp:iot:discovery' nodeId='imc1' sourceId='MeteringTopology'/>
|
||||
@ -948,7 +960,7 @@
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='thing@clayster.com/imc'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='7'/>]]>
|
||||
</example>
|
||||
</section2>
|
||||
@ -956,37 +968,33 @@
|
||||
<p>
|
||||
Up to this point only basic configuration and ownership and visibility of a Thing has been covered. For more advanced operations, a Thing might be required to
|
||||
use a Provisioning Server to whom it can delegate trust and allow making decisions, controlling access rights and privileges for the Thing, as described in &xep0324;.
|
||||
If a Provisioning Server is not preconfigured, one must be found. The following lists methods to obtaining the JID for the Provisioning Server. Note that the last two
|
||||
have <link url='#security'>security considerations</link> that need to be taken into account.
|
||||
If a Provisioning Server is not preconfigured, one must be found. The following lists methods to obtaining the JID for the Provisioning Server.
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
Preconfigured JID to Provisioning Server.
|
||||
Preconfigured Component Address of Provisioning Server. A Component address is normally a subdomain to the domain of the XMPP Server that hosts the component.
|
||||
</li>
|
||||
<li>
|
||||
Preconfigured user name only, on the same XMPP domain as the XMPP Server connected to.
|
||||
Preconfigured bare JID of Provisioning Server.
|
||||
</li>
|
||||
<li>
|
||||
The XMPP Server itself can be a Provisioning Server. This can be found out by sending a discovery request to the server,
|
||||
as described in <link url='#support'>Determining Support</link>.
|
||||
Preconfigured subdomain part of Component Address. This will be added to the domain of the XMPP Server used to connet to.
|
||||
</li>
|
||||
<li>
|
||||
Preconfigured user name of JID. This will be added to the domain of the XMPP Server used to connected to.
|
||||
</li>
|
||||
<li>
|
||||
The Thing Registry itself can be a Provisioning Server. This can be found out by sending a discovery request to the Thing Registry,
|
||||
as described in <link url='#support'>Determining Support</link>.
|
||||
</li>
|
||||
<li>
|
||||
The Owner itself can be a Provisioning Server. This can be found out by sending a discovery request to the Thing Registry,
|
||||
The Owner itself can be a Provisioning Server. This can be found out by sending a discovery request to the Owner,
|
||||
as described in <link url='#support'>Determining Support</link>.
|
||||
</li>
|
||||
<li>
|
||||
Search for accounts on the XMPP server with nick-name "provisioning". Search is performed using &xep0055;
|
||||
Searching through Server Components on the XMPP Server currently connected to, as described in <link url='#support'>Determining Support</link>.
|
||||
</li>
|
||||
</ol>
|
||||
<p>
|
||||
<strong>Note:</strong> The above methods might yield multiple JIDs. Each should in turn be checked if the <link url='#support'>support the discovery extension</link>.
|
||||
Note also that the last two have <link url='#security'>security considerations</link> that need to be taken into account. These methods might be
|
||||
skipped, to avoid the possibility that an external user pretends to be a thing registry to hijack new Things installed into the network.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Delegating Trust'>
|
||||
<p>
|
||||
@ -1012,7 +1020,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='thing@clayster.com/imc'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='8'>
|
||||
<update xmlns='urn:xmpp:iot:discovery'>
|
||||
<str name='KEY' value=''/>
|
||||
@ -1030,7 +1038,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='rack@clayster.com/plcs'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='8'>
|
||||
<update xmlns='urn:xmpp:iot:discovery' nodeId='imc1' sourceId='MeteringTopology'>
|
||||
<str name='KEY' value=''/>
|
||||
@ -1046,7 +1054,7 @@
|
||||
<example caption='Update Meta Data request acknowledgement'>
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='8'/>]]>
|
||||
</example>
|
||||
@ -1058,7 +1066,7 @@
|
||||
<example caption='Update Meta Data request failure'>
|
||||
<![CDATA[
|
||||
<iq type='error'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='8'>
|
||||
<error type='cancel'>
|
||||
@ -1074,7 +1082,7 @@
|
||||
<example caption='Update Meta Data response to request from disowned Thing'>
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='8'>
|
||||
<disowned xmlns='urn:xmpp:iot:discovery'/>
|
||||
@ -1216,7 +1224,7 @@
|
||||
<![CDATA[
|
||||
<iq type='get'
|
||||
from='curious@clayster.com/client'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='9'>
|
||||
<search xmlns='urn:xmpp:iot:discovery' offset='0' maxCount='20'>
|
||||
<strEq name='MAN' value='www.ktc.se'/>
|
||||
@ -1244,7 +1252,7 @@
|
||||
<example caption='Search result'>
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='curious@clayster.com/client'
|
||||
id='9'>
|
||||
<found xmlns='urn:xmpp:iot:discovery' more='false'>
|
||||
@ -1268,7 +1276,7 @@
|
||||
<example caption='Search result containing Thing behind a concentrator'>
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='curious@clayster.com/client'
|
||||
id='9'>
|
||||
<found xmlns='urn:xmpp:iot:discovery' more='false'>
|
||||
@ -1302,7 +1310,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='thing@clayster.com/imc'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='10'>
|
||||
<unregister xmlns='urn:xmpp:iot:discovery'/>
|
||||
</iq>]]>
|
||||
@ -1315,7 +1323,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='rack@clayster.com/plcs'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='10'>
|
||||
<unregister xmlns='urn:xmpp:iot:discovery' nodeId='imc1' sourceId='MeteringTopology'/>
|
||||
</iq>]]>
|
||||
@ -1326,7 +1334,7 @@
|
||||
<example caption='Unregister Thing acknowledgement'>
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='10'/>]]>
|
||||
</example>
|
||||
@ -1339,7 +1347,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='owner@clayster.com/phone'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='11'>
|
||||
<disown xmlns='urn:xmpp:iot:discovery' jid='thing@clayster.com'/>
|
||||
</iq>]]>
|
||||
@ -1352,7 +1360,7 @@
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='owner@clayster.com/phone'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='11'>
|
||||
<disown xmlns='urn:xmpp:iot:discovery' jid='rack@clayster.com/plcs' nodeId='imc1' sourceId='MeteringTopology'/>
|
||||
</iq>]]>
|
||||
@ -1363,7 +1371,7 @@
|
||||
<example caption='Failure to disown Thing - Not Found'>
|
||||
<![CDATA[
|
||||
<iq type='error'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='owner@clayster.com/phone'
|
||||
id='11'>
|
||||
<error type='cancel'>
|
||||
@ -1378,7 +1386,7 @@
|
||||
<example caption='Failure to disown Thing - Offline'>
|
||||
<![CDATA[
|
||||
<iq type='error'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='owner@clayster.com/phone'
|
||||
id='11'>
|
||||
<error type='cancel'>
|
||||
@ -1393,7 +1401,7 @@
|
||||
<example caption='Thing disowned in registry by owner'>
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='thing@clayster.com/imc'
|
||||
id='12'>
|
||||
<disowned xmlns='urn:xmpp:iot:discovery'/>
|
||||
@ -1405,7 +1413,7 @@
|
||||
<example caption='Thing behind concentrator disowned in registry by owner'>
|
||||
<![CDATA[
|
||||
<iq type='set'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='rack@clayster.com/plcs'
|
||||
id='12'>
|
||||
<disowned xmlns='urn:xmpp:iot:discovery' nodeId='imc1' sourceId='MeteringTopology'/>
|
||||
@ -1418,7 +1426,7 @@
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='thing@clayster.com/imc'
|
||||
to='discovery@clayster.com'
|
||||
to='discovery.clayster.com'
|
||||
id='12'/>]]>
|
||||
</example>
|
||||
<p>
|
||||
@ -1429,7 +1437,7 @@
|
||||
<example caption='Thing disowned'>
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='discovery@clayster.com'
|
||||
from='discovery.clayster.com'
|
||||
to='owner@clayster.com/phone'
|
||||
id='11'/>]]>
|
||||
</example>
|
||||
@ -1445,32 +1453,99 @@
|
||||
</p>
|
||||
<example caption="Service discovery information request">
|
||||
<![CDATA[
|
||||
<iq type='get'
|
||||
<iq type='get'
|
||||
from='device@clayster.com/device'
|
||||
to='provisioning@clayster.com'
|
||||
id='disco1'>
|
||||
id='13'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>]]>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<example caption="Service discovery information response">
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
<iq type='result'
|
||||
from='provisioning@clayster.com'
|
||||
to='device@clayster.com/device'
|
||||
id='disco1'>
|
||||
id='13'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:iot:discovery'/>
|
||||
...
|
||||
</query>
|
||||
</iq>]]>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<p>
|
||||
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 &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
|
||||
To search for a Thing Registry hosted as a component on an XMPP Server, you first request a list of available components, as follows:
|
||||
</p>
|
||||
<example caption="Checking if server supports components">
|
||||
<![CDATA[
|
||||
<iq from='device@clayster.com/device' to='clayster.com' type='get' id='14'>
|
||||
<query xmlns="http://jabber.org/protocol/disco#info"/>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<example caption="Response confirming support for components">
|
||||
<![CDATA[
|
||||
<iq type="result" id="14" from="clayster.com" to="device@clayster.com/device">
|
||||
<query xmlns="http://jabber.org/protocol/disco#info">
|
||||
...
|
||||
<feature var="http://jabber.org/protocol/disco#items"/>
|
||||
...
|
||||
</query>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<p>
|
||||
If components (items) are supported, a request for available components is made:
|
||||
</p>
|
||||
<example caption="Requesting list of server components">
|
||||
<![CDATA[
|
||||
<iq from='device@clayster.com/device' to='clayster.com' type='get' id='15'>
|
||||
<query xmlns="http://jabber.org/protocol/disco#items"/>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<example caption="Response containing list of server components">
|
||||
<![CDATA[
|
||||
<iq type="result" id="15" from="clayster.com" to="995fab3dd759452ca9c370647323af0c@clayster.com/ebe2348e">
|
||||
<query xmlns="http://jabber.org/protocol/disco#items">
|
||||
...
|
||||
<item jid="discovery.clayster.com" name="Registro de cosas"/>
|
||||
...
|
||||
</query>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<p>
|
||||
The client then loops through all components (items) and checks what features they support, until a Thing Registry is found:
|
||||
</p>
|
||||
<example caption="Service discovery information request made to each component">
|
||||
<![CDATA[
|
||||
<iq type='get'
|
||||
from='device@clayster.com/device'
|
||||
to='discovery.clayster.com'
|
||||
id='16'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>]]>
|
||||
</example>
|
||||
<example caption="Service discovery information response from each component">
|
||||
<![CDATA[
|
||||
<iq type='result'
|
||||
from='provisioning@clayster.com'
|
||||
to='device@clayster.com/device'
|
||||
id='16'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:iot:discovery'/>
|
||||
...
|
||||
</query>
|
||||
</iq>]]>
|
||||
</example>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<section2 topic='JID vs Component Thing Registries' anchor='jidvscomponent'>
|
||||
<p>
|
||||
A client must treat the connection between a Thing Registry differently if it is hosted as a client, having a JID, or if it is hosted as a Jabber Server Component.
|
||||
If it is hosted as a server component, there's no need for the thing to become friends with the Thing Registry. Messages and requests can be made directly to the
|
||||
server component without having to add it to the roster or request presence subscriptions. If the Thing Registry is hosted as a client, having a JID (@ in the address),
|
||||
the Thing Registry must be added to the roster of the client before the client can communicate with the Thing Registry.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Meta Tags' anchor='tags'>
|
||||
<p>
|
||||
This document does not limit the number or names of tags used by Things to register meta information about themselves. However, it provides some general limits and defines
|
||||
@ -1613,6 +1688,28 @@
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<section2 topic='Jabber Components Protocol' anchor='jcp'>
|
||||
<p>
|
||||
The &xep0114; provides an elegant way to introduce external services as server components using a third port into the server (the first two being the client-to-server port
|
||||
and the server-to-server port). But since XEP-0114 is historical, meaning it is not guaranteed to conform to v1.0 of the XMPP specification, it has some serious security
|
||||
issues:
|
||||
</p>
|
||||
<ol>
|
||||
<li>It lacks SSL/TLS support, or the starttls element to switch to TLS after connecting. This makes it possible to sniff traffic in this port.</li>
|
||||
<li>It lacks SASL authentication. Instead a simple handshake is performed</li>
|
||||
<li>There is no way to actually verify that the server is the server. This makes it possible to create a simple Man-in-the-middle attack.</li>
|
||||
</ol>
|
||||
<p>
|
||||
For these reasons, it is not recommended that a Thing Registry service, publishing itself as a Jabber Server Component, does so from outside of the network. Instead,
|
||||
the Thing Registry should be installed on the same server or on a server in the same local area network, so that the Jabber Component protocol port is closed to the
|
||||
Internet.
|
||||
</p>
|
||||
<p>
|
||||
Since it is not guaranteed that an XMPP Server operator allows installation of third party products (such as a Thing Registry), the option to host a Thing Registry using
|
||||
a normal JID is still available. It can be used in proof of concepts, etc. For scalability issues it is recommended that the Thing Registry be hosted as a Jabber Server
|
||||
Component when the population of Things grows.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Hijacking predefined JIDs'>
|
||||
<p>
|
||||
If using predefined user names when searching for a Thing Registry or Provisioning Server, care must be taken to which XMPP Server things connect.
|
||||
@ -1621,14 +1718,6 @@
|
||||
sure the things cannot be hijacked.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Hijacking nicknames'>
|
||||
<p>
|
||||
If searching for accounts with predefined nick names when searching for a Thing Registry or Provisioning Server, care must be taken to which XMPP Server things connect.
|
||||
It might be possible for third parties to register accounts with similar nicknames and pretend to be a Thing Registry or Provisioning Server and in this way hijack unsuspecting Things.
|
||||
If installing things using this method of finding a Thing Registry or Provisioning Server, care must be taken so that undesired third parties are not allowed to create accounts
|
||||
on the server.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Hijacking things in public areas'>
|
||||
<p>
|
||||
The combination of visible key meta information (perhaps in a visible QR-code) and a factory default reset button on a Thing, opens up the possibility to hijack the Thing.
|
||||
@ -1894,7 +1983,7 @@
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>
|
||||
Thanks to Henrik Svedlund, Ivan Vučica, Joachim Lindborg, Joakim Eriksson, Joakim Ramberg, Johannes Hund, Karin Forsell, Kevin Smith, Lars Åkerskog, Olof Zandrén,
|
||||
Thanks to Henrik Svedlund, Ivan Vučica, Joachim Lindborg, Joakim Eriksson, Joakim Ramberg, Johannes Hund, Karin Forsell, Kevin Smith, Lance Stout, Lars Åkerskog, Olof Zandrén,
|
||||
Philipp Hancke, Steffen Larsen, Teemu Väisänen and Yusuke Doi for all valuable feedback.
|
||||
</p>
|
||||
</section1>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user