W3C

- DRAFT -

WoT Security

31 Aug 2020

Attendees

Present
Kaz_Ashimura, Michael_McCool, Clerley_Silveira, Cristiano_Aguzzi, David_Ezell, Oliver_Pfaff
Regrets
Elena, Mizushima
Chair
McCool
Scribe
clerley

Contents


<inserted> scribenick: clerley

Reviewing meeting minutes

McCool: Meeting minutes for Aug, 24 2020 approved with one correction.

PRs for TD

McCool: Topic review what is in the TD.

<inserted> PR 944

McCool: Recommending that combination security scheme be merged.

<kaz> PR 945

McCool: Requesting review for "Simplified inline security definitions"
... To assign it to Cristiano
... Add proof and proofChain still a work in progress. It will not be merged this week. Needs to be review.

Reconsider OAuth2 mandatory items

<McCool> https://github.com/w3c/wot-security/issues/181

McCool: Issue with making authentication/authorization items mandatory.
... How to deal if what the device returns is different?
... Making the scheme optional and decide when to make the changes to the TD spec. Is it reasonable to make it optional.

Cristiano: If user does not know the Authentication scheme. The device would have to make a post request to the server to find out.
... For that reason, it should be mandatory.
... Understands the point. It should be dynamic.

McCool: That is a discovery challenge.

Cristiano: Should make it optional but recommended

McCool: The reason to leave the Authentication in the TD is so that the device can get the access token to make sure it is authorized.
... Are there use cases where we should not add the authentication server to the TD? If there is, it should not be mandatory.
... Added more information to issue 181
... In practice, how often would you want to change the authentication server?

Cristiano: Does not think frequently.

McCool: No clear cut case to make it optional or mandatory.
... Existing schemes must be mandatory for backwards compatibility.
... Version 2 can break backwards compatibility and we can make it optional.
... keep it asis now, and apply the changes to v2

Cristiano: Agrees. That is a good plan.

McCool: Marked issue 181 as deferred.

Directory Security

McCool: Discuss it in the discovery call. Thinks OAuth but, he is not sure what scheme to use.

Lifecycle Review

<inserted> Issue 169

Oliver: Looked at the issue and left a comment.
... Walking through the comments.
... Thinks RFC8576 already has good information.

McCool: Is surprised there is no citation.

Oliver: We should be consistent. Suggestion: Even if there is a reason to make a state machine transformation, it should be consistent with the RFC.

McCool: Make relationship to RFC8576 explicit.

Oliver: Make differentiation between "Consumer WoT vs Industrial WoT"

McCool: Who is the user? Industrial vs Consumer. For consumer, the data must be deleted. That does not make sense for industrial devices.

Oliver: It is a complicated discussion. Even if an industrial WoT component the data created by the device is owned by nobody.
... From a legal perspective, if you go to court, one cannot debate it. It is unusual to call it user data.
... It will raise questions for some people.

McCool: The life cycle is supposed to give stakeholders an opportunity to manage their data.
... In Europe, consumers have an option to request that their data be deleted.

Oliver: His suggestion is to call it data. The data can be attributed to different kinds of stakeholders.
... In Germany, it could be defined by mutual agreement.

McCool: Would like to define it operationally. During operation, certain data is accumulated in the device. The life cycle can reset the state back to manufacture and delete all the data.
... Define user data operationally as data that has been added to the device after it becomes operational.

Oliver: Thinks that is a good concept. Depends on what the system is, it may or may not contain consumer data.
... There is data that must be added to the device when the device is installed. He thinks defining the data that way makes sense.
... Operational vs Installation vs Consumer Data.

McCool: Probably need another lifecycle to define how the data is used, removed. That would address privacy concerns.
... The current lifecycle is correct!
... Could installer data be PII? Thinks as long as the data can be destroyed, "we" should be ok.

Oliver: Agrees, thinks the lifecycle allow for the removal of all data.

McCool: Thinks that should be explicit. All the data can be removed.

Oliver: Display issue with the "reset" state. It looked like the actor had to do something. The Manufacture has nothing to do, it was a little confusing the way it was displaying things.
... Has to provide functionally that would support bringing the device back to manufacture state.
... Will review his comment 4. The comment is incomplete.

McCool: A consumer can buy a device but it needs to use the cloud.
... For that reason, there is a need to differentiate device from the service.

Oliver: Thinks there are both cases, the consumer owns the device but, it relies on somebody's else service.
... And in other cases, there is no service required.

McCool: A user could be the owner and the service provider.
... It is easier to talk about roles.
... Thinks the word "role" should be added to every mentioned. User role, service provider role...

Oliver: Agrees! That way there is no need to make assumptions.

McCool: Would like to bring up the issue in the Architecture meeting. Would like to create a PR to close the issue.

Adjourn.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2020/09/07 12:11:23 $