Meeting minutes
previous minutes
<kaz> Feb-1
McCool: we discussed management API on scripting api. We need some text to describe what is out of the scope in scripting api
… I also opened an issue in discovery. we'll look at it later
… finally APA
… any objections for accepting the minutes?
… ok we'll publish these
… any updates?
… none
issues
McCool: I'll go through open issues in the security repo
McCool: Lagally want a writeup about canonicalization of TDs. It is related to #166
Cristiano: I opened some issues about security and management apis on scripting api, we could check them out
McCool: yeah true, meanwhile I notice some problems with the published minutes. Links have a trailing column which cause an error
Kaz: fixing
McCool: OK we'll check them later.
topic issue 166
Kaz: btw links fixed
<kaz> wot-security issue 166 - Add integrity protection (proof section) to TDs
McCool: we discussed about minimum requirement for constraint devices. We focus about the minimum memory requirement to handle a TD. We nailed down the discussion to the size of the TD.
… we concluded to have a min size of 64Kb
McCool: the problem is signing needs canonicalization but smal devices might not be able to perform the process.
Cristiano: canonicalization could happen at development time.
McCool: we could even make canonicalization part of the sign process but it will burden a constraint device.
philipp: 64kb might not be enough.
McCool: we found libraries capable to handle our requirements in 64Kb
<McCool> WoT Reference Platform
McCool: we could move this question to the profile call
McCool: the trouble with small devices is that we might not have a communication hardware stack. however we were able to implement wot in small devices like esp32
Philipp: I currently working with Nordic NRF-52832 that has 32 Kb RAM and I have able to expose a TD. However, consuming a TD is surely too much.
Cristiano: why consuming a TD is too much? can you read it in streaming mode?
Philipp: I need to parse JSON which kinda heavy.
… plus I don't see the use case for this
… btw the Nordic has also hardware acceleration
… for signing and maybe SSL
Cristiano: I agree that the use case is a little bit off.
… using a JSON streaming parser you might be able to consume a TD
<citrullin> Agree, that sounds more reasonable.
McCool: Interesting, about validation process I'm noting down that before signing a TD should be valid
McCool: I think there's some use cases for consuming TDs in sensors. I'm noting down a peer-to-peer pairing example in issue #166
Cristiano: btw canonicalization could help streaming parser to optimize searching of particular conditions
McCool: true, noting that down
… also having standard semantic types could be useful.
… related to the peer-to-peer example we could even think about filter parameters in the direct discovery process.
… in short if you know exactly what you're looking for you could extract it without having the whole TD in memory
… does this description convince you, Philipp?
Philipp: Probably I need to read more about business environments but yes
… streaming makes for sure sense
… a lot things to think about
McCool: we still have a lot of todos here. One is to survey hardware accelerators. TDs should be compatible whit such a hardware
… Philipp could you please do this? at least for you device?
Philipp: ok
McCool: chain of proof is flexible about the algorithm used. So we just need to choose one according to the survey
Geolocation
<McCool> https://
McCool: working on #114
… there's a section about privacy. I have to be careful when sharing locations. It can be even inferred by a registration in a particular TD
… also history about a location could be used to infer velocity and learn about the fact the user was on a vehicle or not.
<kaz> [adjourned]