W3C home > Mailing lists > Public > public-wot-ig@w3.org > May 2021

[wot-security] minutes - 3 May 2021

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 24 May 2021 18:26:01 +0900
Message-ID: <87tumswkie.wl-ashimura@w3.org>
To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at:

also as text below.

Thanks a lot for taking the minutes, Cristiano!



      [1] https://www.w3.org/

                              WoT Security

03 May 2021

   [2]IRC log.

      [2] https://www.w3.org/2021/05/03-wot-sec-irc


          Cristiano_Aguzzi, Kaz_Ashimura, Michael_McCool,
          Oliver_Pfaff, Philipp_Blum, Tomoaki_Mizushima





    1. [3]agenda
    2. [4]minutes
    3. [5]td signing
    4. [6]minutes review

Meeting minutes


   McCool: I would discuss about signing requirements


   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
   … 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
   … 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
   … 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
   … are we ok with these minutes?
   … ok minutes approved

   McCool: adjourned

   <kaz> [Apr-19 minutes approve; Apr-12 ones to be reviewed next

   <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

This archive was generated by hypermail 2.4.0 : Monday, 24 May 2021 09:26:09 UTC