Meeting minutes
Minutes
<kaz> Nov-28
<kaz> approved
Schedule
<kaz> Cancellations on the main wiki
McCool: until end of this year, we will have one more meeting
… next week meeting will be canceled and then week after, we will have a meeting
wide review
transitions issue 474 - CR Request for Web of Things (WoT) Architecture 1.1
McCool: TAG review is closed and security review is still opened which is odd
(writing an email to Daniel)
… I am not sure who is responsible for security review and Sam didn't response
implementation reports
<kaz> TD 1.1 Implementation Report
McCool: there are few gaps about certain security schemes
… one is the body security location using json pointers which no one is use that
<kaz> * 95: sec-body-name-json-pointer
<kaz> * 97: sec-body-name-json-pointer-array
<kaz> * 100: td-security-in-uri-variable
<kaz> * 102: td-security-uri-variables-distinct
Jiye: I have asked if there is any update regarding security schemes on Siemens side, and there is no big update. The question is do we really need security schemes in the body?
… there is no difference on security strength if we use TLS/DTLS
McCool: it's about API support. I can implement this part in Java or Python
… for instance, philips hue add security key into URI
Jiye: but this is not secure
McCool: agree but that's how they do
… we need to find an example of using security scheme in the body using JSON pointer and refer to it
<McCool> https://
<kaz> s/331 See also: wot-profile PR 331 - narrowing down oauth required flows/
McCool: seems we don't have client side implementation. only client flow is at risk
… we also have device flow at risk but it's more like device onboarding than authenticating
<kaz> * 131: td-security-oauth2-client-flow
<kaz> * 132: td-security-oauth2-client-flow-no-auth
<kaz> * 133: td-security-oauth2-device-flow
McCool: I more concern about the client implementation
… probably we need to work on the client side implementation
* 232: td-security-extension
McCool: some of the examples are old. we need another example that someone is using the extension. we have to invent a scenario which needs extension, this is kinda weird one
McCool: table is sorted number 282 downward, security, privacy are groupped
scanning security implementation for discovery
* 33: security-bootstrapping-endpoints
McCool: this is simple to handle, we just need to add an assertion.
* 34:exploration-secboot-401
McCool: this is also related to bootstrapping and it's invisible
Jan: there is an implementation pending having this feature
McCool: note that number 33 - 36 are security related
… 137-144 reasonable to have it.
* 142: sec-tdd-intro-if-multicast-required
scanning security implementation for architecture
McCool: most of the things will be not at risk if there is one more implementation
Jan: there is no DTLS 1.3 implementation
McCool: number 51, there is a bit of ambiguous
Jiye: yes, it doesn't need to be now, but it's better to change from MAY to MUST eventually
Kaz: it wouldn't change implementation requirements. right?
McCool: right
AOB
<McCool> https://
McCool: any other business?
(none)
<kaz> [adjourned]