 Welcome to another round of OAuth Happy Hour. I am Aaron Perrecchi, and we've got Vittorio here as well again. Ciao, come in. Nice to have you here again. Good question. Anybody here speak Italian? We are going to. Go ahead, go ahead. I don't speak any Italian. I speak the tiniest around Spanish, not enough to probably even understand any Italian. So there you go. I'll take advantage of that when you least expect it. Oh, thank goodness. Well, in that case, I will just throw some German at you in exchange. You win. You win. So today we are going to talk about all things OAuth. Feel free to drop in questions in the chat at any point. Well, we're always happy to take questions if you're joining us live. If you're not joining us live, you are missing out. And said you'll be just listening to the recap of this. But I also wanted to focus today's conversation on something that I've been talking about a lot this week, since I have been doing several workshops this week. This was one of my busiest weeks teaching workshops for people. And one of the topics that I always enjoy talking about is in the mechanics of the OAuth flow, how data moves around between different parties. We've got several different things going on. We've got the OAuth client, we've got the OAuth server issuing tokens, handing out tokens. We've got the API that's there ready to hand over data when it's asked, assuming the token is valid. And got to make sure that this is all secure. And this is all working well. So how tokens move around and who's trusting who is always a fun topic of discussion. So before we get into that, I guess any news, Vittorio, on the standards front of new developments that have happened in the last week or two? Thinking. I think that the main thing that happened is still the aftershocks, after the big forum that we made with user agent vendors. Identity providers and identity vendors, which happened a couple of weeks ago. And one of the actions emerging from that forum was the desire to found a new W3C community group which would bring together under the same tent, identity providers, user agents, and identity people, whomever identity people are. And so what happened is that there are some discussions right now for the charter. And so there is a template for the charter for community groups. And I participated with some calls with browser people and singer. And so I anticipate that in the next week or so, there will be a charter to read. And that's pretty much the main thing that I've seen happening in this space. But I'm also pretty negligent with my folders. I have rules in Gmail that send stuff in their own areas. And then I very carefully open it because there might be feedbacks on my specs. And then I have to work. And being myself of Europe, I don't like to work. Of course, I'm joking. But still, that is an extent of news for this week, I think. Great, yeah, yeah. And on my side of things, I have been working with the other editors of OAuth 2.1. So we are still progressing things forward. There's no new draft yet. We're still working on just editing amongst ourselves. So we've been working on that. We'll hopefully get an update out soon to schedule the next interim meeting on the actual calendar to have that discussion again. Fantastic. Yeah, lots of good comments have been coming in about that though. And we're still processing the feedback that we have received because there's a lot and people are very thorough. And we're trying to just make this effort make sense. It needs to be worth it. It needs to actually be a significant cleanup in order to justify the amount of work that it takes to actually push a document like this all the way through. Yeah, I think that this is a classic example of no good deed goes unpunished. Let's say that the idea behind this of like let's consolidate, let's do best of, let's give people in a single place all the things that are most salient was a good idea. But of course, at the moment in which you started opening this thing up like, I know I'm partly guilty of that because a lot of the feedback that I provided isn't necessarily about consolidating. It's more about opportunities to clarify. Like you, I spent years helping people wrap their head around this thing and they were recurrent issues that people stumbled upon while looking at this. And given that you guys are so nice to be touching the language, then there are opportunities to make things better as in like being more consistent, clarifying certain things that people don't get, having maybe better diagrams, which like the signature asking diagrams we are not always easy to parse for me and Mortons. So like there's so much scope creep that you guys are so gracefully handling. And I think that community will be backed up for your work. So feel good about all the extra work that you have to do. I'm happy to be doing those kinds of cleanup things as well because yeah, especially now looking back at it this closely, I am realizing how much of the language in it is kind of just out of date in terms of as an industry we just don't really talk about things that way anymore. And there's just sort of new assumptions that we have now as a general understanding that we're not true in 2010. So it's a good opportunity to kind of just modernize the whole thing and make it so that it doesn't seem like you're reading old or weird or why do they refer to this thing like this all the time? So it's a good opportunity to do that. Yeah, although unfortunately there are limits to what we can do. Like as you mentioned in 2010, this thing was largely how to teach to a third party to call an API. And so that the user is involved in the picture and there's no improper moving of credentials in the wrong place. But these things grew so much beyond that some of the terminology that I'm sure we will touch as soon as we start talking about front channel and back channel is just odd. Like whenever I talk about client and there is also a browser involved. Like and we are talking about spa, a lot of people that aren't part of our parlance, jargon and similar, they expect the client to be the browser because they say, wait a minute, this is the thing which is calling the API. That's the client in a traditional computer science. Whereas for us, which we are like twisted as like the client is the thing that gets the token and is the client of the authorization server. And the same goes like when you're trying to send in with Open edConnect and the client is the recipient of your token. So wait a minute, is it the client or is it the resource? So those things we won't be able to fix because the client is the client is the client. So you can change it. But at least we can have the people like you cannot be to clarify the language saying by the way, in here, remember that the client is the code running on the server, not the user agent. And maybe adding those little sentences here and there will make the difference between people going deep in the wrong direction or people saying, oh wow, those guys are weird, but still understand what's the intent. Yeah, I think that's a great point. And that is actually a great segue into the main thing that we want to talk about today, which is details about how the data does move around and how these roles are expressed in the OAuth spec and in the flows. So let's, how are we gonna do this? Let's start with a, what I've been doing in the workshops in backup, what I've been doing in the workshops is when I'm explaining how OAuth works, what I like to do is demonstrate what's actually happening under the hood and why more than just show you how to make it work successfully. Because it's one thing to just make your code work. That's great. Some people just want to get that done. That's all good. But if you're actually trying to understand why the code is working or why you have these, what seem like extra steps, it's useful to actually understand the mechanics underneath to see what's going on and why. So the way that I usually approach this is I talk about the implicit flow first as a way to demonstrate how one way for data to move around so that you can see the problems with it and see where is this one little step where if we add in an extra thing, we can make it more secure. So why don't we start with that? That's a bold strategy. That's a very bold strategy. Mostly because I'm making it. I, go ahead. Yeah, mostly it's like, I felt the pain when collectively we decided to drop the implicit flow. Mostly because I had it in my teaching material and I basically stopped covering it because I tried to be thrift, how do you say this in English? Frugal with the cognitive resources of the audience. And so if it's something that I put in that hat and then I need to tell them now, forget about it. Why is that not the drones we were looking for? Then I said, what if it's the only thing that I remember is the implicit flow? So I ruined them for life. So that's why I'm saying a bold strategy. I'm not saying it doesn't work. I'm sure it works, but probably also people that come to a workshop are committed. And so they will think hard about this. And so you can afford to do the kind of like a mental gymnastic. Whereas if you have a larger crowd, people might be doing slack, doing email, doing Twitter and the same stuff. So you need to give a wide colors. And when I'm doing the shorter ones that are like I fit everything into an hour, I don't cover it because yeah, if you've only got an hour and you wanna get a sense of this stuff, I'm gonna show you how it works the right way and you can explore the rest on your own. But when I'm doing the three hour event, I've got more time to explain the concepts underneath. But let me do this. Let me actually share some slides from the workshop and we can walk through this. And that will, you'll see how this works. I'm actually curious to get your feedback on this too. I like the off server with a very post industrial warehouse, pink Floyd's album cover art, very nice. Yeah, yeah, it's the token factory. So across the top are the roles and these are like we were saying before, maybe not the most clear terms in the world, but this is how OAuth is modeled and we are kind of stuck with these terms and can't get away from that. The application or the client is that it's the same whether it's a web server based app or an app running on your phone or a single page app in a browser. It's all the same in terms of the flow and the model. So we don't really care which in particular we are using right now. The user agent is the browser that is accessing the client. So if we talk about a single page app, the user agent would be the browser, the single page that the single page app code itself would be the OAuth client which is running in the browser environment. And then of course the OAuth server is the one dishing out tokens and then the API is the one that is going to be returning data given a valid access token by the client. So- And here you are already cheating a little but I like the way in which you are cheating because I can only say OAuth server, you don't use these very loaded term which normally would be the authorization server like in the classic roles that thing would be your authorization server but we know that the authorization is only part of the story and a lot of people over indexing it. And so by using OAuth server, you just sidestep the problem in its entirety. So I applaud your cleverness, good sir. Great, excellent. So, okay, we're gonna start the flow. We're gonna start by having the user visit the application's website and click the button that says login. I'm trying to use the app. Let's go ahead and start the flow. So we're not going to collect the user's password here because we are not doing the password grant. The application does not want to see the user's password. So instead, the app needs to send the user to the OAuth server so they can go log in there. This is the first piece of data moving around. This is the app saying, hey, I'm trying to go over to the OAuth server so I can get access and the way it does that is by building a URL to the OAuth server and directing the user's browser to that URL and in that URL are instructions. Instructions to the OAuth server of what the app is trying to do. So this, the way I think of this is there is a message that the application, the client is sending to the OAuth server and that message is this is who I am. This is what I'm trying to access. This is where to send the user back to after they've done logging in and improving this request. That message is not sent directly to the OAuth server. It's sent through the user's browser. So think of it as one message flowing like that. Okay, then the user lands at the OAuth server. That's where they log in. That's where they approve the request if you've got the consent feature turned on for this application. And assuming they say yes, the OAuth server is ready to hand an access token to the application. How is it gonna do this? Well, it can't, it doesn't have a way to talk directly to the app because the user's browser is now at the OAuth server and the app is just somewhere else. So instead of handing the access token to the app, it's going to give the access token to the browser to have the browser deliver it to the app. So this is the second message being sent. There is an access token sent through the user's browser for the browser to deliver it to the app. And now the app can use the access token to go and make API requests. So we've just completed the OAuth flow and successfully delivered an access token to the single page app or the mobile app or the server based app, whatever it is. So this is the implicit flow. I think the name is pretty terrible and the name has other implications that are probably confusing in the general understanding of this, but the reason that this is the implicit flow is that the access token is returned directly from the OAuth server in response to the user clicking that button. So what's the problem with this picture? The, the lines that I've drawn here, the blue handwritten lines, these are messages sent in the front channel. So this is the front channel messages, whereas the pink line, once the app has the access token and it's going to go make an API request, that message is sent in the back channel. These are two different ways of moving data around between these different roles. What are we actually trying to do here? We're actually trying to get the OAuth server to give an access token to the app. That's the end goal, right? We don't care about the rest of it. We're trying to get an access token to the app. So this is a nice shortcut to doing that. What's the problem with the front channel? So if you think about front channel versus back channel, the back channel is an actual HTTP connection sent from an HTTP client to an HTTP server. That's how I define the back channel. The front channel is using the browser's address bar to move data between two pieces of software. So there is actually no HTTP connection from the thing sending the message to the thing receiving the message. If you think about using the address bar, what you've done is you have the client sitting in the browser trying to send a front channel message, so it's going to direct the user's browser to make an HTTP request, which will then have the browser deliver the message. And on the receiving side, you have the thing that receives data in the front channel is not receiving it from the thing that sent the message. It's receiving it from the browser in response to the browser having received the instruction to deliver the message. So the way I'd like to think about it is the back channel is like hand delivering a message where you can walk up to somebody and you can give them the thing and you can see who they are. They can see who you are. You can see that they took it. You can see that nobody came in and stole it. It's all good. It's very normal and we take that for granted all the time because we're so used to making back channel requests. Whereas sending data in the front channel is more like putting your message in an envelope and then shipping it off in the mail and kind of just hoping that it gets there. And the reason that I use this example of sending a letter in the mail is because it's easier to picture the problem in that case which is there's a problem on both sides of the transaction when you're sending something in the mail. If you send your house key in the mail, you don't know if it actually made it to the destination. You don't know if it was successfully delivered and you can't ever prove it. Even if you get a tracking number saying it was delivered that's just a claim by the delivery company that says it was delivered. And you also don't know that even if it does make it there, you don't know if it was stolen or copied along the way and duplicate it. So there's this sort of invisible, there's these problems with sending data in the front channel that you really can't get around with only the front channel. And you have similar problems on the receiving side because if you get something in the mail, you don't actually know who it's from. The return address doesn't really mean anything that's not provable at all. If you wanted to be sure the letter was from who you think it's from, you would need to do something else to verify that. You would need some other information to verify it. And that's the problem with the front channel. And these are just attributes of sending data in the front channel that you can't avoid. And because of that, whenever we use the front channel we need to be able to account for those limitations. So let me pause there. How are you feeling? Pretty okay, but it's a hard fast form. It seemed to be fine in my fasting window. So I feel good and I like the metaphors you are using. As we have every metaphor, there is always a risk of bringing them too far. And so it makes complete sense to me like the way we should visualize these are like pipes not very poetic. And just think like in the case of direct connection you have a client which opens an HTTP connection given that there is an HTTPS. It's a tunnel, so it's a pipe. And so whatever I put in this pipe it kind of like goes from one side to the other and nothing can happen in the middle. The only thing that can happen is that the stuff goes through or maybe it gets stopped but no one can mess with it. The thing is that in the front channel individual requests perform the same way. Let's say that if I'm in front channel and I open a website that goes on HTTPS as I'm talking to that website my browser is in the same channel. Like my browser is an HTTP client, HTTPS client. And so there is a pipe. The challenge here is there's more than one step. Let's say that when you want to communicate through front channel in the way that you described it's a redirect. And so it's in those pauses between pipes. Like there is a pipe between my client and the off server. There is a pipe between my sorry between my browser and the off server and between the browser and my app. Because I have two pipes they both have the same good characteristics that you described but there's two of them. And so there is a moment in the middle in which stuff might happen. But that doesn't necessarily mean that the entirety of the front channel is bad. Is that it offers more opportunities for things to go wrong but instead in the pipe you don't have. And the other thing is that there are things that we can do to make things slightly better. As in your example when you send stuff by mail if I send you something if I give you something to put in your envelope and I know that I gave this to you and then once you send me the letter it's true that once I read the return address it means nothing. But if I open the letter and inside I find this thing and I say all right I don't know what happened to this entire thing but I do know that at some point in the past this thing was in the hands of Aaron because only Aaron could have provided that little piece. So apart from these small things which I'm sure you were going to add in the next wave completely clear. I think you did a fantastic job. Great, yeah. Yeah, I like the pipe analogy too of it's not that there's no HTTP when you're using the front channel it's that there are separate HTTP connections between the different legs and it's the separations that provide an opportunity for things to leak or spill. And yeah, there are several things we can do to protect the use of the front channel which we have to do if we want this to be secure. And there are many different solutions to it which have been explored in several different ways. So in OAuth the short flow that we talked about the implicit flow kind of just stopped there and it didn't get developed further in a way that would add any protections to the use of that flow. And that's really the core problem with the OAuth use of the implicit flow is that there was never added any protections to protect the use of the front channel whereas the authorization code flow does have those protections and if you add Pixi it actually plugs it up on both sides. So let's look at the Pixi flow and look at the same sequence diagram and talk about how we're adding the extra authorization code step specifically to protect the use of the front channel. So we've got the same sequence diagram again the user is gonna start by clicking the button that says login before the app sends the user away. This is where we're just gonna jump right into Pixi before the app sends the user away to the OAuth server the app generates a new random string, a secret stores it internally and then calculates a hash of that secret. And the idea with a hash is that it's a one way operation. So if I told you to think of 10 random numbers write them all down on a piece of paper and then add them up and tell me the sum I would not be able to tell you what 10 numbers are on your paper. That's a one way hash. It's not a very good hash. Computer could crack it pretty quick but I would not be able to do that in my head. So we're gonna use a hashing algorithm that's better it'll be shot 256 and that the point is if you shout that to the world it doesn't matter because it's not reversible. So what is the app gonna send in this first front channel message? Again, here is the first front channel message the app sends. It's going through the user's browser to deliver to the OAuth server. So the app is trying to talk to the OAuth server and it's instead telling the browser to talk to the OAuth server. So it's taking a message, putting it in an envelope giving it to the browser to deliver and in that envelope is the hash. And we know that it's possible that somebody might see the contents of that message which is why it's only the hash and it's okay if it's a hash because it's not reversible. Okay, so we're good so far. The user logs in like before approves the request and now we've got the same problem on the way back. We want to deliver the access token to the app but we don't want the access token in the envelope. You wouldn't chip somebody your house key in the envelope that is not a good idea. So instead what we're gonna do is we're gonna send something back in the front channel where it doesn't matter if it is stolen or seen by anybody. So what we're gonna send back in the front channel is a temporary code. Just a one-time use short-lived temporary code. This is like before in the previous flow this is the message sent in the front channel and what we're doing here is this by itself is an improvement because if someone did steal that from that redirect step from the front channel it couldn't be used for very long. It would be short-lived or it's one-time use. There's those kinds of limitations are all good but we can do even better because we have that hash. So because the OAuth server saw this hash when it got the request for this temporary code the OAuth server can keep track of that on its end. And when the app makes a back channel request using that code through that secure pipe it has to also send the plain text secret that it made up at the beginning. This matches that. And because the OAuth server saw the hash value the OAuth server can hash the plain text secret sent in the back channel, compare the two hashes and now can deliver the access token securely in the back channel where we know that it can't be stolen out of the redirect. And then we're done and the app can go make API requests again. So the trick here is there's two tricks. One it's that authorization code, the temporary code and protecting the temporary code by using the that pixie hash what's called the code verifier in pixie. So if you look at the request of the OAuth server sees we've got a back channel request and a front channel request. If I draw like this line here, what's crossed that line? Well it's the front channel request that the browser makes that the OAuth server can't prove was actually sent by the app. And then there's the back channel request sent by the app itself. And what we can do is use pixie to link the two requests together because the only thing that could have ever had the information of the both the plain text secret and the hash is if the thing that generated the hash also generated the plain text secret. So that is pixie. That is how we can use the front channel even though we know it might be compromised where it doesn't actually matter if it's compromised because you can't do anything with the information that you've learned from the front channel this way. Very nice. Very nice. Here we stumbled on one of my pet peeves which is whenever internally colleagues say, oh yeah, let's use pixie in here. I always get my nostrils very wide and I said, ah, no, that's my authorization code flow. As Zachar, if you look at the original OAuth the main thing, the main idea that fuels the flow that is just described is the authorization code grant which is probably the most quintessential OAuth thing because that's how a website running on the server we were back in the running on the service side calls an API. So this thing about the back channel was always there. And then pixie is a measure that was devised on top of that as an extra protection for the authorization code. So for me, the highest of the bit is we are doing the authorization code and as protection we place the pixie. So it's kind of like there's the car and the car as the anti-aft mechanism. Instead, I wouldn't say I got to do groceries with my anti-aft mechanism but it doesn't matter because pixie always comes with code so you can say pixie and you will be completely fine. It's just me but I have a mild mild mild form of OCD. And so I just want to be precise. I totally get that. I agree it's, and that's actually one of the reasons that I am, it's one of the reasons one of the things we're keeping in mind as we are writing OAuth 2.1 is that because OAuth 2.1 is building in pixie into the authorization code flow and that is the authorization code flow in OAuth 2.1 we don't need to call it pixie. So it actually, if you look at the draft text right now there is no mention of pixie in the text. There's the authorization code flow and that has a parameter called code challenge and code verifier which are from pixie. So it's just built in because yeah, it isn't a separate flow. It's not its own thing. It's a mechanism that you add on into the authorization code flow to make it secure. And to be pedantic which is one of the reasons for which I get my salary twice a month is being pedantic. In the flow in which the client is a web app the benefit of pixie isn't as pronounced as in the case in which the client is and then I said as pronounced I didn't say it as pronounced like as in like in the normal case in which you are doing all the authorization code flow from a confidential client as in a client which is running not on the user's device but elsewhere. And then in the process of registering with client often that client are actually often the thing that makes that client confidential is that it is given a secret which is always used whenever the client opens this magic pipe with the off server. And then at that point you can happily use your authorization code in the front channel. And then even if someone steals that thing they can do odd stuff as in like a mix up attacks and similar but in the simple case that you describe you'd be fine because the moment in which you're trying to use the code you have the authorization server expects you to use the secret and the secret never showed up in the front channel. And so in the case in which the application is in a confidential client then you'd be fine without pixie. So it's not like... So if we compare it to... If we relate it to this diagram again it's this bottom pink arrow that's where the app sends in the authorization code and we're primarily worried about the authorization code leaking out of this step. So if someone is able to steal it with a client secret they can't do anything with it on their own because they have no way to learn the client secret and the only thing the OS server will do is it'll only return an access token if you can provide both the authorization code and the client secret. Right, and the reason for which I brought this up was just to give a bit of a historical perspective of why pixie even come out to begin with. Let's say that confidential clients are of those clients that run on the server but if a client is running on your device like for example it's the Uber client that runs on your iPhone then you cannot really... Well, but it's not getting there let's just say that we usually don't deliver a secret together with a client and so you have to be more careful because the only thing that the client needs in order to get the token is an authorization code there is a before pixie there was no other constraint and the point here is in the first generation of installed apps apps like Uber and similar the thing that happened was that all the interactions that required showing UI like browser UI were happening with embedded browsers as in the application would have a component that was part of the application in the application memory space which would render HTML so not the system browser something that didn't even show the address bar just stuff that rendered HTML and then at that point the authorization code remained in the memory space of the application but there were lots of issues with this as in particular the application might steal your credentials and so they might just listen to the keystrokes and they steal it or you might be already signed in in the browser but when you're using this component the component could not reach the cookies which represent your signature and so you were missing out on the single signal so what happened is that we started telling people don't embed a browser control in your app start using the system browser which leaves on your device so that whenever you're up needs to do something with a browser you will hop on the system browser do your thing and then this thing with using values mechanisms return the authorization code to your app but now we are back to this metaphor of the pipes but not in the browser but within the operating system what might happen is that someone might pause as the browser and then intercept your authorization code or might pause as your app or any other mechanism that would allow them to grab the authorization code before Pixie and all the mechanism that you described with a hash and similar that would have been a disaster but with the introduction of Pixie this thing even if something on device would have stolen your authorization code they would not have been able to use it and then Daniel, you and other big brains discovered that Pixie was useful also for some scenarios in the confidential clients and so we landed on the place which we tell people just use Pixie all the time doesn't matter the flavor of a client but just wanted to make sure it makes it because it provides a bit of perspective if someone followed the story so far these should connect the dots in the right way Yeah, it's definitely a lot of history and baggage there, I feel like and I'm glad that the new recommendation is just Pixie is part of the off-code flow you don't have to worry about when to use it but I think it's useful to remember exactly what problem Pixie is solving because I do see people get confused all the time about because of the history of it they think of it as an alternative to a client secret they think of it in that sense it's either you do a client secret or you do Pixie and they don't those are two different problems and they're actually completely unrelated so a client secret is the application's way to authenticate itself to the OAuth server which is very useful if you can do that and if you can have the client authenticate itself to the OAuth server you absolutely should and that's a confidential client and great, that's fantastic do that Pixie has nothing to do with authenticating the client the only thing Pixie does is authenticate the specific exchange of the one authorization code go back to this diagram it makes sure that the thing that makes I'm running out of colors to use it makes sure that the thing that made this request is the same thing that made this request that's all it's doing it's saying yes, the thing that is exchanging the authorization code is the same thing that requested this authorization code it does not prove the app's identity it has nothing to do with authenticating the app it could be an app impersonating another app still none of that matters, it's totally irrelevant to Pixie it's only ensuring that the one request is made by the same or the two requests may be the same application instance and what's more is once the flow is done once Pixie is done and once the authorization code flow is done and the tokens are issued Pixie is completely out of the picture it has nothing to do with anything anymore so client authentication is still a consideration for using refresh tokens and all of that stuff Pixie's a different issue so I like to completely different animals you are absolutely right it's like you can repair yourself from a rain using an umbrella or using a house they are completely different animals which occasionally might they are meant to do different things but occasionally you could use them to a particular spot but they are not the same like Pixie is you are the same guy who made X earlier on client credential is like, oh yeah, you are Aaron are actually Aaron is not Aaron as user but still, so yeah this is a really good clarification if they are completely different they can be useful sometimes for similar things but they are intrinsically different properties and reason that if you can say that in English yeah and yeah, and I think that's one of the one of the sort of unfortunate parts about how slowly this all came together in the space is that because this was all developed over the last 10 years and these new pieces of information came to light slowly it's very, there's been a lot of if you've come into it in the last three years you will have come from a different background than if you have been here for five years so you'll be working with different sets of information and that's again one of the reasons that I am excited about OAuth 2.1 which is just like let's just set a new baseline let's all start from here and we're gonna agree that this is the starting point and then we're gonna build from that going forward let me say something unpopular the way that you described it might be messy but it's to me, their life finds a way of Jurassic Park memory as in I like when the universe has things happening problems, new scenarios, new possibilities people trying to achieve their goals with that app, say, empowering their users to do stuff and similar and as we learn and evolve and the situation changes the solutions that we give to people the solution that people themselves find and then we step in and provide guidance they just develop organically, naturally to me that's the right way like we learned, like a pixium merge to whenever there was a need and then we discovered that this thing was useful for more things and we did it it's kind of like the urban areas with ramps instead of stairs which were originally made for people on wheelchairs which turns out to be useful also when you are carrying a trolley they were never designed to carry a trolley but there they are and maybe the trolleys also came out because of that because when everything was stairs maybe it wasn't a great idea to go around with trolley so it's evolution and it's messy and occasionally we need to step back and have a poor Adam Thorsten and Dick to spend their evenings creating a new baseline but this baseline is solid whereas in today's landscape there here is the controversial part I think that often you have the people but wait before we get that I want to just sort of summarize what you just said again I hope because I totally agree with it which is the evolution of that and the sort of natural growth of how we all think about it is super, super important and it is absolutely the right way to do that I'm a big fan of slow evolution slow changing of these specs let's try things, see what works see what doesn't work let's take the good parts let's throw away the bad parts and have it grow organically like that and what we're trying to do with OAuth 2.1 is capture that is to sort of put a bookmark in that evolution process of we're saying here is what has grown organically here is what we like here are the things we don't like let's stamp that, put a marker in it so that we have a thing to refer to which refers to this set of functionality that is based on all of this past fantastic summary that's great exactly what I meant but in more proper English thank you for providing subtitles for my broken English your English is far better than my Italian well, but your Italian is useless because you live in the States I live in the South nice courtesy but unfortunately it doesn't have but anyway, the thing I wanted to add is that if you look at today's output of the body's working groups and similar you'll also see a lot of pies in the sky I think like things that try to create guidance for scenarios that don't exist like in scenarios that you can imagine you can think, oh yeah I can imagine elves and klingons and what kind of language would they speak and you can build like entire sagas and canons on top of it but that doesn't mean that they are solving a problem or anything interesting in fact, this stuff is messy it's messy because people try to use it people like if they think about I want my users not to sign in again when they are using my app if they already use my website it's a very real consideration which led them ultimately to pixie whereas again, I wanted to, I know that if we would not be recorded I'd say exactly where specs that I'm thinking of but we are being recorded so I don't want to be too controversial but the point is they already said some things that are purely theoretical as in like wouldn't it be great if they were to be X so here let me give you the rules of the game for that particular thing and then you end up with these specs that eventually they die on the vine anyway because if they don't solve a real problem like facts are stubborn things and so eventually they just don't get used and then they but in the meanwhile, so much talent so much time is spent developing these fictions which don't account to anything and personally I'm very mad because I have less and less neurons as I get older and so I like to try to focus on very consequential problems things that actually do improve people's lives and so whenever I feel like we are wasting time on the sources, I don't like that so sorry, I just have to do my little rant Yeah, yeah, fair enough No, there's definitely I've seen that in a lot of other standards groups that I've been a part of as well of sort of coming up with a technical solution that seems like it's a perfect technical solution but it isn't actually based in any reality it's not based on practical experience or any previous work it's sort of just we think this thing is great you should all use it and that's not a good way to go about the world which is why I also like the way that IETF works for the most part which is the very much based in running code, right? You have to get stuff working and then you base specs on stuff that works not on how you think it should work in the future Yeah, absolutely Embrace the messy Messy is the way to go Yes, yes, I like that Well That was delightful Let's go ahead and let's go ahead and wrap things up we're only a little ahead of schedule but we can we can share some info about what's coming up in the future what's where to find us next Let's talk about upcoming events I know that you have something coming up soon I do in a couple of weeks actually at this point, like 10 days we're going to do identifiers which is the first in-person conference I'm going to do after 15 months Yeah, it's going to be a hybrid experience which is very interesting because it has a challenge that in two decades of doing public events I've never encountered so there will be a mix of speakers from countries that cannot yet travel and so there will be broadcasting things live and people on the premises or the conference which is going to happen in Denver at the Gelord will be able to actually watch these things as they get streamed and the things that we'll be doing in Denver some of them will stream some others we have pre-recorded like I pre-recorded some of the sessions that I'm going to deliver and they will be cast at the same time as I deliver them live I don't know exactly how the the expo will work but I know there will be an expo in fact, like we have an amazing swag from zero I'm looking forward to be able to see the reaction of people once we'll give them this swag so it's exciting but it's not just exciting because of that I am fortunate enough to be the topic lead for two trucks the developer truck and the architecture and standard truck together with them and these sessions are going to be extraordinary like the speakers are all thought leaders in this space like the right people the people that are close to the manner and the content we like I bugged them a lot as content lead for like all sorts of and they are amazing like those that will be both informative and entertaining and so I think that for whomever is lucky enough to be very person is going to be a party even if it's like a business conference so normally not exactly a bit somber but I'm sure it's going to be a party and if for every once in a while they'll be able to access all the same content they simply won't be able to join us at the bar in the evening which are another thing that honestly I'm really looking forward for so yeah that is my that's the main thing that I'm looking forward for that is very exciting I wish I was going to that this year but was not in the cards for me next year but that sounds next year and that sounds like a lot of fun it seems very soon to be going to an in-person event right now but I guess I guess it is a thing that is okay to do I'm trying to get my head around that still it's crazy I know it's crazy like being trained to stay indoor first along I recently made a flight after again 15 months of being grounded and it was a real experience like I had a million miler like diamond with delta all sorts of so I've been flying my whole life very often so one would think I'm used to it this particular flight it was just really odd like we have the masks you are drinking your drink and then they fly the tent and shows up and says where's your mask so I'm thinking for one you have to wear it between six okay so it's kind of like a bit of a pattern of the atmosphere but things are moving and so I think that the I'm very optimistic that the event will be will be a good event so fingers crossed that's great yeah well I'll have to report back on that after afterwards and I'm looking forward to hearing all about it so that's excellent if you are looking for I need to add to our calendar actually speaking of if you're looking for other events coming up check out this octodev.ev.events I need to put Identiverse on here for sure and maybe highlight some sessions from there and this morning sadly it's over I can't tell you to go watch but this morning I had part three of the workshop that I did this week it was a lot of fun and we'll have more of those coming up as well I think I have a couple scheduled for the fall that are very nearly finalized so I'll post those on here as well and developer day should be a lot of fun as well we are both going to be there and talking about we'll be doing a few things I don't think we've quite finalized the agenda yet but that will be a lot of fun as well that's in August should be a good event full of lots of interesting talks and workshops so definitely make sure to to to sign up that one's a free event too so no excuse no excuse we will see very nice very nice yes all right well with that let's close out there and thank you all for watching that was a lot of fun and we will be back here in I guess it's about a month until the next one so after well after Identiverse we will hear all about how it went and what cool swag you came back with and with that see you all later and have a great rest of the day thank you bye