- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 12 Jun 2018 19:01:01 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:
https://www.w3.org/2018/06/04-wot-sec-minutes.html
also as text below.
Thanks a lot for taking these minutes, Michael Koster!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Security
04 Jun 2018
Attendees
Present
Kaz_Ashimura, Michael_McCool, Elena_Reshetova,
Kazuaki_Nimura, Michael_Koster, Tomoaki_Mizushima
Regrets
Chair
McCool
Scribe
mjkoster, kaz
Contents
* [2]Topics
1. [3]Agenda review
2. [4]Review previous minutes
3. [5]Security metadata PR
4. [6]Follow up on the issue of how security metadata is
used in TD
5. [7]PR #103
6. [8]Security for the next plugfest
7. [9]Actions
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
<kaz> scribenick: mjkoster
Agenda review
McCool: goes through the [12]agenda
[12] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Agenda
review previous minutes
<kaz> [13]prev minutes
[13] https://www.w3.org/2018/05/28-wot-sec-minutes.html
<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> [14]PR 144
[14] https://github.com/w3c/wot-thing-description/pull/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> [15]HTML diff
[15] https://services.w3.org/htmldiff?doc1=https://w3c.github.io/wot-thing-description/&doc2=https://rawgit.com/mmccool/wot-thing-description/security-metadata/index.html
McCool: the main change is in the security section of the TD
document
... want to change from URI to URL
<kaz> [16]5.4 Security Vocabulary Definition
[16] https://services.w3.org/htmldiff?doc1=https://w3c.github.io/wot-thing-description/&doc2=https://rawgit.com/mmccool/wot-thing-description/security-metadata/index.html#sec-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> [17]PR 103
[17] https://github.com/w3c/wot-security/pull/103
Security for the next plugfest
<kaz> [18]McCool's slides
[18] https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/Security-Bundang-PlugFest-Preparation.pptx
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
Summary of Action Items
[ONGOING] ACTION: mccool to talk with security guys about
testing/validation timeline
[ONGOING] ACTION: mccool to work on issue 70 (Require Not
Exposing Immutable Hardware Identifiers?)
[ONGOING] ACTION: mjkoster/elena to review examples in the
security spec
[ONGOING] ACTION: mccool to write a short proposal on what
security tools to use for the next plugfest
[NEW] ACTION: mccool to finish TD PR 144 (Security metadata)
and merge it
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [19]scribe.perl version
1.152 ([20]CVS log)
$Date: 2018/06/12 09:55:56 $
[19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[20] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 12 June 2018 10:02:16 UTC