<kaz> scribenick: clerley

Meeting agenda

Farshid: Some concerns about OAuth2. Will add to the agenda.

Prior meeting minutes approval.

<kaz> Aug-10 minutes

Reshetova: Had an issue accessing the Conexxus Threat Model template.

Meeting minutes for August, 10 2020 approved.

McCool: OAuth2 PR has been merged. Created a few issues.

TD PR on OAuth2

<inserted> TD PR 927

McCool: Would like to clean up the OAuth2 security scheme. Would like some feedback from the group.
... Create a new issue related to the device authorization element.

Farshid: For consistency, "device authorization" should be camel case.

McCool: Discuss the issue during the TD call

<McCool> https://github.com/w3c/wot-thing-description/issues/953

Cristino: Would like to discuss validation of variant records.

McCool: Created a issue and linked to an issue defined in "Scripting"

<McCool> https://github.com/w3c/wot-thing-description/issues/954

Other TD PRs

<kaz> TD PRs

McCool: Would like to assign some reviewers to PRs.
... Does not think they are ready yet.
... Looked through the proofChain. Listed some issues.

<kaz> TD PR 943 - WIP: Add proof and proofChain sections

McCool: Extension should specify the context file.
... Normalization of the TD spec. For some things, order of types do not matter. But for others, it does.
... For proofChain, order must be preserved.
... Need reviewers for PR 943.
... Worked with "Linked Data Signatures" to improve their spec. Does not think the spec is clear.

Farshid: Thinks both can be defined as array. If order does not matter, an array can be used.
... During initialization order matter.

McCool: Explicitly called proof set. For sets, order does not matter.

<kaz> TD Preview from PR 943 - 5.3.1.1 Thing

McCool: 5.3.1.1. needs to be reviewed. The text related to arrays is not correct.

<kaz> Diff

<kaz> Linked Data Proofs

McCool: TD spec section 7.1 must be updated. Currently not clear. It does not provide enough information.
... Should discuss with Task Force.
... "LD Proof" PR needs more detail to handle all the options.

TD PR 944

<kaz> TD PR 944

McCool: Created a PR "and/or". Decided to use "anyOf" or "allOf" to follow the proper terminology.
... Farshid to create an issue.

Farshid: If flagged then it can be deprecated in 2.0

Cristino: Why define a scheme for anyOf and allOf.

McCool: Would like to add an example.

<FarshidT> example for security combination: https://github.com/w3c/wot-discovery/blob/71612e81f987ba43f6943f9fd542d15492bcefdb/directory.td.json

Farshid: Shows example of device flow and code and a combination.

Cristino: Would like to link to example. That way the preview can be displayed directly from the PR.

McCool: Agrees with the suggestion.
... Added example to PR with multiple security schemes. No need to make up name for "things"

Farshid: If you would like to make it compact, create an array with the flows and remove the existing data type.

<kaz> McCool's comment to TD PR 944 including an example TD

McCool: The spec will allow for an string, security scheme or an array. if we just allow array then, it becomes string or security scheme.
... That would have to be changed in version 2.0.

<kaz> Diff from TD PR 945

Farshid: Concern about how to mandate oneOf or allOf. Why not define in the JSON schema?

McCool: Has not changed the JSON schema to account for the changes. JSON schemas are non-normative, there is no standard for JSON schemas.
... Similar issue with the variant record.

<kaz> TD Issue 955 - Better validate "oneOf" choices

Directory security

Farshid: Does not think the token needs to be mandatory. None of the endpoint is needed, the back-end software will swap the authorization token and get the access token

McCool: please raise an issue about that

Adjourn