- 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