<scribe> scribenick: kaz
McCool: turns out that we have to fill out the security questionnaire assessment
<McCool> https://github.com/w3c/wot-architecture/blob/master/proposals/TAG%20review%20request.md
<McCool> https://www.w3.org/TR/security-privacy-questionnaire/
McCool: review request above
... refers to the security/privacy questionnaire
... similar questionnaire for a12y/i18n?
Kaz: no, we can simply ask those groups for review
McCool: ok
... (goes through the questionnaire assessment doc)
McCool: kind of tricky to answer
this
... but they can read this as the summary
... basically, we need their feedback by April 5th
... and submit CR transition request by April 9
... there are 2 weeks
... let's see what would happen
... architecture document 55 pages
... TD document 107 pages
... let's get things done
... (shows Elena's response on TAG review)
... issue with same origin things
... maybe we can develop a sentence
... architecture tf got agreement
... but td tf not
... adding a sentence on the scope would be helpful
... another comment
Elena: recommended usage for security/privacy
McCool: turn of changes
... private security data and public security data
Elena: don't understand subsystem things
McCool: need a system which maintains
the security/privacy
... (shows the updated architecture document)
McCool: high level view of the
architecture
... black bold line means "building blocks" within fig 19
... "public security configuration" within TD
... scripting api should not look into the keys
Elena: maybe just give some example here
McCool: e.g., TPM?
... we could say
... going into the document
Elena: 2nd paragraph in "high-value data" section
McCool: can leave out SGX
Elena: just say "TPM" instead of TPM1 or TPM2
McCool: what "TPM" stands for?
Elena: Trusted Platform Module
McCool: ok
... (commits the changes)
... the other thing?
... put this section here
[[
The situation is unavoidably more complex than the client-server architecture of browsers. A better analogy than browsers would be the microservice architecture used by many web services. The WoT Architecture supports best practices there, such as Zero-Trust networks.
However, to be more specific, here "origin" in the usual web meaning means content from a specific web server, and "access to other devices" would mean from the browser. In the WoT context, "origin" could be interpreted as a WoT Server (WoT Thing in server role) and "browser" would be a WoT Client. In that specific case, there is no way for an arbitrary server to force an arbitrary client to access another device. The WoT Client is in control, initiates
messages, and decides what to do with the responses. Even if we reverse the roles, which is common in the IoT (IoT endpoint devices are often servers) a WoT Server is never forced to do what a WoT Client requests.
]]
McCool: a lot of questions on
"origin"?
... let me steal this
... here we have the background
... (updates the background section)
... Security in the IoT is unavoidably...
... For example, the "same origin policy" is considered of web
security. ...
... In addition, security is often concerned with the "user's
device" or the "user agent".
... (adds text)
Elena: worrying about user data from
one origin
... but possibly multiple data comes from multiple
origins
... at once
... a bank, a service provider and another service
provider
... should explain what "origin" means?
McCool: WoT dosn't support
downloading scripts from somewhere and run it locally
... we can actually have cross-origin scripts
Elena: for web browser context,
everything happens on the client side
... but with WoT context, not only the client side
McCool: WoT does not support downloading scripts and running them on the local side
Elena: browser is delicate example for WoT
McCool: (updates the Background
section)
... would assume engineered systems like micro services
... almost ready to finish this description
Elena: maybe "attack surfaces"?
McCool: (updates the text)
... in the documents above we address the threats and attack
surfaces of the WoT in detail.
... In the following we have answered the questions posted by
the Web Security group as best as we could... but please take
into consideration that most of these questions are not fully
applicable to our situation.
Kaz: points out the self-review questionnaire document is a TAG Note
Self-Review Questionnaire: Security and Privacy
McCool: wonders if the 2 blocks to be
merged
... (and merges them)
... (1) Security in the IoT..." and (2) "For example,
..."
... (and adds a sentence on variety for use interface depending
on the manufacturer)
... (on the other hand, removes the block of [[On the web, the
"origin" means...]])
... next
... question 3.9
... which one?
... "Does this specification allow an origin access to aspects
of a user’s local computing environment?" ?
... the key point here is "allow an origin"
... if we interpret the origin as a WoT server
... the user's local computing environment a WoT Client that
retrieves content from that WoT Server.
... (updates the answer)
... No, in general
... there is no executable content expected in data or required
in the metadata (TD) provided by WoT Things
... If we reverse the definitions, and let the origin be a WoT
Client and the user be a WoT Server, which is possible in same
WoT topologies.
... In general, the answer is still no under reasonable
constraints on system design.
Elena: ok
... misunderstood the question
McCool: no unintended access
... what about the last question?
... there is an option in the WoT Thing Description to specify
alternative mechanisms to access a resource.
... The designer or a WoT Server needs to ensure that the least
secure alternative is sufficiently secure.
McCool: Elena, can you look into this from now?
Elena: can read through it
again
... will send an email when I finish the review
[adjourned]