<kaz> scribenick: elena

Previous minutes

agenda for today's call is at https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf

first looking at the minutes from March 9 https://www.w3.org/2020/03/09-wot-sec-minutes.html

<McCool> typo, rivisit -> revisit

McCool, any comments/objections to accepting minutes?

McCool: minutes accepted

<kaz> (typo fixed)

Virtual F2F minutes - security section

McCool: from virtual F2F each taskforce should check the respectable minutes

<kaz> security session

McCool: we might need to create issue for MQTT brokers
... we didnt get to discuss the lifecycle during F2F
... should be discussed this week at architecture call

typo IETF Aniva -> IETF Anima

<kaz> (fixed)

terminology from ISO --> terminology from IEEE

<kaz> (fixed)

MASA should be expanded to manufacturer authorized signing authority

<kaz> (fixed)

anser -> answer

<kaz> (fixed)

McCool: any other comments, objections to approving security section of F2F?
... no objections, approved with few fixes above

PING issue feedback

McCool: no update on PING

PRs

Looking at PR 828 from wot repository

<kaz> WoT repo PR 828

McCool, this is an old PR which is probably outdated by now

McCool: proposing to close and ask to resubmit with updates

McCool writes a resolution on PR

McCool: any objections to closing this PR?

PR closed

McCool: any PR from Oliver pending?

Oliver: nothing ready right now

McCool: reopening a PR since it belongs to wot repo and not security repo
... we have two PRs from Oliver, what order we should handle them?

<kaz> PR 159

Oliver: PR 159 can be closed without merging
... text has been already moved to a different place

McCool: next is PR 164

<kaz> PR 164

McCool: I have suggested some changes to this PR, but they are not critical
... so we can merge it and cleanup can be done later
... how should we proceed with this?

Oliver: I prefer to update this PR first

McCool: we can then consider updated PR in next week's call

Issues

McCool: let's recap new issues we have
... issue 160 has been discussed with Scripting taskforce

<kaz> Issue 160

McCool is writing the summary from scripting call on issue

McCool: in summary - we need to do PoC first and dont change scripting API right now. We might need changes to runtimes
... our S&P guidelines should provide some recommendations on implementing runtimes to mitigate these risks
... should we close or leave this issue open?
... discovery API does not need changes, so I am favoring closing this issue

issue closed, please feel free to reopen if needed

McCool: issues 161 and 166 are related
... looking into 161

McCool is commenting on 161

<kaz> Issue 161

McCool is proposing to have a mapping in TD for pubkey and didURL

McCool: this requires integrity of TD
... we can define an optional proof section and specify that it is required if TD has "publickey"
... given our timeframe, I propose that it should be part of version 2 of TD spec
... update to TD should be mostly backwards compatible and it is not a correct place

by that time hopefully JSON-LD gets a normative status and we can just use it

McCool: any other comments on this?
... we need to understand needs and usecases for key management
... my action would be to create a new PR to TD spec to define this mapping and also separate PR to create a proof section in TD
... not sure how to make a PR to TD 2.0 (Next) while people still working on update to current TD version

<kaz> Issue 166

McCool: any comments?

Elena: this sounds reasonable, bigger work would be to define practices on key management, revocation, etc.

McCool: we should review proposed JSON-LD spec

to make sure it has what we need

Next issue 152

not a pressing issue

McCool: next issue 165

<kaz> Issue 165

McCool: Siemens is planning to update node-wot to support OAuth2.0
... but when introducing OAuth2.0 there will be flows that do not make sense for an IoT enviroment

but maybe better to support all flows for consistency

McCool is leaving comment on the issue

McCool: I am hoping that by summer we have this as part of TD update release
... any comments on OAuth2.0?
... David do you have any thoughts on requirements that would be relevant here

David: we consider OAuth2.0 as required due to its good security
... OAuth has good methods for key updates

McCool: OAuth2.0 has good reputation, and even if it is not a perfect fit for IoT, it is well known scheme
... consumer does not have to support all the flows of OAuth
... if anyone has further comments, please let us know
... we are almost at the end, let's next week go through F2F minutes and check if we need to open new issues
... anything critical to create right now?
... lifecycle discussion should be moved to arhcitecture

[adjourned]