12:00:52 RRSAgent has joined #wot 12:00:52 logging to https://www.w3.org/2021/10/28-wot-irc 12:01:04 pchampin has joined #wot 12:01:07 Tomoaki_Mizushima has joined #wot 12:01:08 ktoumura has joined #wot 12:01:53 Ege has joined #wot 12:02:09 you do not hear me I guess? 12:02:54 sebastian has joined #wot 12:04:00 meeting: WoT vF2F in October - Day 5 12:04:07 cris has joined #wot 12:04:59 McCool has joined #wot 12:05:22 Fady has joined #wot 12:07:34 Chair: Sebastian, McCool 12:07:46 topic: Agenda 12:07:53 @@@ sk slides 12:08:08 sk: (goes through the agenda) 12:08:39 ... marketing, OPC-UA, T2TRG/DID/Security, break, PlugFest/Test report 12:08:47 ... and wrap-up 12:09:55 topic: Guests 12:10:14 lg: Lorenzo Gigli from UNIBO 12:10:51 sk: be aware of the W3C Patent Policy 12:11:07 lg: sure 12:11:14 sk: anyone else? 12:11:42 (no more) 12:11:52 sk: we use IRC for minutes 12:12:02 h_endo has joined #wot 12:12:07 citrullin has joined #wot 12:12:14 ... also manage the speaker queue there 12:12:25 https://irc.w3.org/?channels=wot 12:12:35 sk: presentation slides available online 12:12:36 https://mit.webex.com/mit/url.php?frompanel=false&gourl=https%3A%2F%2Fgithub.com%2Fw3c%2Fwot%2Ftree%2Fmain%2FPRESENTATIONS%2F2021-10-online-f2f 12:12:37 mlagally has joined #wot 12:13:04 PeterAndersen has joined #wot 12:13:25 i|sure|https://www.w3.org/Consortium/Patent-Policy-20170801/| 12:13:30 topic: Scribes 12:14:34 Mccool, Ege and Kaz 12:14:41 tm has joined #wot 12:15:27 topic: Marketing (continued) 12:15:35 scribenick: McCool 12:15:37 ege cannot join in last session, may have to reschedule testing discussion 12:15:43 topic: marketing II 12:15:48 s/topic: Marketing (continued)// 12:15:55 ege: last time summarized work 12:16:01 agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting,_October_2021#Oct_28 12:16:14 ... want to discuss "WoT Communication Platform" for non-W3C members 12:16:27 ... see issue 146 in wot-marketing 12:16:51 ... want non-W3C members to have easier discussions with WoT WG and IG, e.g. to ask questions 12:17:05 ... example from node-wot, recently added Telegram 12:17:12 ... is linked in the README 12:17:22 ... sometimes talk about WoT in general there 12:17:41 dape has joined #wot 12:17:41 ... other orgs, see JSON-Schema uses slack workspace, about 2500 members 12:17:57 ... every day a few questions, about 5, promptly answered by community 12:18:08 s|@@@ sk slides|-> https://github.com/w3c/wot/blob/main/PRESENTATIONS/2021-10-online-f2f/2021-10-28-WoT-F2F-Opening-Kaebisch.pdf Sebastian's slides| 12:18:09 ... other example is Cloud Events, also use Slack 12:18:21 ... have 58K members 12:18:38 ... also W3C has a slack instance, but not usable for us 12:19:12 ... we can use github issues, but word "issue" puts off some people; opening an issue if you only have a question? 12:19:22 ... there are also a lot of repositories 12:19:31 ... issues are repo-specific 12:19:49 ... we could use github discussions; more approachable, but still repo-specific 12:19:55 mlagally_ has joined #wot 12:20:07 q+ 12:20:10 i|last ti sum|-> https://github.com/w3c/wot/blob/main/PRESENTATIONS/2021-10-online-f2f/2021-10_WoT-Marketing.pdf Ege's slides| 12:20:13 hyperloris has joined #wot 12:20:31 ... we also have a StackOverflow tag, but we can't moderate it, and recommendations/discussions get deleted 12:20:32 q+ 12:20:41 ... intended for Q&A only 12:21:08 ... we could use chat-based platforms, e.g. WhatsApp, Telegram, Signal, etc. 12:21:19 ... need mobile number to joint 12:21:30 ... only a single discussion thread, no channels 12:21:49 ... we could use Slack, already used by others 12:22:02 ... more for small teams; maybe changing 12:22:07 ... we already have one 12:22:14 q? 12:22:15 ... but limitation on the number of messages 12:22:29 q? 12:22:47 q+ 12:23:02 ... then there is discord; still a "product", but more community oriented 12:23:16 ... used to be more oriented to gaming, that is changing 12:23:33 ... no limitation on number of messages 12:23:45 ... then Matrix, really a comm standard like IRC 12:24:04 ... less polished than Slack or Discord, no video or audio (we may not care) 12:24:13 q? 12:24:13 q+ 12:24:26 ege: let's take qs 12:24:32 ml: thanks for the roundup 12:24:47 ... should be mechanism accessible to everyone, e.g. without installing a client 12:24:54 present+ Kaz_Ashimura, Ege_Korkan, Ari_Keranen, Cristiano_Aguzzi, Daniel_Peintner, Fady_Salama, Hiroki_Endo, Klaus_Hartke, Kunihiko_Toumura, Lorenzo_Gigli, Michael_Lagally, Michael_McCool, Peter_Gruhn_Anderen, Philipp_Blum, Piere-Antoine_Chapin, Sebastian_Kebisch, Tomoaki_Mizushima, Tomoya_Asai, Zoltan_Kis 12:24:58 ... so signal, telegram, etc. are overkill 12:25:01 zkis has joined #wot 12:25:15 ... and... why not just use an email reflector? 12:25:39 ege: downside of email is a single thread 12:25:52 ryuichi has joined #wot 12:25:53 ... unless we allocate multiple emails 12:26:06 q? 12:26:08 akc ml 12:26:13 s/akc ml// 12:26:15 ack ml 12:26:19 ml: I would not fragment the problem space too much 12:26:30 ege: ideally we would have many people asking questions 12:26:43 q? 12:26:47 ... we could delay until we have more people asking questions, and use email for now 12:27:00 ... not sure if it is seen as approachable as the others 12:27:38 ... people may be worried that people will "take things badly"; 12:28:04 ml: kaz, do we have such a reflector? 12:28:19 kaz: we do have the public mailing list, and IRC channels 12:28:35 ... as well as of course repos, etc. 12:28:54 ... not sure about the main objective of the proposal; what does "approachable" mean here? 12:28:57 q+ 12:29:06 ... what is missing in the current tools? 12:29:23 ... within W3C team, there is dicussion of Matrix 12:29:24 ack k 12:29:35 ... we need to consider use cases and requirements 12:29:46 q+ 12:29:48 ml: so one place to start is to promote the current channels 12:29:59 ... they do not appear prominently on the web page 12:30:11 kaz: main purpose of WG is spec generation 12:30:24 ... community building should technically be done by a CG 12:30:27 q? 12:30:32 q- 12:30:51 seb: time check, let's clear the queue 12:31:01 kaz: and we can follow up in marketing call 12:31:05 ack cris 12:31:24 cris: proposals are great, would like to focus more on community side 12:31:38 ... don't think existing channels are that great 12:31:46 +1 12:31:52 ... should give people a chance to share with each other 12:32:01 ... another possibility is reddit 12:32:07 q? 12:32:10 ack mc 12:32:39 q- 12:32:59 mm: I agree we do need a mechanism for people to share *with each other*, email does not do that 12:33:10 mjk has joined #wot 12:33:14 ... and probably marketing should be a CG activity 12:33:27 ege: ok, let's wrap up, will update slides with email and reddit 12:33:40 topic: OPC-UA 12:34:17 seb: prepared some slides... see repo 12:34:47 i/prepared/@@@ sk slides/ 12:34:48 ... what is OPC-UA? 12:35:02 ... widely used communciation standard for automation 12:35:31 ... all the pieces for what can be done with it defined in "companion standards" 12:35:53 ... we also already have an liaison and a MOU to cooperate on interop of IoT 12:36:00 ... back from 2016 12:36:21 ... one committment to collaborate on development of specs, white papers, guidelines, etc. 12:36:31 ... however, we have not yet realized this activity 12:36:40 ... we should actively work on this 12:37:18 ... there are different kinds of motivation, e.g. use cases for WoT/OPC-UA: cross protocol interworking, building technologies, industry 4.0 12:37:49 ... (these are in our usecases document or WIP to be added to that document) 12:38:51 ... industry 4.0, WIP, related to industrial automation, where OPC-UA is very important 12:39:30 ... We do have some experience with OPC-UA in plugfests and at the Munich workshop, with node-wot 12:39:54 ... also combined with other things, e.g. CoAP, Modbus, M-bus, etc. 12:40:17 ... and showed some factory automation examples, e.g. bottle filling line 12:40:26 rrsagent, make log public 12:40:30 rrsagent, draft minutes 12:40:30 I have made the request to generate https://www.w3.org/2021/10/28-wot-minutes.html kaz 12:40:38 ... the good news is that it is not a big deal to add OPC-UA support to WoT 12:40:43 ... so what is missing? 12:41:13 ... we currently have documents, binding templates, for other protocols: HTTP, MQTT, CoAP, and MODBUS 12:41:28 ... but we are missing a OPC-UA binding template 12:41:57 ... needs to define how the forms in the TD should be set up for OPC-UA endpoints 12:42:31 ... and ideally it is a joint effort with OPC-UA 12:42:57 seb: my proposal is a joint work, a new OPC-UA companion specification 12:43:13 ... that defines the binding ontology and security and comm metadata 12:43:23 Webex appears broken "meeting has ended" 12:43:26 q? 12:43:38 ... guidelines to transform nodeset file to TD 12:43:55 @cabo_ is working for me 12:44:16 ... nodeset has similar data to the TD, use to browse capabilities of OPC-UA system 12:44:46 ... and then on WoT side, we should set up a binding template that relies on the OPC-UA companion specification 12:44:49 I have a Link ending in c0592f9a8 12:44:50 ... and then we have to test it 12:45:02 q+ 12:45:14 q+ 12:45:17 ... I have written a proposal document: @@ 12:46:01 sebn: proposed next step: meet with liaison team, clarify legal agreement, clear plan with W3M, etc. 12:46:25 seb: then get in touch with OPC-UA, get their agreement 12:46:42 ... then declare a joint working activity and begin the actual work 12:46:47 q+ 12:46:54 present+ 12:47:13 https://github.com/w3c/wot-binding-templates/pull/133 12:47:19 q+ 12:47:22 seb: Rainer is also in the call, is an OPC-UA representative, best to answer questions 12:47:27 ack ml 12:47:42 ml: have been talking about OPC-UA, nobody doubts the benefits of such as collab 12:47:58 ... great to see this push; but on slide 7 12:48:12 ... see three documents; two docs are probably the minimum 12:48:44 ... if someone is currently adopting OPC-UA and have adopted a companion spec 12:49:12 ... what would it require to get WoT adopted by OPC-UA user? Would they have to implement something new? 12:49:25 seb: should be no impact on existing OPC-UA implementation 12:50:05 ... the new document would not change any other document, it's providing additional information to define "ahead of time" metadata 12:50:27 ... and nodeset only defines data model, not communication or security metadata 12:51:04 q? 12:51:11 rainer: would be very useful to align TD and OPC-UA information models 12:51:28 ... should consider how you would do it "normally" inside OPC-UA 12:51:43 ... right now this information is defined in companion specifications 12:52:15 ... other companion specs are about "importing" interfaces to specific protocols 12:52:42 ... the WoT would give us a *general* way to bind to other protocols, if we could transform from a TD to OPC-UA data 12:52:53 ... this would be very useful to OPC-UA 12:53:34 ... and there are other things that would be useful, e.g. access to ontologies 12:53:49 burn has joined #wot 12:54:03 ml: what are the dependencies between docuements? 12:54:32 seb: WoT binding would depend on OPC-UA doc, but OPC-UA doc would have to depend on WoT TD spec 12:54:38 q? 12:54:47 ... at least for the nodeset/TD conversion 12:55:01 ml: to rainer, what is the typical publication time? 12:55:11 rainer: assume at least a year 12:55:42 ... companion specs are however faster than core specs 12:56:02 ... there is no formal IC process 12:56:21 ml: so in short, it would fit into the W3C charter cycle 12:56:27 q? 12:56:45 seb: regarding the timeline; ontology should be the first task 12:57:01 q? 12:57:07 q- 12:57:32 kaz: my suggestion is always starting with concrete use case scenario 12:57:46 ... after that we can clarify the gap, and what kind of documentation is needed 12:58:03 ... it's true we already have an official liaison, similar to that with ECHONET 12:58:17 ... should we follow the same process? 12:58:39 seb: not sure the ECHONET liaison has the same strong statement in the MOU 12:59:23 ... 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 BIM use case 12:59:50 s/BIM/Building Technologies/ 13:00:24 seb: in that the BT use case, OPC-UA is already motivated; and there will be more in the upcoming Industry 4.0 use case 13:00:35 ... this is not a new thing 13:01:04 kaz: just saying we should continue discussion of requirements, etc. and then discuss requirements, then docs 13:01:12 q- 13:01:31 q? 13:01:47 q+ 13:01:58 kaz: not saying further collab is wrong, but just bringing up procedure 13:02:09 (time check) 13:02:47 q? 13:03:06 seb: step 1 is to talk with W3M, as I've said; let's do that 13:03:48 q? 13:03:56 kaz: @@@ 13:04:27 ml: have industry 4.0 in the works, that would be a reasonable place to document OPC-UA use cases and requirements 13:04:34 seb: that is the plan 13:04:44 ml: conversation with W3M can happen in parallel 13:04:49 s/@@@/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./ 13:05:09 topic: T2TRG/DID 13:05:18 scribenick: Ege 13:05:20 bkardell_ has joined #wot 13:05:46 mm: I saw people joining, let's check the participants 13:06:23 cb: we are me and ari from t2trg and also others from the other communities 13:06:42 mm: (shows patent policy) 13:06:48 s/then discuss requirements/then discuss gaps between WoT and OPC/ 13:07:21 -> https://www.w3.org/Consortium/Patent-Policy-20170801/ W3C Patent Policy 13:08:59 mm: signatures and object security discussion with ietf 13:09:04 i|I saw|-> https://github.com/w3c/wot/blob/main/PRESENTATIONS/2021-10-online-f2f/2021-10-28-WoT-F2F-T2TRG-DID-McCool.pdf McCool's slides| 13:09:19 ... did is big, we need to discuss which methods are suitable for profile 13:10:44 cb: there will be an ietf hackathon next week and there will be people working on tds there 13:10:50 s/did is/DID is/ 13:11:03 topic: Signatures 13:11:28 hfujisawa has joined #wot 13:11:46 q+ to provide related work on digital signatures using DIDs and VCs. 13:12:03 q+ to mention RDF processing isn't necessary. 13:12:09 ack k 13:12:17 mm: normal signatures take into account json spaces, annoying for round tripping with databases 13:12:23 q+ to mention CBOR-LD 13:12:41 ack ml 13:12:45 ... there is some work on a json-ld signature but it needs an RDF processor which is heavy 13:13:12 q+ to mention HTTP Signatures 13:13:39 ... signature in a TD or wrap TD in a signature 13:14:08 ... xml signatures exist. does what we need but also more. It also is xml 13:14:23 +q 13:14:46 ack manu 13:14:46 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 13:14:50 ... Signatures 13:15:13 https://w3c.github.io/lds-wg-charter/ 13:15:13 ms: there was work going on for a couple of years and new work at w3c for signing TDs 13:15:33 s/is xml/is XML Signature/ 13:15:38 s/... Signatures// 13:15:47 ms: rdf processing is actually optional. things would be allowed with minimum compute 13:16:11 ms: it is constant memory/compute stuff 13:16:18 New VC Charter -- https://w3c.github.io/vc-wg-charter/ 13:16:30 ... there is a new verifiable credentials charter that will focus on signing and packaging formats 13:16:43 ... active work on the challenges you were talking 13:16:56 ... json-ld to cbor-ld and then signing there 13:17:05 q? 13:17:11 afk 13:17:19 s/afk// 13:17:25 ... we are going to start normative specs from w3c if the charter is approved 13:17:32 Introduction to CBOR-LD: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Jul/att-0004/Introduction_to_CBOR-LD.pdf 13:17:46 HTTP Message Signatures: https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html 13:18:36 mm: any comments from ietf members? 13:19:03 back 13:19:22 s/back// 13:19:27 q? 13:19:55 ack cabo 13:20:57 q+ 13:21:00 cb: signing any json is not going to work, it should be self contained 13:21:17 cb: you should think of the semantics of signing (what it adds) 13:21:54 mm: we are signing tds, not random jsons 13:22:48 s/tds/TDs/ 13:22:56 s/jsons/JSONs/ 13:23:01 q+ on partial and chained signatures. 13:23:08 s/any json/any JSON/ 13:23:31 s/ietf/IRTF/ 13:23:44 q- 13:23:49 mm: I should work more on use cases. next step is working on the use cases 13:23:55 ack ml 13:24:33 q+ on signed stuff that works today. 13:24:51 ml: what can we do with the existing standards? 13:26:13 cb: manufacturer description (Ege: not sure about the name) can be used. it is not a td though 13:26:15 q- 13:26:28 q+ to suggest some things w/ DIDs. 13:26:39 MUD (RFC8520) Manufacturer's Usage Description 13:26:54 mm: we still have to distribute the keys 13:27:12 q+ to provide did:key, VCs signed by manufacturer and did:key. 13:27:24 ... https on LANs do not work. Mozilla WebThing developers gave up on HTTPS on LAN and said simply use HTTP 13:28:25 q+ 13:28:42 ... use case is a dashboard at home, how can I be sure that it is secure if I cannot do https 13:29:27 ack manu 13:29:27 manu, you wanted to suggest some things w/ DIDs. and to provide did:key, VCs signed by manufacturer and did:key. 13:29:51 ms: I suggest that the group starts with did:key 13:30:36 ms: browsers will probably not support did right now. some are looking into more decentralized protocols like ipfs 13:31:42 You can get an initial anchor via RFC 8995 BRSKI 13:33:01 action: ege to upload his updated slides on GitHub preso area 13:33:14 @@@ to be moved to the marketing section 13:34:20 ms: in this case it can boil down to hardware protected keys 13:35:42 mm: we have a problem that there can be a single id with different tds 13:35:56 ms: it is important to not mix them from the beginning 13:36:12 ... it can be avoided by having fragment identifiers 13:36:28 q? 13:36:38 ack ca 13:37:11 cb: tls works in LANs, the problem is namespacing 13:37:28 s/tls/TLS/ 13:37:29 ... the way the browsers use tls is dependent on PKIs and DNS 13:37:34 s/tls/TLS/ 13:37:57 ... so the problem would be browsers talking to devices in IoT networks 13:38:52 cb: the other problem is the device identity. We often have devices with shielded trust. So the key can be kept for a long time 13:39:16 cb: RFC8995 is a solution to provide a key on the device 13:43:05 mm: I don't want to reinvent mechanisms but to adopt standards 13:43:12 ... but they should meet our requirements 13:43:14 q? 13:43:17 ack manu 13:43:21 q+ manu 13:43:23 ack manu 13:43:36 rrsagent, draft minutes 13:43:36 I have made the request to generate https://www.w3.org/2021/10/28-wot-minutes.html kaz 13:45:55 Write up of DID Core formal objections: https://msporny.github.io/did-core-formal-objections/ 13:46:15 ms: DID was objected formally by apple, google, mozilla and another company 13:47:55 ms: we are working on them, some objections were misguided 13:47:58 s/apple, google, mozilla and another company/some of the W3C Members/ 13:52:00 mm: we have a dependency on json path 13:52:20 mm: also have an issue around geospatial discovery 13:52:26 i/we have/mm: (talks about Geospatial Discovery)/ 13:53:56 q+ to speak to geospatial use case -- car data encoded as VCs for purposes of safety -- discovery via registry. 13:54:02 -> https://github.com/w3c/wot-testing/issues/167 related issue 167 on wot-testing 13:54:13 q? 13:55:19 ack manu 13:55:19 manu, you wanted to speak to geospatial use case -- car data encoded as VCs for purposes of safety -- discovery via registry. 13:55:31 q+ cabo 13:55:33 q+ to speak to geospatial use case -- car data encoded as VCs for purposes of safety -- discovery via registry. 13:55:33 ack cabo 13:56:06 mm: devices return different types of geolocation date 13:56:45 q+ 13:57:40 ms: some cases around cars: geofencing, autonomous driving, insurance where you want to know if they exceed speed, location restrictions 13:58:37 q+ 13:58:44 ack m 13:58:44 manu, you wanted to speak to geospatial use case -- car data encoded as VCs for purposes of safety -- discovery via registry. 13:59:41 mm: I will contact the people in this list for followup discussions 14:00:01 ack k 14:00:24 q+ to request to pull DID WG and VC WG in more often... VC WG might be the most appropriate for next six months. 14:00:35 kaz: so we'll continue the discussion based some concrete use case description. right? 14:01:01 q? 14:01:10 ack seb 14:01:43 zkis has joined #wot 14:01:43 q? 14:01:53 scribenick: kaz 14:02:07 sk: want to talk with Manu about JSON-LD versioning if possible 14:02:09 manu: ok 14:02:12 q? 14:02:41 q? 14:02:41 ack m 14:02:42 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. 14:02:55 kaz: before that let's check Manu's comment above 14:03:08 ms: please pull DID and VC more often 14:03:21 ... if you want to invite them for signature discussion, etc. 14:03:26 ... please don't be shy 14:03:39 kzms2 has joined #wot 14:03:47 ... the only thing we're not aware is IoT-specific ID 14:03:57 ... may not be working on that 14:04:04 s/ID/canonicalization/ 14:04:09 mm: ok 14:04:18 topic: Versioning 14:04:35 sk: we have been holding discussion on versioning 14:04:42 ... TD spec version 1.0 vs 1.1 14:04:58 ... already have implementations for 1.0 spec 14:05:17 ... possible incompatibility between 1.0 spec and 1.1 14:05:32 ... should we provide a new context file for 1.1 spec? 14:05:51 ... most of the 1.0 processor can't understand the new namespace, though 14:06:04 ... is there any possible solution? 14:06:09 ms: understand the question 14:06:15 ... good you think about this 14:06:27 ... general suggestion for JSON-LD and VC 14:06:41 ... would advise NOT reusing the 1.0 context 14:07:00 ... something that with signs many years ago 14:07:07 ... the new processor may change the signature 14:07:17 ... so suggest publish a new context for 1.1 14:07:40 ... would be better to use v11 for 1.1 context 14:08:28 ... never change once it's decided 14:08:37