Meeting minutes
Minutes Review
<kaz> Apr-11
McCool: Security and Privacy Considerations for Discovery were merged, but for Architecture the PR is still open
… there are minor spelling issues
… (mentions the progress on a number of PRs)
Kaz: The typo is fixed now
McCool: Propose to publish these. Any objections?
There are none, minutes are published
Security and Privacy Considerations
Discovery PR #295
<kaz> wot-discovery PR 295 - Make Security and Privacy Considerations Normative
McCool: Got merged in the Discovery call
… issue #293 got closed by it
… if you have any concerns regarding discovery, raise new issues otherwise we can consider it done
Architecture PR #734
<kaz> wot-architecture PR 734 - Make Security and Privacy Considerations Normative #734
McCool: This one is still open
… did not manage to continue working on it
… no significant edits regarding normative changes, with the exception of assertions
… as we discussed last time, there is a serious problem with the document structure
… One aspect is the structuring by deliverables
… another one is the mix of problem descriptions and mitigations
… a third one is related to public security information in TDs
… we currently don't allow public keys in TDs
Philipp: One question: Didn't DID also contain public keys?
McCool: DID does, but they also contain information for validating
… DID is currently opposed, 50 different mechanisms for resolution but some are not secure
… can be secure but it is not guaranteed
… in my opinion
… to summarize, public security data should not include public keys
… I'll try to get it done by the next architecture call
… then there will be a feature freeze by May 6
… we can do a review in the next call and then merge on May 5
… are there any more points that should be addressed here?
Kaz: I generally agree with you, Michael, but public keys can be public. Also TD doesn't need to handle the public key directly but it can refer to an external DID document for that purpose. So we should at least think about how a TD should refer to an external DID.
McCool: They would theoretically be okay in a TD
… not allowing public keys is not normative, yet
… we could delete the sentence
Kaz: How TDs should rfer to DIDs should be documented at least. Maybe not for 1.1 specs but for 2.0 specs, though.
McCool: We don't mention them in the TD spec, yet
… we are currently in the clean up phase
… we could say that public keys are only allowed in signed TDs
… should be addressed in the next version, where we should be able to adopt JSON-LDs signing mechanism
… we could also refer to other documents with public keys, as Kaz mentioned before
… DID would be an option but they are not normative, yet
Philipp: DIDs could also be changed in a TD, so there is a similar problem
McCool: At this point we should not open "cans of worms" in order to not be inconsistent
S&P considerations for Profiles
McCool: Is there anything else we should consider regarding S&P considerations?
… there is no section for S&P considerations in the profile document yet
… there is a mentioning of security
… we still have the problem with security in that local networks
… could be added, but might be a bit redundant
Philipp: I wrote you an email regarding security in local networks, should I open a PR with that?
Jiye: Could you summarize?
Philipp: Especially with IPv6 you can let nodes change IP addresses to avoid attacks on DNS entries(?)
McCool: You describe an onboarding mechanism
… there are a lot of points that need to be figured out here
… we should open an issue and put it in the next charter
Philipp: I'll create an issue
McCool: Defining a mechanism normatively might not be possible, unfortunately
… there is a lot of ongoing discussion
<McCool> https://
McCool: Onboarding is already mentioned in the issue for the next charter
… can you add your points regarding onboarding here, Philipp?
… You can also create an issue and link it here
Philipp: Will do
McCool: I just noticed that there is already an issue for security cosiderations in the Profile repository
<McCool> https://
McCool: and also one for privacy considerations
https://
Additional Security Schemes
<McCool> https://
Jan: Extensions are currently not allowed by the JSON schema
McCool: We should probably change the document and schema to allow extensions again
… additional requirements are needed
… One possibility would be to do nothing and simply allow extensions
… we should focus on bug fixes for now, not add additional normative statements
… a broken example certainly is a bug
… (adds a comment to the PR)
… we should rather refrain from adjusting the JSON Schema
<McCool> https://
McCool: current specification is consistent as it says "oneOf" instead of "e. g." for the values of scheme
<McCool> above is inconsistent with "one of" used in https://
Philipp: 1.0 also says e.g. not oneOf
<McCool> also, TD 1.0 uses "e.g.", so using "one of" also breaks compatibility.
Philipp: saying oneOf in 1.1 would break compatability with 1.0
McCool: Change to oneOf was a breaking change, should be reverted
Matter Specification
<kaz> Matter site (CSA IoT)
McCool: Took a first look into the Matter specification
… looks interesting with regard to onboarding
… should align our process with Matter's
<kaz> [adjourned]