Meeting minutes
Minutes Review
<kaz> May-2
McCool: (Goes over last week's minutes)
… I brought up the topic of global IDs which should now be resolved in Profiles.
… There are a number of new PRs
… in the minutes there is a confusing line that says "ID" instead of "UUID". Can you delete it, kaz?
Kaz: Will do.
… (removes the line)
… The line has just been removed.
McCool: I don't see any other issues. Any objections to publishing?
There are no objections, minutes will be published.
Wide Review Responses
TD Issue #1490
McCool: There came up this issue, that asks for prohibiting unique IDs in TDs when nosec is being used
<McCool> https://
McCool: There is a related issue in discovery
<McCool> https://
McCool: the issue is by Ben Francis, he also mentions problems regarding TLS
<McCool> 7.2.2 Directory Service API The HTTP API MUST be exposed over HTTPS (HTTP Over TLS).
McCool: this was a problem that he noted, which is currently in the discovery spec. Using TLS locally is not really possible at the moment, though
<McCool> https://
McCool: I tried to capture some possible mitigations in a new PR in the Architecture repository
… I added some assertions, differentiating between internet access and LAN
… stricter requirements for TLS usage could then be applied if the Thing is available on the internet
… these are MUSTs, while the LAN assertions are SHOULDs
… only using TLS does not solve the mentioned issue, though, not allowing nosec is also required
… the immutable identifiers are not addressed, yet, therefore I would take this part out
… nosec should also not be used for directories containing privacy related information
… (shows the addition in the rendered document)
… I added MUST assertions regarding TLS usage to a subsection called public networks
<kaz> Preview - 10.5 Secure Transport
McCool: in a private networks subsection, there is a new MAY assertion
… in the case of Brownfield devices, I added the recommendation of not exposing them on the internet
… when it comes to PII, I added a new assertion that prohibits the use of nosec and mandates the use of TLS, when privacy related information is contained in a TD
Jan: looks good to me
McCool: have just created the PR
… regarding this one (11.2 Access to PII)
… (generates comments for the PR 747)
<kaz> McCool's comments
McCool: Another aspect that we might want to add would be to require non-nosec on private networks without TLS
… this might complicate things, however, as private networks are better protected from random attacks in general than Things on the public internet
UUIDs
<kaz> wot-profile issue 139 - unique id
McCool: Current Profile spec has the requirement that IDs must be set and that they must be globally unique
… I discussed this in the last profile call
… and said that we took out globally unique IDs out of the TD spec for a reason
… instead, cryptographically unique IDs should be used instead
… there are security issues with some versions of UUID, though
… the only suitable versions are v4 or v5
… my proposal would be to only recommend v4
… v4 does not use hashing, relies completely on random numbers
… constrained devices might not have access to reliable random generators
… current proposal is to use UUIDs and put this ID in the database of a directory
… DIDs would be another alternative, but those are not mature, yet
Kaz: I tend to agreee
… UUID is a possible solution
… however, we should probably clarify the our requirements for IDs a bit more, based on use-cases and concrete scenarios
… as I mentioned in the profile call, which kind of uniqueness is required for local IDs (session-wide uniqueness, global uniqueness, reuse of IDs, etc.)?
McCool: We don't have IDs with metadata in them
… we don't want to have collisions with IDs in directories
… IDs should be reasonably unique and be based on a standard
… UUIDs tick all of those boxes
… they also don't rely on a central authority
… we could list those requirements explicitly
… I will propose the current approach (using UUID v4) in the profiles call on wednesday
Jan: Sounds reasonable to me
Issues
McCool: Let's see if we have any more issues
WoT-Security Issue #204
<McCool> https://
<kaz> 204
McCool: (Adds a comment to the issue)
… I noticed some security related aspects with home assistant
… I linked an issue from the testing repository in the comments
WoT-Security Issue #197
McCool: This issue is relatively new
<McCool> Issue 197 - Promoting an approach where every thing is a server is a security nightmare
McCool: we discuss it in the future
… rather: the latest comment is new, the issue is older
… I will the issue to the next meeting's agenda
… (adds the issue to the Wiki page)
WoT-Security Issue #195
<kaz> Issue 195 - Consider specific security guidance for particular contexts
McCool: This issue relates to what I just did here
… let me make a note here
… (adds a comment about the updated S & P consideratiosn in the Architecture repository regarding TLS on LANs, PII and immutable IDs)
McCool: Private networks can be differentiated, however, into personal and institutional ones
… is an issue of use-cases
… question of how to relate security considerations to use-cases
… the MAY assertion regarding the use of TLS should probably be a SHOULD instead
… (adds another comment to PR #747 in the WoT Architecture repository)
… I think that covers all the cases
… institutional networks could have stricter requirements/need stricter assertions than personal ones
… the assertions should be kept as SHOULDs, but we should add an informative note that says that the risk increases with the number of people and the sensitivity of data. The use of secure transport should than be advised more strongly in more vulnerable contexts
<kaz> McCool's updated comments
<kaz> [adjourned]