Meeting minutes
Minutes Review
<kaz> Feb-6
McCool: Spent some time on the first agenda items, need to address the two items in this call
… there is a spelling mistake in "Lumine"
… "jy" should be expanded to "Jiye", there is also a typo in "specking"
Kaz: Fixed
McCool: Any objections to publishing?
Luca: There is a typo in my name in the "Welcome" section
… there is an "r" missing
Kaz: Is fixed
McCool: No other objections, minutes are approved
Profile Security Issues
<McCool_> https://
McCool: What you see here are all the issues that are labelled as "security"
… there are some that are assigned to me, but I want to find volunteers
… there some that are labelled as "P1" for "Priority 1" but the more important ones are the ones labelled "Profile-1.1"
… let's go through them in order
Profile Issue #6
<kaz> wot-profile Issue 6 - Recommended Security
McCool: In this one, there is a set of allowable security schemes
Kaz: Before starting the discussion, I have a question on how to run the discussion. Given you want to have some more volunteer reviewers, do you want to improve the procedure as well? Or OK with having discussion during this WoT Security call for a while?
McCool: My proposal would be doing a quick survey and then assigning the issues to the volunteer reviewers.
… issue deals with section 5.4
… there is a set of schemes
McCool: ...question is if we can trim them down
… I think we can actually retire this issue
Jiye: I am fine with getting rid of Digest in this section. There is also no mention of TLS in this section
<kaz> WoT Profile - 5.4 Security
McCool: Using Basic without TLS is not very secure, but can be seen in some scenarios. Assertions to use TLS are already present in Architecture
Luca: You need to keep in mind that Things might already use a secure channel, e.g. a VPN
… so you need to define the layer
McCool: No mentioning of VPNs yet
… which themselves are likely secured by TLS
… (captures the discussion in an issue comment)
… I think there should probably be at least be a SHOULD or a MUST for secure transport. But might be redundant with regard to the Architecture
Kaz: From my viewpoint, this section has a bigger question about the relationship among specifications
… another point is, as already captured within this Issue 6, that the discussion in this section is kind of redundant
… we should think about a bit more what should be described by the Profile specification and what should be discussed in other documents
McCool: This Profile document is dealing with HTTP in particular
… so the intention is to limit the available security schemes to a well-defined subset
… there are also a lot of "weird ones" like API key
… some of its variants also have a lot of implementation effort
… so we want a minimum set of "good" security schemes
… and define best practices
… a bad scheme, for example, would be using Basic with credentials in the URL
Jiye: Maybe that should be mentioned in an informative note
Kaz: Probably this is partly related to Luca's point as well: We should probably define the security scope of WoT Profile spec a bit clearer
… e.g., HTTP-based interaction like HTTP Basic Profile, HTTP SSE Profile and HTTP Webhook Profile are our targets, and technologies like VPNs are not in our scope of this spec.
McCool: Question is if we should disallow some variants of the Basic security scheme (e.g., putting it in the Query)
Jiye: Strongly in favor of that, since Basic with information in the query is not RFC-compliant
McCool: My suggestion would be to remove the security section from common constraints and move it under the HTTP Basic Profile
Kaz: think that is what we've been describing by the section 5.4.
Luca: OAuth2 is bound to HTTP so mentioning it in common constraints does not make sense
McCool: If we move the whole section to the HTTP Basic Profile then this problem disappears as well
… need to define some actions based on the discussion we had
… (adds another issue comment)
Kaz: I partly agree, but we cannot avoid thinking about security aspects for other profiles as well and think about common security considerations
McCool: HTTP SSE Profile and HTTP Webhooks Profile are part of the HTTP Basic Profile, so should be able to reuse the security mechanism for the HTTP Basic Profile.
Kaz: Yeah, that's possible. My point is those guys (=HTTP SSE Profile and HTTP Webhooks Profile) also needs some description on security.
McCool: Can someone volunteer to do a PR that addresses this issue?
Luca: I can try
McCool: Great, I'll assign you then
… meeting is on Wednesday, would be great if you could prepare a PR until then
Luca: Any formatting advice?
McCool: Avoid making unrelated whitespace changes or typo fixes
Profile Issue #359
<kaz> wot-profile Issue 359 - Security - open issues
McCool: Not sure if we need to discuss the points mentioned in this issue
… one issue is that NoSec in Common Constraints applies to everybody
… while Basic and OAuth2 only apply to HTTP
… issue #6 was somehow not listed in this issue, adding it
… issue #220 looks similar to #6 and should be resolved at the same time
… let me quickly look at the other ones
<kaz> (McCool updates the list of open Issues around security within Issue 359)
<kaz> Issue 220 - List of required Security Schemes
McCool: issue #224 deals with Webhooks
<kaz> Issue 224 - subscribeallevents security requirements
McCool: so from my understanding, to use Webhooks securely you need to provide some kind of authentication to subscribe to every event, otherwise it is rejected
… during a subscribeallevents operation
… does somebody feel confident to work on this issue?
Jiye: I will take a look
Luca: Does it have a deadline?
McCool: Should be done by next week, want to retire many of the profile issues
Luca: Will also have a look on the issue
McCool: (Now turns to Issue #221)
<kaz> Issue 221 - Security Schemes are too loose
McCool: should also be resolved together with Issue #6
… (looks at Issue #222)
<kaz> Issue 222 - Security Requirements for WebHook Consumer
McCool: will discuss this issue in next week's call
Next Meeting
Jan: Opened two small PRs for wot-security
Kaz: Should define a label for all security-related PRs
McCool: Will have a look on the PRs, but we can do that next week :) and remaining Profile issues next week
<kaz> updated Issue list within Issue 359
[adjourned]