 Okay, welcome again everyone to Delhi stage. We are starting with our first talk after the keynote by James Favill. That was amazing and So we have been with us Let me quickly add Ben to the stream Yeah, we have Ben with us and Ben everyone. Hey, Ben. Can you hear us? Yes? Can you hear me? Great? Great. Your microphone is working perfectly and I love your screen handle We also am shanking all of it. Yeah Yeah, I'm available on internet by this name and if I just put my real name no one will find out because there's a lot of Yeah So before we do on I just want to thank you to auto because auto is one of the gold sponsors for pike on India 2020 this year Thanks for making it possible and Ben is joining us from auto and he'll be taking us through stock Um Here on so here's your screen Ben the stage is all yours lovely. Thank you very much Just a lot of people call it author. It's it's all zero I don't know that it makes much of a difference, but just in case you're searching for it It's a zero at the end not at the letter. Oh, so both zero dot com if you want to find out more Anyway, I'm here to talk to you about two identity and beyond Stick your hands up in the chat if you love toy story and your favorite character is is your spaceman Buzz Lightyear, I knew I thought it was on the tip of my tongue. There we go. All right So I want to talk to you about identity Where it came from how how we solve the problem what protocols there are for it If you saw my talk yesterday, we went more in depth into the access control stuff This is going to be more of an overview into a warth and open ID connect So let's get started. Where did it all start? Why do we have the solutions now that we? The we have in order to solve the problems that we had now one thing I do want to say before I go on is please ask questions throughout I want this to be an interactive conversation If you have questions at any point about what I'm talking about or you want to go off on a tangent We have time to do that. I'm happy to take questions at any point if you want to leave them till the end That's fine, too. I can revisit any of the slides and we can go over it So where did identity start? This isn't really the very start of identity This is one of the things that That caused us to consider how to do identity on the internet and it all started with this form right here Does anybody you remember on Facebook and LinkedIn did it as well and Google did it I'm not blaming or attacking any one technology company But back in the early 2000s you would see this kind of thing very often and the thing is with social networks The strength of the social network was from the network And if you're starting your own social network from scratch and you don't have anybody in your database There's not much of a network there So it's understandable why they implemented mechanisms like that you join a new site you join Facebook for example And they want all of your friends to join Facebook so that you'll all use Facebook together So what they did was they gave you this form and they said hey give us your email address Then give us the password for your email account And what we'll do is we'll log in to your email account and grab all the the emails Does anybody think this might be an issue? I think there's probably a small security issue here Nowadays we're probably a lot more aware of this we as developers are certainly more aware of it But even mainstream if I asked my mom to Paste her email password into Facebook nowadays She would say that I'm not doing that We know that passwords shouldn't be shared even between systems that we think we trust But this is this is the root of it. We wanted to try and solve this problem. It's still a valid Problem that we want to solve we want Facebook to be able to get in touch with all our friends and say hey join Facebook I mean personally, I don't I don't have a Facebook account But conceptually if you're if you're developing an application You want this kind of functionality to make it easier to onboard your users so What was going on behind the scenes I've kind of described it already But essentially what would happen is you would send your login credentials for your email account to Facebook Facebook would then take those local login credentials for your email account and send them to say you're with gmail They would send them to google server and say hey I want to log in with this username and this password And google sees that or the email server sees that as the user logging in They don't necessarily know it's facebook or another system For all intents and purposes, it's a valid login by a user It's a standard user login, which means once they're logged in they can do everything you would do You could do if you logged in so what they'll do is they'll go through your Your contact list and maybe even go through your emails and see all the email addresses that have been sent from and to Perhaps I mean they've got the possibility of doing that they could They could mine all the information in your email account and suck all of that in all of the contacts you have And then what they would do is Send an email to all of those people saying hey ben is just joined facebook. Why don't you join facebook too? Here's a link for you Now the really cheeky thing is that originally what facebook did and perhaps some of the others as well In order to reduce spam because if the email came from a third party then it might go into the spam box They wanted it to come from the person who had just joined facebook So they would actually use your email server to send the email. So it actually looked like it came from you It wasn't even detectable that it wasn't from you because they were logged in as you so it was a massive issue here And then what they would do is they take those contacts and they put them all into a database Regardless of whether or not the person logged in and this is more of a an ethics question as opposed to a technical security question But they would saw all the users even if they never followed the account and then sometime in the future Maybe if one of my friends joined facebook totally independently with the same email address They'd link it up and then suddenly they'd know that for all these years we've been friends So they would be able to suggest a lot of my posts and it's a great way of of Profiling somebody before they've even joined the site So ethics aside, let's keep keep on the security side of things. This is obviously a huge big no-no We don't want to share our credentials for one site with another site So this is the problem that was solved with oauth and open id connect So what is oauth? Oauth or specifically oauth 2.0 because there's an oauth one as well Oauth can fix the The friend finder mechanism by having you never divulge your credentials to facebook And let's stick with the idea that it's facebook and google mail and and you logging in So you've got your credentials on the left hand side here These are your logging credentials to your your google mail your gmail account So you make a request to uh to facebook to say hey, I want to use the friend finder mechanism And facebook says that's great. I'm going to need some kind of token to be able to talk to google So it's going to send a response back to you which redirects you to the gmail server Or in in google's case, they've got a one area like the accounts or gmail.google.com where you log in But yeah, you're logging into google's infrastructure at this point So you're sending your credentials to google not to facebook and this is fine because they're your credentials for logging into google So there's no reason you shouldn't this is a perfectly normal Process you're identifying yourself to google using your google credentials. So that's great Google then is able to generate a token In some way there are a number of different ways how this token can get back to facebook I won't go into that in depth right now, but essentially it generates a token an access token Which it uses your browser as a redirect So it'll send that back to your browser as a redirect to then send the token back to facebook So facebook When you requested the access to the friend finder system said hey, I need a token redirect you to the the provider the provider then sent back a token That's all the facebook has at the moment. It doesn't have any of your your your friends or any of those details just a token This token in this particular case is an access token And what this allows the facebook server to do is to send that access token directly to google now to say Hey, I want to call an endpoint of yours Uh an api that's going to give me a list of all of the contacts in ben's address book It doesn't actually say ben's address book I want all the contacts in the address book that's associated with a user that's associated with this token that I have So it passes this token in and google then looks at the token and says well I know this token was generated for ben's identity ben logged in This is the token we generated for that So you now have access via this token to ben's data But even better than that is the token can specify the scope the capabilities of what facebook can do So in the original instance before we had Facebook logging in and it was able to search emails and look at your contacts is even able to send emails This token can be locked down to only allow read access To the contact list for example, and in this case, this is what would happen You would have the capabilities to read contacts and that's it. You couldn't create them. You couldn't delete them You couldn't access emails. You couldn't send emails All you can do is get a list of the contacts so that the token will specify this inside So in response to this Google is now going to say hey, I've validated that you have access to this So I'm going to send you all the data you've requested. You can do whatever you like with it So facebook now still needs to send an email to each of these users Each of these email addresses to say hey, we need to join but they can't do it through google anymore Because the token doesn't allow them to do that So they need to find their own way of sending emails Which to be honest is the way they should have done it in the beginning And now they have to so that's great And if we have a look at the ethics again, they're still going to put all the data in their database They're still going to link you up years later if you join Two three years after your friend joined But you know that that's That's what they do. That's fine. That's a use case all right So that's a orth a orth is around authorization. It authorized facebook to talk to google It's not authentication though So authorization is things like linkedin can read emails on gmail So you could actually have a token that allows you to read the emails You could have one where tweet deck can post tweets on twitter And this is a real example. I'm I'm sure linkedin probably don't want to read your emails They might want to access to your contact list But tweet tech is a product that's now owned by twitter But it's still a whole separate website and when you log into tweet deck You're actually logging in with twitter, which gives tweet deck an access token to talk to twitter's api Which means that it can post tweets. It can delete tweets It can schedule tweets. It can do all of these things And that's an authorization that's allowed between these two entities There's an action in the middle and two entities on the outside Eventbrite can create events on facebook For any of you that run Meetups or any kind of events You'll know that that's actually a feature that you can do And you can link your facebook account to eventbrite from the eventbrite portal you'll click on Connect to facebook and you have an oath process that will generate a token or facebook will generate a token That gets sent back and gets stored by eventbrite So that eventbrite can then talk to your facebook pages, for example And create an event based on the event that you've just defined in eventbrite And then people can even register directly on facebook and that gets put directly into your eventbrite database your Tickets that regenerate it that kind of thing. So there's a good close coupling there. That's all done using oath What oath can't do is something like eventbrite can get ben's identity from twitter twitter That's that's not something that oath supports again It's an action between two entities But the action of get ben's identity is a very Obscure one that you can you can define what send a tweet is you can define what Create an event is but how do you define what get ben's identity is and A lot of the social media providers social media login providers started adding their own mechanisms on top of of oath to allow this to happen because Using up until this point. It's been authorized google to do something or other The whole login with google button at this point wasn't possible. I mean they started started doing it But it wasn't part of the the oath spec So what they did um google did it facebook did it a whole lot of other social media social login providers Did it is they defined this concept of user info user info is essentially just another api endpoint That allows you to request information about the current user the current user being the person Who has the access token that Or for whom the access token was generated. So if I log in To google and I send my access token to facebook facebook can call the user info point endpoint on google server And and get information about me because the access token has access to that endpoint So in the same way as we use the token for getting contacts the contact that would then be returned in some kind of format Most likely it's going to be like an icard format or an xml format that's fairly standardized all about your contacts and There's there are libraries out there already for reading and deconstructing this information and incorporating it into your application For the user info endpoint though The because there was no standard around it. We didn't know what the format was that was coming back Was it going to be xml? Was it Just plain text could have been in the same way as a post request is just multi-line key value pairs Could it be jason and what's the endpoint? Is it slash user info or is it slash something else? There was no standardization around this We still use the the access token as the bearer token in the header in order to authorize the request to the endpoint But each implementation was different which meant that if you wanted to add login with google and then log in with LinkedIn then you'd have to rewrite those two components because the data that comes back would be slightly different So from this open id connectors born an open id connect is nothing more than basically the standardization Of the user info endpoint which sits on top of oauth 2.0 So open id connect cannot exist without oauth 2.0 Oauth 2.0 is the authorization process that allows open id connector to work I tried to find a definition of open id connect and they're long-winded But essentially it boiled down to these points It has to be a simple identity layer All it does is it provides information about the identity of the person for whom the access token that you have has been generated It needs to sit on top of oauth 2.0. So we don't need to re-implement our own authorization We've we've got these protocols already that exist So it sits on top of that and all it does is verify identity It doesn't allow me to get somebody else's identity It just says look we know that somebody's logged in we have this identity And here's the information we have the identity information we have about the person that's just logged in It's basic profile information. It's not going to be too complicated. It's going to be things like the email address Maybe some permissions if you want to add those in and that's where the the access control talk that I did yesterday goes into There'll be a a standard identifier so that you obviously when somebody logs in using logging with a social media provider You you don't have a username and password in your database anymore But you still need to know who's logged in and need to record that against your user table So there's a standard format for that and we'll we'll see that in a second It needs to interoperate it needs to operate in a rest-like manner So there are many different ways we could have done it It could have been soap it has to be rest so that's just the decision that was made and Open ID connect has to use rest for this communication And finally it uses jason as a data format and one of the main reasons As I understand it the jason was chosen is because it is a standard format that almost every language has a reader for And it allows you to put in arbitrary data. So there are some bits of data that are standardized key value pairs and we'll look at those in a second But you can also put your own data in so the payload itself can contain whatever you need So let's have a look at how open ID connect works. We've seen how the oauth part works What does open ID connect that layer on top do to change the communication process? So you've got a user You've got your application in the top right hand side that you're writing You've got your identity provider Down at the bottom where's my mask going down at the bottom here That would be like oauth zero for example, and then you've got a login page You need to log in somehow at some point because you're doing a login process Now we've defined up here within this application two bits of information We've got at the top here the client ID and here we have a client secret So when you define any kind of open ID connect based authentication with an identity provider You have to configure the identity provider to know about your application It needs to have configuration information about where the users are going to be stored About whether there's a maximum number of password retries How does the password reset work? Do you have multi-factor? All of these things are configuration items within the identity provider So you have this client ID that links this instance of the application that you've written With a configuration set within the identity provider This will hopefully become a bit clearer as we go through the process We've also there's the client ID We've also got a client secret and this is used for any communication between Your application and the identity provider directly. It has to be kept secret We can't publish it anywhere. The client ID can be public that gets shared. That's fine So user comes along and says hey, I want to access some kind of resource And your application says well, you don't have access yet because we don't know who you are. You're not logged in So i'm going to send you my client ID and it also sent through the scopes So i mentioned before that scopes allow you to define What actions can be taken in this case the scopes that get sent through by default for an open ID connect login mechanism Are called open ID and profile this basically tells the identity provider that we want an open ID process So we're going to get an ID token as well and we want profile information about the user because that's what we're going to use To manifest the user within our own databases So the client ID and the scopes get sent over. This is actually a redirect again Much like the oauth process which redirects the user to or zero or the identity provider that you're using At this point, you're not logged in yet though. So you need to log into or zero You're not looking into or zero here. You're logging into your tenant or your configuration So this is your users for your application or whichever other identity provider you're using So the identity provider is going to return a login form to the user And the user will then complete the credentials in there and submit them back to the identity provider So in this case the username and password aren't going to your application anymore. They're only going to the identity provider Once the correct credentials have been passed in the identity provider knows that uh, you are who you say you are So it can then generate a An authorization code an orth code And they'll send this orth code as a response back to your browser So this orth code goes to your browser as a redirect a 302 redirect to the application to your application So your application has now received this orth code which comes through as part of the query string And you can then take that orth code now at this point this orth code has no identifiable information in it at all It's basically a random string That is associated with my login or whoever's just logged in Over in the identity provider here. So having just logged in it's created essentially a session uh with me To the domain that the identity provider is sitting on and it says okay. I'm going to generate this orth code I'm going to remember that this this orth code was generated for ben because he just logged in So your application now has the orth code and it's able to take the orth code and now the client's secret And it'll send those to orth zero whichever identity provider you're using It'll send though because it's all standardized um protocols It'll take those two bits of information and it'll say hey, I've got this orth code Here's my client secret in order to prove that I am who I say I am I'd like to exchange this orth code for some tokens So the identity provider will then take that orth code and say okay Well, I know this orth code was generated for ben So i'm going to generate some tokens for ben It's going to generate an id token and an access token and perhaps also a refresh token And it'll then send those tokens back And because this request was made by post A post request the data that gets returned is wrapped up inside the payload of a post response Which means it's never going to appear in any query strings. It won't appear in any logs It's a Pretty secure way of passing those tokens back to your application Your application now has an access token and an id token Which will allow it to know who's logged in and potentially with that access token start accessing other bits of information as well Now I mentioned the user info endpoint There is still a user info endpoint at the identity provider Which will give you the information that's inside the identity token but by default nowadays The identity token is returned as well as part of this I want some tokens request because it's inevitable You're going to want it so we might as well send it the first time But you could also call that endpoint to get information further down the track So how do these tokens look like they they're called json web tokens or JWTs Some people will call them jots. I think the the official specification says the pronunciation of JWT is jot I personally have a huge objection to this because I think it's ridiculous if you disagree with me. Let me know We can have an argument about that. It sounds like fun No, it's only a pronunciation But yeah json web tokens are basically tokens for the web that contain json Um, if you haven't seen what a json web token looks like on the inside, let's go and have a look That's what a json web token looks like make sense Okay, we'll move along In a normal conference scenario, I'd see your faces and hopefully you'll be laughing at this point It's always hard when you're doing it from home So I'm going to assume you laughed at my joke and I'll go straight on to the okay Well, let's have a look a little bit more in depth At what a json web token looks like I'll color coded and I'll just highlight these two punctuation marks The full stops So there are three components to a json web token. The red part of the top is the header The purplish light purple part in the middle is the payload and then we have the yellow part at the end Which is actually more green. I don't know what it looks like to you Uh, that's the signature and they're separated by full stops The first and second parts are base 64 URL encoded. In fact, the third part is as well But the first and second parts are base 64 URL encoded json So we could essentially just take this run it through a base 64 URL decoder and get the json straight out There's no encryption. There's no protection. If somebody gets access to any token They can read it. I mean humans would probably need to use a decoder. I can't read this That's why I have this screen here, which tells you what's actually inside it So the header has typically at least two key value pairs The first one that's in there is usually the type. I mean not necessarily in that order Um but uh The type is json web token in this case now the idea here Obviously, it's json web token. We wouldn't know that if we didn't know it was a json web token because otherwise we we would Not have decoded it as a json web token So instead what we we could do in the future is we can have json web token types And we can add like the plus addressing in the same way as you have Um Content types that have pluses in them to break down the kind of json web token. It is so it's built for future Um flexibility The algorithm is important though. So this is telling us that we're using an hmax char 256 hashing algorithm In order to create the signature Uh, I won't go into depth into what the different algorithms are hmax char 256 is a pre-shared key basis So every application is going to have to know the key for generating the the signature There's also rs or rsa char 256, which is a public private key mechanism Which is arguably Stronger and safer because then you can just share a public key with anybody and they can verify the signature is valid And then the payload itself has the subject I mentioned before that there's this one key that you can use to know who's logged in Every time I log in in the future the subject will always be the same if I change my email address If I change my password if I change my username any of these things my subject will always be the same This is the unique idea when you consume an identity token into your application You can rely on that subject as an identity Link in your user database. So if you've got your own database of users You store the subject in there not a username or password And then the signature part if you look down at the bottom here, we've got this assertion So basically we take the header that we had and the subject we can catnate them We base 64 you are all in code the result of the hashing algorithm in this case the hmax char 256 So if we take this and we we share it and then we base 64 you're encoded with that pre-shared key that all the applications would need Then that is going to produce a signature And if the signature matches the signature here, which is the signature that came in the original token Then we can trust that the header and the payload haven't changed It's how most signatures work, but that's how it works for a json web token Now other kinds of json web tokens i've mentioned are access tokens and access tokens give you different bits of information This is not about the user's identity. This is about what the bearer of the token can do on behalf of that user So if i log in to your application your application gets an access token You can use this token against apis in the ecosystem That that are defined as essentially audiences and you can see in here. There's an audience On that third line there An audience is an api or an endpoint for whom an access token is intended to be consumed So you wouldn't consume an access token that's not designed for your system You've got an issuer. So, you know who created it got the subject again So even without the identity token you can make a request to an api and the api knows Who has made the request or who the user is that the token was generated for that's making the request You have an iat is the issued at exp is the expiry. So you have Timestamps and then we've got those scopes that i've mentioned. So sometimes they If you're looking at third party connections to third party apis, you'll be using scopes more Otherwise, you might use a permissions array, but again, this is jason. So you can put whatever you want in there and then consume that at the end point all right, so the title promised beyond and the next screen is a little more Conceptual. So let's just jump straight into it. We have An example here where you might have you've got your user on the left here And I hope you can see my my mouse moving on your screens Sometimes there's a little too small and vague But the the the user object at the top left here Is basically the the person who's trying to log in On the right in the middle, we've got or zero or the identity server and all around we've got all of this communication going through and this is just requests between systems So you might have your web application here talking to a database you can have an api also talking to a database You can have a mobile phone app that talks to the database via an api connection You've got your your desktop app the the web app that could be talking to the api via ajax while also getting information from So you're familiar with complex situations like this when it comes to authorization and making sure that when the The web application is talking to the api that it's doing it on behalf of the correct user Without having to to share Credentials or imply any kind of implicit trust Because if the web application talked to the api without using the user's credentials The api would have to just trust that any request from the web application is safe Not necessarily a great idea. We can use access tokens at this point as well So the access token can be generated by your identity provider You'll notice that the orange lines here from the mobile phone and from the The web app here these are the login flows and these send the credentials and they only ever get sent to the identity provider So the credentials are never shared with any other application The identity provider can exchange with an active directory service for example in order to make sure the person who's logging in is using credentials from active directory So you can do a single sign-on perhaps There's all sorts of possibilities of how you can Design your ecosystem of applications services service oriented architecture or monolithic however you decide but without having to to focus on the credential storage and management and the Transmission of those credentials between systems json web tokens by themselves even outside of the scope of an of an identity provider can Can alleviate a lot of those issues and then within the scope of an identity provider as well Because identity Open id connect identity providers will use json web tokens as part of the spec It's an easy way to integrate all of these disparate systems and have a consistent underlying mechanism for Conveying who the user is in all of these requests that are going on So it's a bit of a massive bird's eye overview this one here But I wanted to point out that it's not just about logging in at the very least if you're starting off with your A new application and it's a pet project or it's a new application at work a new project you're working on Stick an oath open id connect authentication mechanism in at the beginning Because when you scale and you get to this point You don't want to be thinking in the future about how to how to deal with this communication mechanism In a secure way if you're using tokens already from the beginning makes your scale journey a lot easier That's all I have to talk about During this session. I'm happy to take questions as I mentioned So thank you for your time if you want to get in touch with me. I'm on most of the social medias at ben decry And my twitter dms are open if you have any feedback on this talk. We're giving away t-shirts to anybody provides feedback um So if you go to well not anybody you've provided feedback, but if you um if you go to a zero dot two slash feedback dash ben There's a form there that you can fill out to make sure you select my name so that we know that it's about me And it's just good to know the kind of people in your audience What's working if there's any way we can explain things better? And you'll go into a draw. We'll do a monthly draw for a t-shirt And if you want to learn more from me, I'm I talk about security and related tech web development Platforms and and and products. I'm on youtube as well. So I'd love you to follow me over there and and stay in touch Thank you for your time Thank you Ben. Thanks a lot. We have a lot of engagement on Chat on hopping chat. Lovely So I filtered out two questions from that So you shared two different Diagrams one is before the beyond slides and one is after the beyond slide So when you were taking the diagram explaining the diagram before the diagram slide Which was fairly very simple only the authentication part between the third party and the odd zero So the question came during that This is the authentication one. So this one is here. Yeah, this one this one So the question goes from the diagram. I can see there are many requests getting redirected Will it will not that cost loan is in my application? Not really. So remember this is only the login component the redirect There's only two redirects. The first one is when you make a request Imagine your application is going to send a 401 unauthorized instead of a 401 unauthorized is going to send a 302 redirect to the login So that's the first part is logging in and then the second redirect is getting the access The authorization code back to your application So there are two redirects that happen in the open id connect login process Once your application has the token This this no longer happens Everything just goes on as normal. You've now got a token and an id token an access token and an id token So you know who I am I'm logged in so during the login process only you'll get two redirects And it's not going to add that much overhead Good and we have the next question are jwt similar to csrf tokens Uh, they have very different purposes. So jwt itself. It's a token. It doesn't necessarily have to be for Identity or access tokens jwt's by themselves are a a standard that allows you to encapsulate a payload and transport it or send it to somebody In a way that they can then verify and by they I mean like a system Not a human Verify with the signature that the payload hasn't been modified So it's basically a way of sending and the the technical term in json web tokens is the stuff inside the payload is a set of claims I'm claiming that my name has been I'm claiming that the issue the token was issued at this time and the signature verifies that these claims are correct So json web token is basically a way of sending claims in a way that you can verify. They haven't been modified in transit a csrf token is a Random string that that's part of a form submission That gets checked against a a session in order to make sure that a form is submitted from the the same browser that it was rendered to so that you can't get Cross-site requests coming through and correctly essentially So while csrf tokens Are an important part of the login page in order to verify that there's no attacks in terms of attacking these forms The json web token itself is just a way of transporting verified data around I hope that Explains the difference between the two So we have one last question. What is your view regarding key cloak? I used key cloak once about five Years ago, I think so any changes to key cloak since then um I can't speak about But I I come from a php background originally so key cloak wasn't necessarily natively comfortable for me I found the configuration was quite complicated and But the thing is that I also know people who who have worked on the project who use the project and once it's up and running It's quite stable as I understand it. I've never really gotten to the point where I got it working But that might just be me The thing with key cloak though is that it is an application that you are hosting yourself So that's something you want to take on. That's fine. One of the things one of the reasons why I always recommend people use something like auth zero or strike for payments or any of these as a service providers is The application that you're writing unless you want to be an identity provider Your key benefit is in writing software that makes Your application better for your users Writing better identity is not going to make it better for your users And even hosting your own identity is not going to make it better for your users if you can outsource that And not have to worry about it. You can save in terms of maintenance one example Atlassian came over towards zero a couple of years ago and all of the Atlassian logins are now through us I hear different numbers depending on which person within the organization. I talked to but Let's let's pick one of the numbers that I heard ones There were 13 people working in the identity team at Atlassian Those 13 staff were able to work on new features and fixing bugs and various other business as usual Aspects of the product. So suddenly Atlassian was able to concentrate more on making his products better Rather than focusing all their time or 13 people's time on identity because they were able to outsource that So there's always a pro and con to hosting your own Thanks for being a bit out of time and We have great comments on the on the chat and people are appreciating your talk and And I guess all the questions that you have taken The people who asked the question as have the flight that they've got to your answer and they really liked it Thanks a lot. Thank you And I'll jump in and I'll have a look at the questions as well now And if anybody wants to ask me anymore, I'm going to jump into the author of booth And we can carry on a conversation there if you want Great. Thanks a lot man. All right. Thank you. Take care. Bye. Bye