Re: updates for the TPAC plugfest

Hi Zoltan,

Thanks for responding, my comments are inlined below.

> On 27 Sep 2017, at 16:22, Kis, Zoltan <zoltan.kis@intel.com> wrote:
> 
> 
> On Wed, Sep 27, 2017 at 5:54 PM, Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> wrote:
> 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.

I was thinking about this from the perspective of web page scripts where browsers limit the HTTP and WebSocket URIs that a script can open based upon the URI for the web page itself. For more details see the HTML5 suite of specifications.

> 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. 

Yes, apart from a question of terminology about what exactly we mean by the term “proxy”.  I am thinking of applications that create abstractions of physical devices as being producers of things for consumption by other applications. The application that produces a thing hides the details of how the sensors and actuators are accessed.

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

That depends upon what you mean here by id.  I can imagine a given physical device being exposed as different things corresponding to different abstractions, possibly different versions. In this case, the different things would have different URIs for their descriptions. Other metadata would tell you about the relationships between them. This would be useful for discovery purposes.

>  
> 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.

I am assuming the use of transport layer security, strong authentication, and time limited authorisation, that requires re-authorisation when needed.  This could build upon evolving best practices for authorisation over HTTP.  Other considerations include a secure boot process for application platforms, and strong separation between different applications running on the same platform. So yes, lots of details, but perhaps most of these are beyond the scope of what we need to specify.

>  
> 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?

When a servient receives a message it needs to identify which thing is being referred to from the set of things that servient exposes. This doesn’t require UUIDs, just that the identifier uniquely identifiers a thing in the set of things exposed by that servient. The id could be passed as part of the path string for a URI, or as part of a URI query parameter or some other technique that the server can deal with.

A physical device could provide a UUID as a globally unique identifier, equivalent to a product’s serial number as opposed to its model number. OCF could require manufacturers to use UUIDs as serial numbers or perhaps in addition to serial numbers.  Other standards bodies may take a different approach.

I am saying that there is value for the thing description to include an identifier that a server can use to identify a thing from the set of things it exposes. How this identifier is used in the messaging protocol is going to be protocol dependent, but needs to be part of the agreement on how the web of things is layered on the protocol.

Best regards,

Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
W3C champion for the Web of things & W3C Data Activity Lead