<kaz> scribenick: elena
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)
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
McCool: no update on PING
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
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]