<kaz> scribenick: mjkoster

Agenda review

McCool: goes through the agenda

review previous minutes

<kaz> prev minutes

<kaz> explanation on Linux Security Summit should be added (conflict with TPAC and Elena can't join TPAC)

McCool: more explanation is needed in section discussion TPAC conflict
... remove mention of OASIS

<McCool> mccool: change "one way is Oasis" to "I just have to follow the internal Intel processes"

McCool: minutes accepted except the above tweaks

Security metadata PR

<kaz> PR 144

#144

McCool: comments about OCF security scheme
... removed OCF from the core vocabulary, but the security vocabulary needs to be more open ended
... can we use a custom extension on security vocabulary?

Koster: this is what I meant by extension points needed for both security and forms

McCool: need to explore how to include these as extensions to the core vocabulary
... review individual updates, http diff

<kaz> HTML diff

McCool: the main change is in the security section of the TD document
... want to change from URI to URL

<kaz> 5.4 Security Vocabulary Definition

McCool: removed ocf as a scheme
... oauth and bearer are separate schemes, oauth implies bearer pattern and doesn't need to include the term "bearer" with oauth
... took out the security definitions section
... now the security in lower level constructs will over-ride the definitions in higher level constructs
... examples in the document of over-ride behavior
... same levels, different levels, multiple schemes examples
... multiple schemes at the same instance provide a choice of schemes
... in other words the "or" pattern
... removes security definitions for links
... mechanism for adding a scheme from an external vocabulary
... one issue is that a lot of the terms are defined as strings but should be enumeration types
... more constraints would be good for validation
... how are the constraints applied from external namespaces?
... need a way to add values which makes the validation harder
... its a general problem
... has anyone else reviewed?

Elena: have started reviewing

McCool: is it ready to include in the editors draft?
... any objections to merging with the TD master branch

Elena: what about the security and privacy consideration section?

McCool: some fixed needed
... will do a few more changes and extend the example to show "or" pattern
... need to draft a section for the TD document, after the plugfest
... any other changes needed?
... OK, will make these changes and merge

Follow up on the issue of how security metadata is used in TD

McCool: to know what the pre-requisites are for accessing a thing
... sometimes the metadata are exposed in the protocol
... exposing in TD enables developers to plan in advance
... however there is a tension between class and instance TDs
... security metadata makes more sense in a class TD, and ties into class templates

<inserted> scribenick: kaz

Koster: all of the information put into the TD could be sort of links/hypermedia
... maybe annotations of different levels
... a class template might make sense
... also pre-qualified things
... another stage of filtering
... to choose appropriate security mechanism
... more granular hypermedia mechanism
... there are bunch of differences
... there might be a way of discovery dynamically

McCool: many choices among access points

<inserted> scribenick: mjkoster

McCool: the optimization of having it all in one place may be substantial
... being able to plan ahead

<inserted> scribenick: kaz

Koster: do we need a definition section?
... would see use cases
... going to build a client
... and consider how to use security
... not sure at the moment

MkCool: typed in a bunch of stuff
... 3 levels of things relevant here
... what include in core vocabulary, etc.
... 3 protocols which matter: HTTP, CoAP and MQTT

<inserted> scribenick: mjkoster

McCool: protocols that matter are http, coap, and mqtt
... what are the choices in schemes for these different protocols?
... http has a lot of choices, but maybe CoAP and MQTT are more limited to a fixed set of schemes
... MQTT has basic
... CoAP has DTLS
... what about object security?
... so things that have choice should be included, things that are accepted standards should be included
... the schemes and options we have are probably good enough

PR #103

McCool: please review for discussion at the next meeting

<kaz> PR 103

Security for the next plugfest

<kaz> McCool's slides

McCool: would like to get to a set of concrete objectives
... get everyone to use security as a standard practice
... maybe starting with TLS
... online access to things will drive secure implementations
... focus on basic, digest, and bearer style auth
... protection of a thing directory API, using auth
... there is an npm option that was effective in resolving many of hte issues in node-wot by updating packages
... recommended practices, where should this go?

Actions

McCool: finish PR and merge it
... tools to use
... other ongoing actions from the last minutes
... just the one new action on the PR integration
... meeting adjourned