Re: updates for the TPAC plugfest

On Wed, Sep 27, 2017 at 5:54 PM, Dave Raggett <dsr@w3.org> wrote:

> Thanks for the slides and for the focus on bridging the NAT/firewall
> boundaries between the network edge and the Internet.
>
>  https://lists.w3.org/Archives/Public/public-wot-ig/
> 2017Sep/att-0017/update_Issues_for_TPAC_plugfest_170927a.pdf
>
> I have a few points.
>
> First: I think we should also consider the role that web pages can play.
> Web pages can include a web of things library module that creates
> scriptable objects that function as proxies for things exposed by
> servients. The local origin security policy acts to limit web pages to
> accessing servients with the same origin as the web page.
>

We have not defined the notion of origin for servients (found it
problematic). If you have suggestions for this and the associated security
policies, please share with the security task force. We can put this issue
in the agenda of the next security meeting.



>  For that reason, my servient embeds a web server for HTTP and WebSockets.
> This allows applications installed on the servient to present a user
> interface that runs within a web browser whether on a desktop, smart phone
> or tablet. On your slide 5, this is loosely equivalent to replacing the
> application servients at the top by web pages.
>

I am not sure this is new. I see nothing that would prevent the FPWD
implementations from being used from web pages either. It's one deployment
option, for sure. And the slide could be indeed changed to reflect the
options here.


>
> Second: on slide 16, I’ve used a different approach that avoids the need
> for binding templates for what you call legacy devices.  My solution uses a
> servient that acts as an application platform.  These applications may
> produce (expose) or consume things. An app that produces a thing embeds the
> code needed to communicate with the IoT device.  This is easy for NodeJS as
> there are plenty of networking modules to choose from.  In my case, I was
> easily able to write a few lines of code to use CoAP to get and put the
> state of a device and to subscribe to a stream of updates to the state. It
> would be straight forward to use other Node modules for Bluetooth, Zigbee
> and so forth. This essentially means that we only need to focus on the
> protocols used by servients to expose things, in my case, a messaging
> protocol over Web Sockets.
>

Basically this is another way of saying proxies encapsulate everything
below (whether we explicitly expose the binding templates or not) - and
these are currently being discussed.

Question: when multiple proxies expose the same things, do the Things have
the same id?


>
> Third: when a servient behind a NAT/firewall boundary wants to publish a
> thing on an Internet server, it can push the thing description to that
> server. In my case, this is done via an HTTP request that is also used for
> authorisation, and returns a security permit that is then used in the
> WebSocket connection the servient behind the firewall opens to the Internet
> server. I use a similar request when an app requests an object as a proxy
> for a thing. Here the HTTP request is for the thing description. The
> response also contains the security permit. This is then passed over
> WebSockets when registering a consumed thing.
>
>
The details here would be important. I am not sure if this is really secure.


> Fourth: there can be multiple URIs for the same thing, depending on which
> network interface is used (e.g. localhost or WiFI), whether using IPv4 or
> IPv6, and the difference between the IP address within a LAN and the
> corresponding external address on the Internet. A work around for this
> multiplicity is for each servient to use local identifiers for the things
> it exposes. This can be included in the thing description, and used within
> the messaging protocol.
>

What do you mean by local identification? Should we use UUIDs for
identification? Or UUID for device identification and a path to identify
the Thing within the device (like OCF is doing)? Then, what about id
resolution vs network addresses and URLs? Should WoT servient
implementations provide that?


>
> Fifth: I would prefer us to discontinue the term “legacy device” as this
> doesn’t help us when we are trying to explain what W3C is doing, to people
> involved in other IoT standards development organisations.  It is better to
> say that the Web of Things focuses on the application layer, exposing
> things as objects independently of the underlying protocol standards. We
> thus complement the work by those  IoT standards development organisations,
> firstly through reducing the costs and risks for developing applications,
> and secondly, by enabling the use of semantic descriptions of things and
> their relationships as a basis for open markets of services encompassing
> many different IoT protocol standards.
>

Agreed.

Best regards,
Zoltan