W3C

– DRAFT –
WoT Security

20 February 2023

Attendees

Present
Jan_Romann, Jiye_Park, Kaz_Ashimura, Luca_Barbato, Michael_McCool, Tomoaki_Mizushima
Regrets
-
Chair
McCool
Scribe
kaz

Meeting minutes

Feb-13

McCool: (goes through the minutes)

approved

Profile PR

wot-profile PR 364 - Security http sections

McCool: (goes through the discussion on the PR)

(Luca has some trouble with audio connection)

Jiye: probably should talk about this PR later?

McCool: ok

Profile Issues

Security issues on Profile

Issue 6

wot-profile Issue 6 - Recommended Security

McCool: This is a blocking issue for publication

related wot-profile Issue 359 - Security - open issues

McCool: some of the points are related to Luca's PR
… so let's talk about the latter points

Issue 222

wot-profile Issue 222 - Security Requirements for WebHook Consumer

McCool: the question where the stuff to go

Jiye: yeah
… thought there were another issue on webhook

wot-profile Issue 224 - subscribeallevents security requirements

Jiye: the above Issue 224 is also related to WebHook

McCool: how can we summarize the situation and do we have any recommendations?

Jiye: no actual recommendation yet...

McCool: when I subscribe, register some callback
… and specify using some specific token to be used

Jiye: a bit confused

McCool: WebHook means we'll get some callback later
… two problems here
… how to authenticate consumers
… and subscribing all the events
… however, don't see technical problems here

Jiye: technically, agree
… but I'm not sure if what Ben describes here is really correct

Kaz: given the situation, having multiple issues around WebHook and those issues are getting longer, I'd suggest we clarify people's expected mechanism on how to deal with WebHook a bit more first
… then think about how to describe that later

McCool: yeah
… need to clarify how to deal with the body and the payload, etc.
… also it seems Ege is reopening what we had already concluded again

Luca: do we have any implementations for WebHook?
… to refer to?
… would see the expected behavior
… also do we want to bind some specific WebHook mechanism to ordinary Web security model?
… one of the problem is trying to clarifying multiple Consumers using WebHook

McCool: yeah, that's yet another problem
… let's quickly look at existing standards...
… (goes through the Wot Profile Editor's Draft)

10. HTTP Webhook Profile

McCool: my understanding is this is based on the Cloud Event mechanism

McCool: so need clarification around Cloud Events a bit more first

Jiye: right
… there is no concrete description within the WoT Profile spec
… another problem is how to authenticate the Consumer

<Jiye> https://hookdeck.com/webhooks/guides/what-are-the-webhook-authentication-strategies#signature-verification

Jiye: some information on Webhook authentication above

Jiye: not really authentication of WoT Consumers, though

Luca: is there any specific implementation for that?

Jiye: no

Kaz: so we need a firm specification around Webhook as the basis first, and then we ourselves need to think about what to be done for WoT Consumer authentication via Webhook

<Jiye> https://hookdeck.com/webhooks/guides/webhooks-security-checklist#verify-the-consumer

Jiye: some more resource around Webhook security on Verifying the consumer

McCool: maybe we need some more research
… even though we're under some pressure with the timeline, think we need correct definition

Kaz: definitely

Luca: still wondering if there is any implementation
… also who proposed this approach?
… technically, there could be some good point with using Webhook
… but need to clarify the need and how to handle it

McCool: yeah
… for example, SSE is easier
… but has problem with scalability
… leaving a socket open would be an option, though
… on the other hand, mutual TLS would require authentication on the both sides
… anyway, we need further research on the Webhook mechanism itself

Kaz: agree we definitely need further research on the Webhook mechanism and have a firm basis for our specification

<luca_barbato> cloudevents/spec this is the cloudevents spec

Kaz: maybe we can ask the TAG for help

McCool: right

Luca: FYI, there is a specification for CloudEvents as above

Kaz: there is a link within that document for "HTTP 1.1 Web Hooks for Event Delivery - Version 1.0.2"

HTTP 1.1 Web Hooks for Event Delivery - Version 1.0.2

Kaz: we can start to read those pages but should talk with TAG as well

<luca_barbato> https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/http-webhook.md#4-abuse-protection this seems to be the part that could be expanded a bit

<McCool> https://openid.net/wg/sharedsignals/

McCool: would look into the above document as well

Kaz: we've already started to ask for the wide reviews
… so can ask the TAG and the Wide Review groups for help

McCool: that's correct
… someone needs to read the resources
… the one from OpenID seems to be promising, I think
… during the WoT Profile, I'll mention this issue again

Luca: as put above, "HTTP 1.1 Web Hooks for Event Delivery - Version 1.0.2" has some description
… maybe we can try some PoC implementation as well

McCool: However, Cloud Events itself doesn't handle necessary security for our purposes. right?

Kaz: what Luca is talking about is rather the "HTTP 1.1 Web Hooks for Event Delivery - Version 1.0.2" document and the security section within it
… However, that document might not be enough, and I agree we need further research anyway
… also we should ask TAG, etc., for help as well

[adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).