- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 24 May 2021 18:26:01 +0900
- To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at: https://www.w3.org/2021/05/03-wot-sec-minutes.html also as text below. Thanks a lot for taking the minutes, Cristiano! Kazuyuki --- [1]W3C [1] https://www.w3.org/ WoT Security 03 May 2021 [2]IRC log. [2] https://www.w3.org/2021/05/03-wot-sec-irc Attendees Present Cristiano_Aguzzi, Kaz_Ashimura, Michael_McCool, Oliver_Pfaff, Philipp_Blum, Tomoaki_Mizushima Regrets - Chair McCool Scribe cris_ Contents 1. [3]agenda 2. [4]minutes 3. [5]td signing 4. [6]minutes review Meeting minutes agenda McCool: I would discuss about signing requirements minutes kaz: same problems with w3c server, it is very slow McCool: ok let's skip the minutes review and do it next time td signing Philipp: I have the wiki opened McCool: do we need anything from it? McCool: ok skipping McCool: The signing mechanism that I have in my PR does not heavily rely on canonicalization. it uses just for stability <kaz> [7]wot-thing-description PR 943 - WIP: Add proof and proofChain sections [7] https://github.com/w3c/wot-thing-description/pull/943 McCool: #943 is based on obsolete information. we should close it … I would like to gather some requirements from people … and start working from them kaz: btw W3C server is now live again. McCool: ok then let's review the minutes in the last 10 minutes McCool: a signed td is object security … we do not know about any system using object security … so we lack implementation information and we need to figure it out … another point is that TDDs want to add metadata to a TD. This creates a problem cause it changes its signature. … but most metadata is easly recognizable cause it will use its tdd namespace … the problem is that id could be added by TDDs … and it's no easy to recognize this condition <kaz> [8]wot-thing-description Issue 940 - Add optional proof section to TDs [8] https://github.com/w3c/wot-thing-description/issues McCool: I would follow the ld proof pattern … so that each proof is in a chain and the latest contain the previous ones McCool: finally there is the issue about canonical form. … I am afraid that we missed little different serialization details that could lead to different strings breaking signinig … in the end we need a key value store to return the original string … kinda a fallback plan if something breaks the signature … the canonical form just make signing more robust but with the current proposal is orthogonal to signing. McCool: about algorithm I would use something based on JWS … we should pickone <philipp proposing an alogrithm> McCool: I am thinking a single chain Philipp: you could make an hash tree, signature every property … so you could check which affordance has changed McCool: I am not sure how it's different from a single chain Oliver: are we looking at json web signature? McCool: yes Oliver: there's also xml signature … it has some flexible feature McCool: yeah JWS is very simple Oliver: We have different options for signature formats: JSON, XML and COSE McCool: I think we should go for a concrete proposal mccool writing a proposal in 940 McCool: with the proposal we could keep track of the used vocabularies and sign metadata … furthermore we could create a chain of different signing pass (e.g., td<- thing description directory) cris: in context are we using urls or just prefixes? McCool: good point … the TD would have prefixes and it might be safe … rdf databases preserve prefixes … we could have both McCool: then we can have another simpler method … the signing order is give by the appearance in the list. … this second proposal is similar to ld-proof Oliver: I think it is a good proposal considering that jws is lacking feature that we need (like signing pieces of information) … in xml signature first you hash each object and then you sign over the hashes. It's one document - one hash - than hashes with signatures McCool: we could use json pointers but data may move and it's not robust … so the xml strategy is to have a manifest with parts and then sign each part Oliver: right McCool: we could do the same in the proposal Philipp: your proposal embeds the signature inside the TD, there might be usecases where the signature is pointing to a TD or part of it McCool: if the signatures are named is simply to refer it … but with pointers we could use array indexes … however it might be a problem cause indices might chages Philipp: I was thinking about putting the signature on a chain … and pointing back to a TD McCool: I noted down the point, plus how this would relate to DID and VC? <Zakim> kaz, you wanted to ping for minutes review minutes review <kaz> [9]Apr-12 [9] https://www.w3.org/2021/04/12-wot-sec-minutes.html <kaz> [10]Apr-19 [10] https://www.w3.org/2021/04/19-wot-sec-minutes.html McCool: there's a typo in the title is canonicalization … I don't understand one line attributed to me, please delete it … are we ok with these minutes? … ok minutes approved McCool: adjourned <kaz> [Apr-19 minutes approve; Apr-12 ones to be reviewed next week] <kaz> [adjourned] Minutes manually created (not a transcript), formatted by [11]scribe.perl version 131 (Sat Apr 24 15:23:43 2021 UTC). [11] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 24 May 2021 09:26:08 UTC