Re: Strawman Proposal: Web Thing Protocol - WebSocket Sub-protocol

> On 20 Nov 2023, at 14:07, Ben Francis <ben@krellian.com> wrote:
> 
> 
> 
> On Thu, 16 Nov 2023 at 14:44, Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> wrote:
>> Hi Ben,
>> 
>> My experience with implementing the web of things over WebSockets may be helpful.
> 
> Hi Dave,
> 
> Thank you very much for this feedback.
>  
>> 
>> For security, there needs to be a way for servers to require clients to be re-authorised when the previously granted security token expires. This can be implemented as simple message exchanges.
> 
> I had hoped that token expiry could be solved using standard OAuth2 refresh tokens. However, now that you mention it I haven't thought about what to do with active WebSockets when a token expires. Does there need to be an in-channel mechanism for a Consumer to request a new token? Should the protocol require the socket to be re-opened with a new token following the usual OAuth2 flow? Or should the Consumer be allowed to continue to exchange messages over an open WebSocket until the connection is closed (technically the authentication happens via HTTP before the connection is upgraded to a WebSocket, so the server may continue to accept messages after the token has expired)? Obviously the last case means that a Thing revoking a token would not have an immediate effect on open WebSockets and a WebSocket could remain open indefinitely. We can't be the first people to solve this problem, so it would be interesting to look at how this is solved elsewhere.

Assuming an encrypted connection, it makes sense to be able to pass authorisation tokens with messages as part of a Web Sockets connection. Likewise, for the server to signal that the client lacks sufficient authorisation to access given data, metadata and services, e.g. an action may be declined based upon the parameters it is passed, requiring the client to seek a higher level of authorisation.  Whilst you could close the socket and rely on authorisation when establishing the HTTP connection that is then elevated to Web Sockets, that is rather clumsy and risks losing state.

> 
>> 
>> You need a way to signal changes to metadata as well as to data, for instance when the user snaps together two devices to extend functionality, e.g. plugging in a camera and likewise unplugging.
> 
> I would suggest this is out of scope <https://w3c.github.io/web-thing-protocol/requirements/#out-of-scope>, since it relates to "an API for managing a collection of Web Things". There are already mechanisms for listening for changes to Thing Descriptions in the events <https://www.w3.org/TR/wot-discovery/#exploration-directory-api-notification> part of the Directory Service API <https://www.w3.org/TR/wot-discovery/#exploration-directory-api>.

May be out of scope for your specification, but definitely in scope for the IoT as a whole.

>> 
>> For telemetry applications a bundle of measurements can be transmitted in the same message, and there is a choice of whether to include the timestamp in each message or for this to be implicit when such updates are set at a regular interval, e.g. 10 times per second.
> 
> I definitely think that batching and rate limiting are areas we should look at. I've left various Editor's Comments on these topics.
>  
>> 
>> Some services send a combination of data and metadata, e.g. medical devices using FHIR (Fast Healthcare Interoperability Resources).  Likewise, services may support actions that return graph data expressed in JSON-LD or other formats.  It isn’t sufficient to limit information exchange to what can be specified with JSON schema!
> 
> The W3C WoT specifications have a clear separation between metadata (in a Thing Description) and data (via Interaction Affordances). Even if the underlying protocol combines the two, they should ideally be separated at the Web of Things layer in my opinion.

That would be hard to arrange with FHIR for medical data and metadata.

> Time-series data is a work item <https://w3c.github.io/wot-charter-drafts/wot-wg-2023-details.html#timeseries-workitem> being looked at under the new charter of the Web of Things Working Group. I'm not sure yet how that might map onto a WebSocket sub-protocol, but let's see what new operation types (if any) come in Thing Description 2.0.
> 
> In the meantime it could be possible to request historical property readings using this strawman proposal, by specifying a `lastpropertyReading` member in a `readProperty` message.

For a telemetry stream that wouldn’t be sufficient. An example is a device sending ECG, oxygenation and breathing data.  Another example is a brain cap that sends multiple channels of data in real-time.  Streaming analytics needs more than just the last sample.


> 
> Thanks
> 
> Ben

Dave Raggett <dsr@w3.org>