Cloud Native Computing Foundation Serverless Working Group, 15 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CNCF Serverless Working Group 2020-10-15

Description

CNCF Serverless Working Group 2020-10-15

A

Hey everybody. Sorry, oh wait a minute! I did not create the next section. Wait a minute. I could have sworn.

B

This is really weird hello there, simon here, hello, you know what I did I modified hold on.

A

I put today's after last week's so hold on a minute. I apologize I'm just coming off another meeting that I was presenting and that's why I didn't get a chance to do this beforehand hold on.

A

All right that was simon. What is your last name again like I apologize.

C

uh Simon from sap, okay.

A

I'm gonna try to admit that. Do me a favor. Can you edit that um for me, when you get a chance, if not I'll figure it out later.

B

I'll write it in the chat. Thank you very much.

A

Tommy, are you there yo, daniel hello, hello, uh ginger.

D

Good morning afternoon, whatever time.

A

Whatever good, whatever, yes, I like that, all right, hey, jim, hey, all right, amel, hi, hello, uh scott, hello, timmer,.

B

A

Hello, hello, uh kristoff.

E

A

Hello and uh who.

D

Was it lance said he.

A

Wasn't gonna make it uh bye.

E

Hello, clemens, hello, sorry for being three minutes later so.

D

A

uh Thank you, simon all right we have a I. I really struggled to find uh topics for today's call. um In fact, we have no prs to review, um I wasn't sure which issues to discuss so I'm looking for you guys to help fill it out or we can end really early. One of the two.

F

I like free time.

A

Yeah, I'm not talking about it, I'm so hungry.

A

B

E

I see I need to go and create more work.

A

Yes, I think we all need to create more work for us, um mario, either.

A

Mario matthew, klaus.

G

Yeah hi doug, hello, oh close.

A

So clements are klaus, picking on you for being german here. How would you pronounce his name matthew.

H

A

Okay, thank you.

I

Which is french but okay, okay, well,.

A

J

Like he says he doesn't have sound.

A

Oh you're, a thank you, I think, look at the chat. Thank you. There we go. Okay, we got him all right, it's three! After did I get everybody. Oh slinky, you there.

I

A

All right, let's go, then see how quickly we can end this thing, uh just a reminder: if you have an ai, um please look at when you get a chance anything from the community that people want to bring up, no okay cool. uh We do have an sdk call this week. I last time I checked there wasn't anything on the agenda. Let's just quickly check yeah. We have nothing there.

A

So if you want to do something, um go ahead and add another section for today's agenda, otherwise we may not have a call um where's it going next. Oh yeah, okay, discovery interrupt next week. Call, I don't think, there's anything been updated in the discovery doc. So please, if you are planning on doing something there help fill this out. It's on my to-do list as well.

A

I think the more important thing at this point in time is for everybody to actually start coding more than anything else. The way I kind of look at it is once you get the base infrastructure in place. The rest of it should be easy. Hopefully, so please start coding that way. You can find errors in the spec and try to get those ironed out before the proposed interop on november 2nd, which is only a couple weeks away, all right and tim or anything from the workflow side of things you want to mention.

K

um Yeah we from the specification side, we had an agreement that we added um the use of open api for service supplication definitions.

K

We also created a couple of training type of videos that uh mostly for just a community, but also we will use them for kubecon and just overall cubecom this year we have a project booth and that doing that this intro in toronto is that what it's called thing is just it's a pain, so putting a lot of hours into that.

K

A

Okay, any questions about the workflow stuff.

A

Okay- just let you guys know um since he mentioned it, we did not sign up for a booth. um However, I did sign this up, for I think it's called office hours um I have unless I missed it. I have not seen the sign up sheet for when the office hours might be. When I get that I'll look for some message on the slack channel, because I suspect.

H

A

I'm sorry go ahead.

H

Sorry, I can follow you to you that email.

A

H

J

Yeah, you should have gotten it. You know I actually had a problem with this. I haven't said anything to cncf, but last time we had to express interest and then once the deadline was over, then they opened the calendar. It seems like this time as soon as you responded, they opened the calendar to you. So there are a lot of times that were gone already by the time.

G

So I responded.

J

On monday and a lot of wednesday was completely gone already,.

A

J

What do you guys think yeah.

A

If you could for me the email, obviously I missed it, I've been getting so many emails from them. I just I'm starting to phase it out.

A

So if you can send me the email, I'll look for some times and maybe just grab one and if it doesn't work, we can always adjust, but um I don't anticipate it being difficult. Last time we had very few people show up, uh so we just need somebody to you know warm bodies in there is probably all we need. I think most questions should be easy, so all right all right with that, let's keep moving forward. As I said, I couldn't we have no prs to look at issues. I picked out just a couple.

A

I thought might be interesting. Let's pick on this one first, since that one got a little bit of traction over the last couple of days, so just to refresh everybody's memory, this one is really about um the spec says.

A

Basically, uh if a property exists, it has to have a value leave that leave out extensions for a minute because there's a hole there, but for all the spec properties. You can assume that if the property exists, there will be a value there. It will not be null at least that's what the spec kind of leans towards, but this issue is really about.

A

Is that really what we want, um and so let me pick on jem and klaus, since you guys commented the most recently on this to get your opinion on what we might do with the situation. If anything so jim, you want to go first and give your opinion on this, not really, but I will, I guess.

L

um Yeah I mean when, as I read the spec it doesn't, it doesn't to me read like we support nulls and I wouldn't expect to receive an attribute with no value. I I think my bigger concern is, if you do, um how do you are we meant to propagate that through all the different transports yeah? So if we were, you know going to send a null attribute over http. What would we put in the header for that you know? Does it then make everything more complex?

L

You know because it might expect the word null in in a header attribute. That was only expected to be. I don't know a number, um so I think it it sort of is a bit of a deeper issue than than it might appear, but I would lean to not allowing or explicitly saying that if, if an attribute is defined, it should have a value.

L

A

uh Klaus did you want to chime in here, since you commented.

G

Yes, so basically I I agree to what jem said, so it just would like to emphasize that it's not about the empty value. It's about the null value of the discussion, so uh I I realized that most of the standard context attributes also state that they shouldn't be an empty value. But that's, I think, a different topic so um and I agree that that transporting null explicitly would be then a challenge for each and every protocol, binding and format. So that's also what I wrote here.

G

I propose that we treat null as the same as not present, but I guess we would then have to make that more clear in the type system and then in some of the formats like for json, where you can then distinguish null and not present, but I mean undefined and now that this would mean the same for.

A

Us, okay, so just comments before I get to. I just want to ask a clarifying question because jem correct me wrong, but you seem to indicate you wanted the spec to be more clear to say we do not support null but klaus. You start off saying you agree with jem, but then you ended with. We should allow both but be clear that null is. The same thing is not present. Well.

G

I I say that either we allow it and treat it as the same or we don't allow it at all and um yeah. Okay got it. Okay, pretty much the same. It's just a subtlety of what would be easier for the the sdks and for handling of json in detail, and here would also rely on on feedback from the sdk implementers.

G

A

Okay, thank you for the clarification. Okay, clemens. Your handles up.

E

uh I would like to to support what claustro said um which or what he writes there, because I um uh null values. I don't think we allow them anywhere, but if null appears then that's um some, especially for json, some serializers serialize out null.

E

If the um object is not present and if you have a um a strongly typed structure which you might have first for for a cloud event, then um you know you fill all the values that you want to go and fill in, and you omit the ones that you don't want to set and those that end up being null right in java or in c sharp or other languages.

E

And if you happen to have happen, to use a serializer that wants to go and serialize all those values with null values really on the wire. Then then that's what it is right. So so I I that's so I think that means then that there is no value, because nobody said it.

A

Okay, thank you, scott, your hands up next.

F

What do folks think about trying to limit this to just the json binding, because I think trying to figure out what this means for http structured encoding is kind of weird.

E

That's fine with me, I mean this is something that I I think this makes sense to define in the in the encodings.

A

I was going to say: does that mean? Are you implying scott, that this isn't a core spec change, but rather a transport change.

F

Yeah, it's a it's a change to the http binding for only structured events. It's it's a.

E

G, it's a json format change. I would even argue.

F

Oh, yes, sorry! It's it's for json! Only.

E

Yeah, which applies.

F

E

Yeah, if the value is not set, then we would not map a header.

F

But there's no expectation that the that the shape of that is lossy or sorry lossless if it goes from, say http structured to binary to structured again you don't you lose that information, that there was a nil.

E

Yeah because the field wasn't there in the beginning so, but is the case I just want to want to make not too complicated for for the uh for the innocent is, if I mean literally, if you code up a poco type right and you grab just grab a grab, the serializer and the serializer is that its default is to not emit the values but to to write them out onto onto the wire as now. Then, um then, that's what you should that. That's the situation you're in and I'm.

E

So I'm not sure we should make it really difficult for those folks who want to go and express a cloud event as a strongly poke was probably a type poker type in their in their app. um It should not be hard for them to write compliant um cloud events either way.

F

Yeah this this seems like iot, might care about this.

E

I I'm currently um having a side job, helping a soccer professional soccer club, their I.t stuff and then so. I'm dealing with developers who are just doing dynamics every day, and that is um calibrating my uh perspective. I would say for how complicated it can be to deal with jason. So I'm I'm I'm a little um disillusioned. I would say.

A

Okay, well, jim, I know your hands up, but I think my name was the first. Let me just ask my question: it's kind of what I tried to say here in my chat. I I'm wondering well, I understand from a straight geeky spec perspective.

A

It probably would be good to add some clarifying text here and I think, scott, your suggestion of trying to limit this to just the adjacent stuff probably makes sense and just a heads up, I will be looking for a volunteer in a sec, but the reason I raised my hand was I'd like to better understand why this matters at all, in the sense that, as the receiver of this, what would someone do differently, whether it's present in the ce or not present in the ce?

A

I'm sorry present in the ce, with a null versus not present at all? What would the? What would the receiver do differently between those two cases.

F

Well, the go length one would not blow up. Is the change because, right now, if you send it a nil value, no quota is just nil onto a string. It doesn't know how to decode that that's custom.

A

Wait uh back up a little I'm confused. What can you talk about an optional property java? Would the golang john I'm sorry yeah? The golden jason parsons will blow up with a nut with a null yep.

F

A

It doesn't work.

F

You can't uh turn a a struct that has a string, and you say inside the json version that I'm marshaling into this struct it uh it doesn't know how to turn a the value null into a string. It just blows up: okay,.

A

So you need this on the go length side, because you need to know whether you need to have specialized logic or treat this as an air. Conditioner reject the cloud event right.

F

That's right and.

A

F

Because of this, some of the test grid pieces don't work with the go, laying sdk.

A

Okay, that helps thank you, scott, okay, jim.

L

I think your hand is up next. uh So for me I guess it's. You know. What's the expected behavior of an sdk, I mean if, if an sdk receives format with a nil- and I say to it, is this attribute present?

L

Is it going to say yes or is it going to say no, I'm going to get a different answer? If that was subsequently, I don't know marshalled, you know as a binary through um http, because that header wouldn't be there, so it just. I think it's just going to lead to you're going to have to provide guidance to sdk writers as to how they're expected to handle this situation to get a consistent application.

L

um uh Semantic of sort of dealing with stuff.

A

Okay, scott, your hands up; hopefully, to answer that yeah.

F

So I think from my side integrators never asking questions about the original payload they're asking questions about the the converted nominal form of the event, and so in that case I think it ends up being the same. If, if something was set to nil, the parser understands that that should just ignore it and not set that value. So I think you end up with the result. The resulting exact same object after a marshalling.

A

All right, slinky your hands up.

M

Yeah, I'm just thinking that in the case of uh the sdks I'm working on so both sdk, rust and sdk java, this requires changing the main apis, because then we because now the assumption is only there is something there isn't anything and if anything is null or not present, it doesn't make any difference for the interface itself. So this this will require changing the stuff.

A

Okay class, I think your hand was up next. uh Oh wait. I'm sorry were you done slinky, no.

M

No, no, if I can add something to be honest, I I'm not even sure how should I, for example, model this in a rust. Like I'm saying, I'm saying one language, but I have I have no real. I have no real idea. How should I model this in rust? I mean uh what happens when it's not present, and what should I say when it's surprising. What should I say when it's not so the language doesn't give me the ability to to model the null. In fact, it just gives me.

F

M

Ability to or to say, there's something or there isn't anything.

F

So I think clemens point is that the martial arts sees no difference between something that was not present and something that was null correct.

E

Yeah, that's that's right, if you so in the case in the martial art and also someone who's looking at as a strongly typed object in in java or in c sharp or any any type language that they see, no difference between whether you sent now or or and meant to set null or whether the object is absent. It's it's semantically, identical.

A

Okay, I'm not sure who um I guess slinky, that those answers are directed towards you. Does that help or do you need more clarification.

M

No, no, I'm fine with that. I'm just saying that uh I I think it we shouldn't have this difference at the apa level, if you understood correctly the what's the discussion here: where are the discussions going.

A

Okay, uh klaus, I think your hand was up next.

G

Yeah so a remark: if it's just about the json format or also the main stack. I think the main spec has this ce type system and also mentions that there are canonical string representations.

G

So maybe some clarification there that there is no representation of null in that type system could also have.

B

Okay, um simon.

C

I think your hand was up next yeah thanks, so I just wanted to point out one use case where nile is actually different than being undefined or and that's, for example, if you send patch requests or use the json merge patch semantics, and there now basically says if you know this property and you have a value for that, you need to remove it. So it's in.

E

That case yeah, but we don't have that use case.

C

Yeah yeah and remember from mime type nav yeah.

F

This is only for the the envelope properties, not.

J

F

And so you could still do that same patch semantics inside the body, payload.

C

Okay, sorry, then, I missed this yeah you're right.

C

A

I can't remember why I raised my hands all over it.

A

For everybody to hand that out did did you or did you guys already talk or was there something else you I just wanted to know those hands are old. Basically,.

A

Okay, I'm going to assume they're old okay, so I think what I'm hearing is add language to the json. Only spec. Well, okay, two things, add language to the json spec, to make it clear that null and absent are the same klaus. You were thinking that we may need to add something to the main specs type system section, um but I think those are the scope of the possible changes. We've talked about so far.

A

What do people think about those two possible changes? In particular, I wanted to pick on jim to get your reaction.

L

Repeat what I'm having a reaction to.

A

What would would you be okay with us changing the json spec to make it clear that absent is the same as null.

L

So would somebody then change the json schema definition? We have to reflect that. I'm not sure if that would be needed as well.

N

I don't know, let's see what the json schema looks like.

A

um Let's find one that's empty over here.

L

So at the bottom you need to go down to the actual definitions, so I can't see data death is the only thing that we currently have to find. That is allowed technically to be null.

L

All the other um attributes don't allow now, as it's currently schematic if people are using this and schema jenning code, chaining off.

A

It so would it be horribly incorrect for us to say that this was just an oversight, and this is more like a typo change by because we need to add null to all these up.

L

Here I think it's yeah, I mean that's what it would be. It's just a mission.

A

But would would you be okay with that direction because you you.

L

Have concerns? Well I mean it's just if we want to allow stuff to be null, then we should define that it's allowed to be known. I guess that's all I'm saying.

A

Okay, okay got it.

C

Okay, uh simon, your hands up yeah, so um yeah I'm just getting into this, but um I don't see so if we say now providing null or is the same as not providing it the same, then we could just um disallow null at all and we would get the same behavior and don't have to change our contract. Basically,.

C

It's just adding that it's already defined in the json schema that now is not allowed. So basically, it's just not worded out.

B

Okay, scott, I think you raised your hand for this.

F

Yeah, I think the issue that we've run into is that if you, if you write a database, that's cloud events enabled the database has no ability to omit null values. It'll send them out. As the attribute.

F

Correct this, this is intended for um dumb producers and smart consumers. I think.

C

Okay, so if the producer is dump ass and there's no mapping being done, it's directly exposed.

F

Yeah, it just directs serial serializes, the struct that it has and if it sees no value it, it literally writes the null value.

C

Okay, thanks for the context.

A

Okay, I remember now, when I raised my hand- and I think it was because of what jem said earlier- is there's no way for a consumer then to distinguish between not present and present with null, and it gave me flashbacks to um to looking at query parameters in golang right because you can use the methods.

A

um I think it's. The query object to actually just you know say give me the value and there's no way to distinguish between empty string versus the the uh the property. Wasn't there at all. You know, probably not there at all. It's always going to return every string. If you want to actually find out where the query parameter is there, but with no value you have to actually go. Look at the the the map itself to do that, and it just got me wondering, and I know scott.

A

You said that most people don't never really need to look at the original cloud event itself, they're, looking at more what the semantic meaning is later on down the line, I I wanted to poke on that a little not to say that I think it's wrong but more to make sure we've thought about this, because I am worried about somebody coming along and saying you know what I my my sdk does not shield the user from anything.

A

They basically show them what it was basically on the wire for the most part, and I want to make sure that we're not going to close off use cases where someone says you know what I really do need to know whether the whether the thing was present with null versus not present at all. For some reason, I just I would be sure we're not missing some use case here.

A

Anybody think of any reason why someone actually might give a crap as to whether the property was there with null versus not at all.

F

Given that the guidance is that these attributes are meant for uh routing and uh maybe a tagging of some sort of event- and it's not the payload itself, it's a, I think, you're- probably doing it wrong. If you you're expecting the existence of some nil value, especially because the spec says it must be a min length. One we're doing a special case here for serialization between wire format and conical form.

A

Okay, I'm okay with that answer. I just I just get nervous, but okay, I I would prefer it if we kept them if we made them the same. All right, I'm aligning with you guys just want to make sure we're not missing something.

A

Okay, I don't see any other hands up any other points on this before I ask a very painful question:.

F

Okay, I want to do it doug I want to do it.

A

You answered my question. Thank you, scott. Are you serious.

F

A

All right, excellent! Thank you. Let's see if I can get back to the issue.

B

F

Unless someone wants to fight me for it, I doubt that.

A

All right cool! Thank you, sir. I appreciate that. Okay, um one whoops, I can't type okay um yeah. These were there mainly because they were there last week.

A

um The only reason I kind of kept this one on whether epoch should be global or not is because of the conversation you and I had scott during last week's call where we were talking about this, and I was then we got into the the discussion point about how uh if we made this change, it's gonna really really make it hard when you start syncing up between discovery, endpoints and we then kind of landed, I think in a position of well.

A

Maybe we shouldn't talk about that and leave that as either exercise for later or it's someone else's problem, but our initial job should be to focus on how to make a single individual discovery. Endpoint work well, okay, and so what I want to do is to bring back up this issue to say two things: one is is that where everybody's head everybody else's head is at and that for now we should focus on just a single discovery, endpoint, and if so, what do people think about this issue within that scope and just refresh everybody's memory?

A

This issue is talking about how, today, in the spec, the epoch value is basically localized to each individual service, there's no correlation whatsoever between epoch values across services.

A

This is proposing to make that to to change that, to make it so that every single time, a new epoch value needs to get assigned to a service, it's globally incremented or it's globally made a lot a larger value with that, and what that enables is for us to query the system and say give me all services that have been updated since a particular epoch value, okay, and in order to do that, you have to have something that spans all services.

A

Okay, so I guess the question for the group that I have is two things one is: are we okay with right now, focusing just on single discovery, endpoint making that as good as possible and two?

A

What do people think about this feature?.

F

Is it worth it? Anybody want to take care, I think you're asking for uh an atomic incrementer. Yes, and I don't think we can do this like.

A

F

Don't think you.

A

Can mandate this that that is kind of what I'm asking yes, but, but if you think about it, you you almost have to do the exact same thing anyway, on a per service level. Don't you.

F

Yes, on a per service level, you do, um but only for the produce, the services that you produce. That's the key difference elaborate on what you mean by produce.

F

So if you, you are in charge of reporting, x, y and z services, those are yours, but you also accept an aggregation from some other downstreams or upstreams. You don't control those epochs. You control only x y and z,.

A

It's interesting, you say it that way, because the spec doesn't make a distinction between who owns a service. It's the discovery. Endpoint just has a list of services, and my assumption has always been.

A

I may get a put request for any of the services in there and then the discovery endpoint increments, the epoch, for whatever service you targeted, have no notion of ownership is what I'm trying to say.

A

Is that something we need to add.

F

Or roll back the put until we actually need it.

A

Interesting comments you came out with me: did you want to say something.

E

uh No, it wasn't intentional.

A

Darn: okay, um if we roll back the put, how do we standardize uploading.

F

I don't think you do, I think it's a poll model only.

A

B

F

We need to go through the the interop event to actually see if these are problems or not. Okay,.

A

Because, okay, I mean we, could I don't. We don't want to resolve this today. We definitely can wait.

A

I I am kind of confused, though, by your statement of a pull model, only so even even bootstrapping a discovery endpoint should not be done via something like a put to you.

F

No, I think you do it out of band from the ati it's right. It's like it's it'd, be like the zoo keeper config that you're in charge of these downstreams or upstream sorry. I always get the up and down streams, part wrong.

F

I like that, we don't have to define the api for the mechanics of all of how this works. It could be up to the implementer's discretion here.

A

That is true, like.

F

A

F

Sorry go ahead, maybe their bootstrapping process is, you know, pulling from some central config or a database or uh some other like service discovery, endpoint or an api endpoint.

A

So in the but it- but you did mention earlier that the case of a discovery endpoint being sort of some sort of aggregator um and to me whether that's a push or a pull model to get the information into the aggregator.

A

um Does it not seem still useful for somebody who's querying that discovery, endpoint to say, has anything changed since a particular time.

F

To me, the the discovery endpoints that push data to downstream to their downstreams kind of breaks the eventing model, because now the the discovery endpoints understand the topology of this wacky system instead of each node, knowing where it wants to pull data from.

A

No, I'm sorry, it wasn't clear. I wasn't thinking about the what's changed from a sinking of discovery. Endpoint perspective. I was actually thinking more about from a client perspective. Right. I have a. I have a an application that presents some services to a user, so they can maybe choose one right and but periodically. I need to query the discovery endpoint that I hooked up to to know whether I need to update my ui right with a new list or you know, call the list down because things vanished.

A

It would seem valuable to me, as the author of that ui, to be able to query the backend system, meaning the discovery endpoint to say what's changed since the last time I talked to you.

F

Yes, you could do that, but I don't think that the I think that's a different value than this epoch. That's probably a single other epoch value for the the shape of your catalog and and then that could be global for that service. But it's just journaled entries that come from other.

A

Places, okay, and so, if we had a, if we had that other epoch value you're saying, then it would be an internal implementation choice to figure out how to map that global epoch, value to um which services have been updated. Since some value of that global evoc, io.

F

Yeah some somebody else chime in here, but I think we do this. We could do this with the the cache key. That is a header, a standard header for like cdns.

A

Interesting anybody else have an opinion on this.

A

Does anybody else see value in being able to say what's changed since a particular point in time.

F

I do I just don't think it should be the the that epoch value, we're talking about for the service property. Okay, fair enough.

C

Okay, simon your hands up yeah, I agree with scott, so um I'm also at a similar problem implementing discovery and we decided to go with the cache con, basically an e-tag as a solution for finding out if content changed and versioning. uh If you need to have the really the details on it, but we we weren't considering having epochs and logical clocks for this, because eventual consistency would be okay for basically getting a synchronized state.

C

A

All right I'll tell you what that that helps. So, thanks for the discussion, uh scott and simon, um let me go back and rework this, um because you made some good arguments there, scott, and I think you, I think you convinced me that yeah separate value would be probably uh better and easier to implement and maybe even safer. It's okay! Let me go back and rework that. So thank you.

A

Anybody else any comments on this before we move away.

A

Okay, um the only other thing on the list I thought might be interesting was this one, because I don't know whether I don't remember where we landed on this one? Does anybody remember what what, if anything, you want to do with this one? Here's the the original thing, because I had this vague recollection that we may have said it's out of scope for us.

O

um I can help you refresh that yeah, okay, yeah, please yeah, that's correct, so we thought that it's probably not the best fit right now and we would. We basically said that we'll revisit this concept in future, but not not for now for sure.

A

Okay, would you be going to add a comment to the issue stating that yeah sure I could cool? Thank you very much. uh Scott. Your hands up.

F

I thought we also said that uh we would consider it as an extension, like an official extension.

O

Yeah yep, I agree with that as well, but but I think we need to address the concept of extensions in general before we uh think, or we classify anything as extension right so that entire topic is open right now or is it not? I don't know well when you say do, can you elaborate a little on what you mean by um deal with extensions, so the extension fields we we still have to discuss on? How do we want to handle the concept of extension fields within the specification right now or do we already know that.

A

O

Okay, that's something I know is not affair.

A

Yeah, basically, extensions appear as top level attributes.

O

A

F

And and they have their own specifications.

A

Yes, that is true, too hold on. Let me refresh everybody's memory.

E

Those are the that we have there's an extension section in the main spec. Yes, uh yeah.

F

The extensions.

N

F

Main spec is the mechanism that we use to allow those like. Well. Those extensions are the official sanctioned ones by the cloud events providers, and the intention is that those are interoperable. You can also add your own, but make no uh expectation that anyone's gonna understand them.

E

That's right, but, but just so specifically on this one sorry, I wasn't paying attention for two minutes. um The the workbook spec is effectively mandating. The same is building on the same mechanism that http itself builds on, um which is the authorization header and is not trying to invent anything new.

E

um So so the authorization header is defined in what 72, 34 or 35, um and that's the exact mechanism that we're that we're building on and then what the spec says. What the spec says is that it's assuming some uh some token-based scheme, even oauth 2, which is you know the most widely uh used framework that we all use for for web for web authorization, um makes makes no firm, has no firm mandate for using jots or not, um but it leaves you open which of the which format.

E

The token has, because the token is really a an agreement between the issuer of the token and the consumer of the token, none of the parties which are sitting in the middle should care about the token, because the token is really opaque.

E

It doesn't matter whether it's a job or not.

E

So if you look at or2 oauth2 will will have, has extensions that tell you that it's a it's a jwt, but it doesn't ultimately for the relationship between the issuer of the token and the consumer. Of the token, um the the the party, that's actually putting the token into the into the message, doesn't need to know what format that token has.

A

So help me out here: clemens: are you suggesting that we don't need to make a change and.

E

I I think I think that the spec as it stands is, is um we're not we're not um inventing anything beyond um what http prescribes, and I don't think we should. We should invent anything beyond what http prescribes it's 32, it's 30 to 72 35.

E

A

So you're suggesting that we don't even need an extension, no.

E

Because because that's the webhook spec is an extension of our http binding and really defines how you deliver a a cloud event via post to a particular endpoint. So it basically is a constraint on the http binding http binding allows you to bind the cloud event to any http message, whether that's a request or a response, and and doesn't care about which the what the the method is for for web hooks. We need to have something: that's a bit more specific for delivering events out in a push fashion.

E

The web hook, spec is kind of um um sitting. On top of that, so the it it spec that spec gets becau is specific about using post and also referring to um a security mechanism.

E

But it's referring to the security mechanism that is defined in um rfc 7235 and then also points to off to um as the as the framework around it. But I don't think we need to have anything special because that that that authorization header is not expressed in the cloud event. It's out of band.

A

Okay, sky, your hands up.

F

I think the thing that I'm considering is um it would be nice to have this. You know, go through some other cue of some other protocol and then land it still uh with a proof of origin to some uh target web hook.

F

So how do we make this lossless through uh protocol transformations.

E

Oh so you're you're you're asking for something else: you're asking for a um for a signature for the cloud event.

F

Right like the same concept, and it gets projected into http as the standard mechanism. But it also can become part of the conical form of the cloud event so that we can.

E

Convert it to something.

F

E

We've we have discussed this, um so we generally have discussed the the problem of of both encryption and signature for cloud events, and several of us here have been around for a while and have seen the ship of soap sync over w security um and the brutal complexity that it has, and so we have decided to scope out um in basically message level security, both signature and encryption from cloud events, 1 0.

E

That was a very conscious uh um decision, um because we exactly w star evolved into c star, because it it turns out that um uh you know so probably wasn't a terrible idea. Until all the security stuff came around where people then started building, you know tls on top of w star and all it was terrible. It was not the xml scott, so we've we've decided to punt on this, the but you're you're, already kind of hinting at something. That is um probably a good path, and that is s mine.

E

Where I can. I can see that were that we would create something that allows um uh cloud events to be encoded with s mime and that that s mime packets can then be routed. So that's that's. Ultimately, I think where that might land, but we have, we have decided not to tackle that problem.

A

Okay, uh manuel your hands up.

H

Yeah, I think we pretty much summarized where we got to uh last week, but I just wanted to raise that this was about really the signature or it has evolved into this. uh Originally, it was based really on the authorization header, but I think the use case would have been to um authenticate with somebody further down the line.

H

So if you communicate through a web hook with an event gateway- and that is that event is propagated to a consumer, then the consumer has no means to check whether the message, the event, the content had been messed with. So this is, I think, where it came from, and uh I don't think that the authorization header here helps s mime. Yes, sig message, signature, maybe also, but as fm would that work across all transports of cloud events.

H

E

We so if we decided that we wanted to create an s mine binding for um for cloud events and if we then uh made effectively a a binary pass-through of the cloud event um through the infrastructure.

E

I can see that working, um but it's something that we have to go and spec out. So I'm I'm. So as as things stand right now, the the cloud event would probably not translate.

O

Okay, uh nice, your hands up, I I don't know it's probably kicking my ocds into action, but uh somehow does this feel wrong to have something as sensitive as authorization part of the standard spec I mean even as an extension yeah. I don't know it might be. Just me, though,.

E

But that's that was the point. That was the point. It's like that we're referring to it, um we're referring to rfc 7235, effectively and say that's http's problem and then we're referring to oauth and saying and saying yup how you acquire a token go. Go, look, go look here! We don't want to go and define anything related to security here, but we want to go and effectively just refer to existing mechanisms and then on the point of of authenticating it down against against a downstream um uh entity.

E

I hear that a lot um like amongst plumbers. I have to say I don't. I never hear this from customers, but I I hear this a lot from amongst plumbers as a as a alleged scenario that needs to be supported.

E

I'm not sure it's real because most of the messaging systems that I that I'm seeing are um effectively surrounded by gatekeepers and if you're allowed to put a message into the system, then and and the system supports routing, then the system will effectively um you know, route the message to whatever the destination is and having having a system which kind of routes you four hops and then the message kind of stops at one at one gate where it says ah the message can't pass here.

E

I agree that that's a theoretical scenario, I'm just missing the the real scenario for it.

O

Yeah, but, but I do also see the point what's caught brought in like, for example, what, if you really want to propagate it, feels like this down. The protocols like this is a very http specific thing, but what if it's some amqp client is you know it needs this particular value?

O

So do we really need to think into that direction that how do we propagate such sensitive fields across protocol is it? Is it really part of our business.

E

What you can't do is you can't give an intermediary the keys to the castle to a downstream uh entity, because nothing, nothing prevents that intermediary for from then from then reusing your credentials.

A

Okay, so I'm trying to figure out what's the next steps here I mean nothing or guidance or what I think clements you're, suggesting nothing and close the issue right.

A

I believe this is solved.

F

Well, clemens, how do you deal with? uh Let's see you have these guards in the pipes and stuff? But if you use cloud events to act as a router and you don't use the gatekeeped cues anymore and there's a bunch of mixed messages on a single pipe, uh you don't you, you lose the ability to gatekeep.

F

What do you mean I like so maybe there's a particular consumer that would like to verify that only the bank database sent you data.

E

But it it can, it can always do so. It's not clear to me that that's a problem that we need to solve as a in the general case.

E

So if you want to do this since cloud events carries the data is always binary or can always be binary, nothing stops you from from making the event data such that it's s mine signed.

E

So if you have the particular case that you really want to make sure that you have um that the data is can be authenticated, then nothing stops you from crafting the payload of the event such that you can go and verify it. On the other side,.

F

Okay, I think that's what the advice should be. Then is we say the cloud event envelope is not going to support this directly, but it guidances stick it in the data payload.

E

Yeah, I I because I think, that's a the reason why we the the reason why we create the the cloud events metadata or we have it. Is that because we want to make it possible for for arbitrary, well, not arbitrary, but cloud events supporting um infrastructure using arbitrary protocols, the ones that we support to have a shared understanding of what to do with those events and how to dispatch them. But it's so it's it's more, a spec that is helping you to help foster interoperability.

E

Then you know having the the originator of the event the producer of the event and the consumer of the event um deal with their with their end-to-end relationship, because the end-to-end relationship is ultimately about what what's in that event in terms of payload, and they can do whatever they want. One of the print one of the principles that you'll find in most messaging systems is that end-to-end security is generally only happening at the endpoints, with the broker having no business in in dealing with it at all.

E

It's end-to-end security is often something that's that's only being done by the clients, but the only server piece may be. Some shared key store, but that's it so I would. I would follow the same principle here and say you know if you really want to have end-to-end security, including validation of who sent that event. That's something that should be handled end-to-end, which means it's it's handled, based on the payload.

A

Okay, so we're almost out of time um I apologize, it was you that was suggesting you may be able to respond right. Yes, okay, do you feel, like you understand, which way to respond, because I kind of got the sense that maybe there's a pr here, someplace to add additional guidance someplace, maybe in the primer or maybe one of our specs, I don't know yeah. Do you feel like you have a I'm sorry go ahead comments.

E

I think the primer is a good place for it. Okay,.

A

And these do you have a good sense of where the group might be wanting to go with this, that you could take the next steps with it.

O

Yeah I can raise or the primary sure, that'd.

A

Be great, thank you very much. Okay. So, with that uh where's, my cursor there, it is okay, okay, so, okay, so we need to do that cool. Thank you very much, um okay. That was, I think, that's it for the agenda. I don't think we have time to discuss anything else. um One last person last thing erica. Have you michael? Are you still on the call?

A

I am yes, excellent. Okay. Is there anybody else that did not get for the attendee list.

A

M

A

Meantime uh does anybody have any topics for the sdk subgroup, because I believe that the spec or the agenda's still empty, so I'm suggesting that we cancel the sdk call immediately following this one? Is there any objection to that or does anybody have any topics.

A

Okay, anything else people want to bring up for today's call for the main call.

A

Okay, in that case, I believe we are done. Thank you, everybody we'll talk again next week and just render there is no sdk call right after this, we just canceled it all right. So talk to you next week, bye.

A

A