Goals and Deliverable Discussion for WoT WG 2023 Proposed Charter

[mmccool]

Update charter to template and make minor revisions prior to requesting extension renewal. See new consolidated procedure.

• update to template -> draft
• update charter history calendar
• delete completed topics and deliverables
• use github for technical discussions and to collect suggested new topics
• collect proposed topic definitions in MD file
• discuss new topics and deliverable proposals during TPAC 2021 vF2F and come to consensus
• update charter with new topics and deliverables

[mmccool]

Note this is a renewal, not an extension. So we can have new deliverables.

Possible updates:

• TD 2.0
• Discovery 1.1 - including Geolocation

Possible new deliverables:

• Historical databases (e.g. time series queries)
• (normative) Signatures (might be part of TD 2.0)
• Additional profiles: factory (MODBUS, OPC-UA), embedded (CoAP, MQTT) etc.

[mmccool]

PR #983 is meant to resolve the first subgoal: conversion of the old charter to the new template. Once this has been confirmed, we can merge this PR and check off the first subgoal.

[mlagally]

Time series data is certainly an important new topic, suggest to rename to "Historical data (e.g. time series databases)."

I'm not sure we should be splitting the profiles based on use cases right now but rather just list the protocols that we are considering.

[mmccool]

After review by chairs, update to template subgoal marked complete. Still lots to do.

[mmccool]

In w3c/wot-thing-description#1151 (comment) we were discussing whether EJS signatures should be a normative deliverable of the WG. If the spec is normative, we can require them in Discovery 2.0 and TD 2.0. If they aren't, we can't. Also, we can drop a normative deliverable if we determine it is not required, but it is hard to ADD a normative deliverable to a charter after it has been approved. So I suggest adding EJS as a normative deliverable to the next WG charter.

[mmccool]

Additional proposed WG charter objectives, possibly with deliverables:

1. Onboarding process. Needed for offline/local networks in order to establish keys for use with TLS, etc.
2. Management API. This is separate from the Scripting API, and is about setting up a runtime for the scripting API, including configuring security schemes and establishing keys. Should work with the onboarding process. Essentially, onboarding process results in a set of "key objects" (opaque) that the Management API can assign to security scheme objects made available to runtimes. Also the possibility that the Managment API can select and enable network restrictions for runtimes based on MUDs. This could also include access to local services (e.g. other microservices, eg. for AI) and devices (e.g. cameras) and data (e.g. location, private data stores).

[mmccool]

Consider also making "Security Best Practices" a normative document. Perhaps using the evergreen process to allow for easy update. Need to consider how this relates to certification.

[benfrancis]

@mccool wrote:

• TD 2.0

I propose this should include:

• Inline security definitions
• Top level forms shared between interaction affordances

• Additional profiles: factory (MODBUS, OPC-UA), embedded (CoAP, MQTT) etc.

+1 for defining a "constrained profile" based on CoAP+CBOR, including considering the possibility of convergence with OCF
-1 for domain-specific profiles or those using non-web protocols like Modbus and MQTT (on the basis that they don't meet the eligibility criteria for a WoT transfer protocol)

• Historical databases (e.g. time series queries)

This is a large and important area, but could it benefit from some incubation in the Interest Group first to determine use cases and requirements?

Management API.

I'm not clear on the use cases driving a management API, what problems is it solving?

Consider also making "Security Best Practices" a normative document. Perhaps using the evergreen process to allow for easy update. Need to consider how this relates to certification.

This best practices document doesn't seem to include much in the way of normative statements, it mostly contains informative recommendations like "use TLS" and implementation advice. What do you mean by certification? That isn't something that the W3C usually provides.

[benfrancis]

An additional deliverable to consider for TD 2.0:

• Define an algorithm for parsing a Thing Description

Currently the Thing Description specification defines an abstract information model and a default JSON serialisation for Thing Descriptions, but something I think may be missing is an algorithm for parsing a Thing Description. A validation process is defined but is not mandatory, which leads to certain ambiguities for a Consumer parsing a thing Description.

For example:

• If a Consumer is parsing a Thing Description and finds that a mandatory field is missing, what should it do? (Definition of Backwards Compatibility wot-thing-description#1243 (comment))
• If a Consumer comes across a member or a value of a member which isn't in the information model, what should it do? (see Definition of Backwards Compatibility wot-thing-description#1243 (comment))?
• If a Consumer comes across a property affordance which is both readOnly and writeOnly or is readOnly but defines a writeproperty operation, what should it do? (see Definition of Backwards Compatibility wot-thing-description#1243 (comment))
• If a Consumer comes across a top level Form which has no corresponding interaction level Form, what should it do? (see Describing initial connection wot-thing-description#878)
• If a Thing provides multiple forms for the same interaction affordance, how does the Consumer choose which one to use?

Edit: Also:

• If a Consumer comes across a top level Form with no op member, what should it do? (See Default value section misses op default for Thing wot-thing-description#1294)

[relu91]

If a Thing provides multiple forms for the same interaction affordance, how does the Consumer choose which one to use?

+1 for having this in the next charter there's already some preliminary work done in the Scripting API w3c/wot-scripting-api#282

Related issues: w3c/wot-thing-description#1188 , w3c/wot-thing-description#1083 w3c/wot-thing-description#968

[mmccool]

Possible new objective: onboarding process

[mlagally]

Possible additional objective: additional profiles for cloud and digital twin use cases

[mmccool]

Another topic that came up recently: better supporting devices that are clients. Reasons for this include security, power savings, etc. Note that MQTT is designed this way.
Implications are there is a broker or "shadow" that caches the state or data from the device and can respond on its behalf. This leads to extending the shadow to maintain a history of state, which leads to time series databases, which we may want to query...

I propose we consider a standardized "shadow" service that can run in server that clients can register with and update (on their own schedule) periodically with state.

[mlagally]

I think this touches with the sensor profile we briefly discussed in today's architecture call.
The server in the simplest form can just provide a single endpoint that receives an event payload and is able to handle it appropriately.

Once again there's a need for a standardized event object format.

[egekorkan]

In my opinion this is a bit weird. Just send your data to the cloud and use TDs to describe the data in the cloud. How would you even use TDs to describe these client-side devices. Theoritically, in MQTT we are actually describing the broker where any device/Thing can publish to a certain topic.

We should however work on explaining how to use WoT in this case (if it is usable)

[sebastiankb]

from today's main call: we should also cover the gaps that are currently identify by the use case coverage table

[mmccool]

Renaming this issue since it was meant to capture goals for our third charter, which now will start in 2023 (probably).

[mmccool]

Another possible deliverable goal: a data model transformation language. TDs describing existing devices don't necessarily give semantic interoperability because the data models may be inconsistent across different devices even in the same category. As an example, I have an RGBW LED Strip set up using ESPHome and a Hue Color Lamp. Both are lights that can be set to different colors. Both can even be integrated into Home Assistant which can act as a protocol translator making them available via HTTP. HOWEVER, one uses a device-specific RGBW color space and the other uses the CIE brightness + xy color space. To convert one to the other (for example, to allow the color to both to be set using an sRGB color) requires a non-trivial (and non-linear, e.g. power function) data transformation. Other color space conversions even need trigonometry! Even simple cases might require restructuring of the data payloads or breaking apart large payloads into different interactions. I have some devices, for instance, that pack ALL properties into a single "state" property rather than different interactions for different properties. There are other cases where a few bits of hidden state might be necessary to make interactions consistent across devices (e.g. the above lights have a "flashing" action which is modal in the case of the strip but non-modal and temporary in the case of the Hue bulb), or to support calibration, etc.

For the case of transforming the data for a single interaction, something like JSONata would work. It is used in Node-RED for just this purpose. Unfortunately, it is not a "standard". However, it is similar to XPath, and maybe JSONPath could be extended to support similar functionality.

For the case of "reorganizing" data that appears in one set of interactions into data that appears in another set of interactions in a different Thing (Model), we might need something more like a "Digital Twin" that has state and a general mechanism to transform an input TD and output to a different TD. In general, a Servient implemented with node-wot or something could do this, but a more declarative, rule-based approach would be nice (move this property there, etc). A general-purpose language carries security risks that a more limited rule-based system would not have.

[mmccool]

Security TF Call 11 July: discuss Security and Privacy topics for next charter.

• Secure Transport and Onboarding: Need a defined (normative, prescriptive, if optional) process for provisioning keys to greenfield WoT devices and establishing secure communications, especially on protected networks (LANs). This process may also include registration with local WoT Discovery services (not just directories; may also have to set up DNS-SD entries, etc). Should also include an explicit offboarding process to preserve privacy when a device is decommissioned or transferred to a new owner.
• Privacy, Global IDs, and IPv6: Changing IP addresses to enhance privacy; how does this affect discovery, etc. Typically IPv6 uses globally unique IP addresses, which may conflict with some existing privacy assertions. We could use unique local addresses (ULA), but it gives up some of the benefits of IPv6.
• IoT-relevant protocols such as CoAP and MQTT: Most focus has been on HTTP, but CoAP and MQTT are more common for IoT. The current specs are rather focused on HTTP, e.g. the HTTP interface for TDDs, the names of security schemes, and so on. We need a more flexible mechanism for defining security configurations in a protocol-specific-way, perhaps moving all schemes to vocabulary extensions. CoAP/MQTT interfaces for Discovery would also be useful. There are also emerging standards like Matter that we need a flexible way to deal with, and there is also OPC UA in the works...
• ID Rotation and Discovery Notifications: ID rotation (and maybe IP/URL rotation) would be easier if there was a defined mechanism for sending notifications to a finite set of authorized subscribers upon an ID change.
• Time Series/Data Management/Geolocation: If we do add a deliverable to manage actual data from devices, not just metadata, there will be a set of additional privacy considerations, which will make some of the above more important (especially onboarding and setting up secure transport), but we may also want to consider scopes/authentication (who can access the data queries?), whether discovery can include data-dependent searches, and so on. One special case of this is geolocation and geolocation-based discovery.
• Trust Management: general considerations of managing scope, authentication, sharing permissions, etc. See "IoT trust ontology" in use cases (https://github.com/w3c/wot-usecases/blob/main/USE-CASES/coverage.csv)
• Tradeoff between compactness and security: if we look at more compact formats, we may have to look at security tradeoffs.
• Integrity: JSON-LD/RDF signing, etc. to ensure that TDs have not been tampered with. Needs to be powerful enough to deal with queries etc. that return partial results in Discovery.

[mmccool]

Discovery call 11 July:

• Generally issues labelled using https://github.com/w3c/wot-discovery/labels/defer%20to%20Discovery%202.0 should be dealt with in the next charter.
• Of the above, the following are high priority:
  • JSONPath query language. See issue 234 - once standardized, assuming it meets our needs, we (probably) should adopt it officially.
  • Checking whether a Thing is actually live at the point of registration or at a later point, e.g. periodic keep-alive checking. See issue 229 and issue 164
  • Validation. Needs to be clearer how to validate TDs, especially when extensions are used. See for example issue 143
• Geolocation (see geolocation.md proposal). See also use cases for static and dynamic discovery, data encoding.
• "Data-based discovery": search based on data, not just metadata. Relates to having time-series databases integrated (and as a prereq, would probably need a separate deliverable for time-series data storage and retrieval). May also be relevant to dynamic geolocation data.

McCool (I added the following right after the call closed):

• Integration with onboarding. Should onboarding include registration with a TDD service as part of the process?
• Other IoT protocols: better support for CoAP, MQTT, etc. Right now TDDs can only be accessed via HTTP.

[egekorkan]

Another point that keeps coming in different issues is "Payload based protocols", i.e. the implementation structures the payloads in a certain way that is repeated for each message. In some cases, it would be better to describe it with the subprotocol field but there are cases where no such subprotocol specification exists.

Related issues: w3c/wot-binding-templates#167 , w3c/wot-binding-templates#125 and there is some in the TD that I am not able to find.

[mmccool]

Discussion from DTDL call on July 19:

• McCool: one issue I saw was that DTDL seems more "distributed" over a graph, not clear how we would collect information and assemble a TD.
• Kaz: suggest we start with use cases and requirements, use plugfest activities to drive
• McCool: also direction of conversion to discuss, TD to DTDL and vice-versa, have associated use cases. For example, setting up an Azure DT, I might want to go TD->DTDL, but for WoT-based factory automation might want do the other way
• Koster: we might instead want to use TDs for device interfaces, and DTDL for modelling and digital twins; not really a conversion, but an interworking
• Daniel: besides conversion, in a future version might be an alignment so they are one big standard
• Koster: existing pattern we have, using in other ontologies, using annotation from external ontologies in a TD
• McCool: we may also be able to use links to connect to DTDLs. I also think we have a lot more work to do in semantic interoperability, annotations, etc.
• Koster: so the question is what is the best way to express semantic interop, how to harmonize different viewpoints. DTDL may also be able to model internal components better.
• McCool: I am also worried about harmonizing our "component" models, eg. subclasses, delegation, modules, etc. Also, what is the purpose of modelling internal components? Probably for a better understanding of behaviour.
• Koster: What is the general pattern and architecture of integrating the physical world and affordances.
• McCool: I think mapping affordances to physical interfaces and behaviour is important for accessibility, too.
• Koster: also good to discuss these aspects with OPC UA.
• McCool: so clear to me is that we are missing modelling of behaviour in the WoT spec; so do we do our own thing, or adopt/align?

Let's plan another meeting to discuss the above further, in the meantime, here is a link to the DTDL resources (see also the WoT Main Web Conf wiki page): https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/dtdlv2.md

[mmccool]

How can we better organize this? I think we might want to start writing up "deliverable descriptions" and putting them somewhere. I think an MD file per deliverable in a directory somewhere would be useful. Then we can decide which deliverables can be included in which way in the TPAC meeting. If something needs more incubation it can be an IG deliverable, for instance. We may also want to refactor things, e.g. pull out all normative security/privacy things into their own normative document.

Edit: see deliverable-proposals

[egekorkan]

Another point I have is versioning as a topic across the specs. It has two main parts:

• TD Instance versioning: I think we should define how a change in the TD or the Thing should affect the version field. We can use semver etc. but unless we define what is a patch, minor, major it is useless.
• We starting to have multiple version of specifications and do not really check how one spec is compatible with the versions of the other specs. We are publishing them more or less at the same time but this does not have to be the case. How do we tackle this in the future? A versioning section in each spec that talks about how other spec versions can be used in a safe way would be nice

[sebastiankb]

Industrial Digital Twin liaison proposal:

Asset Administration Shell (AAS) is a new standard for the industry and is currently being developed by IEC/TC65 WG 24. The first part was finalized with IEC 63278-1.

An AAS can consist of so-called submodels, and each submodel has a specific application purpose (e.g., Digital Nameplate (DNP)). Currently, there is a submodel defined that is called Asset Interface Description (AID) which relays on the W3C Thing Description approach. The idea is to describe the interface of the asset (=Thing) and/or asset's related services.

node-wot has already an extension that allows to read AAS with AID instances.

The AID work is organized by the Industrial Digital Twin Association.

The idea in the new WG is to have an open exchange by a (small) liaison with the AID team. It would be great to have them on board when discussing use cases as well as at PlugFest meetings.