# T2TRG virtual summary meeting {#t2trg-virtual-summary-meeting} **Time:** Tuesday, October 26th, 2021, 15:00-17:00 UTC Video: [Thing-to-Thing research group][1]
Chairs: * Ari Keränen * Carsten Bormann ## Intro, RG status, upcoming meetings and activities (Chairs) {#intro-rg-status-upcoming-meetings-and-activities-chairs} Ari (AK) introduces the meeting. RG Document status: * RESTful Design: updated recently; improved terminology and added details on affordances. Authors believe it's time to go towards publication. Next steps: chair review and last call. If you haven't looked at this recently, please have a look and send comments to the list. * Edge & IoT: go for publication request this year, as well * Michael McCool (MMC): read two versions, not the latest; most of my comments were small matters, ... * Security Bootstrapping: more 2022ish * Title now: "initial security setup" * Eliot Lear (EL): Major revision? * Mohit Sethi (MS, for the authors): Carsten suggested the term "initial security setup"; also identify the players involved; next version: identify initial assumptions and knowledge imparted during setup ## A Data-centric CoAP Transport (Cenk Gündogan) \[15:17\] {#a-data-centric-coap-transport-cenk-gündogan-1517} Slides: (20) fine-grained forwarding vs. privacy
(33) to port ICN implementation to CoAP (38) future work: discovery proxy paths AK: reusing a lot of existing CoAP functionality -- what is the impact on implementation size
Cenk (CG): State management may be underspecified in RFC 7252; not much more than all other the parts... CG: E.g., distribute name information in RPL DoDAG Carsten (CB): there's a large body of ICN research out there. What are the next pieces of research you would start to borrow? Useful elements for data centric CoAP? CG: having data-centric deployment opens door for all the ICN work. Lots of caching strategies that should be easy to apply here. We have almost no memory in these devices so need some cache replacement strategy. Also a few pub/sub schemes from ICN world that might be beneficial with loose coupling. Caching something definitely that one can use and that is easy to get. CB: looking forward to more research on that! ## Matter Security & Privacy for Security & Privacy Experts (Steve Hanna) \[15:46\] {#matter-security--privacy-for-security--privacy-experts-steve-hanna-1546} Slides: Matter is for Smart Home. Talking about security and privacy today. URL: The Matter specs will be open for everyone once published in their 1.0 version; here today can get a sneak peek. Not allowed to present all details of the draft standard. Matter intended to be of widespread utility (hence the name). One of the essential goals: simplify smart home and IoT products so that consumers don't have to worry about that. Security recognized as essential. Matter works on top of TCP and UDP, and IPv6. Wi-Fi, Thread, BLE, Ethernet supported today; more coming. Can automatically provision e.g. Wi-Fi credentials. Open source approach based on existing work. Common protocol from device to cloud with end to end security. Not just security, like DTLS, but also data model for specific device types. Like light would have "on" and "off" or "color of light". Zigbee already had set of common data models that is being extended for Matter. Designed to be low overhead implementation. Aiming for less than 128KB RAM and less than 1MB of Flash. May seem like large here, but for the world of IoT players these are "medium". Has been barrier in the past: how consumers can make devices work together. Setup experience different whether iPhone or Android, etc. Light bulb should be able to work with any admin or control devices you have (Apple home or Google Nest, etc.). Devices should be able to work with multiple ecosystems at the same time. Matter supports set of device types (slide 8); more planned to be added later. Smart speakers, laptops, mobiles should be able to control the devices. Open source at [Github (PCHIP)][2]. Code already available with Apache 2.0. Raspberry Pi as reference platform you can run the code on. Timeline: specs available to CSA members today. Don't intend to release spec publicly before SDK is ready. Want running code as proof that the spec is good. First half of 2022 should have products ready for certification.
Every device with Matter logo will be tested like Wi-Fi devices are tested. You can create your own protos at home but they won't be supported in consumer environment. Don't think just security of device but also network, cloud, and gateways. Using well tested crypto. Intend to be hallmark for Matter. Ease of use drives design.
Matter systems designed to be resilient. Can't protect from all infections so need to detect and recover. Post quantum crypto important consideration. Need to be able to adapt to new development and threats. Threat model for Matter covers all sorts of threats. From cloak and dagger attackers to ex-lovers. Need to revoke devices e.g., from temporarily trusted parties.
Also devices may have long lifecycles that need to be considered. Also considering human factors. Severity of different kind of attacks considered in the work. Distributed Compliance Ledger, can check DAC (Device Attestation Certificate) against that (attestation). Introducing a device: Scan Device (QR\_Code).
Device gets set of credentials and is then able to operate fully in home as a secured and trusted device.
During commissioning, storing new set of credentials; similar to Local Device ID. Operational cert:
Fabric ID, NodeID: 64-bit IDs Private key corresponding to operational cert. Info on who can do what (change light, e.g.). Raising the bar over today's smart home security: easy&flexible commissioning, device validation, can check validity of certs via distributed compliance ledger, strong ID, secured unicast (based on TLS 1.3).
Secured group communication with secure group key. No sender authentication yet with that, but assurance of group membership and possibility to revoke. Remote attestation as optional; can use root of trust. AK: what's on top of TCP/UDP? Steve (SH): secure channel protocol based on Sigma handshake. Also group communication based on symmetric key; AES-128 CBC. Different from others used. Have whitepaper coming and also one on transport and communication aspects later in the calendar year. (CB: relaying Jabber) MS: thanks for the great overview. Question on slide 23: is it correct that the private key is generated outside of device? SH: no, private key can be generated on the device. In fact it would be here always made on device. Sometimes, due to manufacturing difficulties, could be made outside and injected, but during operation generated inside. CB: discussed the whole aspect of ownership and scavenging; interesting question when IoT device come part of home, installed in home; interesting ownership transfer is the involuntary transfer. When whole home changes. SH: is considered but not entirely solved. Uses physical access and requires resetting each device. Painful now but looking to solve better in future. Michael Richardson (MCR): thanks for good slides. Use sigma-like TLS? Don't seem to have algo agility. Hoping the whitepaper explains how to deal with that. Would be useful to understand what the plan is.
On involuntary; have doc on this and would like more discussion on this. Henning Schulzrinne (Columbia U) has done some work on this and have interesting solutions. Not sure if fit to small devices. A bunch of things happening in academic commmunity. Maybe good place to engage across the whole industry. SH: thanks! will look into this. Algo agility is built in here. (from Jabber) Juan-Carlos Zúñiga (JCZ): I see there are several Security design considerations. Specifically for Privacy, are there any considerations beyond the Secure IDs? SH: yes, additional privacy key accross the fabric to encrypt all IDs. For example node IDs are encrypted so that in same Wi-Fi network will not be able to decrypt unless have the corresponding fabric key. Whitepaper will have more on privacy topics. ## Reports from WISHI and other activities (Chairs) \[16:2x\] {#reports-from-wishi-and-other-activities-chairs-162x} Two WISHI calls: 1. SDF, expanding scope to relationship (not just hierarchical) and instance information (beyond the class information); 2. SDF ↔ DTDL; e.g. SDF's SenML units vs. external ontologies; ## W3C WoT update (Michael McCool) \[16:31\] {#w3c-wot-update-michael-mccool-1631} Slides: Michael McCool (MMC) gave quick overview of WoT; much more details and hyperlinks in the slides. Have published WoT 1.0; working on 1.1 now, targeting end of year. Now in clean-up for final release. New spec on discovery; finding TDs. Profile specs for limiting scope. Recent activity: finished plugfest; one of activities was converting SDF to Thing Models (TM); templates for TDs. Solving similar problem as SDF. TDs are instance definitions whereas TMs are classes. A couple new commercial applications; Takenaka have built system using WoT models for smart buildings. Also startup that is spin-off from TUM; building IoT dashboard.
Directory for metadata queries. Have few implementations. SPARQL supported for powerful searches.
For touch-points with IETF: wanted to include JSONPath queries. Unfortunately no RFC yet. Plan is to make JSONPath informative experimental feature. Have one mandatory mechanism other than JSONPath. Don't want to mandate SPARQL or XPATH. Will have one simple now.
CoRE-RD used as first contact mechanism. Having discussion on 28th on signatures, etc. Also feature completeness between SDF and TMs.
Experimental ideas: ontologies for geospatial data. Needs to be coordinated with other groups. Used for location of IoT devices. Sometimes data static and sometimes dynamic.
Location of device vs. location of feature of interest being measured. Looking at signatures. Want to sign TDs but they are large and need to be modified. Existing mechanisms not quite powerful enough. Looking at how we can adapt or extend what is out there. Have draft proposal for a new thing but want to see if can use existing things. Also JSON-LD signature proposal but that's based on RDF canonicalization. Trying to avoid RDF processing. Will be extending current charter for 6 months to start next one in July. Have set of features for TD 2.0. Maybe make normative something like the geospatial. Also looking at managing data itself. Now have directory for metadata but maybe want a directory for data. IEEE, queries of intervals. CB: for JSONPath, will have WG meeting in 2 weeks. Any doc we could use for limiting the first version of JSONPath for the features we need? MMC: we need more examples for our directory document. Key thing we need to support is keyword search and search over the "@type". Like "find all lights". In two weeks time hopefully will have details. CB: how about in 10 days? MMC: can bring up tomorrow in f2f CB: something preliminary would be very helpful MMC: also owe a review of the draft and braindump of the minimum set. ## OneDM update, iotschema (Michael Koster) \[16:45\] {#onedm-update-iotschema-michael-koster-1645} Slides: Michael Koster (MJK) gave update on application semantics work we are tracking: OneDM and iotschema. SDF being developed at IETF ASDF WG. OneDM concensus process has been developed. Niklas helped to do this. Have started to do reviews for a provisional set of models. Picked sensors and operational state models. Will be broadening from there. Looking at different ways to handle units, etc. Going to work through these and find reasonable solutions. Will get something out of the door soon but also will work on the harder problems like breaking into modular features. Being able to describe simple and complex sensors. Giving rise to discussions on classes, instances, specialization, etc. Not working on fixed time goal but planning to get provisional models out so that people can start using them already. For iotschema, built around same metamodel that everyone is using. Schema.org doesn't want to go towards device specification but rather more generic patterns. Will not be extending schema.org right away, but what doing is re-aligning with OneDM and other ontologies so can align how we talk about devices in physical world. Could be RDF front-end. Also iotschema could be way to get RDF so that you can point to Thing Descriptions. Have some proposals from Siemens on extensions to metamodel so that we can connect to physical devices. CB: very intersting since with SDF just had discussion on relation(ship)s. Might have something we can point to instead of re-inventing wheel. What is the best way for us to find out what is going on there? MJK: have cancelled the monthly meetings for a while but need to restart that. No great answer right now but will try to start things going on again. One observation: we see people knocking at door of WoT; have the full set of problems of where the models go etc. We need to look at better integration across all these. Already have W3C CG but didn't really activate. WoT in middle of rechartering.
There is a gap to be addressed. MMC: WoT would be open to add deliverables? MJK: when people come to WoT they have questions beyond on what's the format. CB: seems like good subject for discussion soon. How to setup such meeting to get progress on physical relation types and others we need also in SDF long run MJK: agree; good thing for WISHI too ## Wrap-up (Chairs) \[16:56\] {#wrap-up-chairs-1656} [1]: https://t2trg.github.io [2]: https://github.com/project-chip/connectedhomeip