W3C

– DRAFT –
WoT Security

11 April 2022

Attendees

Present
Jan_Romann, Jiye_Park, Kaz_Ashimura, Michael_McCool, Philipp_Blum, Tomoaki_Mizushima
Regrets
-
Chair
McCool
Scribe
citrullin

Meeting minutes

Minutes

<kaz> Apr-4

McCool: Any objections to publish the minutes?
… no objections

S&P Considerations

McCool: There are two PRs open. One in architecture and one in discovery. Hopefully in an hour we can get it merged.

Architecture S&P Considerations

PR 743

McCool: I need to think about it more and reorganize things.

<McCool> wot-architecture Issue 726 - Review and Update Security and Privacy Considerations

<McCool> wot-architecture PR 734 - Make Security and Privacy Considerations Normative

McCool: I made security considerations normative.
… privacy was also made normative.

McCool: I noticed the definition of private security included keys. We should talk about that.

McCool: The original text mixed the mitigation with the problem statement. We should fix that. A little more work on that.

McCool: WoT Scripting has the problem statement, but no mitigation.

<kaz> preview - 10.1.2 Thing Description Communication Metadata Risk

McCool: I need to work more on this. Asking for review and we can discuss this next week.

Jan: Scripting is mentioned, but it isn't normative. Is that a problem?

McCool: I thought about this as well. It shouldn't be about scripts, instead we should use code.

mm added a comment

McCool: we should generalize this. It should be applied to any code on the device.

McCool: If there is an additional consideration we need to add, we can do that. But maybe in a second PR.

Discovery S&P Considerations

wot-discovery PR 295 - Make Security and Privacy Considerations Normative

McCool: I haven't added Philipps point yet.

Philipp: I am not sure if that is fixed yet. I haven't looked too deep into the RFC.

mm adds a comment to PR 295

<JKRhb> RFC 9000 QUIC Address Validation

McCool: The Amplification DDOS only applies to open networks. This isn't clearly defined yet.

McCool: I can use a TLS connection to get a public key and establish a secure local connection.

Philipp: This sounds like there should be already an existing solution, or even standard.

McCool: Yes, exactly. I have to take a look into this.

<kaz> McCool goes through the section "8. Security Considerations" from the preview

McCool: I have thought about mentioning OpenID for the auth.

McCool: If you have any comments, please add them to the PR.

Update terms and references in Object Security section 32

Jan: It's a minor PR. I just removed OSCORE, since it doesn't exist anymore. Removed also some unused references.

McCool: I would like to get it in a better shape and publish it as a group note.

McCool: Any objections to merge this PR?
… no objections.

Home Assistant

<kaz> Home Assistant REST API

McCool: I have played around with Home Assistant. Trying to convince them to add TDs for the devices they support.

McCool: They use bearer token, but no TLS.

McCool: I want to fetch the data from their API and give out a TD.

<kaz> Matter (formally CHIP)

Kaz: Home Assistant reminds me of a matter. Maybe we can look into recent approaches including these guys (=Home Assistant, Matter, etc.)/

Jan: Is there an internal format which could be converted to TD?

McCool: Not really. It uses a ingress db internally.

Philipp: Couldn't you add some plugin, read the db and expose a TD?

McCool: Yes, they have this and you could. The internal API isn't documented well. So, I have to reverse engineer it.

Jan: In the context of Zigbee. There is this project Zigbee to MQTT. You can plug in into HomeAssistant.

McCool: Let's pick up this discussion in another meeting. We should close the meeting.

<kaz> [adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).