W3C

- 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


<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

New issue 173 on OAuth2 "device" flow

(Cristiano leaves at this point)

(Daniel also leaves at this point)

Lifecycle model

Elena's diagram

Zoltan's diagram

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> 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: https://github.com/w3c/wot-security/issues/169

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

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> https://github.com/w3c/wot-security/issues/170

McCool: link this issue to the 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> 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 scribe.perl version 1.154 (CVS log)
$Date: 2020/05/25 08:08:01 $