moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

ProtoXEP IoT - Discovery v0.0.3 < see revision log >

Browse Source
This commit is contained in:
Matthew A. Miller 2014-04-09 15:50:17 -06:00
parent 92f03abf00
commit f291286ae5
1 changed files with 184 additions and 95 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

279
inbox/iot-discovery.xml
View File

@ -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'
from='device@clayster.com/device'
to='provisioning@clayster.com'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>]]>
<iq type='get'
from='device@clayster.com/device'
to='provisioning@clayster.com'
id='13'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>]]>
</example>
<example caption="Service discovery information response">
<![CDATA[
<iq type='result'
from='provisioning@clayster.com'
to='device@clayster.com/device'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:iot:discovery'/>
...
</query>
</iq>]]>
<iq type='result'
from='provisioning@clayster.com'
to='device@clayster.com/device'
id='13'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:iot:discovery'/>
...
</query>
</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>