T2TRG virtual summary meeting
Time: Monday, June 21st, 15:00-17:00 UTC
Video: (waiting for upload)
Repository: https://github.com/t2trg/2021-06-summary
Carsten Bormann (CB) gave intro to the T2TRG and session today.
Doc status: pull-request in GitHub for T2TRG RESTful Design draft. Also planning for author/interest team meeting soon. IoT Edge and Secure bootstrapping docs on agenda today. WISHI discussions on IoT info model standards description; draft coming.
Ari Keränen (AK) gave WISHI update. Good discussions with the Microsoft Azure DTDL team about SDF DTDL interworking. Set of topics identified for closer look and alignment: SDF & DTDL enhancements, using external ontologies, units, sharing models. Two DTDL converter implementations: to and from SDF. IoT info model standards description was also discussed and T2TRG draft of that is coming.
Jana Kiesewalter (JK) presented SDF-YANG converter.
JK: writing master’s thesis on the topic. Looking forward to group input on the conversion results.
JK showed SDF – YANG element conversions. Live demo at: http://sdf-yang-converter.org
CB: we can discuss this at the T2TRG list. If we get too detailed we can go off-list but at the moment no danger in drowning the RG list. If you have YANG models of IoT things, please throw them to this tool and tell if the result is useful.
This was example of piece of software. We will spend more time on SW a month from now at the IETF hackathon week. Will be throwing models at each others’ tools and see what happens.
Plan to use Ericsson DTDL converter, SDF YANG converter, and other converters. Hope to get authors of various converters joining.
MMC: Quick update; skipping some slides uploaded. Published metadata format, Thing Description (TD), similar to SDF and DTDL but focusing on instances. Common abstraction/interface for applications. Introduced Thing Models that describe classes. Correlates more with SDF than TDs. Also working on discovery and profiles.
The TD 1.1 work is constrained by backward-compatibility. Bigger changes for 2.0. Thing Model is template for TDs. TD is missing some things mapping to SDF, like sdfObject; will have to look at this for TD 2.0. Defining canonical way for the serialization to enable signing. Discovery work on introductions, directory services, and self-description.
Now working on XMLDsig-like (canonicalizing/embedded) signature mechanism based on JWS [RFC7515]. Some devices include security keys in URLs. Extended TD to be able to describe that (even if not necessarily a good security design). Allowing also OAuth device flow.
Thing Descriptions can refer to one Thing Model (TM) with links but TMs can reference each other (for more complex things). Trying to align this with SDF. Some things, like containers, may need to wait for 2.0.
Discovery extended in particular for better privacy. Spec ready, now trying to figure out how to test this.
CB: JSONPath WG would be very interested in your requirements. What do you need JSON path to do. Thinking is that we’ll have minimum viable product in first RFC. If there’s something you need, tell us.
MMC: main thing needed: need to limit the power of JavaScript snippets. Don’t want to be able to do injection attacks. Limit comparisons done to subset.
CB: that’s already in the doc. But need input on what we need to do and what we can leave out.
MMC: no time for fancy requests. Need MVP out to ref that and can do fancier things next year with 2.0.
Doing baseline profile with HTTP binding now. Smart city workshop on June 25th. Will engage with smart city stakeholders. Have use case document with set of related use cases. Need geolocation and don’t have standard for embedding to TDs. Will look into that. For example, which room you are in.
For the documents, suggest to look at the editors’ drafts for latest. Also new website for accessing things ongoing: https://www.w3.org/WoT
Are now rechartering the group and looking at what to do with next charter. Definitely want to align with SDF but have time constraints to finish current version. Will clean up and then have chance to discuss more major things for our next charter.
CB: We hope to keep getting these updates from W3C WoT; very relevant to the work we do here.
MJK gives update on OneDM. Using SDF language to arrive at common data model that everyone can use for IoT affordance patterns. OneDM depends on SDF; SDF work was moved to the IETF ASDF WG; OneDM to provide requirements there. Doing pressure test now and looking at a couple of new features. Main body of work to do convergence on data models around industry. Have ~200 models currently from OMA, OCF, Bluetooth Mesh, ZCL. Also have an idea to figure out how to handle lifecycle management etc. for the models.
Planning to create provisional models now that might be superseded when we have more groups joining. Will need to engage with some of the early supporters now when language more ready. Have models from OCF on appliances and from OMA on LwM2M sensor models. Decided on process similar to the one everyone uses: making concrete proposals and IETF-style chairs driving consensus to help break deadlocks. Ongoing questions on how quantities and units should be handled with sensors. For the early process decided to go with models that don’t have too much overlap. From OCF a few appliance models.
To give flavor on the kind of questions, one example is quantities and units. Turned out to be bigger question than anticipated. Should we require temperature to always be in Celsius? Or allow run-time differences? Common ways to present? Bunch of definitions tied to units or sensors, like BACnet has, and you have values to customize with units. Or maybe there should be two ways but then people have question which ones to use. Multiple sensors also like Bluetooth has a good system using. Trying to synthesize best from different approaches.
Working on semantic proxy with common abstract models and protocol bindings. Would take single definition converted to ecosystems, having compatible declarations, and then create Thing Models as McCool mentioned. Can use TD as intermediate format. Node-WoT software can consume TDs and create a proxy that automatically consumes any SDF definition and exposes as e.g. OCF client. If common WoT profile, this picture would have many different devices, and top part would be common WoT profile client.
Eve Schooler (ES): curious about following the semantic proxy diagram. Interested to hear about Digital Twin / DTDL work. Talked about number of models. Can also talk about various conversions on the way? Focus of the hackathon? Interesting metric, how many conversions and which directions are converting, and how many under development.
MJK: good metric. MJK recently changed jobs, now at Passive Logic, working on Digital Twins for buildings. Looking at conversions to BACnet and DTDL. Also physics ontology for buildings. That would have 3–4 new conversions. So far only software repository but if could move to high level status on conversion — lots of different ways to do that. Suggestion could be taken as general category to manage. Also Digital Twin work newly emerging that creates whole new application area. The diagram of semantic proxy is also illustration of what kind of data DT would use. Would present single unified semantics to upper layers. Would not have to think about different protocols.
MMC: interested in tracking convergence. Good test cases for how compatible standards are. Having those around allow us to test models. Directory services; can we have single model and just serialize different models. WoT TD could provide SDF models.
CB: useful input to hackathon. Have started WISHI activity to collect references to tools. This is a reminder to update that. Could prepare for hackathon; look there more closely at our tools for conversions. On Thursday at WISHI meeting one good thing that came out is that the DTDL people now also have models out there. Next thing to look at how to get these into repositories too. And other models waiting for that too. Will be doing at or before hackathon. Hope to have good view on coverage after hackathon.
MJK: remember early on in the IAB IoTSI workshop [2016], had diagram on how conversion works. This system includes also the arcs that are the conversion. Makes lots of sense. Also with digital twins, looking at physical models that don’t have the same kind of affordances, but e.g. where connected. Those are also needed but not necessarily converted now. Unless with something like OPC. But depends on ecosystem. Modeling with SDF the devices but also where they connect to.
Xavier de Foy (XF) presenting update on the draft. Addressed comments from Milan and other related comments. Also contacted other SDOs for reviews; no yet tech feedback but waiting.
XF presented summary of updates.
XF: makes sense to start last call? Helpful to elicit comments.
MMC: I read this twice, made set of comments, but didn’t send yet. Can try again, but may have been addressed already.
XF: great! Fine if you send comments that are covered; no big deal.
MMC: lots of comments, but didn’t want to write long email. Could edit the doc myself?
XF: sounds good. On GitHub so not a problem. Can send link to GitHub repository to the list/to you. (Edit: GitHub link is https://github.com/t2trg/t2trg-iot-edge-computing)
CB: often comments where you just want to say “say this way”, easier to edit the doc directly.
MMC: ran out of time and new version got out and comments were no longer valid. Will need to find time to try again.
CB: also what learned: really best to submit comments in smaller pieces. If you do review, and have done a partial one, don’t wait until you have time to complete but send to authors and they can do something useful with that. Monster pull requests also hard to merge. Keep small and timely is good suggestion.
MMC: was thinking of one PR per issue.
CB: that [extreme] might also be overwhelming. But sending incrementally is good idea. Hearing that people are interested to get few more reviews. Also time for the chairs to provide reviews. Getting ready for RG last call. Will spend some more time doing reviews and start RG last call in fall. Whatever we can do before that helps to speed up the call.
XF: thanks!
Mohit Sethi (MS) presented draft. Currently adopted as RG draft. No changes in content but goal here to present some suggestions for future direction of this doc and get feedback before we edit the draft. Lots of change suggestions coming from WG/RG chairs and members. Lots of material based on presentation by Carsten in IoTOPS WG 2021-04-20.
Started with documenting bootstrap technologies but over time more and more new technologies came. Also overview of terms used for bootstrapping and identifying common patterns. Can’t list all techs but pick and choose illustrative examples. Significantly different on user interactions, credential types, and what they achieve in the end. Initially tried to classify bootstrap techs but soon realized it is hard to classify; some are easy but many fall into generic category of hybrid methods. Only few protocols addressing only a single use case or area.
Many similar terms used in this context for “bootstrapping”. Listed on slide 3, let us know if we’re missing still some. In draft title now “bootstrap” so thinking now what should be the term used there. CB suggested “initial security setup of IoT devices”. Also new breakdown of protocols into 3 things: players (different parties), beliefs (pre- and post-setup; knowledge available), processes (sequence of events).
Presented two examples of protocols broken down to these 3 phases: DPP and Bluetooth mesh (not yet in the draft).
MS: looking for your feedback!
CB: since the draft is in GitHub, it’s easy to add Issues and PRs. But also welcome the usual reviews to the list. Can you say more about the timeline for next steps?
MS: guess, would like to get content updated before cut-off for July IETF. After that depends on getting feedback on the content. All authors busy too, but will make up for that. If this direction works for rest of RG, would be simply breaking down other protocols to these stages.
Michael Richardson (MCR): think that proposed revisions to structure are really good. Fair amount of work though. Really like this process that slide 4 showed. Can provide for future docs clarity on this. Don’t know if this doc needs to talk about many examples but probably about those that we know about. Anyone in the RG who could provide details in the CHIP/Matter stuff? Would be timely to include that. Don’t need to do extensively, but representationally. To have idea how to apply to things in the future.
MS: agree, can’t be exhaustive list. Try to cover important ones and different enough that present variations that exist.
CB: one important benefit from the document is that it provides an example/model for how you would talk about a specific bootstrapping/onboarding approach. To have right words. When people coming with new models can be compared to others. Unless they want to obfuscate.
Gabriel Montenegro (GM): like MCR said, don’t think we should list every one, but can offer another in addition to Matter: FIDO recently issued IoT security spec. That might be relevant. FIDO very prevalent in this space. Also NIST has issued guidelines for IoT security. Good to see, maybe extra sec, for NISTs of the world, which to comply to give guidance to folks who want to go next step. Government guidance important for certain style of deployments.
MS: thanks; FIDO currently is in the draft. Described what it does, but not in the fashion suggested here yet. Since people support this, will do that for FIDO as well. Will be there. Regarding NIST, will have to look at the spec and how well covers bootstrapping. Taking a note of that and come back to you in the next meeting.
CB: hope that the prediction holds we made that this is a 2022ish doc to publish. Will hope to get into status where we can do most of the processing this year.
MCR presented IDevID considerations. Certain amount of scepticism on PKI never being deployed etc. others suggested processes to tackle that. Either people think “I can’t ever trust this thing” or “it gets so complicated that can’t use”. This document provides some analysis on what’s going on.
Important especially for industrial applications: restore the configuration when replacing device.
Manufacturers provide credentials. Something like Excel file. Next create IDevID, needs Certificate Authentication to sign in device-unique way. Provide root-CA to be able to cycle CA in the factory. Document talks on how these things go together. On other side trust anchors. For IDevID, private key goes in, but for trust anchor public key goes in and private key stays in factory. With that will probably have code-signing to use with something like SUIT to sign software. Also other anchors to include.
How we do security around this process? Human-factors? Secret held by 3-4 persons? Is 3 better than 4? Don’t know. More pieces you have the higher chance for compromise but OTOH more pieces more likely they don’t get killed in a bus crash. Or if you try to put up a new plant, the holders are able to travel there during pandemic. For DNSSEC, last year, they drilled open the vault because they could not have right people to travel there. Had process, which I guess they understood well, where they attacked themselves on video. If going to convince security reviewers the anchor is properly taken care of, need to go to details and what does that mean. Also, is it same CA or no? Want manufacturers answer these questions. No value judgement on which is better.
CB: what’s the trajectory for this doc?
MCR: would like T2TRG adopt this; preference. Happy to take co-authors. Want to be able to reference this from two documents in IoT operations at ANIMA group. Also other things that are willing to reference this. All onboarding mechanisms should be able to say which apply. This analysis may not apply to FIDO but rather to Qualcomm implementation of FIDO for example. Could answer how they do it, not the details, but so that we can understand what level of caution they have taken. With each level comes increased level of operational impediment in many cases.
CB: how this doc interacts with [Mohit’s] document?
MCR: interesting question. Could do some amount of cooperation for terminology. Could adopt any terms proposed. Needs to reference [Mohit’s] document for different steps. Not sure if references in the other direction make sense, but can do them. See as being related but not co-involved. Would not make sense to merge them.
CB: this document would play the role of an example in [Mohit’s] documents?
MCR: not use case that other docs would look at. Interested in “the yellow box” [on the slide] (manufacturer/provisioning). When going to details what manufacturing is doing, this doc matters. For DPP e.g. different manufacturers may have different methods because of different requirements. If want to know what amount manufacturing does, need to ask that to e.g., know if can use for medical devices or smart home.
CB: interesting way to specialize the more general approach [Mohit’s] document has. Something we can benefit from; in particular for getting feel of how levels of security might be expressed. Not currently lots of grasp on that. Not on operational considerations.
MCR: not asking for levels of security. Think outside of IETF/IRTF view. Needs to be established by someone else. AES bit-level count, for example. But could be meaningless if key is printed on the side of the building. What happens to the credentials asking here.
CB: how to get reviews? Who is interested in putting some review of this document?
MS: can volunteer to review. Need to involve OPS people at IETF and also if chairs can help to get reviews from actual manufacturers and CAs so that processes in the draft reflect what is happening in the organisations.
MCR: have presented the doc to 6 manufacturers, most were nodding. Hard to get comments. Think that with pandemic waning will be able to come back and get their time. Have done lots of that over past year. In many cases “huh, have to think what I can say under NDA”.
CB: in the long run will need to mix in attestation considerations. Systems need to maintain trustworthiness. Will put some of that here.
MCR: using IDevID or something provisioned; one of the things manufacturer provides.
MS: great to have this presented to manufacturers. Don’t expect comments on the list from them but good they have seen it. And indicating that this is correct. Enough for me.
MCR: would like them to write email that could share publicly that says “have seen this and looks correct”.
CB: also need to involve people who make regulations and discuss what they might be eliciting from manufacturers.
MCR: that’s why taxonomy. Don’t want to make judgement. Want the regulators to say “therefore this needs to be 12”. And we will figure out “what are the units for that 12”.
CB: end of our time now and agenda. Will have hackathon in July, another RG meeting some point in September. Wish everyone great summer and talk to you soon!
(meeting adjourned)