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

On Thu, 16 Nov 2023 at 14:44, Dave Raggett <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.


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


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

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.

Thanks

Ben