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> wot-thing-description PR 943 - WIP: Add proof and proofChain sections
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> wot-thing-description Issue 940 - Add optional proof section to TDs
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> Apr-12
<kaz> Apr-19
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]