Introduction of verifiers

[thompson-tomo]

Currently within the sdk we define adapters (convert messages to cloud events) and bindings (maps attributes to transport specific attributes). What I would like to see is the introduction of a 3rd category (verifiers). The purpose of these verifiers is to help guard against tampering.

One such verifier would be standard webhooks https://www.standardwebhooks.com/ hence we end up with complementary standards which a developer can opt in to implementing/using.

Potentially connected to #1302

[duglin]

Hi @thompson-tomo - could you elaborate a bit on what you think a PR would look like? For example, do you see this being more of an SDK change/issue or do you see something more "spec related" being needed?

[thompson-tomo]

Hi @duglin i see this as a spec topic first as we need to have an agreed concept of how to support message verification and that we should in fact be covering it. In terms of PR I see it including an initial specification for leveraging standard webhooks and obviously a basic verifier for cloud events.

A key thing for me being that verification should not be not be looking at properties of the payload but rather metadata & the entire payload. This way the verification can occur before deserialising the event.

In the end I would see the processing pipeline being:

• App Recieve cloud event
• Standardise event data using the correct binding
• Check the message integrity via 1 or more verifiers -> this concept
• Deserialise message into a cloud event using a formatter
• Transform payload to desired structure based on adapter (optional)

Note transmission would be the exact opposite.

Once the spec/concept is agreed it would then flow down to the client/sdk implementations

[duglin]

@thompson-tomo couple of things...

are you on cncf's slack? some folks on today's call were asking because they wanted to have an interactive chat instead of just thru issues

we discussed this on today's call and it still wasn't completely clear what a spec/PR for this would look like. I know we were probably bending the rules a bit with our webhook spec, but for the most part we've tried to stay away from implementation details - at least at the spec level. And focus more on how things look on the wire. SDKs are obviously a different beast.

We've also purposely avoided topics like security because of the rathole it introduces and there are already a ton of security solutions out there that we were hoping people could just apply to their CE flows w/o any CE specifics needed. That's partially why attempts at things like #1330 have failed in the past. We'll see how that one does going forward :-)

Anyway, there was a desire to get a bit more details/specificity around what a PR for this would look like. We definitely don't want you to spend a lot of time writing something that might be rejected, but would it be possible to perhaps give a little more detailed rough outline of what you're looking for at a spec level? For example, I'm not 100% sure what "an initial specification for leveraging standard webhooks" actually means since it sounds a bit like implementation details. Where do you see the need for interoperability (or lack of it today that's causing pain)? Would we be using existing tech or be inventing something new to fill some gaps in what's out there today?

[thompson-tomo]

@duglin please see below answers to your questions.

are you on cncf's slack? some folks on today's call were asking because they wanted to have an interactive chat instead of just thru issues

Yes I am now a member of cncf slack workspace.

Anyway, there was a desire to get a bit more details/specificity around what a PR for this would look like.... For example, I'm not 100% sure what "an initial specification for leveraging standard webhooks" actually means since it sounds a bit like implementation details. Where do you see the need for interoperability (or lack of it today that's causing pain)? Would we be using existing tech or be inventing something new to fill some gaps in what's out there today?

I am big supporter of reusing technology and I would want CE to avoid straying into additional Domains ie security. With that in mind a PR for this would focus on either adding core or extension attributes/fields which is used to transmit the values needed for verifirrs. Also Within the ce spec documentation we describe/link to instructions on how to verification of messages could be done.
The sdk's would provide a flexible way to add these verifies so that they can run as part of the processing pipeline.

[duglin]

@duglin please see below answers to your questions.

are you on cncf's slack? some folks on today's call were asking because they wanted to have an interactive chat instead of just thru issues

Yes I am now a member of cncf slack workspace.

Which one? I see 3 different folks with your name. Perhaps ping me @dug ?

[thompson-tomo]

Just posted in the slack & tagged you.

[duglin]

@thompson-tomo are you able to join one of our weekly calls? It's at 12pm Eastern US time on Thursdays

[thompson-tomo]

It would be difficult as it would be 2am for me.

[duglin]

@thompson-tomo see #1347 (comment)