- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 17 Oct 2018 03:10:43 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at: https://www.w3.org/2018/10/08-wot-sec-minutes.html also as text below. Thanks, Kazuyuki --- [1]W3C [1] http://www.w3.org/ - DRAFT - WoT Security 08 Oct 2018 Attendees Present Kaz_Ashimura, Michael_McCool, Elena_Reshetova, Michael_Koster, Tomoaki_Mizushima Regrets Chair McCool Scribe kaz Contents * [2]Topics 1. [3]agenda 2. [4]review of previous minutes 3. [5]minutes from Sep 10 4. [6]Publication status 5. [7]Object security 6. [8]Security consideration sections 7. [9]Elena's update * [10]Summary of Action Items * [11]Summary of Resolutions __________________________________________________________ <scribe> scribenick: kaz agenda McCool: object security? ... security scheme to handle Koster: need to handle key materials ... tell the system to have key materials ... there are many ways to handle object security ... going to handle some mechanism like handshaking McCool: ok ... (shares the screen) Koster: would get better understanding ... e.g., pub/sub for security ... maybe close to the end of the year McCool: (updates the agenda wiki) ... Object security: COSE and OSCORE ... Security consideration sections: Thing Description (McCool), Scripting API (Elena) Koster: Secure multicast McCool: status of W3C Note publication ... also previous minutes review review of previous minutes [12]https://www.w3.org/2018/10/01-wot-sec-minutes.html [12] https://www.w3.org/2018/10/01-wot-sec-minutes.html [13]https://www.w3.org/2018/09/10-wot-sec-minutes.html [13] https://www.w3.org/2018/09/10-wot-sec-minutes.html McCool: (starting with Oct-1) ... basically looked at issue 118 [14]issue 118 [14] https://github.com/w3c/wot-security/issues/118 McCool: this is where object security came up Koster: JavaScript Object for JOSE as well McCool: (adds JOSE to today's agenda) ... ok ... let's go through the minutes from Oct 1 ... let's add a note here ... object security ... use the title of issue 118 Kaz: ok Signing and encrypting body of actual responses of interaction pattern endpoints ]] McCool: and then ... update from online plugfest ... TPAC schedule ... publication plan ... security consideration for TD ... any other corrections? (none) McCool: ok let's accept the minutes except adding the title of issue 118 minutes from Sep 10 McCool: prior to plugfest ... adding Kaz to the editors list ... wondering if it's ok ... I'm OK with it ... any thought? ... let's talk about this offline ... PR207 ... online plugfest ... best practices document ... btw, any update from Ryo? Kaz: not yet McCool: ok ... now the publication is in process ... would accept the minutes ... any objections? (none) McCool: accepted Publication status Kaz: have been working on TD McCool: can we publish the note by TPAC? Kaz: maybe next week ... anyway, I'll start the initial check so that I can get back to you McCool: ok Object security McCool: COSE, JOSE, OSCORE ... need to look into them ... we should address the standards ... how the payload is encoded ... that is a media issue ... should specify media-type for them ... regular media-type and another one for encryption ... do we combine or separate the security scheme Koster: the way it works ... JS and CBOR or JSON and CBOR, etc. ... similar work done for HTTP ... various ways ... thing to look at is what header option would remain ... regular CoAP processor and payload separately ... options for protected or unprotected ... (refers to rfc8152) ... unicast or not ... having media-type for encoding ... how to specify media-type and sub media-type McCool: could be sub type ... looking at here for CoAP ... COSE encoding ... these parameters and algorithm used ... section 3.1 ... table 2 ... need to read through this draft Koster: don't really know either ... between schema and media-type handling McCool: kind of secure encoding ... you normally combine the other things ... 5.4 how to encrypt and decrypt for AE algorithm ... Koster, are you volunteering to read through RFC8152? Koster: yeah [15]https://tools.ietf.org/html/rfc8152 [15] https://tools.ietf.org/html/rfc8152 McCool: do we have to modify TD at all? Elena: we've indicated security metadata ... but not specified it in detail ... need to go into the detail ... some payload may available even without sign ... not going to be very different ... need new token McCool: maybe a bit different level of metadata ... simply say we need COSE ... third level indicating the parameter ... intermediate level to mention COSE and JOSE ... COSE with possible algorithm Koster: would agree with Elena ... need to see the other systems using similar pattern ... we don't have to provide tags ... can go into the draft and see what is needed ... we may need to invent our own protocol McCool: need common use cases ... for multicasting Koster: URI and scheme ... IP address to be defined for multicast purposes ... maybe like observing, but not sure McCool: observing or eventing Koster: it's listening anyway McCool: we could look into multicast first ... and think about security for that later Security consideration sections <McCool> [16]https://github.com/mmccool/wot-thing-description/blob/secur ity-considerations/index.html.template.html [16] https://github.com/mmccool/wot-thing-description/blob/security-considerations/index.html.template.html McCool: I have something and Elena also has something ... changed the paragraph here ... "In many locales, ..." ... TD can contain personally identifiable information ... normative assertion here ... A thing description associated with a personal device SHOULD be treated as if it contained personally identifiable information. Koster: interesting thing ... move the point on consent ... we're looking at interoperability ... getting beyond that is interesting McCool: there is a question about when to prepare it Koster: interesting but out of our scope, isn't it? McCool: information needed to be accessed ... main point here is what should be normative assertion ... (mentions some example) ... basically we're recommending same category coming from things Koster: makes a lot of sense McCool: only edited the last paragraph here ... informative part and normative part ... seems to be OK to merge this proposal? ... need to regenerate the HTML for TD draft Elena's update Elena: (shows scriptin API draft on her PC) ... 9. Security and Privacy ... specific recommendations related to WoT runtime implementations McCool: 3 categories? ... big paragraph could be split into 3 pieces ... sometimes you don't really need isolation ... trouble is that normative assertion needs statement ... particular cases to be described ... you should expand the statement Elena: ok Kaz: regarding the first bullet. right? McCool: yes ... normative assertion needs to be clear Kaz: maybe safer to use section title with a link to the fragment instead of section number Elena: ok ... the next one ... (second bullet) ... Therefore the WoT Runtime SHOULD avoid exposing the native device interfaces to the script developers. McCool: orchestrating with the other devices? ... the first sentence may be a bit misleading ... need right logics ... may want to say ... have to expose the endpoint ... maybe instead ... avoid directly exposing ... maybe we could add some clarification here ... only required functionalities here Elena: ok ... next bullet ... Therefore, if WoT Runtime supports post-manufacturing provisioning or update of WoT scripts, WoT runtime or any related data, such operations SHOULD be done in a secure fasion. McCool: we'd mention best practices? ... "in a secure fashion" is important ... we need to include a section on security update Elena: ok ... next one ... Therefore the WoT runtime SHOULD securely store the provisioned security credentials, guaranteeing their integrity and confidentiality. Koster: what do you want to test for within an implementation? McCool: the issue is trust of scripts ... dangerous to use untrusted scripts ... this is intentional feature design ... we should emphasize it Kaz: which part to be modified? Elena: additional sentence ... should not expose an API directly access security credentials for WoT scripts Kaz: will you create a PR for these changes? Elena: will do McCool: there is functionality on Thing Directory ... probably we should add an extra point here ... script should not assume ID immutable ... ID may change via transition Elena: functionality to be preserved? McCool: yes ... ID can change ... we should go ahead and generate a PR ... should provide a proposal to the Scripting guys and get feedback Elena: what about testing? McCool: why don't we have an empty place holder section at the moment? Elena: ok McCool: Elena will create a PR to be reviewed ... and I'll update my PR as well [adjourned] Summary of Action Items See [17]the Action wiki. [17] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Actions Summary of Resolutions [End of minutes] __________________________________________________________ Minutes manually created (not a transcript), formatted by David Booth's [18]scribe.perl version 1.154 ([19]CVS log) $Date: 2018/10/10 07:08:00 $ [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [19] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 16 October 2018 18:11:48 UTC