Meeting minutes
Prev minutes
McCool: (goes through the minutes)
(approved)
McCool: we got a resolution about PR 145, and are waiting for an additional PR
Farshid: yes
McCool: should add speaker's name for Cristiano's comment
Kaz: will do
Quick updates
wot-security issue 196
wot-security issue 196 - Update security and privacy considerations in Discovery
McCool: we had discussion about that
… Maybe add note about use of object security in unencrypted networks, e.g. .local domains that can't use normal TLS?
… need to talk with Ben about that point
… planning to do some more work on this issue
Canonicalization
wot-thing-description PR 1086 - Add section to define Canonical serialization
McCool: also validation
wot-thing-description PR 1085 - WIP: Add Validation Section
McCool: regarding the canonicalization
… need discussion during the TD call on Wed
… (shows Farshid's comment 3 days ago)
McCool: we could leave this out
… any more to track down?
McCool: what about the default?
… the problem is we don't have information about the original user's assignment
Farshid: can understand it
… but do we mandate it?
McCool: (adds comments)
Farshid: people should be aware any kind of defaults will be removed
McCool: yeah
… The problem is that when you pull things into a database, you will fill in all the default values. Later you don't know whether a value was assigned during import or by the originator. Would only apply to defaults defined in the TD spec, not in extensions.
McCool: (also adds another comment)
McCool: do we need to have a special filter to get a canonical form?
… concerned it's expensive to implement it
… also if the signature is broken, the canonicalization will be also broken
PR 1085
McCool: and then next, validation
wot-thing-description PR 1085 - WIP: Add Validation Section
McCool: we have outstanding points with validation for directories
… any other quick updates?
(none)
McCool: regarding canonicalization...
… (adds some more notes to the agenda wiki)
[[
Pending, items to discuss
Plan B: store original string in directories still an option/safe fallback
]]
Publication preparation
McCool: planning to do Call for Review today
Farshid: thought you sent a request 2 weeks ago
message on editorial updates from McCool (Member-only)
Kaz: to be strict, that message is not a call for consensus for publication
McCool: still need to wrap-up
PR 151 - HTML formatting and editorial notes
McCool: (goes through the PR 151)
Farshid: I've added notes
McCool: (creates a branch, wd-update-candidate, for the next publication)
McCool: the question is it would take two more weeks to get resolution for publication :(
Kaz: if the final changes are just editorial, we can note that and ask the whole group for quick review, e.g., within one week
McCool: (generates a request message and send it to the group)
Issue 149
Issue 149 - Anonymous TDs in a directory
Farshid: (explains his generated issue)
McCool: directory stores legal TD. right?
Farshid: potential privacy issue there
McCool: (adds a comment)
… possibly we can use some auto-generated ID which is used only within the Directory service
Farshid: thought we already had some discussion
McCool: right
Farshid: where to put the ID?
… not associated with the TD itself?
McCool: technically, we could use some key separately from the TD itself
Farshid: would like to see the comments on the issue a bit more
… how to solve the problem if there is no ID available?
… can we improve the signing algorithm?
McCool: I'm ok with generating a tentative ID and put it into the metadata part of the TD
… we can have a chaining mechanism to handle that
Kaz: do we have consensus to have an auto-generated ID, e.g., generated by the Directory, for the system-wide purposes?
McCool: ok to use some local ID
… e.g., could be a rotated ID
… another question is if the local ID should be generated based on the original ID
… but should be discussed separately
… when we specify signing, we can include a "chaining" label to make sure this additional data does not break the signature
… (then records our consensus from the call)
… consensus:
… 1. directory assigns a local ID to all TDs
… 2. this ID can be (optionally) embedded in an enriched TD just like other metadata
… 3. API needs to allow for looking up TDs by local ID (in a URL)
… 4. signatures need to support chaining mechanism that omits enriched metadata
Farshid: maybe we should call it "proposal" at the moment given Victor is not here
McCool: (changes "consensus" to "proposal")
[adjourned]