- 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:07 UTC