Meeting minutes
Agenda
<kaz> Sebastian's slides
Sebastian: (goes through the agenda)
... marketing, OPC-UA, T2TRG/DID/Security, break, PlugFest/Test report
... and wrap-up
Guests
Lorenzo: Lorenzo Gigli from UNIBO
Sebastian: be aware of the W3C Patent Policy
<kaz> https://
Lorenzo: sure
Sebastian: anyone else?
<kaz> (no more)
Sebastian: we use IRC for minutes
... also manage the speaker queue there
<kaz> https://
Sebastian: presentation slides available online
Scribes
<kaz> Mccool, Ege and Kaz
ege cannot join in last session, may have to reschedule testing discussion
marketing II
Ege: last time summarized work
… want to discuss "WoT Communication Platform" for non-W3C members
… see issue 146 in wot-marketing
… want non-W3C members to have easier discussions with WoT WG and IG, e.g. to ask questions
… example from node-wot, recently added Telegram
… is linked in the README
… sometimes talk about WoT in general there
… other orgs, see JSON-Schema uses slack workspace, about 2500 members
… every day a few questions, about 5, promptly answered by community
… other example is Cloud Events, also use Slack
… have 58K members
… also W3C has a slack instance, but not usable for us
… we can use github issues, but word "issue" puts off some people; opening an issue if you only have a question?
… there are also a lot of repositories
… issues are repo-specific
… we could use github discussions; more approachable, but still repo-specific
Ege: we also have a StackOverflow tag, but we can't moderate it, and recommendations/discussions get deleted
… intended for Q&A only
… we could use chat-based platforms, e.g. WhatsApp, Telegram, Signal, etc.
… need mobile number to joint
… only a single discussion thread, no channels
… we could use Slack, already used by others
… more for small teams; maybe changing
… we already have one
… but limitation on the number of messages
… then there is discord; still a "product", but more community oriented
… used to be more oriented to gaming, that is changing
… no limitation on number of messages
… then Matrix, really a comm standard like IRC
… less polished than Slack or Discord, no video or audio (we may not care)
Ege: let's take qs
Lagally: thanks for the roundup
… should be mechanism accessible to everyone, e.g. without installing a client
… so signal, telegram, etc. are overkill
… and... why not just use an email reflector?
Ege: downside of email is a single thread
… unless we allocate multiple emails
Lagally: I would not fragment the problem space too much
Ege: ideally we would have many people asking questions
… we could delay until we have more people asking questions, and use email for now
… not sure if it is seen as approachable as the others
… people may be worried that people will "take things badly";
Lagally: kaz, do we have such a reflector?
Kaz: we do have the public mailing list, and IRC channels
… as well as of course repos, etc.
… not sure about the main objective of the proposal; what does "approachable" mean here?
… what is missing in the current tools?
… within W3C team, there is dicussion of Matrix
… we need to consider use cases and requirements
Lagally: so one place to start is to promote the current channels
… they do not appear prominently on the web page
Kaz: main purpose of WG is spec generation
… community building should technically be done by a CG
Sebastian: time check, let's clear the queue
Kaz: and we can follow up in marketing call
Cristiano: proposals are great, would like to focus more on community side
… don't think existing channels are that great
<dape> +1
Cristiano: should give people a chance to share with each other
… another possibility is reddit
McCool: I agree we do need a mechanism for people to share *with each other*, email does not do that
… and probably marketing should be a CG activity
Ege: ok, let's wrap up, will update slides with email and reddit
Action: ege to upload his updated slides on GitHub preso area
OPC-UA
Sebastian: prepared some slides... see repo
… what is OPC-UA?
… widely used communciation standard for automation
… all the pieces for what can be done with it defined in "companion standards"
… we also already have an liaison and a MOU to cooperate on interop of IoT
… back from 2016
… one committment to collaborate on development of specs, white papers, guidelines, etc.
… however, we have not yet realized this activity
… we should actively work on this
… there are different kinds of motivation, e.g. use cases for WoT/OPC-UA: cross protocol interworking, building technologies, industry 4.0
… (these are in our usecases document or WIP to be added to that document)
… industry 4.0, WIP, related to industrial automation, where OPC-UA is very important
… We do have some experience with OPC-UA in plugfests and at the Munich workshop, with node-wot
… also combined with other things, e.g. CoAP, Modbus, M-bus, etc.
… and showed some factory automation examples, e.g. bottle filling line
… the good news is that it is not a big deal to add OPC-UA support to WoT
… so what is missing?
… we currently have documents, binding templates, for other protocols: HTTP, MQTT, CoAP, and MODBUS
… but we are missing a OPC-UA binding template
… needs to define how the forms in the TD should be set up for OPC-UA endpoints
… and ideally it is a joint effort with OPC-UA
Sebastian: my proposal is a joint work, a new OPC-UA companion specification
… that defines the binding ontology and security and comm metadata
<cabo_> Webex appears broken "meeting has ended"
Sebastian: guidelines to transform nodeset file to TD
<cris> @cabo_ is working for me
Sebastian: nodeset has similar data to the TD, use to browse capabilities of OPC-UA system
… and then on WoT side, we should set up a binding template that relies on the OPC-UA companion specification
Sebastian: and then we have to test it
… I have written a proposal document
Sebastian: proposed next step: meet with liaison team, clarify legal agreement, clear plan with W3M, etc.
Sebastian: then get in touch with OPC-UA, get their agreement
… then declare a joint working activity and begin the actual work
<Ege> https://
Sebastian: Rainer is also in the call, is an OPC-UA representative, best to answer questions
Lagally: have been talking about OPC-UA, nobody doubts the benefits of such as collab
… great to see this push; but on slide 7
… see three documents; two docs are probably the minimum
… if someone is currently adopting OPC-UA and have adopted a companion spec
… what would it require to get WoT adopted by OPC-UA user? Would they have to implement something new?
Sebastian: should be no impact on existing OPC-UA implementation
… the new document would not change any other document, it's providing additional information to define "ahead of time" metadata
… and nodeset only defines data model, not communication or security metadata
rainer: would be very useful to align TD and OPC-UA information models
… should consider how you would do it "normally" inside OPC-UA
… right now this information is defined in companion specifications
… other companion specs are about "importing" interfaces to specific protocols
… the WoT would give us a *general* way to bind to other protocols, if we could transform from a TD to OPC-UA data
… this would be very useful to OPC-UA
… and there are other things that would be useful, e.g. access to ontologies
Lagally: what are the dependencies between docuements?
Sebastian: WoT binding would depend on OPC-UA doc, but OPC-UA doc would have to depend on WoT TD spec
… at least for the nodeset/TD conversion
Lagally: to rainer, what is the typical publication time?
rainer: assume at least a year
… companion specs are however faster than core specs
… there is no formal IC process
Lagally: so in short, it would fit into the W3C charter cycle
Sebastian: regarding the timeline; ontology should be the first task
Kaz: my suggestion is always starting with concrete use case scenario
… after that we can clarify the gap, and what kind of documentation is needed
… it's true we already have an official liaison, similar to that with ECHONET
… should we follow the same process?
Sebastian: not sure the ECHONET liaison has the same strong statement in the MOU
… also, we already have some use cases, i.e. Industry 4.0 (which I think will address your question), but the needs are already clear in Building Technologies use case
Sebastian: in that the BT use case, OPC-UA is already motivated; and there will be more in the upcoming Industry 4.0 use case
… this is not a new thing
Kaz: just saying we should continue discussion of requirements, etc. and then discuss gaps between WoT and OPC, then docs
Kaz: not saying further collab is wrong, but just bringing up procedure
(time check)
Sebastian: step 1 is to talk with W3M, as I've said; let's do that
Kaz: yes, as I've been repeatedly proposing we should talk with PLH about the next steps before diving into the discussion on the possible joint documentation.
Lagally: have industry 4.0 in the works, that would be a reasonable place to document OPC-UA use cases and requirements
Sebastian: that is the plan
Lagally: conversation with W3M can happen in parallel
T2TRG/DID
<kaz> McCool's slides
McCool: I saw people joining, let's check the participants
Carsten: we are me and ari from t2trg and also others from the other communities
McCool: (shows patent policy)
<kaz> W3C Patent Policy
McCool: signatures and object security discussion with ietf
… DID has many methods, we need to discuss which methods are suitable for profile
Carsten: there will be an ietf hackathon next week and there will be people working on tds there
Signatures
McCool: JWS signatures take into account whitespace in JSON, annoying for round tripping with databases
… there is some work on a json-ld signature but it needs an RDF processor which is heavy
… signature in a TD or wrap TD in a signature
… XML signatures do what we need but also more.
<Zakim> manu, you wanted to provide related work on digital signatures using DIDs and VCs. and to mention RDF processing isn't necessary. and to mention CBOR-LD and to mention HTTP
<manu> https://
Manu: there was work going on for a couple of years and new work at w3c for signing TDs
Manu: rdf processing is actually optional. things would be allowed with minimum compute
Manu: it is constant memory/compute stuff
<manu> New VC Charter -- https://
Manu: there is a new verifiable credentials charter that will focus on signing and packaging formats
… active work on the challenges you mentioned
… json-ld to cbor-ld and then signing there
… we are going to start normative specs from w3c if the charter is approved
<manu> Introduction to CBOR-LD: https://
<manu> HTTP Message Signatures: https://
McCool: any comments from IRTF members?
Carsten: signing just JSON is not going to work, it should be self contained
Carsten: you should think of the semantics of signing (what it adds)
McCool: we are signing TDs, not random JSONs
McCool: I should work more on use cases. next step is working on the use cases
Lagally: what can we do with the existing standards?
Carsten: Manufacturer Usage Description can be used. it is not a td though
<cabo_> MUD (RFC8520) Manufacturer's Usage Description
McCool: we still have to distribute the keys
… https on LANs do not work. Mozilla WebThing developers gave up on HTTPS on LAN and said simply use HTTP
… use case is a dashboard at home, how can I be sure that it is secure if I cannot do https
<Zakim> manu, you wanted to suggest some things w/ DIDs. and to provide did:key, VCs signed by manufacturer and did:key.
Manu: I suggest that the group starts with did:key
Manu: browsers will probably not support DID right now. some are looking into more decentralized protocols like IPFS
<cabo_> You can get an initial anchor via RFC 8995 BRSKI
Manu: in this case it can boil down to hardware protected keys
McCool: we have a problem that there can be a single id with different TDs
Manu: it is important to not mix them from the beginning
… it can be avoided by having fragment identifiers (@@@need another review during the Discovery call)
Carsten: TLS works in LANs, the problem is having unique namespaces
… the way the browsers use TLS is dependent on PKIs and DNS
… so the problem would be browsers talking to devices in IoT networks
Carsten: the other problem is the device identity. We often have devices with shielded trust. So the key can be kept for a long time
Carsten: RFC8995 is a solution to provide a key on the device
McCool: I don't want to reinvent mechanisms but to adopt standards
… but they should meet our requirements
<manu> Write up of DID Core formal objections: https://
Manu: DID was objected formally by some of the W3C Members
Manu: we are working on them, some objections were misguided
<kaz> mm: (talks about Geospatial Discovery)
McCool: we have a dependency on json path
McCool: also have an issue around geospatial discovery
<kaz> related issue 167 on wot-testing
<Zakim> manu, you wanted to speak to geospatial use case -- car data encoded as VCs for purposes of safety -- discovery via registry.
McCool: devices return different types of geolocation date
Manu: some cases around cars: geofencing, autonomous driving, insurance where you want to know if they exceed speed, location restrictions
<Zakim> manu, you wanted to speak to geospatial use case -- car data encoded as VCs for purposes of safety -- discovery via registry.
McCool: I will contact the people in this list for followup discussions
<kaz> kaz: so we'll continue the discussion based on some concrete use case description. right?
Sebastian: want to talk with Manu about JSON-LD versioning if possible
Manu: ok
<Zakim> manu, you wanted to request to pull DID WG and VC WG in more often... VC WG might be the most appropriate for next six months.
Kaz: before that let's check Manu's comment above
Manu: please pull DID and VC more often
… if you want to invite them for signature discussion, etc.
… please don't be shy
… the only thing we're not aware is IoT-specific canonicalization
… may not be working on that
McCool: ok
Versioning
Sebastian: we have been holding discussion on versioning
… TD spec version 1.0 vs 1.1
… already have implementations for 1.0 spec
… possible incompatibility between 1.0 spec and 1.1
… should we provide a new context file for 1.1 spec?
… most of the 1.0 processor can't understand the new namespace, though
… is there any possible solution?
Manu: understand the question
… good you think about this
… general suggestion for JSON-LD and VC
… would advise NOT reusing the 1.0 context
… something that with signs many years ago
… the new processor may change the signature
… so suggest publish a new context for 1.1
… would be better to use v11 for 1.1 context
… never change once it's decided
… that's kind of what you want
… make sense?
Sebastian: ok
… but still the 1.0 processors don't understand the new context namespace
Manu: they need to update the processor itself
… would it be very bad for the WoT WG?
Sebastian: we're just talking about the possible solutions
… from Siemens, not a big problem
Manu: you can go for another approach, but need further analysis
Sebastian: good to get your advice
<cris> +1 for v11
Kaz: why don't we simply use wot/td/v11
… need further discussion during the TD call, though
McCool: yeah, further discussion during the TD call
… any further points?
(none)
McCool: thanks a lot for your contribution, all!
[5-min break]
Plugfest/Testing report
McCool: we should not take break for the next week but should continue to work due to the delayed schedule
… high-level summary on testing
… basically
… had plugfest mid-feb
… implementation report done 2-4 weeks later
… not only for TD but also for all the other specs
… tooling and better organization
… people need to provide files
… let me explain next week
… we had testfest as well
… generated TDs
<McCool> https://
McCool: to generate the test report
… some of these orgs sharing the codes
… like node-wot
… so should clarify the code-base
… should include previous results as well
<McCool> https://
McCool: PR to be merged
… wot-testing/data/input_2021/TD/TDs/AllOrgs is the area
… under that, there are implementations
… currently ECHONET implementation is based on node-wot
… also node-red may be broken up into several pieces
… the question is how to identify the code bases
… under node-wot
… siemens, tum are included
… that's the input data for the test report
… next
… the script to generate the report
… invalid error for ECHONET data
… seems it was caused by Japanese
… no descriptions
… other place, have descriptions for ja and en
… should have same data for both the languages everywhere
… you can see the log
<McCool> https://
dp: copy it over to the playground and it will show the issue
McCool: need to handle that
McCool: then need to see the report now
… some problems
… first, section "6. System" to be updated
… need to reorganize the content
… and archive the old content
… and identify the code bases
… node-wot is used not only by Siemens now
… should start with the current situation, and then extend it
… implementation status
… need to avoid red marks
… only one implementation for optional features
… have to look into that
… node-wot supports these features or not? (red area)
… like browsers support HTML features
… red here is canonicalization
… if we choose to rollback this feature
… don't think we have to handle canonicalization
… shouldn't require canoincalization for Profil
<Zakim> lagally, you wanted to react to McCool
Lagally: we're not using it externally
McCool: moving it to Profile wouldn't require testing
… one implementation available and need one more
… if we have a good use case for this feature, we need implementations
… the other red area
… TD Directory
… 3 implementations but same code base
… cocntentType and schema
… next language issue
… generated a test case
… td-context-default-language-direction-script
… just weird test case, pretty narrow
… one failure with td-data-schema
… some more failures probably require TD fix
… td-default-AddtionalResponseContentType
… (goes through features)
… whole bunch of errors
… maybe need more examples
… big category on security
… a number of security schemes here
… about vocabulary extensions
… URI variables added
… example in the spec
… can be turned into the test cases
… added device flow
… oauth2-code-flow, device-flow, other-flows
… we took out them to avoid redundancy
… device is new
… took out the other two
… anyway a few cases here
… no example for oauth2-cilent-flow or oauth2-client-flwo-no-auth
Cristiano: node-wot supports those features
McCool: need to check
Cristiano: LinkSmart is another implementation
McCool: ok
… td-security-in-uri-variable
… particular device which uses the URI template
… good news is Philips HUE satisfies one of those features
… node-wot should also support it
… td-security-uri-variables-distinct
… kind of anti thing
… have to figure out how to test it
… (goes through the other red areas)
… td-vocab-cancellation-EventAffordance
… event handling
… td-vocab-conentMediaType--StringSchema
… kind of weird example
… you can't look at it using browser
… td-vocab-default--DataSchema
… new keyword
… should figure that out
… td-vocab-exclusiveMaximum--IntegerSchema, etc.
… also new features
Sebastian: small fixes
… just provide TD examples. right?
McCool: yeah
… td-vocab-model--VersionInfo
… version of TMs
… need to add examples
… (continue to skim the features)
… td-vocab-op--Form
… there are more than one form...
… need to check
… td-vocab-pattern--StringSchema
… td-vocab-profile--Thing
… td-vocab-schemaDefinitions--THing
… mostly useful for additional response
… td-vocab-sizes--Link
… requested by WebThings
… tm-***
… bunch of features on TM
… not implemented yet
… existing tests won't cover this
… need to probably some of these can't be tested
… and need manual assertions
… (goes through the manual assertions part)
… whole bunch of manual assertions
… one more thing
… on TD repo
… wot-thing-description/testing/inputs/implementations
… there is a PR to update the data for the report
<McCool> https://
McCool: todo: update implementation/organization descriptions
… (merges PR 1245)
… will do the others with future PRs
… next plugfest meeting on Nov 3
<McCool> https://
McCool: make a PR against the system descriptions
… each fragment HTML describes each company's implementation
… would archive the old ones
… and distribute the updated ones as the template for people
… then describe how to update them
… considering the code base as well
… that's it
Wrap-up
Sebastian: a lot of topics today
… also many guests
… made good decisions
… thank you very much for your participation!
… let's continue the discussion next week
Kaz: please update the "Cancellation" section of the WoT main wiki as well :)
McCool: will do
Lagally: also I'll distribute a doodle poll to decide the new slot for Architecture
… probably will make it a one-hour call
Kaz: Editors call will be also held on Tuesday, Nov 2
[adjourned]