Previous minutes

<inserted> Aug-17

McCool: I put on the agenda OAuth2 again
... anybody have any comments?

(none)

McCool: ok, minutes will be published

Agenda

McCool: no guest today
... Elena will talk about conexxus
... then we have a bunch of PRs ready to be reviewed and maybe closed
... we also have open discussion topics
... like OAuth2 and lifecycle
... anything else?

Kaz: the agenda section for today had a wrong date, so I've just fixed it. please reload the agenda.

McCool: ok.

<McCool> https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#24_August_2020

Conexxus

Elena: Conexxus have defined a threat model for API designers

Clerley: we actually have three model templates
... one is the current one. Another is the implementation threat model, which can be used to describe how to security is implemented

Elena: how do you know how to be complaint? For example in the different section what would we check

McCool: I think this is for a particular application. I saw this also this in Intel.

Elena: ok, let's continue and see each chapter
... it starts from API description and then use case
... In 4 the template asks to identify resources at risk

Clerley: usually, the template is not used as whole. People chose some chapter and our internal security group review the document

Elena: why do you have different section for assets and data?

David: maybe it is a bug... it is probably redundant
... it helps people think about it more than once

McCool: I was thinking that assets were more physical... but the examples do not match

Clerley: maybe

Elena: next the document talks about the threat boundery
... after that we have API consumers chapter

McCool: is there a stakeholder section

Elena: I think this chapter should be used... but I am not sure

Clerley: this section describes the interaction between systems i.e. payment system --> pump

Elena: inside wot is difficult to fill this document, because we are at the interface level. Probably it might be easier for a particular WoT application

Clerley: I agree some section are pretty specific. I suggest to go back to data section if you are dealing with more abstract usecases

Elena: ok moving on. There is a section about data integrity and finally a logging and auditing section
... in wot we have to think more about logging and auditing
... my final comment about the document is that from my point of view is a bit hard to use

Clerley: you are free to use the document for your needs, feedback is welcomed

McCool: we can use it to feel the threats in wot and create a checklist for usecases.
... about feedback, Elena my add comments to the document. would it work?

Elena: I do not have more detailed feedback on that document

<McCool> https://github.com/w3c/wot-security/issues/170

Clerley: We certainly report what Elena said today

McCool: we can use the github issue (above).
... conexxus personal can have a look there
... the question now is what are we going to do inside WoT?
... I'll create an issue about a security template for wot
... we should at least point to the conexxus document inside our security documentation.
... let's gather more input in the issue
... oliver did you finished the lifecycle review?

Oliver: I made a couple of comments and started the review

McCool: ok thanks

Combination security schema PR

<inserted> wot-thing-description PR 944

McCool: if we make the combination scheme the default, it cleans lot a lot the security field syntax
... However, it might cause compatibility problems
... I laid down a plan to address this change in step
... it is available on the pr/s.
... let me show how the PR looks
... anybody have any comments?

Inline security definitions PR

<inserted> wot-thing-description PR 945

McCool: I think it lacks an example
... I think this week we'll close combination and simplified PR
... any comments on this two?
... ok Ege was happy with it, I'll chage it to ready

Proof chain sections

<inserted> wot-thing-description PR 943

McCool: I think we have to wait a little bit. I'll leave it untill the next week

Reconsider mandatory items for OAuth2

<inserted> wot-thing-description OAuth2 issues

McCool: I am thinking that they should not be mandatory for reasons described in the issue
... ok we are out of time now
... is there any final concern?
... ok, let's close the issue

[adjourned]