[wot-security] minutes - 26 February 2018

available at:
  https://www.w3.org/2018/02/26-wot-sec-minutes.html

also as text below.

Thanks a lot for taking these minutes, Zoltan!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                              WoT Security

26 Feb 2018

   [2]Agenda

      [2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Agenda

Attendees

   Present
          Kaz_Ashimura, Elena_Reshetova, Michael_Koster,
          Michael_McCool, Zoltan_Kis, Tomoaki_Mizushima

   Regrets

   Chair
          McCool

   Scribe
          zkis

Contents

     * [3]Topics
         1. [4]prev minutes
         2. [5]NDSS
         3. [6]security metadata requirements
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <kaz> scribenick: zkis

prev minutes

   <kaz> [9]prev minutes

      [9] https://www.w3.org/2018/02/12-wot-sec-minutes.html

   mccool: is the Scripting API frozen now?

   zoltan: yes, last PR has been merged and officially the API is
   frozen on Wednesday

   elena: so security discussions will affect a later version of
   the API

   mccool: are algorithms included?

   zoltan: not yet

   mccool: we have the metadata issues going on
   ... any comments of the last meetings minutes?
   ... looks OK
   ... any objections to accept the minutes?
   ... no
   ... accepted

NDSS

   mccool: added more examples of metadata we could include

   <kaz> [10]McCool's slides

     [10] https://github.com/mmccool/ndss-wot-sec/blob/master/talk/WoT
- S&P - NDSS DISS 2018 - Talk.pdf

   mccool: addressing states, caching
   ... firewalls, network policy, including incoming AND outgoing
   traffic
   ... discussing services, using cryptocurrency deposits
   ... endpoint adaptation
   ... unencrypted headers and encrypted payloads

security metadata requirements

   mccool: in the TD there is a lot of discussion about security
   metadata
   ... Matthias has shared some examples
   ... Scripting API issue #91

   [11]https://github.com/w3c/wot-scripting-api/issues/91

     [11] https://github.com/w3c/wot-scripting-api/issues/91

   mccool: provisioning is out of scope
   ... before exposing a Thing, actually the Thing needs
   provisioning
   ... actually the Scripting API affects the state before
   provisioning
   ... about the example on how does OCF handle security
   ... looked at iotivity
   ... security metadata is kept in specialized resources
   ... the raml files have class metadata, the resources have
   instance metadata
   ... one can access them via introspection

   <kaz> [12]IoTivity security architecture

     [12] https://wiki.iotivity.org/iotivity_security_architecture_overview

   [13]https://wiki.iotivity.org/iotivity_security_architecture_ov
   erview

     [13] https://wiki.iotivity.org/iotivity_security_architecture_overview

   scribe: we have a requirement to expose BOTH patterns
   ... also, looked through OpenAPI security scheme
   ... support API keys, Oauth2 etc
   ... would it be OK just using that?

   (link to be inserted)

   <kaz> [14]OpenAPI spec ver.3.0.1

     [14] https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md

   mccool: will create issues for these

   elena: Matthias suggested to autocomplete security metadata by
   implementation

   mccool: let's start by narrowing focus to operational issues,
   but now we need to broaden the scope to make usable systems

   elena: this is not an operational vs provisioning question
   ... scripts can create new TDs and Things
   ... it is part of runtime state

   mccool: this includes security provisioning

   zoltan: currently the runtime generates the security metadata
   (the TD .security data)

   elena: how does the runtime know what to provision?

   mccool: this automatic provisioning does not work with all
   security deployments

   elena: also the granularity is an issue

   mccool: on OpenAPI they have a global security conf, then each
   resource can override it to a local definition
   ... this will not work with OpenLD
   ... we need a finer granularity than global
   ... the TD spec contains an old example for security metadata
   ... it's an array of objects
   ... each object containing category (e.g. token), algorithm,
   authority etc
   ... context definition is also considered

   zoltan: we need more data coming from implementations to
   determine the right representation of security metadata

   mccool: what if we took the OpenAPI security metadata model
   ... it should be able to represent OCF devices
   ... OCF tends to hide information inside resources

   <kaz> [15]McCool's comment on scripting issue 91

     [15] https://github.com/w3c/wot-scripting-api/issues/91#issuecomment-368476017

   elena: will look into it

   <McCool>
   [16]https://github.com/OAI/OpenAPI-Specification/blob/master/ve
   rsions/3.0.1.md#securitySchemeObject

     [16] https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#securitySchemeObject

   mccool: will put a link to an example in the agenda (wiki)
   ... discussing OpenAPI spec

   koster: MQTT and HTTP endpoints will have different security

   mccool: different endpoint forms will refer to different link
   to security configuration
   ... i.e. define a list of security metadata and link them from
   the endpoint forms
   ... discussing how to represent OCF ACLs in the TD

   koster: we don't need to do that
   ... scope the TD

   mccool: make protocol bindings for all CoAP, but need to figure
   out how security works

   koster: provisioning state and operational state

   mccool: the security section could just say "this is an OCF
   device"
   ... the implementation should encapsulate OCF security
   ... the other way is to open it up, but it's too complex

   zoltan: the minimum information is more than "this is an OCF
   device"; it needs client role, validity period etc

   mccool: let's put OCF aside for now, and focus on what generic
   mechanisms we need to expose in the TD
   ... we need a strawman specification for this
   ... Elena would look into the OpenAPI
   ... Michael McCool work with Zoltan on OCF security adaptation

   koster: how does using OpenAPI vocabulary play out
   ... analyse the different security flows and derive metadata
   ... OCF has the access management service

   mccool: what is the minimum data to bootstrap OCF communication
   ... will do a basic strawman for next weeks call
   ... security metadata will be a list of objects referred by id
   in JSON-LD

   <scribe> ACTION: mccool to generate a basic straman description
   on security metadata

   koster: important is to be linkable

   mccool: OpenAPI metadata has the "flows" clause

   koster: the overall design of OpenAPI seems OK

   mccool: will make an md file in the security github
   ... closing the meeting, any other questions?
   ... meeting adjourned.

Summary of Action Items

   [NEW] ACTION: mccool to generate a basic straman description on
   security metadata

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [17]scribe.perl version
    1.152 ([18]CVS log)
    $Date: 2018/03/05 18:46:32 $

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [18] http://dev.w3.org/cvsweb/2002/scribe/

Received on Monday, 5 March 2018 18:50:31 UTC