Meeting minutes
Prev minutes
<kaz> Sep-25
McCool: review of the minutes
<kaz> (approved)
Issues on the other TF's repos labeled as "Security"
TD
<kaz> wot-thing-description repo - security issues
McCool: we can't really close issues in those repo's and closing labels, there are a few security labels and quite a few around 20 of them open
McCool: there are stuff specific to a given protocol
… there are features, marked as proposed closing
… there are new features
… there is one related to missing ontology
… there is one on a general issue, that could be hard to fix, because the API is HTTP specific, maybe it could have an openAPI consistent specific security scheme
… there are a few that are open and marked as deferred
McCool: a lot of these issues have been resolved but not closed
McCool: we could resolve this by having an extra statement, we need a PR
Jan: I think there is already a PR
McCool: make auto the default
McCool: comments on the PR: "When we reorganize the security schemes to move protocol-specific schemes to bindings we can clean this up. Really the Basic scheme for HTTP should always use the header specified in the standard and so an "in" field is not required"
Kaz: has comments, given that there are many issues that are not security-related, for version 2.0 we clarify use case scenarios and system modules for proposed issue and feature
McCool: in general, we need to at least talk about the process
Kaz: that's right
McCool: in terms of the time spent, my main conern here is that we have some open security issues, I would like to resolve the ones that are not marked as deferred and some of these are going to be resolved by re-organizing things
… is anybody have a particular issue that they would like to look at now?
Kaz: Right. Actually, what you mean is similar to what I have in mind
… if some the remaining issues are bug fixes or editorial fixes, we could apply them without use case clarification. On the other hand, if some others are new features we need to think about use cases
McCool: a different procedure for a "bug fix" label than a new feature label
… some require improving the presentation
Jan: I have 2 questions, should we defer to 2.0
McCool: we are past the publication time of TD 1.0
Jan: there is one security issue with a label td 1.1. it is implicit password flows 949
McCool: i think there was a render script issue and the ontology was correct
McCool: i think this one has been fixed
Jan: i think there is another issue 949
McCool: another issue for creating an ontology, we decided not to do this
McCool: issue has been resolved (or really not an issue) so propose closing it. However, we might still want to create ontology files for other OAuth2 flows, but this should be done as part of our general security/bindings reorg."
McCool: any objections?
<kaz> McCool's comment on Issue 949
Discovery
<kaz> wot-discovery - Security Issues
McCool: I think these are all feature proposals
… as Kaz pointed out, we need to clarify use cases for new features.
… object security e.g., is another feature
… is there anything that we should do here at the moment?
Architecture
<kaz> wot-architecture - Security Issues
McCool: for architecture we have two things marked as security
… mm commented on issue 508
<kaz> McCool's comment on Issue 508
<kaz> wot-architecture Issue 553 - Information lifecycle
McCool: issue 553 is more complicated, they want to have a clear information on how information is managed
… we need to have an explanatory note on how information is managed
profiles
<kaz> wot-profile - Security Issues
McCool: it's going to be hard to make progress on Profiles
<kaz> wot-profile Issue 6 - Recommended Security
McCool: a general issue SSE, and WebHook are easier to fix and harder in some ways
Jan: is this a recommended security issue number 6
McCool: I think we did already some of these, the problem is that there was parallel re-org, and I lost track where things were going
McCool: I think some of the issues here will go away once we reorganize security schemes to only be applicable in particular bindings
<kaz> McCool's comment to Issue 6
McCool: these labels security-tracker and security-needs-resolutions need to be used by general review and the security groups inside the w3c
Scripting API
<kaz> security-related labels on the wot-scripting-api repo
McCool: the annoying thing with these labels is that you can add them, but you can't remove them
… we should either use a new label and ask them not to do this
McCool: he commented on issue number 315
Jan: so the security-tracker label, we removed?
McCool: if you want an external reviewer to review an issue you can use the "security-issue" tracker
… we can't remove it, we should use another label
Kaz: maybe we can remove them again on https://
McCool: it used to be that when trying to remove the label, a bot is triggered which returns the label
McCool: maybe they fixed it now
Kaz: we can simply copy the issue to another new issue, if needed
McCool: yes
Usage of labels
McCool: there was a "security-privacy" label for the wot-usecases repo, but for use case discussion on the wot-usecases repo, we need a seperate label
… we should have one label for security and another for privacy
wot-security issues
McCool: we have three PR's
PR 230
<kaz> PR 230 - Remove rawgit links from README
Jan: philip raised an issue couple of years ago, remove rawgit links from README issue 230, it's a trivial PR
McCool: any objections to merge this PR?
<kaz> (merged)
PR 227
<McCool> PR 227 - Create Survey.md
<kaz> (merged)
PR 229
<kaz> PR 229 - Rename Requirements section to Analysis #213
<kaz> (deferred to the next time)
McCool: next time we should prioritize the use cases process and not do the PR every time
<kaz> [adjourned]