PlugFest template

mccool: welcome back, Elena!
... would like to propose a template on how to handle security
... focus on particular use case scenarios
... and put them together
... what is done/should be done
... [Goals]
... define standard format for plugfest objectives related to security and privacy
... developers should document a concrete scenario
... developers should document both what they ARE doing for their plugvest contribution and what they SHOULD be doing for a practical deployment
... any other agenda items?

elena: lifecycle PR?
... next week there'll be more time
... might be good to discuss this during this call because there are many attendees today

mccool: ok
... and I'd like to hear people's opinions about these points
... [Agents and Roles]
... [Topology]
... [Confidentiality]
... [Integrity]
... [Authorization]
... integrity is about data
... authentication is identifying people

elena: integrity means the data is not touched by anybody
... people may think about different things for those terminology

mccool: need definition
... (adds definition to each section)
... integrity: information is protected from modification, corruption or loss
... confidentiality: information can only be read by the intended (authorized) party

elena: what about the scope?

mccool: the purpose of the template is having one slide for one topic

elena: do we want to think about confidentiality for not only devices but also TDs?
... data can be lack

mccool: [Topology]
... please indicate the major components of your system and mark the security domains and the boundaries between them
... give these regions and boundaries names so you can refer o them in later slides
... identify the types,...
... don't forget meta data...
... [Authentication]
... [Confidentiality]
... (adds) Privacy: how is data related to users' identities protected from unauthorized disclosure?
... [Authorization]
... authorization: what rights are given to (authenticated) users and how are these managed?
... for example, access control lists
... [Authentication]
... (adds example description)
... [Confidentiality]
... adds example
... how is data protected while at rest (if it is)? Ex: Encryption with X
... how is data protected while in transit (if it is)? Ex TLS
... if encryption...
... [Integrity]
... how are systems securely updated? Ex: signed updates
... [Authentication]
... Ex. use certificates, digital signatures
... [Integrity and Availability]
... how are systems securely updated when security patches are requred? Ex. signed updates
... how are systems protected from Deniel of Service attacks? Ex. limit cost of services provided without authentication
... how are compromised systems identified and remedied? Ex. IDS and HCF

elena: any good ideas for testing/validation?

mccool: [Validation]
... (adds description)
... validation: ensure correct operation even when under attack
... how will the implementation be validated? Ex. Fuzz testing, OWASP web penetration testing (for HTTP-based Web APIs)
... we can discuss lifecycle as well

elena: everyone should have wider understanding about lifecycle

mccool: [Goals]
... focus should be on operational phase of "product" but...
... [Agents and Roles]
... users, owners, maintainers, attackers
... [Authentication and Discovery]
... authentication: identify of agents can be confirmed
... how are agents' identities validated? Ex. use certificates, digital signatures
... [Authorization]
... authrization: what rights are given to (authenticated) users and how are these managed?
... [Confidentiality and Privacy]

zoltan: relevant to what we've been discussing for Scripting

mccool: [Authorization]
... who can load scripts into the WoT runtime and define the behavior of Things?
... Ex. The manufacturer
... [Integrity and Availability]
... in a multitenant system that supports scripting, how are the tenants protected from each other?
... [Validation]
... [Confidentiality and Privacy]
... privacy: how is data related to users' identities (personally identifiable information) protected from unauthorized disclosure
... that's the thing to do now
... Elena, do you want to share your screen?

elena: can do so

Lifecycle

<McCool> https://github.com/w3c/wot-security/pulls

WoT lifecycle diagram

mccool: might be a bit confusing
... 2 back loops for installation&commissioning
... as discussed during the prev call, this lifecycle definition should go not to the security document but to the main architecture document

elena: would make sense to have some discussion during the main call?

mccool: resource for the diagram?

elena: checks IETF drafts
... draft-garcia-core-security-06.txt

mccool: state machine timeline here

https://tools.ietf.org/html/draft-garcia-core-security-06#section-3

koster: more about devices
... maybe some definition slightly different
... security bootstrapping

elena: (shows the definition)

https://github.com/w3c/wot-security/pull/63/files#diff-891748290f755794b17216fefa1ba103

mccool: let's call this security provisioning here
... and add a note saying IETF draft calls it "security bootstrapping"
... then "installation" vs "commissioning"
... let's leave terminology out now
... next time we need to clean up the definition
... should explain why we chose our terminology

elena: don't have proper knowledge about the lifecycle terminology...

mccool: will send an email and upload the template
... we can have discussion on the github repo as well

prev minutes

https://www.w3.org/2018/01/15-wot-sec-minutes.html

mccool: don't see anything missing or wrong
... accept the minutes?

(ok)

minutes accepted

[adjourned]