<scribe> scribe: zkis
Will review the previous minutes in the end.
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)
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
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
<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
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]