McCool: should add action items
... issue 69 for elena and issue 68 as well
... issue 70 for mccool
... terminology for elena/koster
... old action for mccool to talk about testing validation
also
... other than those actions, would accept the minutes
(no objections)
Elena: better to see the rendered version?
Elena: section 6.3
... wanted to updated based on the discussion during f2f
... didn't remove the figures
... added a new section here
... proxy case
... we can discuss the terminology
... describing the scenario with client via local/remote
gateways
... currently using "remote proxy servient" and "local proxy
servient" as the terms
McCool: interesting
... non-WoT connection?
... reverse proxy and forward proxy
... very similar to AWS with device shadows
... slightly different
... forwarding messages not creating shadow
... similar but different
... would call this "split proxy"
Kaz: sounds reasonable but we should ask Fujitsu/Panasonic for opinions
McCool: right
... note that quite similar to AWS's shadow proxy
... similar pattern
... the difference is that the state is maintained by the local
proxy
Elena: should we remove "servient" from "remote/local proxy servents"?
McCool: either of them could be a
servient or a client
... different from HTTP proxy
... which is one-directional
... this is not wrong
... need to clarify entire patterns
... tunnel pattern, HTTP proxy pattern, etc.
Elena: the diagrams look pretty much similar
McCool: shadow pattern
... Koster, do you agree?
Koster: not sure if that requires local/remote proxies
McCool: the local proxy here is optional
Kaz: would agree
... the pair of "remote proxy" and "local proxy" is a mechanism
for tunneling/firewalling
McCool: we have this pair to hide the
information
... pretty hard to handle NAT traversal itself
Elena: only difference would tunneling is...
McCool: tunneling doesn't know anything about WoT
Elena: direct communication
McCool: correct
... so local devices are unaware of the Internet side
... but it works fine
... if you intercept all the possible interaction using
proxy
... there are pros/cons with proxy approach and tunnel
approach
... we should create another PR for tunneling
Elena: yes
McCool: highly recommended not to use
powerpoint for the diagram
... SVG tool would be better
... could reopen issues/pullrequests for the WoT Architecture
as well
Elena: and then 6.4
Single-Tenant
... interaction ladder diagram and corresponding TD
... do we have definition?
... how the syntax looks like?
McCool: what you have is consistent
with my syntax
... main outcome so far
... this is kind of lazy authentication
... there is an issue with Scripting API's exposing
... reasonable to have something for security
configuration
... maybe assignment to a number of scripts
... have to look into the details of the script
Elena: you don't know the
detail
... what syntax is right
... what kind of keywords to have
McCool: this (TD vs sequence) itself is not incorrect
Elena: would see actual syntax
McCool: have to review the
syntax
... your security potion is consistent with my proposal
... I'll do one more review
Elena: would be great if you could a figure for tunneling
McCool: ok
... let's move one
McCool: security metadata
... previous proposal presented to the TD TF last Friday
... read through authentication schemes
McCool: goes through the TD
Example
... this example has many definitions
... did some substitution
... had security for map
... changed to this
... no security definition
... just have [[ security: "basicConfig",]]
... equivalent with what we currently have
... that is my modified proposal
... you can have name definition, etc.
... pretty big changes from syntax viewpoint
... the other thing
... added digest
... under "Detailed Specifications of Configurations"
... "Digest Authentication" added
... under Algorithm
... MD5 hashing is not good but used for digest
... Obsolete and insecure ciphersuites are be supported for
compatibility with older services but SHOULD be flagged with
warnings by a validation system.
... also the case
... a couple of things about validation
... added "digest" to "Protocol-Specific Notes" as well
... also updated the References
... e.g.,
https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml
... questions?
... alternate syntax?
... need further explanation?
... can merge this PR so that people can see it
Elena: this one should be
merged
... hard to track the changes...
McCool: time to merge this
... don't be impacted by the change with JSON-LD 1.1
... you could leave out the global defaults
... a couple of features with pre-processing
... but can leave them out
... Koster, attended the TD call on Friday?
Koster: yes
Koster: security notation separate
from JSON-LD
... not built-in
... but would see examples
McCool: shows "SecurityDefinitions"
[[
"securityDefinitions": {
"basicConfig": {
"scheme": "basic"
},
"ocfConfig": {
"scheme": "ocf"
},
"apikeyConfig": {
"scheme": "apikey",
"in": "header"
}
},
]]
McCool: these modeling to be
substituted in
... if we don't mention security at all, security would appear
by default
... or empty array
... 2 level of substitution
... macro level
... or single substitution
... let me clean up the proposal and check in
... maybe could do some prototyping
... the other question
... need to write done some requirement
... to make the definition not redundant
... having a global default would be nice
... the only question might be whether it would be complicated
or not
Koster: interrupt interaction
... API keys as part of the form
McCool: another good question
... what is the purpose of the metadata
... how that would help the user
... in the case of an IoT device, there might not be a
user
... you have to provide information beforehand
... the other general question
... issue tracker
... what is the purpose of metadata
... instance vs type information
... security information is provided as instance
information
... kind of redundant
... what we hav here is
... what would be protocol-independent information?
... particularly, TD guys would nail done the security
definition
... in particular, for digest
... there is encoding for digesting
... boils down to what kind of metadata is needed
... might forgot something but should be able to get 90% of
what to do
... need to think about all the different parameters and what
is needed
... this would be a good start
... so OK with merging this PR for security metadata proposal.
right?
(no objections)
McCool: we should be able to close some of the existing issues
[adjourned]