<scribe> scribenick: kaz

Review minutes

Apr-20 minutes

McCool: (goes through the minutes)
... any comments/corrections?
... any objections?

(none)

McCool: approved

Agenda

McCool: reviews the agenda for today

Lifecycle

McCool: anything to do today here?

Elena: (summarizes the discussion during the Architecture call on Apr. 23)

McCool: discussion on stack of layers
... Zoltan took an action to do that
... having a table listing various players for each state
... relates to other fuzzy authentication

related to Issue 148

McCool: got a comment from Zoltan

Zoltan's comment to Issue 148

McCool: (responds to Zoltan)

McCool's response to Zoltan

Zoltan: (joins)

McCool: we're talking about your comment on Issue 148
... (goes through the conversation on 148)

Zoltan: just wanted to mention Lagally had created wot-architecture issue 476

wot-architecture issue 476

McCool: the issue was that we needed a table of actors
... currently have TD's server authentication
... the point is we need to see the lifecycle before solving the issue

Zoltan: ok
... it's kind of chicken and eggs problem

McCool: we need to narrow the current definition of "Thing authentication"

Zoltan: we need to define identification, then authentication. right?

McCool: good example

Zoltan: make sense to talk about authentication only during the operational state

McCool: right...
... let's talk about this after your updating the lifecycle diagram

Oliver: what is the identification and what is expected after that?

Zoltan: many protocols use similar mechanisms
... some shared key
... we're modeling the abstract lifecycle states

Oliver: comparison depends on the catalog of protocols, addressing scheme, etc.

McCool: e.g., DID, doesn't handle authentication in that way...

Oliver: my expectation is having clear understanding about the components
... then protocols and addressing schemes

McCool: addition of actors to components?
... in general, it's open ended
... need some general principle including the possible future protocols
... would propose we wait one more week until the lifecycle diagram is updated

Oliver: sounds good

McCool: Oliver, I'd like to ask you for advice
... about how to proceed
... on this issue 148

Oliver: ok, will do

Requirements template

Issue 472

McCool: would add security/privacy considerations to the use case template
... eventually, make it included in the Security/Privacy guidelines doc
... Lagally gave comments

Lagally's comments

<McCool> https://www.w3.org/TR/security-privacy-questionnaire/

self-review security questionnaire above

Issue 168

McCool: what we should do is
... to the use case template, we add security/privacy considerations section
... and to the requirements template, we add security/privacy requirements section

Kaz: sounds good

Elena: but what was the original purposes?

McCool: (explains the background)

Elena: in terms the requirements, not only OAuth as a possible mechanism but various mechanisms to be mentioned?

McCool: right
... but as the starting point, we should add a section

Kaz: yeah
... when we add those sections (considerations/requirements), we should think about what kind of features should be added there

McCool: right
... let me capture those points here within the comment for issue 472 or wot-architecture

David: at Conexxus, we have similar problems
... we look at applications in security terms
... the asset to be protected, etc.
... people should worry about

Kaz: do you have any concrete template about that?

David: sure
... let me check

McCool: one possible question to be included is "what are the assets?"
... can you check those questions?

David: let me do that

McCool: we need to have something like this document (self security review) for us

Kaz: maybe we should reuse some of the existing ones?

McCool: yes, we should look into the existing questionnaire and see which parts are relevant to WoT and which are not
... (updates the comments for wot-architecture issue 472)
... I'd suggest we merge a PR for this issue so that we can start use cases discussion based on the new template (and avoid fixing the existing ones with the updated security/privacy sections)
... we need to define schemes and features
... features can be extracted from the requirements documents
... the question is where to put the table?
... probably to the best practices document?

Elena: don't want to create a new document for that purpose :)

McCool: me neither

McCool's comments to wot-architecture issue 472

[adjourned]