<kaz> scribenick: cris_

Previous minutes

July-13

McCool: keeping track of who is scribing
... reviewing previous minutes
... check PR 28, ok it was merged
... minutes ok?
... minutes accepted

Review OAuth2 PR against TD

<kaz> wot-thing-description PR 927

McCool: I created the PR about OAuth2.0. it was discussed in the TD call but we waited to merge it to have a final pass today
... In the PR I also updated the ontology
... I added mandatory fields for each flows

<kaz> PR Preview - 5.3.3.8 OAuth2SecurityScheme

McCool: I also added more statements about the usage of the OAuth security schema. I hope it helps

Oliver: I am not sure that both authorization and token MUST be defined.

McCool: we have two separate fields in TD, I am still not completely sure if the two endpoint must be specified

Farshid: I think that we need both

Cristiano: I'll check that

McCool: if authorization and token are kind of redundant we have to state that
... review the PR
... I changed the wot-security ontology file
... we need to be backward compatible.

Kaz: possible feedback on the security note?

McCool: we have to put a note about implicit and password flow being deprecated.

TD Issue 929

<kaz> TD Issue 929 - Multiple OAuth 2.0 flows in security definitions

Farshid: I propose a way to factorize common security configurations

McCool: the problem is that if we have multiple optional security schemes for an affordance ..
... we have create one form for each one
... I think your solution is reasonable
... we probably also add a way to have an AND composition on the security schema
... any other comments?

<inserted> McCool's comment

McCool: ok, now let's go over TD related issue that might have also security implications

TD Issue 901

<kaz> wot-thing-description Issue 901 - Clarifying use of multiple security schemes in the security term

McCool: it looks that in OpenAPI uses OR instead of AND (like our proposal)
... the AND was designed to work with proxies
... we can also have one scheme for authorization and for access
... we might define a different field to state proxy security configuration

Oliver: I think we need both (AND and OR) combination of security schemas

Cristiano: what about we have multiple proxies?

McCool: we have again use cases for OR and AND combination of Security schemas
... the real issue is that the OR combination causes redundancy.
... we need to solve that
... trying to define different option to express ORs and ANDs in a concise way
... one is array of arrays. One problem is that the nesting change the meaning
... Another option can be to use a wrapper object
... honestly it seems a little bit strange. Plus is not backward compatible
... evaluating farshid's solution
... it seems like a linked list.
... finally we could define an "or" in securityDefinitions
... also "and"
... we can do complex boolean expressions with this approach

Cristiano: I like this approach

Farshid: should deprecate security field as array?

McCool: better not, for backward compatibility

Cristiano: do we really need "and" security schema? we can leverage on the array

<kaz> McCool's comment to Issue 901

McCool: you can but if go deeper you need a may to define inner ANDs.

Cristiano: right

McCool: we are out of the time. please comment on the issue with you considerations

TD Issue 923

<inserted> wot-thing-description Issue 923 - How to describe Philips Hue security scheme

McCool: lastly let's go quick on the last items of the agenda. We are going to discuss about that in the next call
... ege provide an interesting example when the key is in the URL. We need a way to express template values
... feel free to comment
... there are also related issues about OAuth 2.0
... also another issue on dynamic TDs
... let's close the meeting

<kaz> [adjourned]