W3C home > Mailing lists > Public > public-wot-ig@w3.org > May 2020

[wot-security] minutes - 11 May 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 25 May 2020 17:12:52 +0900
Message-ID: <87v9kkigaj.wl-ashimura@w3.org>
To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at:
  https://www.w3.org/2020/05/11-wot-sec-minutes.html

also as text below.

Thanks a lot for taking the minutes, Zoltan!

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                              WoT Security

11 May 2020

Attendees

   Present
          Kaz_Ashimura, Clerley_Silveira, Cristiano_Aguzzi,
          Daniel_Peintner, David_Ezell, Michael_Lagally,
          Michael_McCool, Zoltan_Kis, Elena_Reshetova,
          Tomoaki_Mizushima

   Regrets

   Chair
          McCool

   Scribe
          zkis

Contents

     * [2]Topics
         1. [3]OAuth2 flows
         2. [4]Lifecycle model
         3. [5]Security issue
         4. [6]Use case review
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: zkis

   Will review the previous minutes in the end.

OAuth2 flows

   Kaz: Note that Cristiano was an invited guest to this meeting
   for the OAuth2 discussion

   Cristiano: we implement OAuth flows for node-wot and those
   require authorization
   ... need to open another page or dialog and need user consent
   ... 2 solutions: leave it to the UA to handle tokens and
   dialogs
   ... the second was to use an API to provide tokens and
   implementation could cache

   McCool: no need involving the UA
   ... there is a redirection, we should deal with that
   ... it is not necessarily in the browser
   ... it could also redirect to a payment page for instance
   ... we should just look at the protocol and implement that

   Daniel: that was the discussion
   ... there are 4 flows in OAuth, one of them is the code flow
   (the one under discussion)
   ... it looks like we don't need the code flow?

   McCool: we should implement all flows
   ... maybe the use cases are not all clear so it's better to
   implement them all
   ... also consistent with OpenAPI
   ... we'll assume we respond at protocol level

   Zoltan: we have the MitM problem with tokens

   McCool: the script will be managed by the runtime
   ... the protocol will manage the requests and challenges
   ... the implementation will have to manage the tokens

   Cristiano: yes, implementation uses bearer tokens

   McCool: bearer tokens need to be protected
   ... we need to study how is it done elsewhere

   Zoltan: look at the Presentation API, Second Screen
   ... the question is should Scripting deal with tokens

   McCool: no, it should be handled transparently
   ... should set up security out of band
   ... we provision security

   Zoltan: fully agree

   Cristiano: how do we do it out of band?

   McCool: provisioning depends on protocols

   Cristiano: I have doubts if code flow applies

   McCool: does not necessarily need to involve a human user
   ... again, let's look at protocol level
   ... it's a bit unspecified
   ... we need a separate API for that

   Zoltan: we discussed that also

   McCool: let's continue in issues
   ... in summary, we should do all the flows
   ... we should not assume the existence of the UA
   ... and we should consider an out of band API

   Cristiano: one of the flows is deprecated, so it's not
   implemented
   ... also, the device flow is getting most momentum
   ... it's and extended flow of OAuth2

   McCool: OK, let's discuss that in the issues, and maybe next
   meeting

   [9]New issue 173 on OAuth2 "device" flow

      [9] https://github.com/w3c/wot-security/issues/173

   (Cristiano leaves at this point)

   (Daniel also leaves at this point)

Lifecycle model

   [10]Elena's diagram

     [10] https://drive.google.com/file/d/1NRDu9I0A5yhBBh3PRWncJXOVNZrDfbt5/view

   [11]Zoltan's diagram

     [11] https://drive.google.com/file/d/1E7dF65r8i1rx5ykJujMYe14RYPOvXAPf/view

   Zoltan: what are the opens?

   Lagally: starting with Manufactured/Decommissioned
   ... describing the diagram

   McCool: in the other diagrams the transitions are labeled

   Zoltan: the purpose for this diagram was mainly the op state
   names
   ... the PR describes transitions in text

   McCool: let's finish the diagram and then have security review

   <mlagally>
   [12]https://github.com/zolkis/wot-architecture/blob/lifecycle/p
   roposals/lifecycle-model-proposal-zolkis.md

     [12] https://github.com/zolkis/wot-architecture/blob/lifecycle/proposals/lifecycle-model-proposal-zolkis.md

   Elena: would prefer is someone else would also review it

   Clerley: could do it

   Lagally: we need the Destroyed state

   McCool: one problem is the arrows between operational and
   maintenance states
   ... another issue is site key vs service provider key
   ... we renamed service provider to site

   Elena: there are problems with "site", it's both specific and
   too general

   Lagally: ok, let's discuss in the architecture call

   Zoltan: will update the diagram following some of these hints

Security issue

   <mlagally> Thanks for putting the lifecycle on the agenda.
   Here's the github issue for the review:
   [13]https://github.com/w3c/wot-security/issues/169

     [13] https://github.com/w3c/wot-security/issues/169

   <McCool> [14]https://github.com/w3c/wot-security/issues/169 for
   lifecycle security review

     [14] https://github.com/w3c/wot-security/issues/169

Use case review

   McCool: in general, for solutions we need to focus on whether a
   solution fulfills the requirements, and if they do, they should
   be fine
   ... for OAuth2, said to implement all flows, but some of them
   maybe are not recommended for IoT
   ... we may actually require also end user intervention, too
   ... we need to look at the use cases

   David: we got permission to donate the threat model, it might
   be useful

   McCool: is it non-public document?

   David: there is permission to publish

   McCool: would prefer to have a copy in the repo

   David: could have a link to it in the repo
   ... could attach it to the issue as well

   McCool: will create an issue for that

   Elena: we'd need to review our privacy and security too
   ... could review the Conexxus document

   McCool: we should also capture the main points in retail.md as
   well

   <McCool> [15]https://github.com/w3c/wot-security/issues/170

     [15] https://github.com/w3c/wot-security/issues/170

   McCool: link this issue to the
   [16]https://github.com/w3c/wot-architecture/issues/494

     [16] https://github.com/w3c/wot-architecture/issues/494

   Clerley and McCool discussing about email on reviewing W3C
   Privacy and Security considerations

   McCool: a PR needs to be done for this

   (actually doing it on github web interface)

   McCool: made the PR, please comment on that

   <McCool> [17]https://github.com/w3c/wot-architecture/pull/500

     [17] https://github.com/w3c/wot-architecture/pull/500

   [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [18]scribe.perl version 1.154 ([19]CVS log)
    $Date: 2020/05/25 08:08:01 $

     [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [19] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 25 May 2020 08:12:24 UTC

This archive was generated by hypermail 2.4.0 : Monday, 25 May 2020 08:12:25 UTC