Meeting minutes
Minutes Review
<kaz> Jan-23
McCool: We looked at topics for the new charter, discussed the DTLS issue
… not the end of the world to leave things as they are. If I am mistaken, PLH has not responded to my mail yet
… can you clarify one formulation regarding the options for addressing the DTLS issue, Kaz?
Kaz: fixed. BTW, we've already got a response from PLH, and we need to respond around the date and time for a meeting.
McCool: Any objections to publishing the minutes?
There are no objections, minutes are approved.
Next Charter
McCool: Did not have time for reviewing
… security is currently not a separate deliverable, many points are in TD, refactoring can be done later and details can be removed
… any comments?
<kaz> wot PR 1067 - Update wot-wg-2023-draft.html
Kaz: I created a PR for fixing the CSS of the draft. can be merged safely before having further discussion.
McCool: Will merge afterwards since it does not change any contents
<kaz> wot PR 1057 - WG 2023 Charter - Security Deliverable
McCool: PR 1057 regarding the actual normative deliverable is still open
… there was a discussion if it should be normative
… so this PR version is putting things into the other already existing documents
… while keeping the Security Deliverable informative
… not quite ready to be merged since there are still some normative parts in it
… any more points that should be discussed here?
… if you have any more points, create a comment or an issue
S&P Guidelines
<kaz> Issue 209 - Update "Security and Privacy Guidelines" prior to 2022 PR transitions
McCool: Last week, I said we need to make some reviews
… I made some progress and created some notes in the Issue 209
… problem is that discovery is not mentioned yet at all
… therefore, a revision is needed
… also, some parts of WoT are now prescriptive which needs to be addressed
… DDoS as a threat needs to be mentioned
… intro section does not mention privacy
… alignment with Architecture Document (e.g., regarding lifecycle) is needed
… protocol bindings need to be mentioned
Jiye: What do you have in mind for referring to Protocol Bindings?
McCool: We don't actually mention Protocol Bindings but limit ourselves to HTTP/CoAP/MQTT
Jiye: We could amend the places where HTTP/CoAP/MQTT are mentioned
McCool: Referring to Protocol Bindings might take future additions such as OPC UA into account
… introduction was also quite weak, referenced documents need to be updated
Jiye: I have some more notes
… in section 3, the requirements are not very well defined, the threat model is not really a requirement, could be moved to another section or the section could be renamed
McCool: Section is rather a requirements analysis, section could be renamed as such
Jiye: Also, I had some issues with section 6
McCool: Yeah, we are repeating ourselves a lot here. However, at least we are not contradicting ourselves
… specific protocols are mentioned here as well
Jiye: "Secure Practices" is also not very well fitting, since we already have a Best Practices document
McCool: Also, signing TDs is mentioned here, which we have not specified yet
… section should be removed in order not to repeat ourselves
McCool: (Adds a comment to Issue 209)
Kaz: I think we should clarify which parts of the topics within this Issue 209 should be applied during the current charter and which should be moved into the next charter. Furthermore, it should be clarified which security topics are by which spec, e.g., Architecture, TD, Discovery and Profile.
… also should clarify which to be covered by the (future version of) the Binding Templates spec
McCool: Simplest approach would be aiming for the next charter. It is unfortunate that it is outdated and does not mention discovery.
… however, updating it within the next two weeks might be tough. However, some small updates could be made, including references
Kaz: right. that's why I'm suggesting we clarify which points to be applied during this Charter period to which spec.
McCool: new versions of deliverables should be referenced
… some of this fixes should be easy and might take a month overall. Revisions to the abstract or the intro could be made afterwards
… beyond the points mentioned in the Issue, it is mostly major refactoring and alignment with Architecture and other documents
… do you have any more comments, Kaz?
Kaz: We should look into all propose deliverables and should clarify which feature is proposed by which one
McCool: There are some things that might turn out to be too specific for architecture
… and should then be moved into to another document
… so we should probably create a "pile" of security considerations and then move them to the appropriate place
… of concern are assertions that overlap
… review across all the documents is needed
… should a longterm coordination of security considerations be a workitem?
Jiye: I strongly agree with the suggestion, would make things a lot easier in the end
McCool: Could be added as an item "Coordinating security and privacy considerations"
Kaz: that might be going to make sense, but we should clarify which security/privacy portion to be described which specification how/ in order to be able to be understood by developers
McCool: Should be aligned with Security Best Practices, but we need to be careful not to contradict ourselves
<McCool> w3c/
McCool: my proposal would be to create issues which people can comment and work on
<kaz> Issue 206 - Add and Update References
McCool: an issue for references already exists, would you be fine with looking into this, Jiye?
Jiye: Sure
McCool: Another easy fix should be mentioning the new deliverables, I can take care of this one
… then we have "revise the abstract", we I can take care of as well
… can you have a look into the intro and the requirements section?
Jiye is assigned to the requirements and Jan to the intro
McCool: I will take care of the DDoS threat topic and check for contradictions
… after a thorough review, we should then be able to publish an update
… hope to be done in a month or two
… will create the remaining issues after the meeting
[adjourned]