- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 28 May 2020 22:44:08 +0900
- To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at:
https://www.w3.org/2020/05/18-wot-sec-minutes.html
also as text below.
Thanks a lot for taking the miutes, David!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Security
18 May 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#18_May_2020
Attendees
Present
Kaz_Ashimura, Clerley_Silveira, Michael_McCool,
Oliver_Pfaff, David_Ezell, Tomoaki_Mizushima,
Elena_Reshetova, Zoltan_Kis
Regrets
Chair
McCool
Scribe
David
Contents
* [3]Topics
1. [4]Approve minutes from 11 May
2. [5]PR #172
3. [6]June F2F planning
4. [7]Conexxus Merge
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<kaz> scribenick: dezell
Approve minutes from 11 May
<kaz> [10]May-11 minutes
[10] https://www.w3.org/2020/05/11-wot-sec-minutes.html
McCool: (creates a new issue for OAuth2 flow)
<kaz> [typo fixed]
<McCool> [11]https://github.com/w3c/wot-security/issues/173 -
insert in May 11 minutes
[11] https://github.com/w3c/wot-security/issues/173
<kaz> ACTION: kaz to add a link to issue 173 on OAuth2 to the
May-11 minutes
RESOLUTION: accept minutes for 11 May - but add link to issue
#173.
PR #172
McCool: closing PR #171 without merging.
<McCool>
[12]https://pr-preview.s3.amazonaws.com/w3c/wot-security/172/41
66672...OliverPfaff:39d8e12.html
[12] https://pr-preview.s3.amazonaws.com/w3c/wot-security/172/4166672...OliverPfaff:39d8e12.html
Review section 7.
Focus on section 7.4 end-to-end security.
<McCool>
[13]https://pr-preview.s3.amazonaws.com/OliverPfaff/wot-securit
y/pull/172.html
[13] https://pr-preview.s3.amazonaws.com/OliverPfaff/wot-security/pull/172.html
Oliver: people tend to think that end-to-end security is
absolute.
... it's not a fixed thing. You need to know assets, how
they're used, and what technologies you use to protect them.
... so "end-to-end" might be different things to different
people.
... examples in this section call on classical security
practices - CMS, TLS, IPSec, MACsec
McCool: we should really add references to each of these
technologies.
... also, the technologies are used at different levels of the
stack.
... we need some indication of what that level is for each.
Oliver: Second part addresses the data itself.
... if you have to do your own security scheme at the data
level, classical offerings are second best.
McCool: we've been looking at signing TDs, and maybe using
DIDs.
... we should look at using JWS for signing.
Oliver: for signing objects, the first plan is to use JSON
specific encrypted/signed data.
... there has to be a good reason for expressing an "alien"
syntax.
McCool: in "discovery" we were talking about directory
structures, and I think we created an issue somewhere, maybe in
"security," #166.
<McCool> [14]https://github.com/w3c/wot-security/issues/166
[14] https://github.com/w3c/wot-security/issues/166
McCool: (reference 7.4 in the Security document)
... if we have some LD proofs, getting the TD from the
directory should leave proof that it hasn't been tampered.
Clerley: a big part is a mechanism for protecting the keys.
Should we give specific consideration to keys.
... My experience is that this is a hard problem.
McCool: let's hold that and create a new topic.
... I think this comment should be linked to directories.
Oliver: XML Signature had 3 ways of expressing signatures.
... JWS is less complex. Enveloped is not supported directly.
... detatched, enveloping, and enveloped.
(end digression into "signing")
McCool: any objections to merging #174?
(hearing none...)
(Note: merge shows everything changed - must try to remedy
offline.)
McCool: so Clerley asked if key protection should be in scope.
... question is "what is standardizable."
Clerley: not so much management, but protection.
Elena: you'll have to use OS provided means to do the
protection, so it's hard to predict.
McCool: some systems do a good job of strong key protections,
where you'll never handle the keys.
Clerley: are there assumptions that only known OSs will be
used?
McCool: we have security and privacy guidelines.
... we don't force certain things.
... we could say "you should" in certain cases.
... we also have best practices.
... this last is "if you were building a device today, do
this."
<McCool>
[15]https://github.com/w3c/wot-security-best-practices/blob/mas
ter/index.html
[15] https://github.com/w3c/wot-security-best-practices/blob/master/index.html
McCool: recommend you review best practices and add
suggestions.
Clerley: OK.
David: important to tell people what to worry about, even if we
don't give a prescription.
McCool: agreed. Making Clerley and assignee for this issue.
... issue #170.
<McCool> [16]https://github.com/w3c/wot-security/issues/170
[16] https://github.com/w3c/wot-security/issues/170
McCool: we can make informative recommendations.
June F2F planning
McCool: we need to come up with a short list of topics.
... part of the meeting should be driven by issues.
(adding topics to Wiki)
Kaz: we will have some presentations tomorrow at the AC
meeting, and it might be a good opportunity.
McCool: I'm trying to figure out how to have a constructive
discussion.
... next meeting let's add 4 slides for this topic.
Conexxus Merge
McCool: we should discuss further in the architecture call.
Adjourned.
Summary of Action Items
[NEW] ACTION: kaz to add a link to issue 173 on OAuth2 to the
May-11 minutes
Summary of Resolutions
1. [17]accept minutes for 11 May - but add link to issue #173.
- [DONE]
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [18]scribe.perl version 1.154 ([19]CVS log)
$Date: 2020/05/28 13:40:11 $
[18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[19] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 28 May 2020 13:43:37 UTC