<scribe> scribenick: kaz

TAG submission review

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)

security/privacy assessment

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)

updated architecture draft

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.

Next steps

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]